2009/8/7 Even Rouault <even.roua...@mines-paris.org>: > > ----- Original Message ----- From: "Jorge Arévalo" <jorge.arev...@gmail.com> > To: "Tamas Szekeres" <szeker...@gmail.com> > Cc: "gdal-dev" <gdal-dev@lists.osgeo.org> > Sent: Friday, August 07, 2009 7:43 PM > Subject: Re: [gdal-dev] Overriding IRasterIO in class derived from > GDALRasterBand > > >> 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' suggestion. Best regards, Jorge >> Best regards, >> Jorge > >> >> Best regards, >> >> Tamas >> >> >> >> 2009/8/7 Jorge Arévalo <jorge.arev...@gmail.com> >>> >>> Hello, >>> >>> 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, >>> Jorge >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev