On 20-Feb-08, at 4:29 PM, [EMAIL PROTECTED] wrote:
- When you consider the complexities that Google must be facing
with GE in trying to manage 256x256k tiles of imagery over the
entire world, at multiple pyramid layers and with constant revision
of imagery, you can soon see that a file based approach would lead
to a major headache.
Hi Bruce,
Am I correct in believing that the two things people desire with
images in an RDB, is having an abstract 1) storage framework
(tables) and 2) a common access language (SQL) for managing the
framework. You could have the most complex storage set up behind
the scenes, but as long as the access interface plays well, the
complexity could be minimised by good UI design. At least I think
so, but haven't done it before.
However, I did manage massive (at the time) amounts of vector files
in the file system, and was dreaming about using a db. All the while
I watched some others make the wholesale shift to vectors in a
transactional db. I grimaced when asking them for data, only to wait
while they batched up an SQL request to extract back into files --
what used to be a simple copy command to move a zip file into an FTP
folder. I admired their commitment, but was frustrated by usability
in the end (as were they). It was good food for thought nonetheless
as I planned my own vector-in-db direction :)
Some more recent raster in db discussion here:
http://spatialgalaxy.net/2008/02/15/rasters-in-the-database-why-bother/
Tyler
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
