<div dir="ltr"><div>That relates to a question I have:</div><div><br></div><div>The conversion from ITRF2014 to NAD83(2011) has velocities. What should I set in the 4th dimension converting with proj?</div><div>- 2010 (that is the EPOCH of ITRF2014 I guess. BTW, strange name then)</div><div>- 2021.3 (the date of the measurement I did this morning)</div><div>- something else</div><div>- it does not matter (it does, because it returns different values in projinfo)</div><div><br></div><div>Thanks<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, 15 Apr 2021 at 17:02, Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.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"><br>
XCTrails <<a href="mailto:info@xctrails.org" target="_blank">info@xctrails.org</a>> writes:<br>
<br>
> Maybe as background from where the problem originates:<br>
><br>
> I'm getting shapes in EPSG:31468 which will subsequently be imported/mapped<br>
> to OpenstreetMap. Eventually, there will be updates to the EPSG:31468<br>
> shapes and I'm in the process of writing a script which should detect shape<br>
> changes/deletions/additions. In order to be able to geometrically compare<br>
> the 2 datasets, my current workaround is to perform the transformation from<br>
> EPSG:31468 to EPSG:4326 manually in QGIS, the diff then runs on 2 4326<br>
> geojson files and produces reasonable polygon matches with an intersection<br>
> over union approach. Ideally, I'd like to get rid of the manual<br>
> transformation step in QGIS (along the way understanding the underlying<br>
> issue).<br>
><br>
> So, if I understand this correctly: creating a pyproj transformation using<br>
> one of the mentioned PROJ strings/pipelines should yield better results?<br>
> Within the limits of WGS84 - which might by in the same range as my<br>
> initially observed offset.<br>
<br>
I have also been transforming data for openstreetmap.   Some hints<br>
from my experience:<br>
<br>
Openstreetmap is documented to use WGS84.  This, strictly speaking means<br>
that data is in some realization of WGS84 and you don't know which.<br>
This is not a useful or reasonable approach in 2021, because the old<br>
version of WGS84 that contributes the most to the uncertainty has not<br>
been in use since the 90s and you are transforming *to* WGS84, so the<br>
idea that you don't know which realization you are transforming to is<br>
nonsensical.  Therefore, you should transform to a datum which is<br>
precisely defined and which is equivalent to the modern version of<br>
WGS84.  Candidates are IRF2008, ITRF2014 and WGS84(G1762) itself.<br>
However I had difficulty expressing WGS84(G1762) in proj so that the<br>
right thing happened.<br>
<br>
My source data is in "NAD83(2011) epoch 2010.0", which is similar to<br>
DHDN in that it is not ITRF/WGS84.  (Some of my data I have observed<br>
with RTK, and some is from government databases.)<br>
<br>
There is a particular problem in the US in that the first realization of<br>
NAD83 and first realization of WGS84 are equivalent, but WGS84 quickly<br>
moved towards ITRF.  But this leads to "transform NAD83 to WGS84" having<br>
a null transform, which is basically a wrong answer while technically<br>
true.  I do not know if this applies to your situation.<br>
<br>
So, what I have ended up doing is transforming the data from NAD83(2011)<br>
to ITRF2014, and then treating that as WGS84 for the purpose of using it<br>
in OSM.  This results in observed points lining up well with imagery<br>
published by my state government.  My original data in NAD83(2011)<br>
aligns with the imagery in its native NAD83(2011) coordinates within<br>
10-20cm.  And the transformed-to-ITRF2014 data align with the imagery as<br>
published as TMS, so they have obviously done a (non-null) transform as<br>
well.<br>
<br>
You will still need the grids, and also to understand what transform<br>
paths are available.  I would expect a lower-error path from DHDN to<br>
some ETRS to ITRF but that is wild speculation.  And you can look up the<br>
metadata on the grids that transform to "WGS84" and see when that is<br>
from and if it targets a particular realization.<br>
<br>
Beware that the EPSG database adopts error estimates from transforms<br>
without validating and correcting them, so what proj is doing by finding<br>
a min-error path is, while the best approach possible, strictly not<br>
really the right thing.  But the effort of determining consistent error<br>
bounds is enormous, and there is no indication anyone is going to do it.<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>