[postgis-devel] [raster] Strategizing and specifications

[Bryce L Nordgren]

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

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

Correct.


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

Since "changes" are a probability, either now or in the future, I think it
makes sense to enforce strict encapsulation of raster access in all of the C
code. By this I mean that NO CODE should be allowed to directly manipulate
band data in the memory buffers. All changes are thru rt_band_set_pixel, and
all accesses are thru rt_band_get_pixel. No exceptions. Ideally this is
already the case, but we have a good reason to make very sure. When we
switch over to GDAL, the damage control teams will have a very well defined
area upon which to focus their attention.

The majority of the code in rt_api.c manipulates raster or band header data.
Header data should not be affected by tiling.


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

I think any fundamental change to the structure of the band data buffer
stands an equal chance of destabilizing the code base. I would suggest
leveraging the "version" field to the in-database raster header. The current
version 0 stands for the existing format. Whatever comes next will be
version 1. No clients ever need access to this field, but
rt_band_set_pixel/rt_band_get_pixel can use it to correctly perform their
duties. The key is to limit the impact to a manageable subset of the
codebase.


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

Just out of curiousity, what is the status of support for out-database
rasters?


>
> For sure we need to know more on the possibilities to make a GDAL TOAST
> driver before... I'll poke Sandro...
>
>
+1

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