[PROJ] PROJ 9.3.0 EPSG behavior on debian:sid versus osgeo/proj image

[David Hoese]

Hi everyone,

I'm attempting to debug a failure on some CI when using the latest PROJ 9.3.0 RC1 tarball for my python package pyresample. This uses the pyproj library to access PROJ functionality. One of our test failures comes down to a use of pyproj's `CRS.to_epsg` methods which takes a CRS definition and uses PROJ's `proj_identify` function with a confidence of 70% to see if there is a matching EPSG code for the CRS.

https://proj.org/en/9.2/development/reference/functions.html#c.proj_identify

The CRS is created from a PROJ.4 string:

"+proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +R=6371228 +units=m +no_defs +type=crs"

Then converted (potentially) to an EPSG code or else converted back to a PROJ.4 string (due to legacy use of PROJ.4 for on-disk representation). With PROJ 9.2.x it does not match to an EPSG code so PROJ.4 string is used. This EPSG code or PROJ.4 string is then loaded again and compared against the original CRS object with `proj_is_equivalent_to_with_ctx`:

https://proj.org/en/9.2/development/reference/functions.html#c.proj_is_equivalent_to_with_ctx

For PROJ 9.3.0RC1, the EPSG code version of the CRS is not considered equal to the original PROJ.4 version of the CRS. Even weirder is when I use the `osgeo/proj:latest` Docker image to do this test and install pyproj, I *don't* get an EPSG code from `to_epsg()`, but for a `debian:sid` image I do. Even when I install PROJ and pyproj from github source and 9.3.0RC1 tarball source code I get the same behavior (no EPSG from osgeo/pyproj Ubuntu-based image, but EPSG code from debian:sid). So really I have two issues:

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.
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."

More context can be found in this pyproj issue:

https://github.com/pyproj4/pyproj/issues/1339

Does anyone have any guidance on my next step for debugging or if any of this is unexpected or expected?

Dave