[PROJ] Adjusting priorities in proj.db: grid vs helmert transformations

[Thomas Knudsen]

When you know which transformation you want, you probably shouldn't use
PROJ's search logic to find it, but just use the PROJ-string implementation
of the transformation directly with the PROJ cct utility.

Den søn. 14. nov. 2021 kl. 21.31 skrev Craig de Stigter <
craig.destigter at koordinates.com>:

> Hey folks
>
> We're trying to adjust proj to use a specific transformation between two
> CRSes *by default* (ie. we don't want our calling software to have to be
> explicit about which to use, since there are several places we're calling
> PROJ from and we'd like to make them automatically consistent)
>
> Stock proj 8.1.1 gives us these transform choices:
>
> > $ PROJ_NETWORK=ON projinfo -s EPSG:4283 -t EPSG:7844 --spatial-test
> intersects --summary
> > Candidate operations found: 5
> >
> > EPSG:8048, GDA94 to GDA2020 (1), 0.01 m, Australia including Lord Howe
> Island, Macquarie Island, Ashmore and Cartier Islands, Christmas Island,
> Cocos (Keeling) Islands, Norfolk Island. All onshore and offshore.
> > DERIVED_FROM(EPSG):8446, GDA94 to GDA2020 (3), 0.05 m, Australia -
> Australian Capital Territory; New South Wales; Northern Territory;
> Queensland; South Australia; Tasmania; Western Australia; Victoria.
> > DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), 0.05 m, Australia -
> Australian Capital Territory; New South Wales; Northern Territory;
> Queensland; South Australia; Tasmania; Western Australia; Victoria.
> > ...
>
>
> The one we want is DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), which is
> third in the list, and thus not chosen by default.
>
> Aiming to bump that to the top of the list, we modified our proj.db build
> to add this SQL:
>
> > -- When transforming from GDA94 to GDA2020,
> > -- use the distortion+conformal grid in preference to the conformal-only
> grid.
> > UPDATE grid_transformation
> > SET accuracy = 0.0099
> > WHERE auth_name = 'EPSG' AND code = 8447;
>
> We expected this to bump the transform to the top of the list. It did bump
> up by one slot, above the other grid-based transform (EPSG:8446). However,
> it's still below the helmert transformation (EPSG:8048):
>
> > Candidate operations found: 5
> > EPSG:8048, GDA94 to GDA2020 (1), 0.01 m, Australia including Lord Howe
> Island, Macquarie Island, Ashmore and Cartier Islands, Christmas
> Island, Cocos (Keeling) Islands, Norfolk Island. All onshore and
> offshore.
> > DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), 0.0099 m, Australia -
> Australian Capital Territory; New South Wales; Northern Territory;
> Queensland; South Australia; Tasmania; Western Australia; Victoria.
> > DERIVED_FROM(EPSG):8446, GDA94 to GDA2020 (3), 0.05 m, Australia -
> Australian Capital Territory; New South Wales; Northern Territory;
> Queensland; South Australia; Tasmania; Western Australia; Victoria.
> > ...
>
>
> I couldn't find anything documenting that PROJ prefers Helmert transforms
> over grid-based ones - merely that it prefers operations with defined
> accuracy, and then prefers transforms in order of accuracy. In which case I
> would have expected it to choose EPSG:8447 over EPSG:8048 now that we've
> hacked the accuracy number.
>
> Interestingly, setting the accuracy of the Helmert transform to NULL *did*
> fix this:
>
> > DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), 0.0499 m, Australia -
> Australian Capital Territory; New South Wales; Northern Territory;
> Queensland; South Australia; Tasmania; Western Australia; Victoria.
> > ...
> > EPSG:8048, GDA94 to GDA2020 (1), unknown accuracy, Australia including
> Lord Howe Island, Macquarie Island, Ashmore and Cartier Islands,
> Christmas Island, Cocos (Keeling) Islands, Norfolk Island. All onshore
> and offshore.
>
>
> So my questions are:
>
> 1. Is setting the accuracy of EPSG:8048 to NULL a bad idea? We'll still
> want to use EPSG:8048 as an offshore fallback.
> 2. Any idea why PROJ is still prioritising EPSG:8048 after our first tweak?
> 3. Is there a better way to accomplish this reprioritisation?
>
> Thanks a bunch!
>
> --
> Regards,
> Craig
>
> Platform Engineer
> Koordinates
>
> +64 21 256 9488 / koordinates.com / @koordinates
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20211115/f8c147da/attachment.html>