Transformation: no longer do vertical trasnformation when doing compound CRS to 2D CRS / add --3d to cs2cs #3119
Conversation
…und 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 OSGeo#2318 (comment) 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 OSGeo#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.
|
This looks like a great improvement to the predictability of transformations, thank you! Is there a way to "demote" the compound CRS to 2D to force this behaviour in older versions? (EPSG or WKT representation would be fine) |
|
I think this change makes sense. I agree that is should only go to 9.1.x. |
What are some examples of the syntax and shorthand to do the promotion? We use |
this is invalid, but "NAD83 + NAVD88 height" or "EPSG:4269+5703" are strings recognized by proj_create().
There's no shorthand name to do the promotion (was discussed recently in #3075). Promotion only makes sense for geographic 2D CRS (compound CRS are already 3D by definition). You need to use the proj_crs_promote_to_3D() C API, or the --3d switch of projinfo and (just added in this PR) cs2cs, or the WKT resulting from "projinfo --3d NAD83 -o WKT2:2019 -q" |
|
This change means |
Those CRSs are compoundCRS. They are already 3D. Promoting them is a no-op. Promotion only makes sense for a 2D geographic or projected CRS, to add an ellipsoidal height to it. |
|
This makes sense to me 👍 |
… is 3D, with PROJ 9.1 Due to change OSGeo/PROJ#3119
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 #2318 (comment)
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 #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.
CC @kbevers @hobu @snowman2 : I'd be interested in hearing if you think this change of behaviour is a good idea. I think it is valuable as it makes PROJ behavior more predictable (and "correct"), but this has a price w.r.t backward compatibility. I believe this is material only candidate for 9.1, not 9.0.x (well, we could possibly backport the addition of the --3d switch to 9.0.x, but not the suppression of the automatic promotion, so that people can anticipate the future change of behaviour by opting in)