[gdal-dev] GDAL 3.3.2 RC2 is available [was Re: GDAL 3.3.2 RC1 available]

[Even Rouault]

Hi Sean,
>
> Would it be difficult to change the RC URLs and release directory to 
> include the "rc*" string? If the download was at 
> https://download.osgeo.org/gdal/3.3.2rc2/gdal-3.3.2rc2.tar.gz 
> <https://download.osgeo.org/gdal/3.3.2rc2/gdal-3.3.2rc2.tar.gz> and 
> extracted to gdal-3.3.2rc2 I would only need to make a one line change 
> to my build system to test it.
ok will try to remember that for next time
>
> I did find some failures in the tests we run when building and testing 
> rasterio's binary distributions (the wheels on PyPI). GDAL 3.3.2rc2 
> and PROJ 7.2.1. The errors seem to come from a failure to auto 
> identify the EPSG codes in spatial reference systems created from, for 
> example, '+init=epsg:4326' or '+proj=longlat +datum=WGS84 +no_defs'.
>
> https://github.com/mapbox/rasterio/blob/master/rasterio/_crs.pyx#L241-L243 
> <https://github.com/mapbox/rasterio/blob/master/rasterio/_crs.pyx#L241-L243>
>
> These failures did not occur with 3.3.0. I'm retroactively checking 
> 3.3.1 now.

This is a 3.3.2 change : https://github.com/OSGeo/gdal/pull/4047 . And 
this is intended. The issue with the PROJ strings you mention is that 
they are legacy syntax that results in a CRS that is instantiated with 
longitude, latitude order, whereas official EPSG:4326 is latitude, 
longitude order. The previous tolerance on the axis order in 
AutoIdentifyEPSG() was actually causing issues in some contexts 
(coordinate transformations)

I'd suggest you use OSRFindMatches() (much more capable) instead of 
AutoIdentifyEPSG(). You can walk through the suggested matches and 
compare them with the original CRS for example with OSRIsSame(). By 
default OSRIsSame() is tolerant on the axis order for geographic CRS 
(using OSRIsSameEx() with CRITERION=EQUIVALENT you'll get enforcement of 
same axis order).

Even

-- 

http://www.spatialys.com
My software is free, but my time generally not.