On Feb 22, 2008, at 2:26 AM, Gilberto Camara wrote:
In corporate applications where vectors and raster live together, and data processing and editing operations are used, handling different types of data together in a database is convenient. Control is more important than performance.
Agreed, vector->raster, raster->vector operations and associated raster analysis operations in the database (GRASS-in-the-database, for lack of a better term) is something I find compelling, for the same reason that non-storage-oriented functions like ST_Buffer() and ST_Union() in the database are compelling. Database as fully functional analysis platform. All your base are belong to SQL.
Unfortunately, most people talking raster-in-database are focussed on stuffing their imagery in, and can articulate no real reason for doing so. It'll be faster? (no) It'll be safer? (no) It'll be easier to manage? (no)
On Feb 22, 2008, at 7:13 AM, P Kishor wrote:
If the db can take care of indexing images for you so you can retrieve only desired portions of the image,
Images are regular grids. I don't need an index to know that the center pixel of a 1000x1000 image is at byte 500000. Indexes don't speed up image access, because images are already regularly organized. The image *is* the index.
if the db can take care of figuring out where and how to store the images on the hard disk,
No, it'll just write it into a data file, and the file system will end up locating it on disk. Cluster your table, and you still end up with physical data locality no better than simply using the TILED option of GDAL in writing out a TIFF.
if the db can take care of the boring but essential admin tasks such as backups and restores for you, definitely use a db.
Databases are no easier to backup than file systems. Harder, in my opinion, and that's from a guy who loves databases.
Can I ever let go of this topic? (no) It's pathological. Stop me, please. -- Paul Ramsey [EMAIL PROTECTED] +1 250 885 0632 _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
