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

[Tamas Szekeres]

2009/8/12 Jorge Arévalo <jorge.arevalo at gmail.com>

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


I may have been misunderstood somewhere, but I've never talked about the
requirement to fetch all the data (the entire extent) of the raster data
table.
We have been talking about fetching all the tiles requested by a single
RasterIO call which tiles would definitely be requested by the subsequent
IReadBlock calls if we were rely on the default RasterIO implementation.
Just like what the WCS driver currently implements in DirectRasterIO to
prevent from accessing the server for each tiles.

Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090812/efdecd7f/attachment.html