[PROJ] Obtaining possible transformation pipelines

[Nyall Dawson]

Hi list,

So, I think I'm finally onto the last piece of the QGIS proj 4 -> 6
puzzle. I think I've got the way forward here, but I'm after
confirmation that this is the right path to take.

The situation is:

- In current QGIS versions (proj 4 builds), a custom table of datum
transforms exists. This table maps src -> dest crs pairs via a
corresponding grid shift file. E.g. 4283 -> 7844 has entries for
GDA94_GDA2020_conformal_and_distortion.gsb and
GDA94_GDA2020_conformal.gsb.

- There's potentially multiple rows in this table per src/dest pair,
representing each of the different paths for transforming between
these systems

- Depending on users settings, either the "best" (an extremely loose
definition - basically the first non-deprecated path!) is selected
from this table when first transforming between a pair of systems, OR
users are shown a dialog listing all available pathways and they can
make a manual selection from these. (Settings are stored in projects,
with an option to save as the default choice on a particular install).

- This transformation is used for all future operations between those
two coordinate systems in that project

Now, obviously under proj 6 we want to dump all that, and use proj 6's
(far) superior intelligence and db to handle this. I would still like
to be able to (optionally) present users with a list of possible
transformation pathways which they can select from though.

Currently, I'm thinking of doing this by:

- Using proj_create_operations to obtain a list of the possible
transforms between a source/dest reference system

- 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).

- 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.

- 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)

- 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

- 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.

Questions:

- Does this approach seem reasonable? Is there anything I'm
misunderstanding, or better ways I could approach this?

- 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?

- 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.

Many thanks!
Nyall