<div dir="ltr">Thomas,<div><br></div><div>Thank you for the explanation. These parameter expansions appear to be more complicated than I had assumed.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Olli</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2018 at 16:27, Thomas Knudsen <span dir="ltr"><<a href="mailto:knudsen.thomas@gmail.com" target="_blank">knudsen.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>Hi Olli,<br><br>Thanks for testing RC6! What you have found is really more a matter of missing documentation than a bug in the handling of +datum.<br><br>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.<br><br>So the brief message is that except for init files, cs2cs style modifiers are for use in cs2cs only.<br><br>The somewhat longer background story:<br><br>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.<br><br>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:<br><br>proj=pipeline no_defs step proj=longlat datum=potsdam inv step init=epsg:4258 ellps=bessel nadgrids=@BETA2007.gsb<br><br>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:<br><br>proj=pipeline step proj=latlong datum=potsdam inv step proj=latlong datum=potsdam<br><br>i.e. a back-and-forth dance on the spot.<br><br>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.<br><br>Finally, 4 take home points:<br><br>1)<br><br>Do not use cs2cs style modifiers anywhere else than in cs2cs and in init files.<br><br>2)<br><br>Even in init files: Avoid them and write a pipeline instead.<br><br>3)<br><br>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<br><br>cct -I +init=epsg:4314<br><br>or<br><br>cct +proj=hgridshift +grids=BETA2007.gsb<br><br>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.<br><br>Essentially it is a matter of sign conventions, which can give rise to much confusion. So...<br><br>4)<br><br>Geodesy is often hard to grasp, but not always due to complex mathematical and geophysical reasoning.<span class="HOEnZb"><font color="#888888"><br><br><br></font></span></div><span class="HOEnZb"><font color="#888888">/Thomas</font></span></div>
<br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br></blockquote></div><br></div>