Hello, 2009/8/7 Tamas Szekeres <[email protected]>: > 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 <[email protected]> >> >> >> 2009/8/7 Jorge Arévalo <[email protected]> >>> >>> > 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 >> > > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
