Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unspecified +vunits no longer scaled the same amount as +units #2624

Closed
dmahr1 opened this issue Mar 29, 2021 · 2 comments
Closed

Unspecified +vunits no longer scaled the same amount as +units #2624

dmahr1 opened this issue Mar 29, 2021 · 2 comments

Comments

@dmahr1
Copy link

dmahr1 commented Mar 29, 2021

Problem description + examples

I am upgrading some old code that unprojects + transforms coordinates from an arbitrary input to WGS84. With PROJ 6.2.1 it correctly converts the input 650.000 foot elevation to 198.120 meters:

$ docker run --rm -it osgeo/proj:6.2.1 bash
root@aa66cbfb0aed:/# echo 3200000 10200000 650 | cs2cs "epsg:6578" "epsg:4326" -f %.3f
30.618  -97.461 198.120

But starting with PROJ 6.3.0 the z-coordinate is unchanged at 650.000:

$ docker run --rm -it osgeo/proj:6.3.0 bash
root@24492e9f6418:/# echo 3200000 10200000 650 | cs2cs "epsg:6578" "epsg:4326" -f %.3f
30.618  -97.461 650.000

It appears that PROJ used to assume that the +vunits for horizontal CRSs was the same as the +units. But this is no longer the case. Is this expected behavior, or a regression?

The only related PR or issue I found was #1731.

Environment Information

  • Docker versions osgeo/proj:6.2.1 and osgeo/proj:6.3.0

Installation method

  • Docker
@dmahr1 dmahr1 added the bug label Mar 29, 2021
@rouault
Copy link
Member

rouault commented Mar 29, 2021

The issue here is that you convert between two 2D CRS. EPSG:6578 has US-survey-foot for horizontal components, but we know nothing about the vertical direction: is it ellipsoidal height or orthometric height, in meters, us-survey-foot, whatever... So the behaviour of the transform of the Z component is completely unspecified. There was indeed a change of behaviour in the 6.x series regarding that, but neither, nor the new behaviour are correct. To get reliable transformation of Z, you need to use 3D CRS, that is either Compound CRS (Projected/Geographic + Vertical), Projected 3D CRS (with ellipsoidal height) or Geographic 3D CRS (with ellipsoidal height).

@rouault rouault removed the bug label Mar 29, 2021
@dmahr1
Copy link
Author

dmahr1 commented Mar 29, 2021

@rouault Thank you for confirming my suspicion! It seems like the old code was relying on undefined behavior. I will change the code to either specify the +vunits explicitly or use a 3D CRS.

@dmahr1 dmahr1 closed this as completed Mar 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants