[gdal-dev] GDAL WKT Raster cache: Problem, options to solve and
warmerdam at pobox.com
Fri Aug 14 11:35:09 EDT 2009
2009/8/14 Jorge Arévalo <jorge.arevalo at gmail.com>:
>> I would note that one round trip per block is not necessarily so terrible
>> if the block size is reasonably large (128x128 or larger for instance).
> Yes, but don't you think it could be a good idea trying to avoid extra
> server rounds, in general?
It would be nice, but only as long as the complexity and risk is
appropriate to the benefit.
> Mmmm... I was studying the WCSDataset.cpp code and I thought that this
> might happen:
> - WCSDataset::IRasterIO calls GDALRasterBand::RasterIO
> - GDALRasterBand::RasterIO calls WCSRasterBand::IRasterIO
> - WCSRasterBand::IRasterIO calls WCSDataset::IRasterIO
> But I'm sure I'm making a mistake, a misunderstanding, because WCS
> driver is a solid, well tested driver.
I believe the WCS code is careful about this, only calling into
WCSDataset::DirectRasterIO() for cases that can be handled
directly (checked via a Test method). This care is exactly to
avoid a looping recursion.
> Anyway, my idea is only to call
> IReadBlock as the "last resource". For this reason, I'd like to take
> advantage of the GDAL Data Model with this simple algorithm:
> // Fetch all raster rows covered by the area requested
> If I have rows:
> // Get the data of these rows and copy it into the pImage
> buffer (byte swapping if needed)
> // Anything more? return CE_None? add blocks to rasterband
> cache? delegate in GDALDataset::RasterIO?
> // Delegate in GDALDataset::RasterIO? This will derive in
> WKTRasterRasterBand::IReadBlock or not??
> poDS->IRasterIO(current band);
> What's the normal way in which a program calls GDAL IO system. Is
> usual to call RasterIO directly? maybe call IReadBlock directly? What
> should a driver expect? Should a driver expect something as "usual"?
Normally applications call RasterIO() regardless of the underlying
format. Direct block reads are very rarely done.
> I suspect that depends of the driver format...
>> I would note that the optimized IRasterIO() implementation is
>> not really necessary for a successful project though it would
>> certainly be a crowning achievement for the summer.
> Ok. I've quite a lot of code related with this concept (cache,
> IRasterIO...), but doesn't seem to works fine, for any reason. Maybe
> needs more discussion and/or thinking. I could put it off...
Well, please ensure that the more sophisticated machinery can
be easily disabled, getting back to a safely working block at
a time approach if needed.
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the gdal-dev