<!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>