[PROJ] Wrong transformation in NL?
Greg Troxel
gdt at lexort.com
Sat Feb 21 17:22:30 PST 2026
Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> writes:
> Just testing something else, I tried this transformation to go test that
> the grids are properly used.
> In master this seems to be wrong
>
> echo 52 5 0 | PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/cs2cs EPSG:4326+3855
> EPSG:7415
> 128410.09 445806.51 -43.41
>
> ./bin/cs2cs
> Rel. 9.8.0, March 2nd, 2026
>
> While in the native cs2cs in Ubuntu 24.04 makes more sense. Just 20 cm
> difference between EGM2008 and NAP height.
>
> echo 52 5 0 | PROJ_NETWORK=ON cs2cs EPSG:4326+3855 EPSG:7415
> 128410.10 445806.50 0.20
>
> cs2cs
> Rel. 9.4.0, March 1st, 2024
Separately from what's being viewed as a bug, etc. WGS84 is an ensemble
with 2m error just from the ensemble. But I would then expect any wrong
answers people are complaining about to be within 2m or so.
Am I reading this right that 0 m in EGM2008 is 20 cm in NAP? (I get it
that this is super close and we expect close since they are both trying
to match mean sea level, with the caveat that mean sea level is a
difficult concept, with EGM2008 tied to some global MSL and NAP to some
measured sea level over some period at one(?) tide gauge.)
What I'm boggled by is -43.41 m. That feels like a geoid height, not a
difference it orthometric datum reference surface. Which suggests that
something is more seriously wrong.
> If my tests are correct, and I had to guess, I would say it is a
> consequence of the new ETRS89 ensemble.
Do you mean "ETRS89 recently got a new member ETRF2020"? Without really
understanding, I would expect coordinate differences between ETRF2000
and ETRF2020 to be on the order of one to a few cm, and that this is not
able to explain a 1m delta, let along 43m.
(Also, I think this discussion is all about NAP and not about EVRF at
all.)
More information about the PROJ
mailing list