[PROJ] Transforming from epsg:4326 to epsg:31468 produces a 2 meter offset

[Javier Jimenez Shaw]

That relates to a question I have:

The conversion from ITRF2014 to NAD83(2011) has velocities. What should I
set in the 4th dimension converting with proj?
- 2010 (that is the EPOCH of ITRF2014 I guess. BTW, strange name then)
- 2021.3 (the date of the measurement I did this morning)
- something else
- it does not matter (it does, because it returns different values in
projinfo)

Thanks
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Thu, 15 Apr 2021 at 17:02, Greg Troxel <gdt at lexort.com> wrote:

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