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

Peter Townsend peter.townsend at maplarge.com
Wed Sep 29 14:44:04 PDT 2021


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.

On Wed, Sep 29, 2021 at 4:39 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>


-- 
Peter Townsend
Senior Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210929/aa9a26b9/attachment.html>


More information about the PROJ mailing list