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

Do not pivot over WGS84 when doing cs2cs-emulation with geocent #1026

Merged
merged 1 commit into from Jun 1, 2018

Conversation

Projects
None yet
2 participants
@kbevers
Member

kbevers commented Jun 1, 2018

Fixes #1025

@rouault

This comment has been minimized.

Member

rouault commented Jun 1, 2018

Woo, thanks ! But doesn't that mean than in the if ( P->helmert || do_cart) case we also go through WGS84 ? So people doing helmert or cart on other bodies would go through WGS84 at some point ? I don't claim to understand this part of the code, so perhaps I'm wrong

@kbevers

This comment has been minimized.

Member

kbevers commented Jun 1, 2018

P->helmert and/or do_cart is only meant to be set when a datum specifying parameter like +datum, +towgs84 or +nadgrids is used in the setup. Depending on the direction of the transformation we either need to step into WGS84 or from WGS84 to whatever when emulating cs2cs/pj_transform behaviour. It is not pretty but hard to avoid as long as we want to support those parameters. geocent is special because it effectively is defining a "datum" (in the cs2cs at least). When stating something like +proj=geocent +a=2342342 +b=2342324 it is regarded as a datum specification and the input is expected to be WGS84 geodetic coordinates (because that is how cs2cs works). Does that make sense?

@rouault

This comment has been minimized.

Member

rouault commented Jun 1, 2018

Does that make sense?

a bit more :-) thanks

@kbevers

This comment has been minimized.

Member

kbevers commented Jun 1, 2018

At some point this whole cs2cs emulation thing should be described. Or what really should be described is the difference between declarative parameters like +datum, +towgs84, etc and imperative parameters that works on a given operation. It has been on my mental list for a long time but not something I particularly look forward to writing!

@kbevers kbevers added the bug label Jun 1, 2018

@kbevers kbevers added this to the 5.2.0 milestone Jun 1, 2018

@kbevers kbevers merged commit de44aa7 into OSGeo:master Jun 1, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@rouault

This comment has been minimized.

Member

rouault commented Jun 1, 2018

will this 5.2.0 release done through master ?
or will 5.2.0 be a tag of the '5.1' branch ?

@kbevers

This comment has been minimized.

Member

kbevers commented Jun 1, 2018

I figured "business as usual" (5.2 through master) but I have been meaning to shoot you an email about how to orchestrate the coming releases regarding gdalbarn. What is the time frame for the PROJ parts of gdalbarn?

An idea could be to aim for including WKT-support in 5.2 (september 1st) and the EPSG db stuff in 6.0 (february 1st). Would that work for you? Or do you prefer something more flexible?

@rouault

This comment has been minimized.

Member

rouault commented Jun 1, 2018

I would prefer something more flexible. The PROJ stuff will be really shaken/tested properly through GDAL, and that will take time. So as soon as my first things are going to land in master, it will be in a 'unreleasable state' for some time... mean I'll try to keep everything 'green', but the new functionality will probably be moving, so we probably don't want to make releases with that

Or... I keep my new stuff in a dedicated branch, into which master is merged regularly (shouldn't be too hard, as I don't really anticipate 'old' code to be touched for now). We can use pull requests mechanism to merge things in that branch as we would do for master. And at some point when I'm completely happy, we merge the whole stuff into master

@kbevers

This comment has been minimized.

Member

kbevers commented Jun 1, 2018

I prefer the last option. At least until we hit 5.2, then we can merge the gdalbarn branch into master. That's three months with parallel maintenance and six months only working on master. Some things will probably be simpler if added to master as well, i.e. like the test suite and cpp support already have been. Would that work?

Another possibility is to cancel 5.2 and go straight to 6.0 and issue bimonthly patch releases of 5.1 until 6.0 is ready. It would result in a long time without being able to release new features though.

@rouault

This comment has been minimized.

Member

rouault commented Jun 1, 2018

I prefer the last option. [...] Would that work?

Yes, we can start with that hypothesis for now, and I'll come back if at some point things are becoming too messy for me. It is good if regular new features can be delivered without me holding up releases.

@kbevers

This comment has been minimized.

Member

kbevers commented Jun 1, 2018

Yes, we can start with that hypothesis for now, and I'll come back if at some point things are becoming too messy for me. It is good if regular new features can be delivered without me holding up releases.

Sounds good. At least the WKT stuff is more or less orthogonal to the existing code so hopefully that makes it less painfull. Let's revise the plan in a couple of weeks or so.

@kbevers kbevers deleted the kbevers:fix-geocent branch Jul 9, 2018

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