[gdal-dev] Where is GDALRasterBlock documentation?

[Jorge Arévalo]

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.

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
>