[PROJ] "Fallback" support for transformations

[Nicolas Cadieux]

Hi,

I have not into the issue yet but 3 or 4 would be good.  Whatever option is selected, it would be nice to have the option of seeing the selected grid shift file border (a bit like the Grass region).  Perhaps this grid could be toggled on and off by a bouton on the lower right (near the scale) or at the very least with the error message.

Nicolas

> Le 4 févr. 2020 à 02:12, Nyall Dawson <nyall.dawson at gmail.com> a écrit :
> 
> 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
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj