[postgis-users] Re: Proposed SQL interface for PGRaster

[Patrick]

"Stephen Marshall" <smarshall at wsi.com> wrote in message 
news:4575AEDC.5030506 at wsi.com...
>I have written a proposal for the SQL interface to PGRaster, a raster-in-DB 
>implementation.  The document can be found on the PostGIS Wiki at
>
> http://postgis.refractions.net/support/wiki/index.php?PgRasterSqlInterface
>
Hi Steve,

That looks like fine piece of work. Thanks for the effort.

After (rather cursory) reading of the pages I have two immediate points of 
attention:

1. There is no mention yet of any kind of tiling or compression of the data. 
Rasters are easily larger than a page size and some form of design has to be 
applied to it, because the default TOAST approach is clearly too slow and 
the same goes for the lo_ interface IIRC.

2. IMHO rasters are a logical collation of thematically related data sharing 
a common geometry (regular tesselation and CRS). The data itself is 
organized in raster bands, where each raster has 1 or more raster bands. 
This concept is immediately obvious for satellite imagery, but the TIFF 
format also uses a similar concept for instance. Such a design adds a level 
of flexibility at the application level and most software already supports 
this design. The raster band has a certain data type and a single raster can 
have bands with different data types. The resolution of the pixels can 
either be fixed at the level of the raster (all bands having the same 
resolution) or at the level of the raster band. The latter situation is of 
course more flexible and some satellite imagery has this characteristics 
(e.g. Landsat ETM+ data, ASTER data), but it complicates indexing and 
processing of data (e.g. extracting and sending a cube of data to, say, R 
for processing). Up for debate, I'd say.

Cheers,
Patrick