[PROJ] Tie breakers used when ordering candidate operations

Nyall Dawson nyall.dawson at gmail.com
Thu Feb 11 14:47:07 PST 2021


On Thu, 11 Feb 2021 at 20:02, Even Rouault <even.rouault at spatialys.com> wrote:
>
> > 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?
>
> I believe nobody (maintaining a geodetic database) wants to go into that
> business of saying what is prefered or not.

Well - as background I've been asked by ICSM (Australia) what's
required to get proj's ordering of the operations for conversion of
EPSG:4326 to 4283.

Proj master:
4326 <-> 4283
1. EPSG:9688, GDA94 to WGS 84 (2), 3.0 m, Australia including Lord
Howe Island, Macquarie Islands, Ashmore and Cartier Islands, Christmas
Island, Cocos (Keeling) Islands, Norfolk Island. All onshore and
offshore.
2. EPSG:1150, GDA94 to WGS 84 (1), 3.0 m, Australia including Lord
Howe Island, Macquarie Islands, Ashmore and Cartier Islands, Christmas
Island, Cocos (Keeling) Islands, Norfolk Island. All onshore and
offshore.
3. DERIVED_FROM(EPSG):9689, GDA94 to WGS 84 (3), 3.0 m, Australia -
Australian Capital Territory; New South Wales; Northern Territory;
Queensland; South Australia; Tasmania; Western Australia; Victoria.

Officially recommended by ICSM:
9688 (7P) highest priority > 9689 (NTv2) > 1150 (Null)

ie. ideally operations 2 and 3 would be flipped in proj's sorted list
to match with ICSM's recommendations

To clarify -- there's no bug in proj here, and proj's candidate
ordering is giving the expected results. It's just that they'd like to
know what they could do to get the ordering given by proj to match
their recommendations.

That's why I was wondering about some free-form way to influence the
ordering for tie-breakers...


> This depends on too many factors,
> and this would make the maintenance of the database even more complicated (I'd
> say that I have to notify IOGP about issues found by the PROJ import script
> for half of the recent EPSG releases).

Sounds like IOGP should contract you to update their in-house scripts
and add testing to those :D

Nyall


 Furthermore, accuracy values in EPSG
> for a transformation involving the generic WGS 84 CRS are generally derived
> from accuracies of other transformations between plate-fixed CRS, and adding 1
> or 2 m to it to reflect the accuracy of the WGS 84 datum ensemble.
>
> Even
>
> --
> http://www.spatialys.com


More information about the PROJ mailing list