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

[David Hoese]

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
>