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

[Greg Troxel]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210415/9cb1efb4/attachment.sig>