[Proj] Correction of definition of CRS EPSG 5456 and 5457

[Kristian Evers]

Just a few comments regarding early-binding EPSG definitions in PROJ.4. This is indeed a shortcoming . The good news is that we are actively working towards changing the situation. With the new version, that will be released soon(-ish), we introduce “transformation pipelines” that lays the foundation for a late-binding implementation in the future. Specifically,  the a late-binding implementation logic is destined to go into the proj_create_crs_to_crs function in the new API. The discussion about this has been spread out across several GitHub issues on both the PROJ.4 and QGIS pages. Here’s a link to one of the discussions touching on the need for the possibility to specify the area for which a given transformation is needed: https://github.com/OSGeo/proj.4/issues/559

The actual work towards a late-binding implementation will probably be started in the second half of 2018. At least if I am going to take lead on it. I have a rough idea how to do it, but haven’t got the time until after summer to actually do it.

/Kristian

Fra: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] På vegne af Martin Desruisseaux
Sendt: 22. januar 2018 10:52
Til: proj at lists.maptools.org
Emne: Re: [Proj] Correction of definition of CRS EPSG 5456 and 5457


Hello Eduardo

Le 22/01/2018 à 03:51, Eduardo Rojas Rodríguez a écrit :

By having proj LCC 1SP with a scale factor is basically the same as LCC 2SP.

Indeed, EPSG "Lambert Conic Conformal (1SP)" and "Lambert Conic Conformal (2SP)" are basically the same projection with different way to specify parameters. After those parameters have been converted to internal coefficients, both projections can be implemented by the same formulas. The same observation applies to some other projections, for example "Mercator (variant A)", "Mercator (variant B)" and "Mercator (variant C)". As a side note, the Mercator projection itself is the limit case of Lambert Conic Conformal projection when the standard parallel is at the equator, and similar relationships exists between some other projections.



the only thing then is to ask the EPSG for a transformation of EPSG :: 5470 Coordinate Transformation [Ocotepeque 1935 to WGS 84 (1) more presiding using 7 parameters. maybe?

Here we reach a known issue with the way Proj.4 stores its definitions. Proj.4 is what EPSG calls an "early-binding implementation", meaning that datum shift parameters (the "+towgs84" element) are specified together with the Coordinate Reference System (CRS) definitions (the "+lat_0", "+lat_1", "+k_0", etc. elements). In the EPSG database, map projection definitions and datum shifts information are two separated tables, for at least two reasons:

  *   Datum shifts are not necessarily between the CRS and WGS84. In some cases (e.g. in Martinique), passing through WGS84 can only introduce errors in the results.
  *   Many datum shifts may be defined between the same pair of CRS for different area of validity.
  *   (side note: with ongoing revision of ISO 19111 standard taking in account tectonic plate motions, dissociating the two tables will be yet more important).

In your case, the EPSG database gives me 3 coordinate operations from EPSG:5451 to EPSG:4326 (in addition of two operations to NAD27 and to CR05; this illustrates what I said before, that datum shift operations are not necessarily toward WGS84). Among them:

  *   EPSG:6891 (looks similar but not identical to what you reported the Proj.4 does), the domain of validity is "Costa Rica; El Salvador; Guatemala; Honduras; Nicaragua" and the reported accuracy is 14 metres.
  *   EPSG:5470, the domain of validity is "Costa Rica - onshore" and the reported accuracy is 8 metres.

So the datum shifts to choose depends of the desired compromise between accuracy and domain of validity. I think that by default, parameters in Proj.4 CSV files were selected for the datum shift operation which is valid over the widest area. An improvement over that would be to change Proj.4 design from "early-binding implementation" to "late-binding implementation", when datum shifts operation are fetched from a separated table once Proj.4 know the source and target CRS, the desired domain of validity and the epoch. They were some discussion one or two years ago about replacing the Proj.4 CSV file by a full EPSG database on SQLite, in order to prepare Proj.4 for such evolution.

    Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180122/765297f1/attachment.html>