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

[Mateusz Loskot]

Jorge Arévalo wrote:
> Hello,
> 
> 2009/8/12 Mateusz Loskot <mateusz at loskot.net>:
>> Frank Warmerdam wrote:
>>> 2009/8/9 Jorge Arévalo <jorge.arevalo at gmail.com>:
>>>> 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.
>>> Jorge,
>>>
>>> I'm afraid I have not quite followed the discussion of the IRasterIO
>>> implementation, but I find the above statement quite alarming. It is
>>> imperative that we *not* end up reading back all blocks if only a few
>>> are requested.  Imagine a 100GB image split up into blocks in a
>>> table.  If an application using GDAL is run and only needs a small
>>> area of the file it is important that the blocks not requested never
>>> be pulled from the DB.
>> I can only second Frank's comment.
>> IOW, general idea is to query minimum (sub)set of tiles requested,
>> where request is based on spatial extent (i.e. geographic coordiantes)
>> or extent within pixel space of a coverage (specified as range of rows
>> and columns of a raster).
>>
> 
> OK. Then, and correct me if I'm wrong, the point is to query only the
> extent asked by the program using GDAL driver. Then, I should query
> only the blocks requested in, for example, the IReadBlock method, just
> as I did. But Tamas' suggestion was to minimize the number of server's
> rounds implementing a kind of cache system at driver's level.

My comment was related to similar use case as gdal_translate
and its -srcwin and -projwin parameters

But, I may be missing some of Tamas' points as I've not been
tracking the discussion closely enough.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org