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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
