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