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

[Thomas Knudsen]

... or, from your own code: use the API calls proj_create(...) +
proj_trans(...) or proj_trans_generic(...)
(see https://proj.org/development/reference/functions.html )

Den man. 15. nov. 2021 kl. 09.42 skrev Thomas Knudsen <
knudsen.thomas at gmail.com>:

>
> 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/5f773186/attachment-0001.html>