Hi Even,
Thank you, now I get it, and that would work well I think.
Would the next step be for me to prepare a PR based on this?
Kind regards, Alex
________________________________
From: Even Rouault <even.roua...@spatialys.com>
Sent: 06 July 2025 23:13
To: Alex Hagen-Zanker <alexhigh...@hotmail.com>; gdal-dev@lists.osgeo.org
<gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Random Raster Driver
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
