Jochem
*RDNAP to ITRF2014:*
echo 128410.0957 445806.4960 -0.4754 2023.00 | cs2cs epsg:7415
epsg:7912 -d 9
The result is a null transformation, which is _not_ what we recommend:
52.00000_0000_ 5.00000_0000_ 43.0_000_ 2023.00
You didn't mention which PROJ version you use. But starting with 9.1.0,
here's the result I get:
$ echo 128410.0957 445806.4960 -0.4754 2023.00 | PROJ_NETWORK=ON
PROJ_DEBUG=2 bin/cs2cs epsg:7415 epsg:7912 -d 9
[...]
Using coordinate operation Inverse of RD New + Amersfoort to ETRS89 (9)
+ Inverse of ETRS89 to NAP height (2) + Null geographic offset from
ETRS89 (geog3D) to ETRS89 (geog2D) + ETRS89 to ETRF2014 + Conversion
from ETRF2014 (geog2D) to ETRF2014 (geocentric) + Inverse of ITRF2014 to
ETRF2014 (2) + Conversion from ITRF2014 (geocentric) to ITRF2014 (geog3D)
[...]
52.000004918 5.000008844 43.001783708 2023.00
This is the first pipeline suggested by projinfo -s epsg:7415 -t epsg:7912:
unknown id, Inverse of RD New + Amersfoort to ETRS89 (9) + Inverse of
ETRS89 to NAP height (2) + Null geographic offset from ETRS89 (geog3D)
to ETRS89 (geog2D) + ETRS89 to ETRF2014 + Conversion from ETRF2014
(geog2D) to ETRF2014 (geocentric) + Inverse of ITRF2014 to ETRF2014 (2)
+ Conversion from ITRF2014 (geocentric) to ITRF2014 (geog3D), 0.102 m,
Netherlands - onshore, including Waddenzee, Dutch Wadden Islands and
12-mile offshore coastal zone., at least one grid missing
PROJ string:
+proj=pipeline
+step +inv +proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889
+k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel
+step +proj=hgridshift +grids=nl_nsgi_rdtrans2018.tif
+step +proj=vgridshift +grids=nl_nsgi_nlgeo2018.tif +multiplier=1
+step +proj=cart +ellps=GRS80
+step +inv +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
So this kind of works, but using the ETRS89 -> ETRF2014 direct
transformation, not through the ETRF2000 -> ETRF2014 one you expect,
which is quite logical since NAP height is only linked to ETRS89.
I assume that the best way to fix this is to ask EPSG to link RDNAP to
ETRF2000 instead of the ETRS89 datum ensemble. Would that indeed solve
the problem in PROJ?
I wouldn't say "instead", but "in addition". There should likely be a
ETRF2014 to NAP height transformation, and a Amersfoort to ETRF2014 one
(that could be a concatenation of Amersfoort to ETRS89 (9) + ETRS89 ->
ETRF2000 + ETRF2000 -> ETRF2014 or Amersfoort to ETRS89 (9) + ETRS89 ->
ETRF2014 depending on your preference)
Kind regards, Jochem
Disclaimer:
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor
de geadresseerde(n).
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of
verstrekking van deze informatie aan derden is niet toegestaan.
Op al onze producten en diensten zijn onze algemene
leveringsvoorwaarden van toepassing
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].
Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the intended recipient, you are notified that
disclosing, copying, distributing or taking any action in reliance on
the contents of this information is strictly prohibited.
Our general terms and conditions of delivery apply to all our products
and services
[https://www.kadaster.com/general-terms-and-conditions].
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
