[postgis-devel] [raster] Strategizing and specifications

Pierre Racine Pierre.Racine at sbf.ulaval.ca
Thu Jun 30 11:46:59 PDT 2011


> The backend: select a back end for in-database rasters. The back end must
> support loading part of a raster. I would prefer a strategy which leverages the
> current backend (TOAST), if TOAST can be made to load a partial raster.
> 
> The API: select an API for efficient raster access. I would prefer a strategy which
> leverages an existing API, preferably an API which does not add dependencies to
> postgis raster. A strategy which involves developing a GDAL driver for the
> selected backend would be ideal. This API does not need to be exposed to the
> end user.

So if I understand well you would like to "plug" GDAL between rt_api.c and the disk serialized PostGIS rasters? Am I understanding well here?

> Uniformity and ease of maintenance: the preferred strategy would treat in-
> database and out-database rasters exactly the same. This is another preference
> for developing a GDAL driver for in-database rasters, since GDAL will be used for
> out-database rasters. Ideally, the postgis raster codebase (operations,
> accessors, etc.) will not have to be aware of the difference.

For sure, from what I understand, if GDAL underlays rt_api.c, that the raster is serialized in a PostgreSQL TOAST or is stored as a TIFF in the file system should be transparent. So GDAL would really become to PostGIS raster what GEOS is to PostGIS GEOMETRY (and even more since it would allows transparent operation on out db rasters). I often dreamed of that. GDAL certainly provide a nice abstraction layer for that but one reticence I always had about using GDAL is that it does not provide many raster algorytms. What would be a real analysis library for raster equivalent to GEOS for vector?

> No impact on existing functionality: all existing raster capabilities should be
> unaffected.

:-)

> 	-If you want this to be part of PostGIS 2.0 you must implement it quick
> and make sure it is VERY stable before the release (September - October).
> Otherwise it will have to wait for PostGIS 3.0 in a couple of years because a
> dump of stored rasters will be necessary. (Maybe not if your modifications
> supports the present not tiled rasters?)
> 
> Strategizers: this is why I'd prefer the TOAST backend if possible. Can we make a
> GDAL driver that understands TOAST slices?

Paul Ramsey already suggested that... I must say I don't know the PostgreSQL internals enough to answer the question. Sandro would probably the guy to answer this. He wrote the code base of PostGIS raster.

Pierre




More information about the postgis-devel mailing list