[Proj] PROJ 5.0.0RC6

[Olli Räisä]

Thomas,

Thank you for the explanation. These parameter expansions appear to be more
complicated than I had assumed.

What do you think about checking old-style parameter compatibility in
pipeline setup, and handling unsupported cases as errors? This being not a
suggestion for 5.0.0, but for future development.

Regards,
Olli


On 26 February 2018 at 16:27, Thomas Knudsen <knudsen.thomas at gmail.com>
wrote:

>
> Hi Olli,
>
> Thanks for testing RC6! What you have found is really more a matter of
> missing documentation than a bug in the handling of +datum.
>
> The thing is that the support for cs2cs style datum definitions are for
> use in init-files only: It was introduced in order to be able to use the
> current epsg-file with the new API. It will (presumably) be removed once we
> have a streamlined way of producing pipeline style versions of EPSG data.
>
> So the brief message is that except for init files, cs2cs style modifiers
> are for use in cs2cs only.
>
> The somewhat longer background story:
>
> In cs2cs, the command line input is split at “+to” before handling the two
> parts using two separate calls to pj_init(). From pj_init(), +datum is
> expanded through a call to pj_datum_set(), which stomps on the parameter
> list, adding the expansion from hardcoded values in pj_datums.c.
>
> But the initial splitting of the command line at “+to” implies that a
> +datum definition in the “from” part will not spill over to the “to” part,
> while the opposite is true in your pipeline example, which actually expands
> to:
>
> proj=pipeline no_defs step proj=longlat datum=potsdam inv step
> init=epsg:4258 ellps=bessel nadgrids=@BETA2007.gsb
>
> And due to unfortunate (but hard to avoid - the full tale is complicated)
> interference between old and new syntax, the expansion of +datum=potsdam
> (i.e. the two tokens ellps=bessel nadgrids=@BETA2007.gsb) takes effect in
> *both* steps of the pipeline, essentially meaning that what you do is this:
>
> proj=pipeline step proj=latlong datum=potsdam inv step proj=latlong
> datum=potsdam
>
> i.e. a back-and-forth dance on the spot.
>
> Why does this not happen in the first case (i.e. the one with two
> init-calls)? It does not happen because inits in pipelines are *not*
> expanded by pj_init() but by the pipeline setup code in PJ_pipeline.c (see
> pj_init.c around line 540 for the ugly details), where each pipeline step
> is handled in a separate pj_init() call, much like in the cs2cs case.
>
> Finally, 4 take home points:
>
> 1)
>
> Do not use cs2cs style modifiers anywhere else than in cs2cs and in init
> files.
>
> 2)
>
> Even in init files: Avoid them and write a pipeline instead.
>
> 3)
>
> The +init=epsg:4258 step in your pipeline (which defines the output system
> as ETRS89) is necessary in the declarative cs2cs style, but superfluous in
> the cct imperative style, where you can get away with
>
> cct -I +init=epsg:4314
>
> or
>
> cct +proj=hgridshift +grids=BETA2007.gsb
>
> Note the missing “-I” in the last case: The grid shift file takes us FROM
> the Potsdam datum TO ETRS89, while the epsg:4314 entry (in loose terms)
> “defines” the Potsdam datum in terms of ETRS89.
>
> Essentially it is a matter of sign conventions, which can give rise to
> much confusion. So...
>
> 4)
>
> Geodesy is often hard to grasp, but not always due to complex mathematical
> and geophysical reasoning.
>
>
> /Thomas
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180226/a20a97af/attachment.htm