<div dir="ltr">... or, from your own code: use the API calls proj_create(...) + proj_trans(...) or proj_trans_generic(...)<div>(see <a href="https://proj.org/development/reference/functions.html">https://proj.org/development/reference/functions.html</a> )<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den man. 15. nov. 2021 kl. 09.42 skrev Thomas Knudsen <<a href="mailto:knudsen.thomas@gmail.com">knudsen.thomas@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den søn. 14. nov. 2021 kl. 21.31 skrev Craig de Stigter <<a href="mailto:craig.destigter@koordinates.com" target="_blank">craig.destigter@koordinates.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey folks<br>
<br>
We're trying to adjust proj to use a specific transformation between two<br>
CRSes *by default* (ie. we don't want our calling software to have to be<br>
explicit about which to use, since there are several places we're calling<br>
PROJ from and we'd like to make them automatically consistent)<br>
<br>
Stock proj 8.1.1 gives us these transform choices:<br>
<br>
> $ PROJ_NETWORK=ON projinfo -s EPSG:4283 -t EPSG:7844 --spatial-test<br>
intersects --summary<br>
> Candidate operations found: 5<br>
><br>
> 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.<br>
> 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.<br>
> 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.<br>
> ...<br>
<br>
<br>
The one we want is DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), which is<br>
third in the list, and thus not chosen by default.<br>
<br>
Aiming to bump that to the top of the list, we modified our proj.db build<br>
to add this SQL:<br>
<br>
> -- When transforming from GDA94 to GDA2020,<br>
> -- use the distortion+conformal grid in preference to the conformal-only<br>
grid.<br>
> UPDATE grid_transformation<br>
> SET accuracy = 0.0099<br>
> WHERE auth_name = 'EPSG' AND code = 8447;<br>
<br>
We expected this to bump the transform to the top of the list. It did bump<br>
up by one slot, above the other grid-based transform (EPSG:8446). However,<br>
it's still below the helmert transformation (EPSG:8048):<br>
<br>
> Candidate operations found: 5<br>
> EPSG:8048, GDA94 to GDA2020 (1), 0.01 m, Australia including Lord Howe<br>
Island, Macquarie Island, Ashmore and Cartier Islands, Christmas<br>
Island, Cocos (Keeling) Islands, Norfolk Island. All onshore and<br>
offshore.<br>
> DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), 0.0099 m, Australia -<br>
Australian Capital Territory; New South Wales; Northern Territory;<br>
Queensland; South Australia; Tasmania; Western Australia; Victoria.<br>
> DERIVED_FROM(EPSG):8446, GDA94 to GDA2020 (3), 0.05 m, Australia -<br>
Australian Capital Territory; New South Wales; Northern Territory;<br>
Queensland; South Australia; Tasmania; Western Australia; Victoria.<br>
> ...<br>
<br>
<br>
I couldn't find anything documenting that PROJ prefers Helmert transforms<br>
over grid-based ones - merely that it prefers operations with defined<br>
accuracy, and then prefers transforms in order of accuracy. In which case I<br>
would have expected it to choose EPSG:8447 over EPSG:8048 now that we've<br>
hacked the accuracy number.<br>
<br>
Interestingly, setting the accuracy of the Helmert transform to NULL *did*<br>
fix this:<br>
<br>
> DERIVED_FROM(EPSG):8447, GDA94 to GDA2020 (2), 0.0499 m, Australia -<br>
Australian Capital Territory; New South Wales; Northern Territory;<br>
Queensland; South Australia; Tasmania; Western Australia; Victoria.<br>
> ...<br>
> EPSG:8048, GDA94 to GDA2020 (1), unknown accuracy, Australia including<br>
Lord Howe Island, Macquarie Island, Ashmore and Cartier Islands,<br>
Christmas Island, Cocos (Keeling) Islands, Norfolk Island. All onshore<br>
and offshore.<br>
<br>
<br>
So my questions are:<br>
<br>
1. Is setting the accuracy of EPSG:8048 to NULL a bad idea? We'll still<br>
want to use EPSG:8048 as an offshore fallback.<br>
2. Any idea why PROJ is still prioritising EPSG:8048 after our first tweak?<br>
3. Is there a better way to accomplish this reprioritisation?<br>
<br>
Thanks a bunch!<br>
<br>
-- <br>
Regards,<br>
Craig<br>
<br>
Platform Engineer<br>
Koordinates<br>
<br>
+64 21 256 9488 / <a href="http://koordinates.com" rel="noreferrer" target="_blank">koordinates.com</a> / @koordinates<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>
</blockquote></div>