[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