Hello, 2009/8/4 Jorge Arévalo <[email protected]>: > Hello, > > On Mon, Aug 3, 2009 at 8:26 PM, Frank Warmerdam<[email protected]> wrote: >> Even Rouault wrote: >>> >>> Le Monday 03 August 2009 18:07:33 Jorge Arévalo, vous avez écrit : >>>> >>>> Hello, >>>> >>>> Why GDALRasterBlock definition doesn't appear in the GDAL class list >>>> at http://www.gdal.org/annotated.html ? >>> >>> Technical reason : It would just require to add a missing line >>> //! Raster block >>> before >>> class CPL_DLL GDALRasterBlock >>> in gcore/gdal_priv.h >>> >>> More realistic reason : very few methods of GDALRasterBlock are properly >>> documented + the fact it is a very internal thing that only interest GDAL >>> developers themselves, not GDAL API users and very few GDAL driver >>> developers. >> >> Jorge, >> >> Even is right; however, I have committed a few changes so parts of the >> class are now documented. It should appear on the web site within a >> few hours. > > Ok, I can see http://www.gdal.org/classGDALRasterBlock.html. But I'm > not updating the last changes on official GDAL tree, of course. > >> >>>> I'm trying to implement a cache-block system for GDAL WKT Raster >>>> driver, but I'm not sure if I should use this class. Maybe is >>>> deprecated? >>> >>> It's not deprecated : it is actively used by GDALRasterBand. >>> >>> But I'm not sure what/why you want to do about block caching for WKT >>> raster driver. Is this a harddisk block caching or a RAM block caching ? If >>> it's RAM block caching, you don't need to do anything as it is the purpose >>> of the GDALRasterBlock/GDALRasterBand and doesn't require to write code to >>> benefit from it. >> >> Jorge - are you wanting to push extra values from pixel interleaved blocks >> into the block cache? This is one of the few reasons a driver would need to >> interact with the block cache directly. >> >> This is done in a few drivers. You might want to use the >> PNGRasterBand::IReadBlock() method in gdal/frmts/png/pngdataset.cpp >> as an example. >> >> In this implementation accessing a block (scanline) causes it to get >> loaded into a buffer on the dataset class, and then the IReadBlock picks >> out the part of that pixel intereleaved scanline that are needed for >> the band requested. >> >> But - since the scanline is loaded it also calls GetLockedBlockRef() on >> the other bands to force IReadBlock() to be called on them and the >> block cache items for them to be filled in. You can use a similar >> approach in the WKTRasterBlock driver if you have it maintain a concept >> of a currently loaded block - likely at the dataset level - and have >> the IReadBlocks operate from that. >> >> There are other approaches too, but I can't think of any examples, so >> I'd suggest you follow the pattern in pngdataset.cpp. >> > > I'm trying to consider this situation: In each IReadBlock call, I need > to perform a spatial query to get a block (or several blocks, in case > on irregular blocking). This, as Tamas suggested, is a "non-optimal" > solution. If I understood the excelent Even's explanation in the last > mail, IReadBlock calls are performed via IRasterIO --> > GetRasterBlockRef (always?) as the "worst solution" if the portion > (block) needed is not cached. > > At present, my "best solution" is IReadBlock method, because this > method is always called when reading data from raster. My point is to > override the IRasterIO method to avoid extra calls to IReadBlock. > Maybe I can perform an only spatial query to read all the extent > required by the client (even the whole raster), instead of one query > per block. Is this point correct? > > If yes, if I understood Even, again, the method to store blocks in RAM > is ¿automatic? I mean, calling GDALRasterBlock::Internalize with each > new block, all the blocks fetched by the big spatial query are chained > in the cache system.
Ok, reading a Tamas' mail I see the way to add a block to the cache is by AdoptBlock, in RasterBand class. I suppose this method will call GDALRasterBlock::Internalize > > Best regards, > Jorge > >> Best regards, >> -- >> ---------------------------------------+-------------------------------------- >> I set the clouds in motion - turn up | Frank Warmerdam, >> [email protected] >> light and sound - activate the windows | http://pobox.com/~warmerdam >> and watch the world go round - Rush | Geospatial Programmer for Rent >> >> _______________________________________________ >> gdal-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
