Yeah I can understand the nervousness on that fix. It feels very much like the code is
just saying "Oh I don't have any good information on this CRS, so let's just assume
it matches everything". If it wasn't for the API description of the 70% confidence
then it would make sense to me to not include this patch. Whether you merge that or not,
thanks for putting the work in to at least identify the issue.
As for the difference in environments, I think you're right. I think I was
overwriting a previous pyproj installation I had tested with and a `PROJ_DATA`
directory was sticking around pointing to the 9.2.x database and therefore not
finding the newly matching EPSG code. When I removed the internal pyproj proj
data directory the EPSG code was found.
Dave
On 9/3/23 16:22, Even Rouault wrote:
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
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
