<div dir="ltr">i.e. your transformation is *exact by definition*: It defines the new system in terms<div>of the old (or probably more likely the other way round, but in that case we</div><div>will - formally - have to talk about a re-definition of the old system).<div><br></div><div>I wrote a related comment about the reverse situation (the full matrix formulation</div><div>not being strictly valid) in the code for PJ_helmert.c:</div><div><br></div><div><div><font face="monospace, monospace">If the option "approximate" is set, small angle approximations are used:</font></div><div><font face="monospace, monospace">The matrix elements are approximated by expanding the trigonometric</font></div><div><font face="monospace, monospace">functions to linear order (i.e. cos(x) = 1, sin(x) = x), and discarding</font></div><div><font face="monospace, monospace">products of second order.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">This was a useful hack when calculating by hand was the only option,</font></div><div><font face="monospace, monospace">but in general, today, should be avoided because:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">1. It does not save much computation time, as the rotation matrix</font></div><div><font face="monospace, monospace"> is built only once, and probably used many times.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">2. The error induced may be too large for ultra high accuracy</font></div><div><font face="monospace, monospace"> applications: the Earth is huge and the linear error is</font></div><div><font face="monospace, monospace"> approximately the angular error multiplied by the Earth radius.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">However, in many cases the approximation is necessary, since it has</font></div><div><font face="monospace, monospace">been used historically: Rotation angles from older published datum</font></div><div><font face="monospace, monospace">shifts may actually be a least squares fit to the linearized rotation</font></div><div><font face="monospace, monospace">approximation, hence not being strictly valid for deriving the full</font></div><div><font face="monospace, monospace">rotation matrix.</font></div><div class="gmail_extra"><br><div class="gmail_quote">In principle it would not be a problem to switch Proj.4 to the full matrix convention</div><div class="gmail_quote">even for the +towgs84 case, but in practice it would, for exacly the same reason</div><div class="gmail_quote">that you need it the other way round: The approximate versions being correct</div><div class="gmail_quote">*by definition*. We would need to introduce an "+noapproximation" option, to</div><div class="gmail_quote">keep the classic behaviour intact by default.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Feel free to submit a pull request implementing this!</div><div class="gmail_quote"><br></div><div class="gmail_quote">/Thomas</div><div class="gmail_quote"><br></div><div class="gmail_quote">2017-03-23 11:52 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">Hello Antoine,<br>
<br>
My coordinates in the old frame have precision of a few cm (obtained by<br>
triangulation a hundred years ago) and the coordinates in the new frame 1 cm<br>
(obtained by static GPS measurements 15 years ago). Both networks are tied<br>
to WGS84 with an precision of a few metres.<br>
<br>
However the two frames are tied to each other far more precisely. The<br>
relative transformation parameters have a precision of a few cm, since these<br>
are based on the measurements. However these parameters have been in use for<br>
some time now in software with strict formulas, and by that they have become<br>
more or less official. Therefore, I need Proj.4 to produce the exact same<br>
result (+/- 1 mm) as the other software with the strict formulas.<br>
<br>
Regards, Jochem<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5313833.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/towgs84-<wbr>approximation-error-<wbr>tp5313738p5313833.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></div>