[gdal-dev] Where is GDALRasterBlock documentation?

[Jorge Arévalo]

Hello,

2009/8/4 Jorge Arévalo <jorge.arevalo at gmail.com>:
> Hello,
>
> On Mon, Aug 3, 2009 at 8:26 PM, Frank Warmerdam<warmerdam at pobox.com> 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,
>> 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
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>