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

cs2cs 5.0.0 ignores +vunits #833

Closed
sebastic opened this Issue Mar 4, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@sebastic
Contributor

sebastic commented Mar 4, 2018

As reported in Debian Bug #889936, survex 1.2.32 failed to build due to test failures.

The maintainer (@ojwb) responded that its caused by +vunits being ignored:

On Thu, Feb 08, 2018 at 10:55:00PM +0100, Bas Couwenberg wrote:

Your package FTBFS due to missing compatibility with Proj 5.0.0:

 ./csbadsdfix.svx:2: error: Station "1" fixed before CS command first used
 ./csbadsdfix.svx:3:5: error: Unknown coordinate system
  *cs EPSG:-1
      ^~~~~~~
 ./csbadsdfix.svx:4:5: error: Unknown coordinate system
  *cs ERSI:1234
      ^~~~~~~~~
 ./csbadsdfix.svx:5:5: error: Unknown coordinate system
  *cs EUR79Z31
      ^~~~~~~~

[...]

This isn't the problem (these testcases are testing that we reject
coordinate systems which aren't valid, so these errors are expected and
correct).

The test failure seems to be actually due to the new PROJ4 ignoring
+vunits entirely and can be reproduced without involving Survex by
using cs2cs:

$ echo 36000 83000 5250|cs2cs +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +vunits=ft +to +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232
36000.00	83000.00 5250.00

In older versions this converted the altitude from feet to metres, and
the output was:

36000.00	83000.00 1600.20

Debug output of cs2cs 4.9.3:

$ echo 36000 83000 5250 | PROJ_DEBUG=3 cs2cs +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +vunits=ft +to +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232
pj_open_lib(proj_def.dat): call fopen(/usr/share/proj/proj_def.dat) - succeeded

pj_open_lib(proj_def.dat): call fopen(/usr/share/proj/proj_def.dat) - succeeded

36000.00        83000.00 1600.20

Debug output of cs2cs 5.0.0:

$ echo 36000 83000 5250 | PROJ_DEBUG=3 cs2cs +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +vunits=ft +to +proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232
get_init: searching cache for key: [proj_def.dat:general]

get_init: searching on in init files for [proj_def.dat:general]

get_init_string: searching for section [general] in init file [proj_def.dat]

pj_open_lib(proj_def.dat): call fopen(/usr/share/proj/proj_def.dat) - succeeded

key=proj_def.dat:general, value: [ellps=WGS84]

get_init: got [ellps=WGS84], paralist[0,1]: [ellps=WGS84,(empty)]

get_init: searching cache for key: [proj_def.dat:tmerc]

get_init: searching on in init files for [proj_def.dat:tmerc]

get_init_string: searching for section [tmerc] in init file [proj_def.dat]

pj_open_lib(proj_def.dat): call fopen(/usr/share/proj/proj_def.dat) - succeeded

pj_ellipsoid - final: a=6377397.155 f=1/299.153, errno=0
pj_ellipsoid - final:    ellps=bessel
get_init: searching cache for key: [proj_def.dat:general]

get_init: searching cache for key: [proj_def.dat:tmerc]

get_init: searching on in init files for [proj_def.dat:tmerc]

get_init_string: searching for section [tmerc] in init file [proj_def.dat]

pj_open_lib(proj_def.dat): call fopen(/usr/share/proj/proj_def.dat) - succeeded

pj_ellipsoid - final: a=6377397.155 f=1/299.153, errno=0
pj_ellipsoid - final:    ellps=bessel
36000.00        83000.00 5250.00

@kbevers kbevers added this to the 5.0.1 milestone Mar 5, 2018

@sebastic

This comment has been minimized.

Contributor

sebastic commented Mar 5, 2018

I don't see any code for vto_meter in pj_transform() any more, the two (src & dst) blocks in 4.9.3 were removed.

@busstoptaktik

This comment has been minimized.

Member

busstoptaktik commented Mar 5, 2018

I don't see any code for vto_meter in pj_transform() any more, the two (src & dst) blocks in 4.9.3 were removed.

This bug was likely introduced when I repaired the ghastly issue #726. Will look into it tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment