[gdal-dev] GDAL 3.9.0beta1 available for testing

[Sean Gillies]

Thanks for the fix and suggestions! I'm looking forward to 3.9.0.

On Mon, Apr 22, 2024 at 11:27 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Sean,
>
> Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.
>
> Metadata output of gdalinfo has changed.
>
> ok, I've run locally rasterio tests and I see gdalinfo now outputs:
> Metadata:
>   a=1
>   b=2
>   AREA_OR_POINT=Area
>
> whereas the test expects
>
> Metadata:
>   a=1
>   AREA_OR_POINT=Area
>   b=2
>
> 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?
>
> As soon as there are docker images I'll look more closely at this.
>
> ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1 is already available
>
>
> Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a RGB.byte.tif.msk
> file:
> https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231
> .
>
> Yes, this is intended. Due to this change:
> GTiff driver:
>  * change default value of GDAL_TIFF_INTERNAL_MASK config option to YES
>
> You might run the test under GDAL_TIFF_INTERNAL_MASK=NO if you want to
> test external mask.
>
>
> The text of an error message which was "tests/data/corrupt.tif, band 1:
> IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed."
> in 3.8 has changed to "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.
>
> Yes, related to
> https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0
>
>
> Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems
> to have changed:
> https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287.
> 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.
>
> ok, this is related to https://github.com/OSGeo/gdal/pull/9336 , which
> indeed wasn't honoring the SRC_METHOD=NO_GEOTRANSFORM and was using
> directly the geotransform from the source dataset.
>
> Fix queued in https://github.com/OSGeo/gdal/pull/9724
>
> (that said, tests reprojecting from 4326 to 3857 while ignoring the
> geotransform are a bit weird)
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240422/03caac76/attachment.htm>