<div dir="ltr"><div>Hi Jochem,</div><div><br></div><div>You say that you would like to do </div> ETRF2000(R14) <--7par--> pseudo_NL_Bessel <--NTv2--> true_NL_Bessel<--proj--> true_RD<div>In Proj.4</div><div><br></div><div>This will, as far as I can see, be possible with the Proj.4 pipeline implementation, when</div><div>Kristian's latest pull request "Horisontal and vertical gridshift drivers "</div><div>(cf. <a href="https://github.com/OSGeo/proj.4/pull/492">https://github.com/OSGeo/proj.4/pull/492</a> ).</div><div><br></div><div>Actually most of what has been mentioned in this thread (and the neighbouring thread about</div><div>dynamical reference systems) is possible using the transformation pipeline framework, which</div><div>Kristian and I have been designing and implementing over the last few months.</div><div><br></div><div>We're making progress, but we're flooded with other tasks as well, so time allocated to building this</div><div>is limited. The plan is, however, to retire our old and venerable transformation software, trlib</div><div>(<a href="https://bitbucket.org/KMS/trlib">https://bitbucket.org/KMS/trlib</a> ), so we have no other way to go than to extend Proj.4 with a full</div><div>geodetic framework.</div><div><br></div><div>The ubiquity of Proj.4 also means that, realistically speaking,</div><div>extending Proj.4 in this way will also be the only viable road to provide</div><div>"longterm centimeter accuracy to everyone, everywhere".</div><div><br></div><div>But this is just the first step: Once Proj.4 is capable of handling generic geodetic transformations,</div><div>we will have a long process going making the downstream application projects actually making</div><div>that available to end users. Here, we will have to depend on end-users actually reqiring and</div><div>requesting that support.</div><div><br></div><div>/Thomas</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">2017-03-24 11:29 GMT+01:00 Jochem <span dir="ltr"><<a href="mailto:jochem.lesparre@kadaster.nl" target="_blank">jochem.lesparre@kadaster.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Martin,<br>
<br>
Thanks for your clarifying email.<br>
<span class="gmail-"><br>
> Many different coordinate operations can exist for the same pair of CRS.<br>
> In USA, there is about 80 datum<br>
> shift operations from NAD27 to WGS84.<br>
<br>
</span>I think we should make a distinction between reference systems and reference<br>
frames here (I assume you are familiar with that). As each frame of a system<br>
will have different parameters. For a frame only one set of parameters is<br>
needed. If these are multiple sets, one could combine the information of all<br>
these stochastic transformations in to one best least-squares estimated set<br>
of parameters.<br>
<br>
However, maybe I should nuance my point that it is nonsense to store<br>
multiple sets of parameters also for a frame. There could be different sets<br>
of transformation parameters for one frame to WGS84 exist in practice, but<br>
here are no *mathematical* reasons to store redundant sets of parameters.<br>
<span class="gmail-"><br>
<br>
> I saw a statement saying that the CRS would be by definition an other CRS<br>
> with the coordinate operation<br>
> defined by the 7 parameters. But I still a little bit surprised by a<br>
> scenario where a derived CRS would be<br>
> defined by Bursa-Wolf parameters.<br>
<br>
</span>For the country where I am working this week, the parameters are not really<br>
by definition (conventional) but official (given) parameters. See the<br>
terminology below my email for the distinction between conventional defined,<br>
official given and self-estimated stochastic parameters.<br>
<br>
However, this is the case for the national grid (RD) of the Netherlands. RD<br>
is defined as the transformation (in ISO19111 terminology this would be a<br>
conversion?) from ETRS89, including a 7 parameter transformation, but also<br>
an correction grid on projected coordinates is used:<br>
<br>
ETRF2000(R05) <--7par--> pseudo_NL_Bessel <--proj--> pseudo_RD <--corr--><br>
true_RD<br>
<br>
Since this order of steps is not supported by Proj.4, EPSG etc., this<br>
procedure will probably be updated this year to:<br>
<br>
ETRF2000(R14) <--NTv2--> true_NL_Bessel <--proj--> RD<br>
<br>
However, I would like to see this possibility in Proj.4, EPSG, etc.:<br>
<br>
ETRF2000(R14) <--7par--> pseudo_NL_Bessel <--NTv2--> true_NL_Bessel<br>
<--proj--> true_RD<br>
<br>
This would be better for 2 reasons. First, the normal of the NL-Bessel<br>
ellipsoid is closer to the true vertical than the normal of ETRS89. Second,<br>
there are always stubborn users that will use RD outside the bounding box of<br>
the NTv2 grid (using: ETRF2000(R05) <--7par--> NL_Bessel <--proj--> RD). Of<br>
course they should not do that, but I know they will keep doing this and it<br>
is causing nasty problems at the edge of the bounding box. With the the<br>
combination of 7 parameters and a NTv2 grid, the values in the NTv2 grid<br>
could fade out to zero outside the Netherlands and the grid can cover the<br>
entire earth. This would produce complete nonsense for points outside the<br>
bounding box, but at least it will be the same consistent nonsense for all<br>
users without edge effects.<br>
<br>
<br>
Citation from Van der Marel, 2016<br>
<<a href="http://www.citg.tudelft.nl/fileadmin/Faculteit/CiTG/Over_de_faculteit/Afdelingen/Afdeling_Geoscience_and_Remote_Sensing/Study/CTB3310_TerrestrialReferenceSystems_TRS_2-1a.pdf" rel="noreferrer" target="_blank">http://www.citg.tudelft.nl/<wbr>fileadmin/Faculteit/CiTG/Over_<wbr>de_faculteit/Afdelingen/<wbr>Afdeling_Geoscience_and_<wbr>Remote_Sensing/Study/CTB3310_<wbr>TerrestrialReferenceSystems_<wbr>TRS_2-1a.pdf</a>><br>
:<br>
| A big difference between datum transformations and coordinate conversions<br>
is that the<br>
| parameters for the datum transformation are often empirically determined<br>
and thus subject<br>
| to measurement errors, whereas coordinate conversions are fully<br>
deterministic. More specific,<br>
| three possibilities need to be distinguished for the datum transformation<br>
parameters<br>
|<br>
| 1. The first possibility is that the datum transformation parameters are<br>
*conventional*. This<br>
| means they are chosen and therefore not stochastic. The datum<br>
transformation is then<br>
| just some sort of coordinate conversion (which are also not stochastic).<br>
|<br>
| 2. The second possibility is that the datum transformation parameters are<br>
*given*, but have<br>
| been derived by a third party through measurements. What often happens is<br>
that this<br>
| third party does new measurements and updates the transformation<br>
parameters occa-<br>
| sionally or at regular intervals. This is also related to the concepts of<br>
| reference system and reference frames. Reference frames are considered<br>
(different) realizations of the<br>
| same reference system, with different coordinates assigned to the points<br>
in the reference<br>
| frame, and often with different realizations of the transformation<br>
parameters. The sta-<br>
| tion coordinates and transformation parameters are stochastic, so new<br>
measurements,<br>
| mean new estimates that are different from the previous estimates.<br>
|<br>
| 3. The third possibility is that there is no third party that has<br>
determined the transformation<br>
| parameters, and you as user, have to *estimate *them using at least three<br>
common points<br>
| in both systems. In this case you will need coordinates from the other<br>
reference system.<br>
| Keep in mind that the coordinates from the external reference system all<br>
come from the<br>
| same realization, or, reference frame.<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5314039.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/towgs84-<wbr>approximation-error-<wbr>tp5313738p5314039.html</a><br>
<div class="gmail-HOEnZb"><div class="gmail-h5">Sent from the PROJ.4 mailing list archive at Nabble.com.<br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br>
</div></div></blockquote></div><br></div></div></div>