[OSGeo-Discuss] Image Handling in RDBMS

[P Kishor]

On 2/22/08, Gilberto Camara <gilberto.camara at inpe.br> wrote:
> Dear OSGEO
>
>  I also beg to differ with Paul about the number of cases where image data handling in RDBMS is useful or necessary.
>
>  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.
>
>  Our TerraAmazon system (presented in the latest FOSS4G conference) does this, and we handle large files without problems.
>
>  For one-way image servers, on a write once, read mostly basis, then the case for handling raster data inside the DBMS is less clear. Since the output is an image delivered to the user, either as a file or as a visualization, DBMS features such as concurrency control and long transactions are not needed. Performance is more important than control in this case.

And, *that*, my dear all, is really the key. I think what Bruce B has
also been saying is that there can be use cases in which storing
images in a db can make sense. From a recent post by the creator of my
favorite database, regarding storing and speed of accessing BLOBs in a
db as opposed to BLOBs on the filesystem and their metadata in the db,
I quote

> One would think.  And yet experiments suggest otherwise.  It
> turns out to be faster to read images directly out of SQLite
> BLOBs until the image gets up to about 15KB on windows and
> up to about 60KB on linux.  And even for much larger images,
> the performance difference between reading from SQLite and
> reading from a file is not that great, so it is a reasonable
> thing to do to read from SQLite if transactions are important
> to you or if it is just more convenient.

The last sentence fragment, "if transactions are important..." is the key here.

Of course, your mileage may vary, and do your own due diligence to
decide when to store images in the db instead of on the filesystem. If
the db can take care of indexing images for you so you can retrieve
only desired portions of the image, if the db can take care of
figuring out where and how to store the images on the hard disk, if
the db can take care of the boring but essential admin tasks such as
backups and restores for you, definitely use a db.

That brings us back to PostGIS supporting images. Clearly, most folks
who use it don't see it worth the effort implementing. I suggest two
things --

one. This being open source, Bruce and others, start developing the
capabilities and contribute it back to the PostGIS project as an
add-on. Many like you, the silent ones, would appreciate it.

two. Again, Bruce, you summed up the thread in another email -- might
I suggest that you add the pros and cons of storing images in a db to
the edu-OSGeo wiki as a presentation/decision-making aid so other data
managers evaluating this issue have a valuable resource to lean on.

Open source folks are nothing if not opinionated. Makes for a great
conversation just about anything. Thanks.




>
>  Best regards,
>  Gilberto
>
> --
>  ===========================================
>  Dr.Gilberto Camara
>  Director General
>  National Institute for Space Research (INPE)
>  Sao Jose dos Campos, Brazil
> _______________________________________________
>  Discuss mailing list
>  Discuss at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/discuss
>
>


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/
Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/