diff options
| author | Even Rouault <even.rouault@spatialys.com> | 2019-11-09 13:22:48 +0100 |
|---|---|---|
| committer | Even Rouault <even.rouault@spatialys.com> | 2019-11-09 13:22:48 +0100 |
| commit | 6780dea0b5f9bbdd5c073ca0dc212477d837c0b9 (patch) | |
| tree | a4c5ded125bb276685de65a447ec521262da4807 /src/iso19111/c_api.cpp | |
| parent | 25c4f55f8559a17e3d01668b0b3fbe3ea5aa5f97 (diff) | |
| download | PROJ-6780dea0b5f9bbdd5c073ca0dc212477d837c0b9.tar.gz PROJ-6780dea0b5f9bbdd5c073ca0dc212477d837c0b9.zip | |
Doc: document oddity related to identification of CRS from ESRI WKT
Or more generally formulations that don't have an explicit axis order.
Refs https://github.com/pyproj4/pyproj/issues/475
projinfo 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]'
returns EPSG:4326 with 100% confidence.
But its axis order is not the same as EPSG:4326.
I've pondered about this, like decreasing the confidence of the match,
but this would have downstream effects on GDAL (shapefiles with the
above content in a .prj would no longer be identified as EPSG:4326).
So for now, document that oddity.
Diffstat (limited to 'src/iso19111/c_api.cpp')
| -rw-r--r-- | src/iso19111/c_api.cpp | 24 |
1 files changed, 18 insertions, 6 deletions
diff --git a/src/iso19111/c_api.cpp b/src/iso19111/c_api.cpp index f3badb51..5f34a22b 100644 --- a/src/iso19111/c_api.cpp +++ b/src/iso19111/c_api.cpp @@ -2158,14 +2158,26 @@ PJ *proj_get_target_crs(PJ_CONTEXT *ctx, const PJ *obj) { * The method returns a list of matching reference CRS, and the percentage * (0-100) of confidence in the match. The list is sorted by decreasing * confidence. - * - * 100% means that the name of the reference entry + * <ul> + * <li>100% means that the name of the reference entry * perfectly matches the CRS name, and both are equivalent. In which case a * single result is returned. - * 90% means that CRS are equivalent, but the names are not exactly the same. - * 70% means that CRS are equivalent), but the names do not match at all. - * 25% means that the CRS are not equivalent, but there is some similarity in - * the names. + * Note: in the case of a GeographicCRS whose axis + * order is implicit in the input definition (for example ESRI WKT), then axis + * order is ignored for the purpose of identification. That is the CRS built + * from + * GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]], + * PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] + * will be identified to EPSG:4326, but will not pass a + * isEquivalentTo(EPSG_4326, util::IComparable::Criterion::EQUIVALENT) test, + * but rather isEquivalentTo(EPSG_4326, + * util::IComparable::Criterion::EQUIVALENT_EXCEPT_AXIS_ORDER_GEOGCRS) + * </li> + * <li>90% means that CRS are equivalent, but the names are not exactly the same.</li> + * <li>70% means that CRS are equivalent), but the names do not match at all.</li> + * <li>25% means that the CRS are not equivalent, but there is some similarity in + * the names.</li> + * </ul> * Other confidence values may be returned by some specialized implementations. * * This is implemented for GeodeticCRS, ProjectedCRS, VerticalCRS and |
