[OSGeo-Discuss] Image Management in an RDBMS...(was OS Spatial environment 'sizing')

[Tyler Mitchell (OSGeo)]

On 20-Feb-08, at 4:29 PM, Bruce.Bannerman at dpi.vic.gov.au 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