<div dir="ltr">Thanks for looking! I'm going to be given proj strings, so I'm just gonna have to try my best. Those all being WGS84 does make sense.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 29, 2021 at 4:39 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Peter,<br>
<br>
Le 29/09/2021 à 23:01, Peter Townsend via PROJ a écrit :<br>
> I was looking at using the proj_is_equivalent_to_with_ctx method, in <br>
> particular the "proj_is_equivalent_to_with_ctx" test method that uses <br>
> EPSG:7844. It pulls EPSG:7844 from the database, then loads it from <br>
> the WKT and shows that they're equivalent.<br>
><br>
> So then I tried against the exported proj string <br>
> version, "+proj=longlat +ellps=GRS80 +no_defs +type=crs". I threw that <br>
> at the equivalent_to method w/ both PJ_COMP_EQUIVALENT and <br>
> PJ_COMP_EQUIVALENT_EXCEPT_AXIS_ORDER_GEOGCRS, and they both came out <br>
> false. I dug down the rabbit hole and got down to <br>
> GeodeticReferenceFrame::hasEquivalentNameToUsingAlias. The reason it's <br>
> coming out false is because the datum names don't match. One is <br>
> "GDA2020" and the other is "Unknown based on GRS80 ellipsoid".<br>
><br>
> It makes sense since the proj string doesn't really give that kind of <br>
> detail. But is there any consistent way to perform an equivalency <br>
> check between two CRS's given an EPSG code and a proj string, or <br>
> is something amiss?<br>
<br>
PROJ.4 strings are too lossy too be a reliable way of identifying a CRS. <br>
They support only a super restricted sets of datums (which means new <br>
fancy things like GDA2020), axis order, etc. You should consider using <br>
WKT for a more expressive way of describing the CRS if the code is not <br>
enough<br>
<br>
<br>
> (I did try proj_identify on that GRS80 string and 7844 doesn't even <br>
> show up.)<br>
That part was a bug. Fixed per <a href="https://github.com/OSGeo/PROJ/pull/2881" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/2881</a> . <br>
You'll get now 206 matches including 7844.<br>
><br>
> This is with version 8.1. I tried a few others to see what happened <br>
> with them. 4326, 3857, 3031, 3995, 32631 worked.<br>
<br>
Yes, those are based on WGS84, for which there's a +datum=WGS84 <br>
available (so more rich than just the ellipsoid name)<br>
<br>
Even<br>
<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Peter Townsend<br></div>Senior Software Developer<br></div></div>