[PROJ] Obtaining possible transformation pipelines

[Nyall Dawson]

On Mon, 27 May 2019 at 17:42, Kristian Evers <kreve at sdfe.dk> wrote:
>
> Nyall,
>
> I think you can use proj_coordoperation_get_grid_used() for that:
>
> https://proj4.org/development/reference/functions.html#_CPPv433proj_coordoperation_get_grid_usedP10PJ_CONTEXTPK2PJiPPKcPPKcPPKcPPKcPiPiPi

I can't use that one, because it requires an existing coordoperation
object, and I can't make the coordoperation when the grid doesn't
exist...

Nyall

>
> /Kristian
>
> -----Oprindelig meddelelse-----
> Fra: PROJ <proj-bounces at lists.osgeo.org> På vegne af Nyall Dawson
> Sendt: 27. maj 2019 03:38
> Til: Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Emne: Re: [PROJ] Obtaining possible transformation pipelines
>
> 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
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj