[postgis-devel] [raster] Strategizing and specifications

[Bryce L Nordgren]

On Thu, Jun 30, 2011 at 6:46 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

>
> 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?
>


> 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.


That's my intent. :)


> 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?
>

Well for the near term, I'd plan on using GDAL mostly for data access. As
long as the accessors in rt_api.c use GDAL, and the algortihms in rt_api.c
use the accessors, the existing algorithms should work. (e.g., histogram,
quantile, etc.) Once this is in place, we can implement algorithms in SQL,
rt_api.c, or in the GDAL library, as appropriate.


> > 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.
>

My preferences are often stolen from those who are smarter than me. :)
Certainly, this is the first question we need to have answered.

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110630/9714b709/attachment.html>