[postgis-users] Re: when rasters in Postgis?
pramsey at refractions.net
Mon Sep 26 18:42:56 PDT 2005
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.
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
> 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
> not tiles of data).
More information about the postgis-users