[PROJ] Tie breakers used when ordering candidate operations

Nyall Dawson nyall.dawson at gmail.com
Wed Feb 10 17:17:58 PST 2021


On Thu, 11 Feb 2021 at 01:01, Even Rouault <even.rouault at spatialys.com> wrote:
>
> Hi Nyall,
>
> Obviously the doc was lagging a bit behind the latest state of the code.
> Update in https://github.com/OSGeo/PROJ/pull/2522
>
> > 11. consider as more relevant an operation that involves less
> > transformation steps
> >
> > Here I'd have thought 8450 (with a single noop step) would be picked
> > over 9690, which has a pipeline of:
> >
> > +proj=pipeline
> >   +step +proj=axisswap +order=2,1
> >   +step +proj=unitconvert +xy_in=deg +xy_out=rad
> >   +step +proj=push +v_3
> >   +step +proj=cart +ellps=WGS84
> >   +step +proj=helmert +x=0.06155 +y=-0.01087 +z=-0.04019 +rx=-0.0394924
> >         +ry=-0.0327221 +rz=-0.0328979 +s=-0.009994
> > +convention=coordinate_frame +step +inv +proj=cart +ellps=GRS80
> >   +step +proj=pop +v_3
> >   +step +proj=unitconvert +xy_in=rad +xy_out=deg
> >   +step +proj=axisswap +order=2,1
>
> If you look at the WKT output, you'll see that both have a single
> transformation step, which is what is considered by the sorting algorithm. But
> a helmert transformation with no translation and no rotation can be simplified
> in a single PROJ operation.
>
> So here only the final criterion apply. Given that "WGS 84 to GDA2020 (3)" >
> "Inverse of GDA2020 to WGS 84 (2)" in lexicographic order, it has higher
> precedence. Completely arbitrary here obviously...

Many thanks Even -- now everything is completely understandable.

Related question: do you think the EPSG registry should include some
kind of numerical "preference ranking" field to allow for better
selection in ambiguous cases? Are you aware if this has ever been
discussed before?

Nyall


>
> Even
>
> --
> http://www.spatialys.com


More information about the PROJ mailing list