[PROJ] Obtaining possible transformation pipelines

[Kristian Evers]

I'm not sure this will work for your particular use case (since you are instantiating
a PJ from a proj-string), but there is proj_operation_factory_context_set_grid_availability_use
which allow you to ignore unavailable grids when creating PJ objects from using a
PJ_OPERATION_FACTORY_CONTEXT. Here's an example from the tests:

https://github.com/OSGeo/proj.4/blob/d67203a6f76a74f5ac029ff052dbcc72e3b59624/test/unit/test_c_api.cpp#L1316-L1351

which may guide you in the right direction.

/Kristian

-----Oprindelig meddelelse-----
Fra: Nyall Dawson <nyall.dawson at gmail.com> 
Sendt: 27. maj 2019 10:35
Til: Kristian Evers <kreve at sdfe.dk>
Cc: Even Rouault <even.rouault at spatialys.com>; PROJ <proj at lists.osgeo.org>
Emne: Re: [PROJ] Obtaining possible transformation pipelines

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