[gdal-dev] Random Raster Driver

[Alex Hagen-Zanker]

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.rouault at spatialys.com>
Sent: 06 July 2025 23:13
To: Alex Hagen-Zanker <alexhighviz at hotmail.com>; gdal-dev at lists.osgeo.org <gdal-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250707/b18e3bfc/attachment.htm>