<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Alex,<br>
    <blockquote type="cite"
cite="mid:GV1P251MB0747DA6663DE56DC79F5788BB44CA@GV1P251MB0747.EURP251.PROD.OUTLOOK.COM">
      <div
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof">
        <br>
      </div>
      <div
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof">
        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. </div>
    </blockquote>
    <p>No, my suggestion was to do that only when one of the random
      pixel functions is used.<br>
    </p>
    <blockquote type="cite"
cite="mid:GV1P251MB0747DA6663DE56DC79F5788BB44CA@GV1P251MB0747.EURP251.PROD.OUTLOOK.COM">
      <div
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof">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.  <br>
      </div>
    </blockquote>
    Yes<br>
    <blockquote type="cite"
cite="mid:GV1P251MB0747DA6663DE56DC79F5788BB44CA@GV1P251MB0747.EURP251.PROD.OUTLOOK.COM">
      <div
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof">
        <br>
      </div>
      <div
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof">
        Looking at VRTDerivedRasterband I was surprised that it
        implements IRasterIO rather than IReadBlock.</div>
    </blockquote>
    <p>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.</p>
    <blockquote type="cite"
cite="mid:GV1P251MB0747DA6663DE56DC79F5788BB44CA@GV1P251MB0747.EURP251.PROD.OUTLOOK.COM">
      <div
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof"> 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.</div>
    </blockquote>
    <p>basically what I'm suggesting is something along those lines:</p>
    <p>CPLErr VRTDerivedRasterBand::IRasterIO(.... )<br>
      {<br>
            if( use_one_of_the_random_functions )<br>
                  return GDALRasterBand::IRasterIO( ... );  // force
      base method to IReadBlock(), which will go to
      VRTSourcedRasterBand::IReadBlock() which will call us again, but
      on block boundaries<br>
      <br>
            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</p>
    <p>}<br>
    </p>
    <p>Even</p>
    <br>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>