[PROJ] Obtaining possible transformation pipelines

Nyall Dawson nyall.dawson at gmail.com
Sun May 26 18:37:46 PDT 2019


On Fri, 24 May 2019 at 20:48, Even Rouault <even.rouault at spatialys.com> wrote:
>
> > Why aren't the options using using the
> > GDA94_GDA2020_conformal_and_distoration.gsb and
> > GDA94_GDA2020_conformal.gsb listed here?
>
> Because you don't use
>
> proj_operation_factory_context_set_spatial_criterion(pjContext,
> operationContext,
> PROJ_SPATIAL_CRITERION_PARTIAL_INTERSECTION)
>
> hint: if you had tried with projinfo, it would have advised you about that ;-)
>
> The reason is that for EPSG:3111 to EPSG:7899, the area of use is "small", so
> there are 3 possible datum shift operations whose area of use covers the area
> of use of the CRSs.
> However, when using GDA94 -> GDA2020, the area of use of those CRS is much
> larger, and there's only the Helmert-based transformation that covers the
> whole area. If you specify PROJ_SPATIAL_CRITERION_PARTIAL_INTERSECTION (or "--
> spatial-test intersects" with projinfo), you ask PROJ to return coordinate
> operations whose area of use intersects at least partially with the one of the
> CRS, but do not necessarily cover them completely.

Thanks -- this was exactly what I was missing.

>
> >
> > And as a follow up question -- when checking the accuracy of the 3
> > pipelines given from EPSG:3111 to EPSG:7899,
> > proj_coordoperation_get_accuracy reports that the transforms using the
> > grid shift files only have an accuracy of 0.05m, vs 0.01m for the
> > non-grid pipeline (counter to my expectations). How is this accuracy
> > derived?
>
> Directly from the EPSG dataset. Strangely enough, the accuracy advertized for
> those grids is 0.05m , whereas the one of the Helmert base transformation is
> 0.01m. If you don't believe me, check EPSG:8048 and EPSG:8446 in
> https://www.epsg-registry.org/

Odd. I suspect this was due to a misinterpretation of
http://www.icsm.gov.au/sites/default/files/DatumMattersT1FactSheet.pdf
. I'll find out what's required to get this fixed.

(hopefully) my last question:

If I have a proj string representing a coordinate operation, is there
any way to determine what grids are required for using it when those
grids are NOT available for use on the system?

Elsewhere I've used using proj_coordoperation_get_grid_used_count, but
this requires an existing coordinate operation object. Attempting to
create the (not available) coordinate operation using proj_create
fails with "Error -38: failed to load datum shift file". So as far as
I can see, there's no current way in API to determine the actual list
of missing grids which is preventing creation of a coordinate
operation. Or am I missing something?

Nyall


More information about the PROJ mailing list