<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Even,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You are my new hero.  That worked!  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Question:  Should I always use GDAL_FORCE_CACHING=YES or is it driver specific?  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?  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks for committing that change.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Best regards,<o:p></o:p></p><p class=MsoNormal>Martin<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Even Rouault <even.rouault@spatialys.com> <br><b>Sent:</b> Monday, October 3, 2022 5:08 PM<br><b>To:</b> mchapman@hyperacktive.com; gdal-dev@lists.osgeo.org<br><b>Subject:</b> Re: [gdal-dev] ECRG RasterIO problem<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p>Martin,<o:p></o:p></p><p>I bet you have GDAL_FORCE_CACHING=YES set. At least that was the only way I could trigger the error.<o:p></o:p></p><p>I've queued in <a href="https://github.com/OSGeo/gdal/pull/6464">https://github.com/OSGeo/gdal/pull/6464</a> a fix for that.<o:p></o:p></p><p>The first commit is sufficient to fix the issue despite being a bit hacky, but you could cherry-pick it without changing GDAL ABI<o:p></o:p></p><p>The second commit is a cleaner fix.<o:p></o:p></p><p>Even<o:p></o:p></p><p><o:p> </o:p></p><div><p class=MsoNormal>Le 03/10/2022 à 19:05, <a href="mailto:mchapman@hyperacktive.com">mchapman@hyperacktive.com</a> a écrit :<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>All,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><pre>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.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>// code snippet from gdalproxydataset.cpp line 247<o:p></o:p></pre><pre>else if( nSrcBlockXSize != nBlockXSize || nSrcBlockYSize != nBlockYSize) \<o:p></o:p></pre><pre>{ \<o:p></o:p></pre><pre>        CPLError(CE_Failure, CPLE_AppDefined, "Inconsistent block dimensions between proxy and source"); \<o:p></o:p></pre><pre>        ret = CE_Failure; \<o:p></o:p></pre><pre>} \<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>The variables nBlockXSize and nBlockYSize are (2304, 1) and nSrcBlockXSize and nSrcBlockYSize are {128, 128).<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>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.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>Does anybody know what my problem might be or is this an error in the driver code?<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>Best regards,<o:p></o:p></pre><pre>Martin<o:p></o:p></pre></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>gdal-dev mailing list<o:p></o:p></pre><pre><a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><o:p></o:p></pre><pre><a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><o:p></o:p></pre></blockquote><pre>-- <o:p></o:p></pre><pre><a href="http://www.spatialys.com">http://www.spatialys.com</a><o:p></o:p></pre><pre>My software is free, but my time generally not.<o:p></o:p></pre></div></body></html>