diff options
| author | Even Rouault <even.rouault@spatialys.com> | 2022-03-16 12:24:22 +0100 |
|---|---|---|
| committer | Even Rouault <even.rouault@spatialys.com> | 2022-03-16 12:24:25 +0100 |
| commit | 3e7984f3b26e408e69b960f8e0d03b6ac0576188 (patch) | |
| tree | e8b57c5cd870103c5514438eeb388be0ca958410 /test/cli/testprojinfo_out.dist | |
| parent | 77751f6c9e023748a90793774e8e4b554515e8b5 (diff) | |
| download | PROJ-3e7984f3b26e408e69b960f8e0d03b6ac0576188.tar.gz PROJ-3e7984f3b26e408e69b960f8e0d03b6ac0576188.zip | |
Transformation: no longer do vertical trasnformation when doing compound CRS to 2D CRS / add --3d to cs2cs
Previously, when computing transformation between a compound CRS and a
geographic/projected 2D CRS, the behaviour was similar to implicitly
promoting the 2D CRS to 3D CRS in the pipeline computation logic, hence
a geoid model could be applied. But note that when doing a geographic 3D
to geographic/projected 2D CRS transformation, we *did* not do this implicit
promotion and if a Helmert transformation existed between the datums, it
was done only in 2D. So this is a bit inconsistent and triggered the
comment in https://github.com/OSGeo/PROJ/issues/2318#issuecomment-1068924513
With this commit, we no longer do any vertical transformation when doing
compound CRS to the 2D CRS, but just take the transformation of the
horizontal part of the compound CRS to the 2D CRS.
Said otherwise, NAD83+NAVD88 to NAD83 will no longer lead to the
application of the geoid model. Unless you explicitly ask for the
promotion NAD83 to 3D.
Also related, in https://github.com/OSGeo/PROJ/issues/1563 that went to 6.3.0,
I changed cs2cs to automatically promote to 3D the CRS as soon as one of
them was compound, for the sake of being consistent with the past
behaviour. But it then becomes difficult to predict PROJ behaviour
depending on which level of it you consider...
This commit undoes that and adds an explicit --3d switch to cs2cs, similarly to
projinfo, to ask for promotion.
Other bug fix found in the process, when using legacy syntax, +init=epsg:4979,
(WGS 84 3D), the resulting CRS was 2D and not 3D.
Diffstat (limited to 'test/cli/testprojinfo_out.dist')
| -rw-r--r-- | test/cli/testprojinfo_out.dist | 8 |
1 files changed, 3 insertions, 5 deletions
diff --git a/test/cli/testprojinfo_out.dist b/test/cli/testprojinfo_out.dist index cb80bdd0..952c6b38 100644 --- a/test/cli/testprojinfo_out.dist +++ b/test/cli/testprojinfo_out.dist @@ -1243,10 +1243,8 @@ PROJCRS["WGS 84 / UTM zone 31N", REMARK["Promoted to 3D from EPSG:32631"]] Testing -s EPSG:32631 -t EPSG:4326+3855 --summary -Candidate operations found: 3 -unknown id, Inverse of UTM zone 31N + WGS 84 to EGM2008 height (1), 1 m, World. -unknown id, Inverse of UTM zone 31N + WGS 84 to EGM2008 height (2), 0.5 m, World. -unknown id, Inverse of UTM zone 31N + Inverse of Transformation from EGM2008 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction), unknown accuracy, World, has ballpark transformation +Candidate operations found: 1 +unknown id, Inverse of UTM zone 31N + Inverse of Null geographic offset from WGS 84 to WGS 84, 0 m, World. Testing -s EPSG:32631 -t EPSG:4326+3855 --3d --summary Candidate operations found: 3 @@ -1262,7 +1260,7 @@ Candidate operations found: 2 unknown id, Ballpark geocentric translation from ETRS89 to WGS 84, unknown accuracy, World, has ballpark transformation INVERSE(EPSG):9225, Inverse of WGS 84 to ETRS89 (2), 0.1 m, Germany - offshore North Sea. Netherlands - offshore east of 5E. -Testing -s +proj=longlat +datum=WGS84 +geoidgrids=@foo.gtx +type=crs -t EPSG:4326 -o PROJ -q +Testing -s +proj=longlat +datum=WGS84 +geoidgrids=@foo.gtx +type=crs -t EPSG:4979 -o PROJ -q +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=vgridshift +grids=@foo.gtx +multiplier=1 |