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

[Tamas Szekeres]

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.


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
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090808/2fbd69a0/attachment.html