On Thu, Jun 30, 2011 at 9:30 PM, Pierre Racine <span dir="ltr"><<a href="mailto:Pierre.Racine@sbf.ulaval.ca">Pierre.Racine@sbf.ulaval.ca</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
We agree that your main reasons to plug GDAL there are:<br>
<br>
a) Profit from the GDAL tile mechanism to optimize big one row rasters access<br>
<br>
b) Implement transparent access to out-db rasters<br>
<br>
Right?<br></blockquote><div><br>Correct.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Two observations:<br>
<br>
-It might be long/difficult/impossible to implement a TOAST GDAL driver.<br>
-For sure that will destabilize the code base.<br></blockquote><div><br>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.<br>
<br>The majority of the code in rt_api.c manipulates raster or band header data. Header data should not be affected by tiling.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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).<br>
</blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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).<br></blockquote><div><br>Just out of curiousity, what is the status of support for out-database rasters?<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
For sure we need to know more on the possibilities to make a GDAL TOAST driver before... I'll poke Sandro...<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>+1 <br><br>Bryce<br></div></div>