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

Jorge Arévalo jorge.arevalo at gmail.com
Sun Aug 9 09:58:17 EDT 2009


Hello Tamas,

2009/8/8 Tamas Szekeres <szekerest at gmail.com>:
> Hi Jorge,
>
> 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.
>

Ok. If I've understood the code, the idea is, in the first attempt to
access the data source to create the dataset, perform a "test" query
to establish several details about the raster (datatype and number of
bands). This will avoid more server rounds to get these data.

Then, my point could be, when creating the dataset (Open static
method), perform a query to get all the blocks that cover the extent
of the raster (the extent is in RASTER_COLUMNS table) and store them
in any place (A new class attribute?, flush the data on a tmp file?).
Then, override IRasterIO in Dataset to get the data fetched in the
extent query, instead of perform a new call. And override the
RasterBand::IReadBlock method too.

It will supppose a change of perspective, but it will improve the
performance, of course.

Thanks for suggestion!

Best regards,
Jorge

>
> Best regards,
>
> Tamas
>
>
>
> 2009/8/8 Jorge Arévalo <jorge.arevalo at gmail.com>
>>
>> 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