<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">
<p>Hello Eduardo<br>
</p>
<p>Le 22/01/2018 à 03:51, Eduardo Rojas Rodríguez a écrit :</p>
</div>
<blockquote type="cite"
cite="mid:1516589463599-0.post@n6.nabble.com">
<p wrap="">By having proj LCC 1SP with a scale factor is basically
the same as LCC 2SP.</p>
</blockquote>
<p align="justify">Indeed, EPSG <i>"Lambert Conic Conformal (1SP)"</i>
and <i>"Lambert Conic Conformal (2SP)"</i> 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 <i>"Mercator
(variant A)"</i>, <i>"Mercator (variant B)"</i> and <i>"Mercator
(variant C)"</i>. 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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:1516589463599-0.post@n6.nabble.com">
<p wrap="">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?<br>
</p>
</blockquote>
<p align="justify">Here we reach a known issue with the way Proj.4
stores its definitions. Proj.4 is what EPSG calls an <i>"early-binding
implementation"</i>, meaning that datum shift parameters (the <tt>"+towgs84"</tt>
element) are specified together with the Coordinate Reference
System (CRS) definitions (the <tt>"+lat_0"</tt>, <tt>"+lat_1"</tt>,
<tt>"+k_0"</tt>, <i>etc.</i> elements). In the EPSG database, map
projection definitions and datum shifts information are two
separated tables, for at least two reasons:</p>
<ul>
<li>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.</li>
<li>Many datum shifts may be defined between the same pair of CRS
for different area of validity.</li>
<li>(side note: with ongoing revision of ISO 19111 standard taking
in account tectonic plate motions, dissociating the two tables
will be yet more important).<br>
</li>
</ul>
<p align="justify">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:</p>
<ul>
<li>EPSG:6891 (looks similar but not identical to what you
reported the Proj.4 does), the domain of validity is <b>"Costa
Rica; El Salvador; Guatemala; Honduras; Nicaragua"</b> and the
reported accuracy is <b>14 metres</b>.</li>
<li>EPSG:5470, the domain of validity is <b>"Costa Rica -
onshore"</b> and the reported accuracy is <b>8 metres</b>.</li>
</ul>
<p align="justify">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 <i>"early-binding implementation"</i> to <i>"late-binding
implementation"</i>, 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.<br>
</p>
<p align="justify"> Martin</p>
<p align="justify"><br>
</p>
</body>
</html>