[gdal-dev] ECRG RasterIO problem

[Even Rouault]

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 calledRB_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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221004/728d7585/attachment.htm>