Hi Jorge,<br><br>What I have in my mind is something like the DirectRasterIO implementation in WCSDataset / WCSRasterBand (see wcsdataset.cpp). It appears that this driver is suffering from the same issue, and intend to minimize the roundtrips to the server as much as possible. It looks like this direct implementation doesn't rely on IReadBlock called by an upper level IRasterIO therefore the RasterBlock cache is also omitted in this case.<br>
<br><br>Best regards,<br><br>Tamas<br><br><br><br><div class="gmail_quote">2009/8/8 Jorge Arévalo <span dir="ltr"><<a href="mailto:jorge.arevalo@gmail.com">jorge.arevalo@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
2009/8/7 Tamas Szekeres <<a href="mailto:szekerest@gmail.com">szekerest@gmail.com</a>>:<br>
<div class="im">> Just thinking out loadly;<br>
><br>
> Wouldn't it be easier to implement that cache at the driver level, just by<br>
> composing the raster in a temp image buffer and feed that image in the<br>
> subsequent IReadBlock calls? I think we should also think about the non<br>
> regular and overlapping blocks which should also be covered by the<br>
> implementation here.<br>
><br>
<br>
</div>And this buffer, would it be part of the Dataset, as a property?<br>
What's the common way of reading data with a GDAL driver? I suppose<br>
that the sequence is like this:<br>
<br>
User's program --> GDALRasterBand::RasterIO --> Format specific<br>
IRasterIO --> Format specific IReadBlock.<br>
<br>
If the format speficic IRasterIO is not implemented, the generic<br>
GDALRasterBand::IRasterIO is called, and this method calls IReadBlock<br>
if needed (by GetLockedBlockRef).<br>
<br>
Am I right?<br>
<br>
If yes, in what point should I implement the cache at "driver level"?<br>
<div class="im"><br>
Thanks in advance<br>
<br>
Best regards,<br>
Jorge<br>
<br>
</div><div><div></div><div class="h5">> Best regards,<br>
><br>
> Tamas<br>
><br>
><br>
><br>
><br>
> 2009/8/7 Tamas Szekeres <<a href="mailto:szekerest@gmail.com">szekerest@gmail.com</a>><br>
>><br>
>><br>
>> 2009/8/7 Jorge Arévalo <<a href="mailto:jorge.arevalo@gmail.com">jorge.arevalo@gmail.com</a>><br>
>>><br>
>>> > One issue with this concept would be related to the limited memory size<br>
>>> > of<br>
>>> > the particular machine, it may be more reasonable to copy the retrieved<br>
>>> > blocks directly onto the output buffer if possible. In this case you<br>
>>> > cannot<br>
>>> > much rely on the base RasterIO implementation.<br>
>>><br>
>>> So, you suggest to copy the block data into the buffer without calling<br>
>>> base implementation of IRasterIO, do you? This implies take care of<br>
>>> the endianess and pixel size "by hand".<br>
>><br>
>> And many more... I agree this wouldn't be that straightforward. Populating<br>
>> the block buffer would be much easier.<br>
>><br>
>> Best regards,<br>
>><br>
>> Tamas<br>
>><br>
><br>
><br>
</div></div></blockquote></div><br>