[PROJ] Obtaining possible transformation pipelines

[Even Rouault]

Nyall,

> 
> - Either using proj_get_name or proj_as_wkt as a way to represent
> these transforms and present them to users (or is there a nicer
> approach? The names I've encountered tend to be vague, e.g. "Inverse
> of Vicgrid + GDA94 to GDA2020 (1) + Vicgrid"/"Inverse of Vicgrid +
> GDA94 to GDA2020 (2) + Vicgrid", yet the wkt string is overly lengthy
> and complex for most users).

No better suggestion.

> 
> - I'll use proj_coordoperation_get_accuracy as a way of showing users
> the accuracy of the operations, and proj_is_deprecated to highlight
> deprecated ones.

You'll never get deprecated coordinate operations when using 
proj_create_operations(). They are automatically removed (deprecated == broken 
in EPSG terms. Which is different from superseded). You can only get 
deprecated objects by querying them explicitly by code.

> 
> - I'll use proj_operation_factory_context_set_grid_availability_use
> with either PROJ_GRID_AVAILABILITY_IGNORED or
> PROJ_GRID_AVAILABILITY_USED_FOR_SORTING so that users can see
> transforms which they are missing the grids for, and highlight these
> differently in the gui (and block their use)

Sounds good

> 
> - I'll confirm grid availability using
> proj_coordoperation_is_instantiable, and
> proj_coordoperation_get_grid_used in order to show the grid details
> (and download url) to users

Sounds good

> 
> - After users have selected their desired pipeline, I'll store the
> WKT2 2018 representation of this. For future transformations between
> that pair of coordinate systems (inside that project), I'll use
> proj_create with the stored wkt2 string to create a transformation
> using the desired pathway.

Storing the PROJ string would also be reasonable (PROJ strings for coordinate 
operations are lossless for the purpose of transforming coordinates), but the 
WKT2 2018 representation will give you a more traceable way. That said, I will 
not guarantee at 100% that the WKT2 2018 representation of the whole pipeline 
can be roundtripped in all situations, so I'd suggest perhaps:

1) export the coord op as PROJ string
2) export the coord op as WKT2_2018 and instanciate it as a PJ with 
proj_create()
3) export the PJ of 2) as PROJ string, and compare (string equality) with 1). 
If they match you can use the WKT2_2018 just fine. Otherwise use the PROJ 
string of 1) (and report such cases so that we can check if that can be 
improved)

> - I never seem to obtain any deprecated results using
> proj_create_operations -- are these filtered in the operation factory
> context by default? If so, is there a way to enable them?

See above. Removal of them is hardcoded.

> - From my tests it looks fine, but I'd love double-confirmation that
> this approach will correctly handle transformations which require
> pivots, such as Vicgrid GDA94 -> Vicgrid GDA2020.

Sounds good.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com