[postgis-devel] [raster] About recent commit r8313

dustymugs dustymugs at gmail.com
Wed Dec 7 10:13:35 PST 2011


On 12/07/2011 09:49 AM, Mateusz Łoskot wrote:
> Folks,
>
> If I may, I'd like to gently complain about the recent change in the
> raster part:
>
> http://trac.osgeo.org/postgis/changeset/8313
>
> Do we really want this change?
> In my opinion, it is not a good idea for the best performance possible.
>
> The natural block concept is there for purpose and operating on larger strips
> performs better.
>
> I had a quick talk with Frank and, I hope Frank does not mind me quoting him,
> there is another issue:
>
> "It was my understanding/hope that postgis raster would be highly optimized
> for the postgis regular blocking case and I had hoped that in at least
> some cases that
> would be setup to map 1:1 to regular blocking in source or destination
> GDAL files.
> This certainly discards any hope of such optimization in this api."
>
> Best regards,

I made this change because of an issue I was experiencing using 
"natural" blocks and specific rasters in the rt_resample regression 
test.  Though the "natural" blocks worked perfectly fine in every other 
regression test, I had two rasters in rt_resample that would fail.  This 
can be seen using r8309 and raster 1.15 in the rt_resample regression test.

I can prevent the failure seen in r8309 by restricting the width and 
height of the region being accessed for each pass of GDALRasterIO to 
just the valid area (see r8310).  But this goes counter to the docs 
(http://gdal.org/gdal_tutorial.html):

"The nXOff, nYOff, nXSize, nYSize argument describe the window of raster 
data on disk to read (or write). It doesn't have to fall on tile 
boundaries though access may be more efficient if it does."

I can also eliminate the error for the same raster 1.15 if I copy the 
entire band in one GDALRasterIO call.

This error occurred in all my test environments (Linux 32 (GDAL r23448) 
and 64 bit (GDAL r23478) and OX 64-bit (GDAL r23478)).  So, to just 
eliminate the possibility of having the bug, I refactored the code to 
use scanlines instead.

-bborie



More information about the postgis-devel mailing list