[OSGeo-Discuss] Image Management in an RDBMS...(was OS Spatial environment 'sizing')

[Paul Ramsey]

All too often, the "benefits" touted for raster-in-database have  
nothing to do with the database, and everything to do with the data  
preparation tools that the vendor is including with their raster-in- 
database solution.

To store rasters in a database, you need a set of tools that will (a)  
chop the inputs into something small enough to fit on a database page  
(tiling), (b) pyramid the source data up so you don't have to run re- 
sampling operations on the fly, and (c) handle mosaicking operations  
at the edges of source input files.

Here's how to do all of this stuff without the database:

On Feb 20, 2008, at 4:29 PM, Bruce.Bannerman at dpi.vic.gov.au wrote:

> - store a relatively large amount imagery and utilise it as a single  
> entity (e.g. a layer).

Use a web service to expose the data, such as WMS. You can view your  
WMS in ArcMap, in Google Earth, in a web browser typing in a URL with  
your toes.

Far more interoperable than raster-in-database client code, because it  
is far simpler.

Using Mapserver, and a tile-indexed raster layer, you can publish a  
seamless view of as many source files as you like.  (Chris Hodgson did  
it for over 1000 source files, see http://mapserver.gis.umn.edu/community/conferences/MUM3/present/session2/hodgson/view)

> - only retrieve the records (tiles) required for the geographic area  
> being viewed. That is
>   we did not need to load the entire mosaic into memory, just stream  
> the records required.

Exactly what the tile-indexed raster collection does.  When the  
rasters that are indexed are themselves internally tiled (using the  
TIFF internal tiling scheme) the effect is identical to the chunked  
database approach.

> - only utilised an appropriate image sample for the viewing scale  
> utilised via the pyramid
>   layers (a common technique used by RS products).

For the large scale tile-indexed approach a combination of pyramiding  
the source files, and creating a pyramided master mosaic for super- 
overviews achieves this.

> - if required, add additional data to the mosaic.

Add new file to directory, re-run master mosaic process.

> - take advantage of corporate data management techniques as  
> discussed previously.

Why people think backing up databases is easier than backing up  
directories is beyond me. Doesn't your IT department back up files?  I  
know personally I would rather back up a huge file system, than a huge  
database table space.  There are way more tool options and way less  
complexity.

Anyhow, the tools for loading and pyramiding that the raster-in- 
database vendors provide are indubitably helpful in preparing the  
data, but the database itself adds nothing, zip, bupkus, to the value  
equation.  And the same stuff the vendor tools do can be done with  
GDAL and Mapserver and little else.

And I hope someone wants to have a performance run-off.

Go ahead, punk. Make my day.

:)

P.



--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632