[gdal-dev] ECRG RasterIO problem

Even Rouault even.rouault at spatialys.com
Tue Oct 4 09:02:06 PDT 2022


Martin,

Le 04/10/2022 à 17:53, mchapman at hyperacktive.com a écrit :
>
> Even,
>
> You are my new hero.  That worked!
>
> Question:  Should I always use GDAL_FORCE_CACHING=YES or is it driver 
> specific?
>
It is used by the GDALDataset::RasterIO() and GDALRasterBand::RasterIO() 
methods (which are not virtual), so this applies to all drivers
>
>   I would like to just set it to YES once at startup and forget about 
> it.  What are the pros and cons of setting it to YES / NO?
>
I would say not to set it, unless you know you need it and are familiar 
with GDAL internals. The default value NO should perform better in most 
situations. By setting to YES, you won't be able to user driver-specific 
IRasterIO() optimizations.

Even

> Thanks for committing that change.
>
> Best regards,
>
> Martin
>
> *From:* Even Rouault <even.rouault at spatialys.com>
> *Sent:* Monday, October 3, 2022 5:08 PM
> *To:* mchapman at hyperacktive.com; gdal-dev at lists.osgeo.org
> *Subject:* Re: [gdal-dev] ECRG RasterIO problem
>
> Martin,
>
> I bet you have GDAL_FORCE_CACHING=YES set. At least that was the only 
> way I could trigger the error.
>
> I've queued in https://github.com/OSGeo/gdal/pull/6464 a fix for that.
>
> The first commit is sufficient to fix the issue despite being a bit 
> hacky, but you could cherry-pick it without changing GDAL ABI
>
> The second commit is a cleaner fix.
>
> Even
>
> Le 03/10/2022 à 19:05, mchapman at hyperacktive.com a écrit :
>
>     All,
>
>     I have an ECRG dataset that fails when reading pixels from the gdalrasterband object on one of the subdatasets.  It appears that the underlying proxy dataset has a macro check called RB_PROXY_METHOD_WITH_RET_WITH_INIT_BLOCK that fails because the block sizes are different.  This happens for all the ECRG subdatasets that I read from, in other words it’s not just specific to a single dataset.  FYI, the same code works fine for RPFTOC datasets and all other GDAL formats.  I am using GDAL version 3.4.2.
>
>       
>
>     // code snippet from gdalproxydataset.cpp line 247
>
>     else if( nSrcBlockXSize != nBlockXSize || nSrcBlockYSize != nBlockYSize) \
>
>     { \
>
>              CPLError(CE_Failure, CPLE_AppDefined, "Inconsistent block dimensions between proxy and source"); \
>
>              ret = CE_Failure; \
>
>     } \
>
>       
>
>     The variables nBlockXSize and nBlockYSize are (2304, 1) and nSrcBlockXSize and nSrcBlockYSize are {128, 128).
>
>       
>
>     I think this is because the ECRG frame size is 2304 x 2304 but the block size of the frame file is 128 x 128.
>
>       
>
>     Does anybody know what my problem might be or is this an error in the driver code?
>
>       
>
>     Best regards,
>
>     Martin
>
>
>
>     _______________________________________________
>
>     gdal-dev mailing list
>
>     gdal-dev at lists.osgeo.org
>
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221004/31da4815/attachment-0001.htm>


More information about the gdal-dev mailing list