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

[Martin Desruisseaux]

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.maptools.org/pipermail/proj/attachments/20180122/4ed50cc0/attachment.htm