[PROJ] Is Equivalent To Between Authority Codes and Proj Strings

[Even Rouault]

Peter,

Le 29/09/2021 à 23:01, Peter Townsend via PROJ a écrit :
> I was looking at using the proj_is_equivalent_to_with_ctx method, in 
> particular the "proj_is_equivalent_to_with_ctx" test method that uses 
> EPSG:7844. It pulls EPSG:7844 from the database, then loads it from 
> the WKT and shows that they're equivalent.
>
> So then I tried against the exported proj string 
> version, "+proj=longlat +ellps=GRS80 +no_defs +type=crs". I threw that 
> at the equivalent_to method w/ both PJ_COMP_EQUIVALENT and 
> PJ_COMP_EQUIVALENT_EXCEPT_AXIS_ORDER_GEOGCRS, and they both came out 
> false. I dug down the rabbit hole and got down to 
> GeodeticReferenceFrame::hasEquivalentNameToUsingAlias. The reason it's 
> coming out false is because the datum names don't match. One is 
> "GDA2020" and the other is "Unknown based on GRS80 ellipsoid".
>
> It makes sense since the proj string doesn't really give that kind of 
> detail. But is there any consistent way to perform an equivalency 
> check between two CRS's given an EPSG code and a proj string, or 
> is something amiss?

PROJ.4 strings are too lossy too be a reliable way of identifying a CRS. 
They support only a super restricted sets of datums (which means new 
fancy things like GDA2020), axis order, etc. You should consider using 
WKT for a more expressive way of describing the CRS if the code is not 
enough


> (I did try proj_identify on that GRS80 string and 7844 doesn't even 
> show up.)
That part was a bug. Fixed per https://github.com/OSGeo/PROJ/pull/2881 . 
You'll get now 206 matches including 7844.
>
> This is with version 8.1. I tried a few others to see what happened 
> with them. 4326, 3857, 3031, 3995, 32631 worked.

Yes, those are based on WGS84, for which there's a +datum=WGS84 
available (so more rich than just the ellipsoid name)

Even


-- 
http://www.spatialys.com
My software is free, but my time generally not.