[gdal-dev] Overriding IRasterIO in class derived from
jorge.arevalo at gmail.com
Sun Aug 9 07:41:06 EDT 2009
2009/8/7 Even Rouault <even.rouault at mines-paris.org>:
> ----- Original Message ----- From: "Jorge Arévalo" <jorge.arevalo at gmail.com>
> To: "Tamas Szekeres" <szekerest at gmail.com>
> Cc: "gdal-dev" <gdal-dev at lists.osgeo.org>
> Sent: Friday, August 07, 2009 7:43 PM
> Subject: Re: [gdal-dev] Overriding IRasterIO in class derived from
>> OK, I commented this part during tests, -1 for me. The assertion
>> disappeared. Many thanks.
>> And about the time, it's only when executing gdalinfo with options
>> "-mm -stats -checksum". Takes about 35 seconds, with this image
>> http://download.osgeo.org/gdal/data/gtiff/utm.tif and one overview of
>> factor 2 (50% of size in both dimensions). I suppose is normal...
> This looks quite slow to me for a modest 512x512 raster. "gdalinfo -mm
> -stats -checksum utm.tif" takes less than one second.
> You should try to profile what is slow exactly : the DB request (server-side
> performance issue ?), the decoding of the result, ...
Ok, I debugged it and now is faster. But sometimes I get errors
because invalid block offsets. So, I need more debug...
>> 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".
> Implementing yourself all the cases of IRasterIO will be complicated. Just
> look at GDALRasterBand::IRasterIO in rasterio.cpp. If you really want to
> implement it, I'd advise you to only concentrate first on a few common
> cases, like when the output buffer size is equal to the source buffer size
> (nXSize == nBufXSize && nYSize == nBufYSize). For other cases, default to
> the base implementation.
Really complicated... Maybe I should take a different way, like Tamas'
>> Best regards,
>> Best regards,
>> 2009/8/7 Jorge Arévalo <jorge.arevalo at gmail.com>
>>> Context: GDAL WKT Raster driver
>>> In my class derived from GDALRasterBand, I've overrided the methods:
>>> - IReadBlock: Fetch a block from database
>>> - IRasterIO: Should fetch several blocks, that cover an area, and add
>>> them to papoBlocks (cache). The idea is to avoid rounds in the server
>>> AFAIK, the base IRasterIO implementation (in GDALRasterBand), tries to
>>> fetch the block from the cache. If the block isn't in the cache, then
>>> call to IReadBlock. So, the normal way to read blocks in any GDAL
>>> driver should be IRasterIO --> IReadBlock
>>> Then, If I override IRasterIO in my driver RasterBand's class, I
>>> should fetch several blocks in one round and call GetLockedBlockRef to
>>> add these blocks to the cache. After this, call the base
>>> implementation of IRasterIO (in GDALRasterBand) to do its work (see
>>> previous point).
>>> Is it correct? I have problems with my IRasterIO implementation,
>>> because it takes a long time executing until this fail:
>>> ERROR 7: Assertion `nLockCount == 0' failed
>>> in file `gdalrasterblock.cpp', line 228
>>> Is there any mistake in this approach? If not, I suppose I had to
>>> debug my queries, but I'd like to rule our wrong concepts first.
>>> Many thanks in advance.
>>> Best regards,
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev