Alex,
I am not sure if I understand your suggestion correctly. Are you
suggesting to change the behaviour or VRT DerivedRasterBand in general
so that its IRasterIO would only work on block boundaries? That seems
quite drastic to me.
No, my suggestion was to do that only when one of the random pixel
functions is used.
I think there would be a few more minor adaptations necessary for
VRTDerivedRasterBand so that it can accept that there are zero source
layers for the pixel function.
Yes
Looking at VRTDerivedRasterband I was surprised that it implements
IRasterIO rather than IReadBlock.
The base class VRTSourcedRasterBand has a IReadBlock() method that
forwards to IRasterIO(). That way you get both the caching effect if
block based reading is done and goes through IReadBlock(), or if
VRTDerivedRasterBand::IRasterIO() is directly called, it is short circuited.
If you indeed meant to restrict IRasterIO to block boundaries in
general, would it be a consideration to implement it as IReadBlock and
use default behaviour for IRasterIO? From my understanding that would
change the way the caching works, as it would cache the results of the
pixel function rather than the input to the pixel function. It would
also allow RasterIO to still be used as it currently is.
basically what I'm suggesting is something along those lines:
CPLErr VRTDerivedRasterBand::IRasterIO(.... )
{
if( use_one_of_the_random_functions )
return GDALRasterBand::IRasterIO( ... ); // force base
method to IReadBlock(), which will go to
VRTSourcedRasterBand::IReadBlock() which will call us again, but on
block boundaries
rest of the method mostly unchanged. You'll need to pass the
nXOff and nYOff arguments as arguments of the random pixel functions,
around lines 1580-1590
}
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
