[PROJ] Matching EPSG:3005

Even Rouault even.rouault at spatialys.com
Wed May 6 14:09:59 PDT 2020


On jeudi 7 mai 2020 06:23:37 CEST Nyall Dawson wrote:
> On Thu, 7 May 2020 at 05:46, Even Rouault <even.rouault at spatialys.com> wrote:
> > Do not hesitate to give the full context for your question. I suspect this
> > is related to https://github.com/qgis/QGIS/issues/36216 and Oracle WKT.
> Correct! I'm mid way through a reply to that (but I'm blaming Oracle
> here, not proj!)

Would I be mean if I'd point that they opted for not being part of the team supporting the 
GDAL barn effort :-) ?

> I guess I misunderstood the proj docs: "90% means that CRS are
> equivalent, but the names are not exactly the same.". I assumed this
> meant that a 90% match would ignore things like the
> NAD83/GCS_North_American_1983 differences. But I'm guessing now that
> there's only **some** names in the wkt which can vary?

Yes I believe this is only on the "top" name of the CRS. Datum names need to match quite 
closely. With PROJ current accuracy, you cannot really consider that NAD83 ~= NAD83(2011) 
or GDA94 ~= GDA2020. Of course as humans we are able to identify that "North American 
Datum 1983 (EPSG ID 6269)" is the same as "North American Datum 1983"

> Can you clarify what IA stands for?

Ah, sorry, I meant AI = Artificial Intelligence. (IA = Intelligence Artificielle in French)

> I did try with replacing this with the versions used by PROJ, but that
> didn't alter the match at all.

Yes, the normalization of the non-WKT2 parameter names is not done if you use the WKT2 
projection method name. If you use the WKT1_GDAL one (Albers_Conic_Equal_Area), it will 
be done.

So the following identifies to EPSG:3005 at 100%

PROJCS["NAD83 / BC Albers", GEOGCS [ "NAD83", DATUM ["North American Datum 1983", 
SPHEROID ["GRS 1980 (EPSG ID 7019)", 6378137.0, 298.257222101]], PRIMEM [ "Greenwich", 
0.000000 ], UNIT ["Decimal Degree", 0.0174532925199433]], PROJECTION 
["Albers_Conic_Equal_Area"], PARAMETER ["Latitude_Of_Origin", 45.0], PARAMETER 
["Central_Meridian", -126.0], PARAMETER ["Standard_Parallel_1", 50.0], PARAMETER 
["Standard_Parallel_2", 58.5], PARAMETER ["False_Easting", 1000000.0], PARAMETER 
["False_Northing", 0.0], UNIT ["Meter", 1.0]]

> Looks like Oracle is definitely at fault here.

Well, WKT has a long history of not being super interoperable, and not sure this has really 
been solved... In 2007, Frank Warmerdam collected some of the mess in the WKT world: 
https://gdal.org/tutorials/wktproblems.html . Part of it is probably outdated now.

> But for my own
> curiosity, what else is missing in proj to allow identifying this
> definition (aside for an alias to match "Albers Conical Equal Area")?

Just the above: triggering normalization of parameter names from WKT1 if "Albers Conical 
Equal Area" is found

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200506/76f35a06/attachment-0001.html>


More information about the PROJ mailing list