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

[Greg Troxel]

XCTrails <info at xctrails.org> writes:

> I have input polygon in epsg:31468 which I need to transform to epsg:4326
>
> My current code boils down to this:
>
> project = pyproj.Transformer.from_crs("EPSG:31468","EPSG:4326",
> always_xy=True)
> poly = transform(project.transform, poly)
>
> The problem however is that the resulting polygons have a 1-2 meter offset
> according to visual inspection in QGIS. On reddit, someone suggested that I
> might also need a datum transformation, on the pyproj4 issue tracker
> someone said, that datum transformations are no longer needed in PROJ 6+
> and that I should ask for clarification here. So here I am ;-)

I'm not familiear with 31468 (but am with similar concepts in the US,
where all the details are different), so take this with a grain of salt.
Even if I'm wrong trying to explain to me how I'm wrong is likely a
useful clarifying exercise :-)

You said "1-2 meter offset" but you didn't say what was offset to what,
and the project CRS (equivalent concept applies outside of qgis) is.

I am unclear on how DHDN relates to ETRS.

It's not clear to me what the intrinsic error in transforms from DHDN to
other frames.  In the use, we have NAD27 (from 1927) and if when workign
with that you got only 1-2m offset you would be overjoyed and lucky.
With recent NAD83 (as of 2011), it's possible to talk about 0.5m offsets
sensibly.  I do not konw the vintage of DHDN but am guessing it is on
the older side.


EPSG:4326 is "WGS84", which is a datum ensemble, and thus a low-quality
datum.  Almost more or less by definition, "WGS84" and "1-2 meter
offset" do not go together; there is 1-2-m of variation between the
oldest member of the ensemble and WGS84(G1762), the newest and current
member.  However, there is no even medium-quality data in the oldest
member, so this would be of only academic interest if transformations to
WGS84 were not chosen as null because the old realization exists.

So, you could finesse this by transforming to ITRF2008 and then
transforming to WGS84.  If that's different from the one-step transform
to WGS84, that's a clue you are having null transform problems.



So I recommend that you understand very clearly:

  what datum are you using for your project CRS

  if you think you need to deal with WGS84, understand why, and think
  about mitigating the ensemble problem by choosing ITRF2008 instead,
  which is the same as WGS84(G1762) at the several mm level.

  how proj and hence qgis chooses null transforms when WGS84 is involved
-------------- 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/0a5e108f/attachment.sig>