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

4D API does not process cs2cs-style proj-strings #700

Closed
kbevers opened this issue Dec 10, 2017 · 5 comments
Closed

4D API does not process cs2cs-style proj-strings #700

kbevers opened this issue Dec 10, 2017 · 5 comments

Comments

@kbevers
Copy link
Member

kbevers commented Dec 10, 2017

The problem

Parameters such as towgs84, nadgrids, geoidgrids, axis, units and vunits are only parsed and used by the pj_transform function. For the new 4D API to be truly useful it should be able to convert cs2cs-style proj-strings to pipelines. This is especially important as long as we still distribute init-files, such as the epsg-file, that uses the cs2cs parameters.

It should be possible to mimic the behaviour of cs2cs with the many new primitives that can be used in pipelines. The order of the steps in a pipeline is crucial. As far as I can tell from pj_transform the order when going from "WGS84" to e.g. epsg:xxxx is as described below. I've used plusses in front of the cs2cs-style to make it clearer which is which.

  1. Apply datum shift of horizontal coordinates:
    First look for a +datum parameters and expand it if it exist. After that we look for either +nadgrids or +towgs84. If both exists (they shouldn't, but they can), +nadgrids takes precedence. If we find one of the two parameters it expands to either:
    +towgs84=??? -> step proj=helmert x=? y=? z=? s=? rx=? ry=? rz=?
    or
    +nadgrids=???-> step proj=hgridshift grids=???

  2. Apply datum shift of vertical coordinates:
    +geoidgrids=???? -> step proj=vgridshift grids=????

  3. Projection:
    +proj=???? -> proj=??? arg1 arg2 arg3 ... argn

  4. Units:
    +units=??? +vunits=??? -> proj=unitconvert xy_in=m xy_out=??? z_in=m z_out=???

  5. Axis order:
    +axis=??? -> step proj=axisswap +order=?,?,?,?

Which in the end becomes pipeline that looks like:

proj=pipeline 
step proj=helmert x=? y=? z=? s=? rx=? ry=? rz=?
step proj=vgridshift grids=????
proj=??? arg1 arg2 arg3 ... argn
proj=unitconvert xy_in=m xy_out=??? z_in=m z_out=???
step proj=axisswap +order=?,?,?,?

In case the transfomation is reversed, that is init=epsg:xxxx to "WGS84", the above is also reversed.

Implementation

Implementation of the above is not entirely straight forward. We very quickly run into nesting pipelines which we only allow in case they are wrapped in init-files. This is a catch-22 for the epsg init-file and friends.

The most general way of doing this would be to handle it when expanding +init's in get_init(). This will affect initialisation of all tranformation objects, including those used by pj_transform(). The latter might not be the best idea at this time since the consequence of not getting it right is quite big. I think this need to be implemented in the new API only, although it might probe to be more difficult.

Since this is primarily an issue when using epsg and friends, we could create epsg4D etc as preprocessed translations of the cs2cs-style proj-strings to pipelines. This would require that proj_create() looks for a "4D"-version of whatever init-file is requested (could be as simple as a search and replace). Making epsg4D and friends can be done fairly quickly with a Python-script. By doing it this way we skip messing with pj_transform() and get_init() while still making it possible to use our distributed init-files with the new API.

Any thoughs on this are much appreciated!

@busstoptaktik
Copy link
Member

Currently, I'm working om PR #693, which heavily modifies the get_init function, you propose to leverage, so I would much prefer not to begin work on this issue until #693 is merged.

Unfortunately, I experience some annoying segmentation faults in the CI builds on Travis and AppVeyor, which I cannot provoke on my development platform (gcc version 7.1.0, x86_64-posix-seh-rev1, Built by MinGW-W64 project, and running under Windows 10), so I'm going through some pretty obnoxious remote, asynchronous debugging currently.

So any help from people able to reproduce the CI segfaults would be much appreciated.

@busstoptaktik
Copy link
Member

I'm working on this currently, but at a slow pace, due to other obligations. So do not expect a PR until about Jan. 10th

@busstoptaktik
Copy link
Member

I now realize that the +units and +vunits options are handled by pj_init_ctx, which converts them to to_meter and vto_meter elements. Since a3a67fb the scaling has been handled by the prep/fin steps in pj_fwd/pj_inv/pj_fwd3d/pj_inv3d/pj_fwd4d/pj_inv4d/proj_trans.

So it seems we do not need the proj=unitconvert step

@kbevers
Copy link
Member Author

kbevers commented Jan 6, 2018

So it seems we do not need the proj=unitconvert step

Nice, that simplifies things a bit.

@kbevers
Copy link
Member Author

kbevers commented Feb 1, 2018

Fixed in #731

@kbevers kbevers closed this as completed Feb 1, 2018
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