[postgis-users] Re: when rasters in Postgis?

[Paul Ramsey]

Thank you Patrick :) !!! It takes a raster geek to note that stuffing  
data traditionally stored in multi-gigabyte files into a RDBMS does  
not necessarily buy you *anything* of use.  And doing it well  
involves a lot of trade offs.  In order for the database to perform  
at random access of the data, it must be cut up into chunks of less  
than the page size. So everything going in must be pre-processed. So  
there's a format conversion step on the way in. And hopefully you  
also push everything into the same SRS.

And when you're done, what do you do with it?  Let me guess, now you  
want mapserver support or some kind of commandline support to pull  
the stuff out into mosaics... Which is nothing more than what you can  
do with mapserver and a bunch of TIFFs.

I have a huge problem with "raster in the database" because I do not  
believe it has any practical purpose.  ESRI promotes it primarily as  
a way to sell ArcSDE licenses, but this has led to a widespread  
belief in the geospatial community that putting raster imagery into a  
database is actually a useful exercise, not the masturbatory waste of  
time it really is.

Buy a lot of disks. Convert your imagery to TIFF and create internal  
pyramids (gdal will do all this for you). Create a tileindex, either  
in shape or in postgis if you have some other programmatic use for  
the index. Put mapserver on top of it and serve it as a WMS.  Want a  
mosaic?  Run a simply curl call on it for the area and size you  
want.  Want to see it in your GIS desktop (ArcMap, uDig, JUMP,  
whathaveyou)? Point the thing at the WMS and you have instant tiled  
complete imagery coverage within your application.

But please, god, don't stuff images into your database.

Paul

On 25-Sep-05, at 1:30 PM, Patrick wrote:
>
> Considering the traditional mismatch in granularity between raster  
> data and
> database storage, the challenge is in devising an efficient storage  
> design
> that does justice to both. That design would no doubt be based on  
> some form
> of tiling of the data, but then new issues surface, such as how to  
> deal with
> the diverse input formats, how to deal with reprojection, and how  
> to present
> data in response to queries (where most user programs expect entire  
> rasters,
> not tiles of data).