Database: update to EPSG v12.022 #4562
Conversation
That's the idea, yes.
I believe in the end this should replicate the current Lines 1810 to 1817 in ff43c46 I think it's difficult to get the metadata of the deformation model correct. Technically it is aligned to NKG_ETRF14 but it is (also) used in conjunction with the different national realizations of ETRS89. From a data modelling viewpoint it might have been better to simple say the interpolation CRS is ETRS89. In practice it works because the differences between the realizations are very small. In conclusion, I don't think there's a problem here. |
|
Yes, as @kbevers pointed out, any ETRS89 realization as the interpolation CRS is ok because the velocity model is so smooth (even much bigger differences in input coordinates will still give the same result with significant digits). This is also mentioned in the remarks of the EPSG:10808 (https://epsg.org/point-motion-operation_10808/NKG-land-uplift-deformation-model-NKG_RF17vel.html). @rouault, yes I can confirm the results from your test transformation (in the height I get 0.03128500 but that's probably rounding error somewhere and anyway not significant) |
|
I've added a commit that maps the 3 new EPSG methods used by NKG transformations: "Position Vector (geocen) & Geocen translations NEU velocities (gtg)", "Geocentric translations using NEU velocity grid (gtg)" and "Geocen translations by grid (gtg) & Geocen translations NEU velocities (gtg)" Quick check shows that it seems to be consistent with nkg.sql records, but could receive more testing... |
|
Thanks, Even! I'll try to run some tests as soon as possible. Likely it'll be on Monday. |
|
Thanks a lot Even and Kristian! |
|
@rouault, just to let you know (or maybe this was found by you?), I just heard that there is a mistake in the parameters of the Danish NKG2020 transformation (in EPSG:10893). There will be a fix in the very near future. |
…1.6) Demo ``` # Tests "Position Vector (geocen) & Geocen translations NEU velocities (gtg)" $ echo 3140996.6730 596336.8511 5500477.1338 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct NKG:ETRF14_TO_FI 3140996.7242 596336.8904 5500477.0896 inf $ echo 3140996.6730 596336.8511 5500477.1338 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct EPSG:10810 3140996.7242 596336.8904 5500477.0896 inf $ echo 3140996.7242 596336.8904 5500477.0896 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct -I NKG:ETRF14_TO_FI 3140996.6730 596336.8511 5500477.1338 inf $ echo 3140996.7242 596336.8904 5500477.0896 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct -I EPSG:10810 3140996.6730 596336.8511 5500477.1338 inf # Tests "Geocentric translations using NEU velocity grid (gtg)" and "Geocen translations by grid (gtg) & Geocen translations NEU velocities (gtg)" $ echo 3140996.6730 596336.8511 5500477.1338 2025 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct NKG:ITRF2014_TO_NO 3140997.2140 596336.4062 5500476.6768 2025.0000 $ echo 3140996.6730 596336.8511 5500477.1338 2025 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct EPSG:10817 3140997.2140 596336.4062 5500476.6768 2025.0000 $ echo 3140997.2140 596336.4062 5500476.6768 2025 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct -I NKG:ITRF2014_TO_NO 3140996.6730 596336.8511 5500477.1338 2025.0000 $ echo 3140997.2140 596336.4062 5500476.6768 2025 | PROJ_NETWORK=ON PROJ_DATA=data bin/cct -I EPSG:10817 3140996.6730 596336.8511 5500477.1338 2025.0000 ```
yes I warned EPSG about that. This PR includes a workaround to fix the wrong values. Regarding the "Geocentric translations using NEU velocity grid (gtg)" method used by EPSG:10809 ""ETRF2014 to NKG_ETRF14 (1)"", I've noticed that this transformation is in the reverse direction than NKG:NKG_ETRF14_TO_ETRF2014 , consequently to get the same results as that later operation, I've mapped it to "+proj=pipeline +step +inv +proj=deformation +t_epoch=2000 +grids=eur_nkg_nkgrf17vel.tif +ellps=GRS80". So we map the forward direction of the EPSG method to the reverse direction of the correspondig PROJ operation. Not a big deal, but just wanted to mention it. |
|
I've added a commit that integrates EPSG v12.022, which contains in particular the fix for operation EPSG:10893 and typo fixes in grid file names |
|
@rouault Yes, I will. :-) |
|
@himsve, it would be preferable if you can do it before the weekend. I'll prepare the next releases early next week and it would be good to have your additions included. |
|
I've tried to compare the current $ PROJ_DATA=./data/ ./bin/projinfo -k operation NKG:ITRF2014_TO_DK -o PROJ
PROJ string:
+proj=pipeline
+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=deformation +t_epoch=2000.0 +grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.66818 +y=0.04453 +z=-0.45049 +rx=0.00312883
+ry=-0.02373423 +rz=0.00442969 +s=-0.003136 +convention=position_vector
+step +proj=deformation +dt=15.829 +grids=eur_nkg_nkgrf17vel.tifThe EPSG equivalent has the same rotation rate parameters but also includes $ PROJ_DATA=./data/ ./bin/projinfo -s EPSG:7789 -t EPSG:10890 -o PROJ
Candidate operations found: 2
-------------------------------------
Operation No. 1:
EPSG:10894, ITRF2014 to ETRS89-DNK (1), 0.006 m, Denmark - onshore and offshore., at least one grid missing, time-dependent operation
PROJ string:
+proj=pipeline
+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=deformation +t_epoch=2000 +grids=eur_nkg_nkgrf17vel.tif
+ellps=GRS80
+step +proj=helmert +x=0.66818 +y=0.04453 +z=-0.45049 +rx=0.00312883
+ry=-0.02373423 +rz=0.00442969 +s=-0.003136 +convention=position_vector
+step +proj=deformation +dt=15.829 +grids=eur_nkg_nkgrf17vel.tif +ellps=GRS80
Grid NKG_RF17vel.tif needed but not found on the system.
-------------------------------------
Operation No. 2:
unknown id, Ballpark geocentric translation from ITRF2014 to ETRS89-DNK, unknown accuracy, World, has ballpark transformation
PROJ string:
+proj=noopIn the above output the final Trying an actual transformation using $ echo 3496736.2286 743254.2298 5264461.3868 2025.52 | PROJ_DEBUG=2 PROJ_DATA=./data/ ./bin/cs2c
s -d 4 EPSG:7789 EPSG:10890
pj_open_lib(proj.ini): call fopen(./data//proj.ini) - succeeded
pj_open_lib(proj.db): call fopen(./data//proj.db) - succeeded
pj_open_lib(eur_nkg_nkgrf17vel.tif): call fopen(/home/e012349/.local/share/proj/eur_nkg_nkgrf17vel.tif) - succeeded
pj_open_lib(NKG_RF17vel.tif): call fopen(./data//NKG_RF17vel.tif) - failed
3496736.2286 743254.2298 5264461.3868 2025.52The output is the same as the input. Obviously not what we want. The equivalent from $ echo 3496736.2286 743254.2298 5264461.3868 2025.52 | PROJ_DEBUG=2 PROJ_DATA=./data/ ./bin/cct
NKG:ITRF2014_TO_DK
pj_open_lib(proj.ini): call fopen(./data//proj.ini) - succeeded
pj_open_lib(proj.db): call fopen(./data//proj.db) - succeeded
pj_open_lib(eur_nkg_nkgrf17vel.tif): call fopen(/home/e012349/.local/share/proj/eur_nkg_nkgrf17vel.tif) - succeeded
pj_open_lib(eur_nkg_nkgrf17vel.tif): call fopen(/home/e012349/.local/share/proj/eur_nkg_nkgrf17vel.tif) - succeeded
3496736.8491 743253.7135 5264461.0077 2025.5200 |
|
@kbevers I've just added a commit that fixes the issue with the lack of substitution of NKG_RF17vel.tif . Now I get exactly the same results when using the EPSG or NKG pipelines: The pipelines are not the same, but are equivalent. For ITRF2014 to ETRF2014 , EPSG uses "ITRF2014 to ETRF2014 (2)" with a pivot epoch of 2010, whereas the NKG one uses "ITRF2014 to ETRF2014 (1)" with a pivot epoch of 1989.0. But both use the same translation and rotation rate, and the difference in static terms is just the rates times the diference of epoch. For example for +rx=0.001785 in "ITRF2014 to ETRF2014 (2)" : this is equal to drx * (2010 -1989) = 8.5e-5 * (2010 -1989) = 0.001785 . So both transformations are effectively equivalent. Comment of "ITRF2014 to ETRF2014 (1)" mentions "See ITRF2014 to ETRF2014 (2) (code 8880) for an exactly equivalent transformation but with the transformation's parameter values at epoch 2010.00" |
It actually has a (small) effect since deformation does a inverse cart to transform geocentric coordinates to geographic ones, to be able to fetch the grid point. But in practice, you need to define a very different ellipsoid than the default one (GRS80) to see an effect: vs |
So do I. Thanks!
Oh yeah, of course. I really should know this since I implemented the darn thing in the first place :) I guess |
|
You will find the related PR in OSGeo/PROJ-data#146. |
CC @kbevers @phakli I presume one or both of you have been involved in the batch of NKG related records in the latest EPSG update. The import of it into the PROJ database does not include yet the below new transformations because they rely on a new method 'Position Vector (geocen) & Geocen translations NEU velocities (gtg)' which isn't mapped yet in PROJ:
comparing that to the current nkg.sql, I presume this is the concatenation of a Helmert + deformation, but without using an explicit intermediate CRS. There's however a possible subtle difference. For example, for the https://epsg.org/transformation_10814/NKG_ETRF14-to-EST97-1.html transformation, EPSG records NKG_ETRF14 as the interpolation CRS for the grid interpolation, that is the initial CRS. But in NKG:ETRF14_TO_EE the interplation is done after the Helmert transformation. Maybe doing the grid interpolation before or after the Helmert transformation has little consequence on the final value, or maybe it has not?
Otherwise, the other currently only record I've mapped is the point motion model within ETRF2014. Could you confirm if the below test transformation is correct? (looks plausible to me for an uplift deformation)
$ echo 60 20 0 | PROJ_DATA=data PROJ_NETWORK=ON bin/cs2cs -d 8 "ETRF2014@2020" "ETRF2014@2025" --3d
59.99999996 20.00000000 0.03128600