[gdal-dev] Random Raster Driver

[Even Rouault]

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/b61ca27e/attachment-0001.htm>