[PROJ] "Fallback" support for transformations

[Nyall Dawson]

Hi list,

Looking for advice on an issue we are seeing reported a lot downstream
at QGIS. Because proj 6 + the other associated changes in the stack
have made use of grid shift files much more transparent and easier for
users, we're seeing an associate uptake in users who are using
coordinate operations which require a grid in their work (which is
great!).

But... one downside of this is that operations based on a grid are
much stricter with respect to area of use -- if you try to transform
coordinates outside of the grid bounds, you (rightly) get null
results. This is in contrast to purely mathematical transforms, where
you still get... some... result outside of the area of use (albeit
possibly meaningless). This manifests in issues like
https://github.com/qgis/QGIS/issues/33929 -- where a user is trying to
use a grid based operation to transform features which fall outside
the grid bounds.

I'm seeking advice on what the best approach is to take with this. I
can see a few options:

1. Stand on the geodesic high-ground, and give null results -- the
selected operation can't be used for those coordinates, so it's a user
error. (the current approach in QGIS)

2. If a transform fails with the specified operation, fallback to
using proj_create_crs_to_crs_from_pj to create a "backup" transform
and let proj decide what to do. Benefits: users always get **some**
result. Downside: users always get **some** result, which may or may
not be using the operation they specified and could potentially be
misleading or inaccurate.

3. As above, but show a user-visible warning that a "fallback"
transformation was used and the results are indicative only. Benefits:
users always get **some** result. Downside: user confusion due to a
complex warning message, we run the risk of desensitising users to
important transformation related warnings and advise.

4. As per 2, but make use of a fallback transform opt-in. When the
selected operation fails, show a user-visible message giving them the
option of using a non-preferred operation. Benefits: no potentially
inaccurate results by default, user-friendly path to overcome the
probem. Downside: as per 3

The other issue is that options 2-4 are not straightforward changes to
make. In order to have the chance to transform using a "backup"
operation, we'd first need to make a temporary of all the original
coordinates, so that if the preferred transform fails we have the
original coordinates to use with the backup transform. We'd have to do
that **always** when transforming, so there's an (unavoidable?)
associated performance cost.

I'm at a bit of a loss which approach would be "best" to take. I'm
personally leaning toward 3, but am not convinced. What's upstream's
advice here?

Nyall