<div dir="ltr"><div>Thanks for the fix and suggestions! I'm looking forward to 3.9.0.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2024 at 11:27 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    Sean,
    <blockquote type="cite">
      <div dir="ltr">
        <div>Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.</div>
        <div><br>
        </div>
        <div>Metadata output of gdalinfo has changed.</div>
      </div>
    </blockquote>
    <p>ok, I've run locally rasterio tests and I see gdalinfo now
      outputs:</p>
    Metadata:<br>
      a=1<br>
      b=2<br>
      AREA_OR_POINT=Area<br>
    <p>whereas the test expects</p>
    <p>Metadata:<br>
        a=1<br>
        AREA_OR_POINT=Area<br>
        b=2<br>
    </p>
    <p>Order of metadata items shouldn't be relied upon. I believe we
      have changed something internally (likely changing from char** to
      CPLStringList that does sorting) that might indeed have affected
      it. You could also potentially use "gdalinfo -json" output to get
      something easier to parse. But don't you have a rasterio API to
      get GDAL metadata that would avoid using gdalinfo at all?<br>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div> As soon as there are docker images I'll look more closely
          at this.</div>
      </div>
    </blockquote>
    <a href="http://ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1" target="_blank">ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1</a> is already available<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Writing a mask to a Rasterio <span><span>RGB.byte.tif </span></span>dataset no
          longer creates a <span><span>RGB.byte.tif.msk file: </span></span><a href="https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231" target="_blank">https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231</a>.</div>
      </div>
    </blockquote>
    <p>Yes, this is intended. Due to this change:</p>
    GTiff driver:<br>
     * change default value of GDAL_TIFF_INTERNAL_MASK config option to
    YES<br>
    <p>You might run the test under GDAL_TIFF_INTERNAL_MASK=NO if you
      want to test external mask.<br>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>The text of an error message which was "<span><span>tests/data/corrupt.tif, band 1: IReadBlock
              failed at X offset 1, Y offset 1: TIFFReadEncodedTile()
              failed." in 3.8 has changed to "</span></span><span><span>corrupt.tif, band 1: IReadBlock failed at X
              offset 1, Y offset 1: TIFFReadEncodedTile() failed." This
              is not a big deal, we can adjust Rasterio's test.</span></span></div>
      </div>
    </blockquote>
    Yes, related to
<a href="https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0" target="_blank">https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0</a><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><span><span><br>
            </span></span></div>
        <div><span><span>Behavior of SRC_METHOD/DST_METHOD=</span></span>NO_GEOTRANSFORM
          for warp options seems to have changed: <a href="https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287" target="_blank">https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287</a>.
          I'm not entirely sure what the intent is in Rasterio's test,
          will dig into that. I just wanted to say that I see a change
          in GDAL.<br>
        </div>
      </div>
    </blockquote>
    <p>ok, this is related to <a href="https://github.com/OSGeo/gdal/pull/9336" target="_blank">https://github.com/OSGeo/gdal/pull/9336</a> ,
      which indeed wasn't honoring the <span><span>SRC_METHOD=NO_GEOTRANSFORM and was using
          directly the geotransform from the source dataset.<br>
        </span></span></p>
    <p><span><span>Fix queued in
          <a href="https://github.com/OSGeo/gdal/pull/9724" target="_blank">https://github.com/OSGeo/gdal/pull/9724</a><br>
        </span></span></p>
    <p><span><span>(that said, tests reprojecting from 4326 to
          3857 while ignoring the geotransform are a bit weird)<br>
        </span></span></p>
    <p>Even</p>
    <br>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Sean Gillies</div></div>