[PROJ] Obtaining possible transformation pipelines
Kristian Evers
kreve at sdfe.dk
Mon May 27 00:42:17 PDT 2019
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
/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
More information about the PROJ
mailing list