[postgis-devel] [raster] Strategizing and specifications

[Pierre Racine]

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

We agree that your main reasons to plug GDAL there are:

a) Profit from the GDAL tile mechanism to optimize big one row rasters access

b) Implement transparent access to out-db rasters

Right?

Two observations: 

-It might be long/difficult/impossible to implement a TOAST GDAL driver. 
-For sure that will destabilize the code base.

I see an alternative strategies to this:

For a) you modify the code base in order to store raster band data by block instead of as big arrays (so you don't rely on GDAL for tiling of internal rasters... and you don't destabilize the code base too much).

For b) you plug GDAL everywhere necessary in the existing code base for external rasters (there are already plenty of slut for this in the code and that was already the plan).

I understand that having GDAL as the only raster access code base is very elegant (fast?). But isn't that alternative more realistic? For sure we need to know more on the possibilities to make a GDAL TOAST driver before... I'll poke Sandro...

Pierre