David,
1. EPSG code returned from `proj_identify` on one platform and not the
other even with the same PROJ source. Assuming I didn't make a dumb
mistake this would suggest some dependency is changing the behavior of
how the proj.db database is read/used...right? The only thing I can
think of is libtiff or sqlite3.
Likely that your pyproj install bundes PROJ 9.2.1 and not 9.3.0 since:
$ docker run --rm -it osgeo/proj:latest proj --version
Rel. 9.3.0, September 1st, 2023
$ docker run --rm -it osgeo/proj:latest projinfo --identify "+proj=laea
+lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +R=6371228 +units=m +no_defs +type=crs"
[...]
Identification match count: 1
EPSG:3408: 70 %
2. The EPSG code created from a confidence of 70% is not considered
equivalent even though the API docs say "70% means that CRS are
equivalent, but the names are not equivalent."
Fixed per https://github.com/OSGeo/PROJ/pull/3879 (although this fix
makes me slightly nervous)
As said many times, using PROJ.4 strings is bound to cause various
issues. In particular, you will not be able to perform correct datum
transformations.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
