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

[kbevers]

Fixes #1025

[rouault]

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]

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]

Does that make sense?

a bit more :-) thanks

[kbevers]

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!

[rouault]

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

[kbevers]

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]

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]

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]

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]

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.