[gdal-dev] Overriding IRasterIO in class derived from GDALRasterBand

Jorge Arévalo jorge.arevalo at gmail.com
Sat Aug 8 11:43:05 EDT 2009


Hello,

2009/8/7 Tamas Szekeres <szekerest at gmail.com>:
> Just thinking out loadly;
>
> Wouldn't it be easier to implement that cache at the driver level, just by
> composing the raster in a temp image buffer and feed that image in the
> subsequent IReadBlock calls? I think we should also think about the non
> regular and overlapping blocks which should also be covered by the
> implementation here.
>

And this buffer, would it be part of the Dataset, as a property?
What's the common way of reading data with a GDAL driver? I suppose
that the sequence is like this:

User's program --> GDALRasterBand::RasterIO --> Format specific
IRasterIO --> Format specific IReadBlock.

If the format speficic IRasterIO is not implemented, the generic
GDALRasterBand::IRasterIO is called, and this method calls IReadBlock
if needed (by GetLockedBlockRef).

Am I right?

If yes, in what point should I implement the cache at "driver level"?

Thanks in advance

Best regards,
Jorge

> Best regards,
>
> Tamas
>
>
>
>
> 2009/8/7 Tamas Szekeres <szekerest at gmail.com>
>>
>>
>> 2009/8/7 Jorge Arévalo <jorge.arevalo at gmail.com>
>>>
>>> > One issue with this concept would be related to the limited memory size
>>> > of
>>> > the particular machine, it may be more reasonable to copy the retrieved
>>> > blocks directly onto the output buffer if possible. In this case you
>>> > cannot
>>> > much rely on the base RasterIO implementation.
>>>
>>> So, you suggest to copy the block data into the buffer without calling
>>> base implementation of IRasterIO, do you? This implies take care of
>>> the endianess and pixel size "by hand".
>>
>> And many more... I agree this wouldn't be that straightforward. Populating
>> the block buffer would be much easier.
>>
>> Best regards,
>>
>> Tamas
>>
>
>


More information about the gdal-dev mailing list