<div dir="ltr"><div>Ouch.</div><div><br></div><div>Thanks Even for the response.</div><div><br></div><div>I could not expect that such transformation was not published.</div><div>Now I see that WGS84(G1762) to ETRS89 goes through WGS84, with an accuracy of 3m. Looks like Europe is isolated from the World (in a datum accurate transformation sense ;)</div><div><br></div><div>Cheers.<br></div><div><div><div dir="ltr" data-smartmail="gmail_signature">.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... .... ._ .__<br>Entre dos pensamientos racionales <br>hay infinitos pensamientos irracionales.<br><br></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 29 Apr 2021 at 12:14, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>There is a transformation
from ETRS89 to CH1903+ with 0.1m accuracy. Why is not
using it (nested with ITRF2014 -> ETRS89)?</div>
</div>
</div>
</div>
</blockquote>
<p>Because there is no transformation registered between ITRF2014
and ETRS89 (*), so there's no reason to use the ETRS89
intermediate because the result would have a unknown accuracy.</p>
<p>(*) actually if you do "projinfo -s "ITRF2014" -t ETRS89
--spatial-test intersects", you'll see that it manages to compute
transformation paths for Nordic countries, but this is already
using an intermediate ETRF2014 pivot, so PROJ logic wouldn't be
able to do ITRF2014 -> ETRF2014 -> .... -> ETRS89 ->
CH1903+, and anyway the area of use aren't compatible<br>
</p>
--
<pre cols="72"><a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div>