[postgis-users] Re: rasters in PostGIS...

[Patrick]

I don't easily get excited by news group posts, but this one really got 
me...

"Chapman, Martin" <MChapman at sanz.com> wrote in message 
news:ED3A48B9840E594890A2BC172D11946502F9C0AC at mailman.san.com...
> On another note, it's a bad idea to store rasters in an RDMS in general.

You mean to say (I hope) that "in your humble opinion there might be some 
arguments that indicate that storing raster data in an RDBMS may not be an 
altogether good thing". Just to get the nuance in there.

> Databases do not handle BLOB data efficiently.  A better solution is to
> store your rasters on a file system and keep path information in the
> database in order to access your image data.  There are numerous reasons
> this is better.  Listed below are just a few:
>
> 1.  Your database will be faster and easier to manage.
> 2.  Your database will scale much easier.

??? I'd like to see some arguments on these two issues.

> 3.  You will require less fast disk for your db.  Rasters can be stored
> on tape, while your db can run on expensive fast disk.

Tape???? HDD sell for less than a $/GB nowadays and tape *systems* (meaning 
jukeboxes to match HDD capacity) are many times more expensive than any HDD 
system. TB RAID arrays can be bought for under $10K from multiple vendors.

> 4.  You can open images with other application like ArcMap, Erdas, that
> have no knowledge of how to access raster data in a database without a
> specific driver.

The same was true when PostGIS first appeared with support for vector data 
only. With the ascent of a user community came the applications. If raster 
data are to be included in PostGIS you can safely assume that applications 
will support it before the blink of an eye, given the large number of 
PostGIS users right now.

> 5.  Easier and faster to ingest rasters into your application.  If you
> store rasters in a database you will have to copy all image data when
> importing into the database.  This can take a long time and require a
> lot of cpu power/ram/disk space.

This is a complete non-argument. Storing data in an RDBMS simply adds 
another format to the already long list of formats. There is some overhead, 
no doubt, but there are also many, many advantages.

> 6.  Some databases, like SDE, actually split the image into tiles, which
> means your data is rendered useless from a scientific perspective,
> because once an image is clipped, you can never get the real image back,
> because pixels are changed/lossed in the clipping/mosaicking process.

As a scientist, I can tell that you are not.

Clipping or mosaicking has nothing to do with data loss; compression may be 
lossy, but even that is not necessarily so. Many spatial analysis functions 
actually work on a local kernel of data (e.g. slope function, hydrological 
functions, filters in image processing, local statistics, etc), which goes 
along very nicely with tiled raster data and with no problem to cross tile 
boundaries.

> 7.  If your database size gets too big...it may be a lengthy, if not
> impossible task to back up the database.

Sure, backing up a TB-sized database involves a little more work than a GB 
database, but the raster data needs to be backed up anyways, whether it is 
in or outside of the database. If it is all under one umbrella, the backup 
system would need to be less complicated if you ask me...

So what exactly were your arguments?

Patrick