Closed nyalldawson closed 4 years ago
Hum, the current ESRI PE database ( https://raw.githubusercontent.com/Esri/projection-engine-db-doc/master/csv/pe_list_projcs.csv ) has no trace of SI-D-48-Gauss_Kruger. For EPSG:3912 the most recent ESRI equivalent is
GEOGCS[""GCS_MGI_1901"",DATUM[""D_MGI_1901"",SPHEROID[""Bessel_1841"",6377397.155,299.1528128]],PRIMEM[""Greenwich"",0.0],UNIT[""Degree"",0.0174532925199433]],PROJECTION[""Transverse_Mercator""],PARAMETER[""False_Easting"",500000.0],PARAMETER[""False_Northing"",-5000000.0],PARAMETER[""Central_Meridian"",15.0],PARAMETER[""Scale_Factor"",0.9999],PARAMETER[""Latitude_Of_Origin"",0.0],UNIT[""Meter"",1.0]]
With the SI-D-48-Gauss_Kruger WKT string, not only the CRS name is completely different from the one of EPSG:3912 (MGI 1901 / Slovene National Grid), but also the datum names are completely different D_Bessel_1841 vs MGI 1901
So to handle this we would probably need an extra database table that would map a full WKT string to a AUTH:CODE
Hmm, odd. I can't find any reference to "SI-D-48-Gauss_Kruger" online. I'll do some more research here.
@rouault Looking into this some more, I'm confused why identify isn't reporting EPSG:3912 as a 70% match. The docs state "70% means that CRS are equivalent), but the names do not match at all.", and unless I'm missing something here that criteria directly applies to the WKT string reported.
unless I'm missing something here that criteria directly applies to the WKT string reported.
Not really. There are several issues at play:
firstly, the look up algorithm doesn't do an extensive search in the database. Perhaps that should be explicited in the docs. That would be too slow (like 10 seconds to bring up into memory C++ objects from the database). So it uses a different set of heuristics to restrict the number of candidates it will test. Here the "issue" is that the ESRI D_Bessel_1841 is detected as equivalent of EPSG:6004, which is "Not specified (based on Bessel 1841 ellipsoid)", and then when looking at geographic CRS that uses this datum, there is only EPSG:4004 "Unknown datum based upon the Bessel 1841 ellipsoid", and this geographic CRS isn't the base of any projected CRS. So the first part of identify() returns an empty result set... hence an empty set as the result
secondly, even if the previous step had identified EPSG:3912 as a candidate, the CRS defintition coming from EPSG and the one from this odd ESRI formulation will not pass the isEquivalentTo() test, given that the datum names are different (and not marked as aliases). If we did, then we also have to consider "GDA2020 / MGA zone 46" and "GDA94 / MGA zone 46" are equivalent because they use the same projection parameters, the same ellipsoid definition, and there's just this tiny difference on the datum name :-)
Ok, let's close then. Discussion on https://gis.stackexchange.com/questions/346757/what-is-the-meaning-of-si-d-48-gauss-kruger-projection-used-in-an-esri-wkt-str indicates this was likely a projection created by some non-default script or utility anyway.
After digging into #1911, I gave a test with renaming just the DATUM part of the WKT to remove the D_ prefix, and get the expected results:
projinfo --identify "PROJCS[\"SI-D-48-Gauss_Kruger\",GEOGCS[\"GCS_Bessel_1841\",DATUM[\"Bessel_1841\",SPHEROID[\"Bessel_1841\",6377397.155,299.1528128]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\",0.0174532925199433]],PROJECTION[\"Gauss_Kruger\"],PARAMETER[\"False_Easting\",500000.0],PARAMETER[\"False_Northing\",-5000000.0],PARAMETER[\"Central_Meridian\",15.0],PARAMETER[\"Scale_Factor\",0.9999],PARAMETER[\"Latitude_Of_Origin\",0.0],UNIT[\"Meter\",1.0]]
PROJ.4 string:
+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9999 +x_0=500000 +y_0=-5000000 +ellps=bessel +units=m +no_defs +type=crs
WKT2:2019 string:
PROJCRS["SI-D-48-Gauss_Kruger",
BASEGEOGCRS["Unknown datum based upon the Bessel 1841 ellipsoid",
DATUM["Bessel_1841",
ELLIPSOID["Bessel 1841",6377397.155,299.1528128,
LENGTHUNIT["metre",1],
ID["EPSG",7004]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["Degree",0.0174532925199433]]],
CONVERSION["unnnamed (Gauss Kruger)",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["Degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",15,
ANGLEUNIT["Degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9999,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",500000,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",-5000000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]]]
Identification match count: 2
ESRI:102060: 70 %
EPSG:3912: 70 %
So this is a duplicate of #1911
The ESRI wkt string
Corresponds to the EPSG:3912 crs in ESRI software. While proj will parse this wkt, identifying it gives no results. Likely this is a result of the aliases used in the string (eg SI-D-48-Gauss_Kruger).