... 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 < [email protected]>: > > 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 < > [email protected]>: > >> 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 >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/proj >> >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
