Thanks to Kristian and Even for some very thorough answers. That was
somewhat heavy reading (for me at least) on such an ordinary Wednesday :-)
I'll guess that QGIS (or the underlying transformation library) is using
some of the "earlier" realizations for both ETR89 and WGS84 datums since
the ETR89/UTM32N and WGS84/UTM32N coordinates of a given location is so
close to each other (0.1 mm)
Actually the answer was more than I had hoped for. I'm currently
teaching some students at the Forestry College, University of
Copenhagen some /elementary/ knowledge of projections as a part of their
GIS education.
I'll try to incorporate this knowledge into the curriculum - hopefully
without exploding their brains (or mine) !
--
Med venlig hilsen / Kind regards
Bo Victor Thomsen
Den 25-09-2019 kl. 10:12 skrev Kristian Evers:
For funsies, let's try to do this using the transformations I linked in my
previous email. Here I have used a coordinate that is actually in Denmark.
Using what is currently the best transformation between ITRF2014 and the local
Danish realization of ETRS89 ([email protected] for those who might find that
interesting). I get a horizontal difference between the two of 75.1 cm
echo 12 55 0 2019.0 | cct -d 10 +proj=pipeline +step +proj=cart +ellps=GRS80
+step +init=NKG:ITRF2014 +inv +step +init=NKG:DK
11.9999917811 54.9999951856 -0.0116067529 2019.0000
echo 55 12 54.9999951856 11.9999917811 | geod -I +ellps=GRS80 +units=cm
-135d32'21.267" 44d27'38.709" 75.092
Unless you care about cm to mm accuracy you will be fine using the
transformations that projinfo suggests :-)
/Kristian
-----Original Message-----
From: QGIS-Developer <[email protected]> On Behalf Of Even
Rouault
Sent: 25. september 2019 09:52
To: [email protected]
Subject: Re: [QGIS-Developer] CRS problems with WGS84 and ETRS89
How come ? Or is the error-source sitting ca. 70 cm in front of the
screen ?? (I have a 34" large flatscreen :-)
Because the data for such a transform isn't in the EPSG database.
I believe the main reason is that both WGS84 and ETRS89 are in fact datum
ensembles, that is a short and convenient nickname for a number of more
well-defined datum realizations. For WGS84, you have 6 different realizations
from Transit to G1762. And ETRS89 has 11 realizations from ETRF89 to ETRF2014
So to get accurate data, you must research tranformations between those direct
realizations. And in EPSG, accurate transformations tend not being given in
terms of WGS84 realizations but from their equivalent ITRF realizations
(WGS84(G1762) is identical to ITRF2014 within ~1cm),
so, while playing with PROJ' projinfo utility,
$ projinfo -s ITRF2014 -t ETRF2014
I see 2 potential coordinate transformations, and the one that makes probably
more sense today is the one using epoch 2010 for the transformation:
unknown id, Conversion from ITRF2014 (geog2D) to ITRF2014 (geocentric) +
ITRF2014 to ETRF2014 (2) + Conversion from ETRF2014 (geocentric) to ETRF2014
(geog2D), 0 m, Europe - ETRS89
PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert
+xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +proj=helmert +x=0
+y=0 +z=0 +rx=0.001785 +ry=0.011151 +rz=-0.01617 +s=0 +dx=0 +dy=0 +dz=0
+drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=2010
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
And you need of course to specify the coordinate epoch of your coordinates as
ITRF/WGS84 are Earth-fixed/dynamic datums.
echo "49 2 0 2019.6" | cct -d 10 +proj=pipeline +step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step
+proj=helmert +x=0 +y=0 +z=0 +rx=0.001785 +ry=0.011151 +rz=-0.01617 +s=0 +dx=0 +dy=0
+dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=2010
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert
+xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
48.9999955186 1.9999924499 -0.0016582003 2019.6000
Actually using the first proposal using an epoch at 1989, I get exactly the
same results
echo "49 2 0 2019.6" | cct -d 10 +proj=pipeline +step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step
+proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0 +dy=0 +dz=0 +drx=8.5e-05
+dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=1989 +convention=position_vector +step +inv
+proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step
+proj=axisswap +order=2,1
48.9999955186 1.9999924499 -0.0016582003 2019.6000
That's a 74cm horizontal shift
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
