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
Comments
Currently, I'm working om PR #693, which heavily modifies the 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. |
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 |
I now realize that the So it seems we do not need the |
Nice, that simplifies things a bit. |
Fixed in #731 |
The problem
Parameters such as
towgs84
,nadgrids
,geoidgrids
,axis
,units
andvunits
are only parsed and used by thepj_transform
function. For the new 4D API to be truly useful it should be able to convertcs2cs
-style proj-strings to pipelines. This is especially important as long as we still distribute init-files, such as theepsg
-file, that uses thecs2cs
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 frompj_transform
the order when going from "WGS84" to e.g.epsg:xxxx
is as described below. I've used plusses in front of thecs2cs
-style to make it clearer which is which.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=???
Apply datum shift of vertical coordinates:
+geoidgrids=????
->step proj=vgridshift grids=????
Projection:
+proj=????
->proj=??? arg1 arg2 arg3 ... argn
Units:
+units=??? +vunits=???
->proj=unitconvert xy_in=m xy_out=??? z_in=m z_out=???
Axis order:
+axis=???
->step proj=axisswap +order=?,?,?,?
Which in the end becomes pipeline that looks like:
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 inget_init()
. This will affect initialisation of all tranformation objects, including those used bypj_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 createepsg4D
etc as preprocessed translations of the cs2cs-style proj-strings to pipelines. This would require thatproj_create()
looks for a "4D"-version of whatever init-file is requested (could be as simple as a search and replace). Makingepsg4D
and friends can be done fairly quickly with a Python-script. By doing it this way we skip messing withpj_transform()
andget_init()
while still making it possible to use our distributed init-files with the new API.Any thoughs on this are much appreciated!
The text was updated successfully, but these errors were encountered: