[PROJ] "Fallback" support for transformations

[Nyall Dawson]

On Tue, 4 Feb 2020 at 22:52, Even Rouault <even.rouault at spatialys.com> wrote:
>
> Hi Nyall,
>
> As in QGIS not all coordinate transformations need a geodetic-class level of
> accuracy, one aspect you didn't mention and that should probably be taken into
> account is the desired final accuracy, which can be linked with the current
> map scale.
>
> One factor to also consider is the amount of shift introduced by a
> transformation. But this information is not easily available. This is, I
> believe, at worse 200 meters when transforming from old systems to new ones,
> and much smaller for transformations between more recent systems (at least for
> Earth based transformation... No idea for potential future non-Earth
> transformations ...)
>
> Doing a quick computation, at 1/1,000,000 scale, and 96 DPI screen resolution,
> a pixel represents 1e6 / (96 / 0.0254) = 264 m. So for scales equal or smaller
> to that, the effect of any datum transformation is invisible at screen.
>
> Now, if for a given (A,B) tuple of source and target CRS, you've a grid-based
> transformation and a Helmert one, then the difference in results between both
> is probably at worse of the order of 5 m (and often < 1 m).
> So the difference between both would only start being visible for scales equal
> or larger than 1/25,000 ( 25000 / (96 / 0.0254) = 6.6 m)
>
> That would mean that, when doing a coordinate transformation in QGIS, if you
> had a hint of the scale for which it is intended, then you could decide if you
> can just blindly use proj_create_crs_to_crs_from_pj() or not.

While that approach could work for map rendering, it's not without
issues. E.g. a point layer dataset with some points outside the extent
of the grid -- when viewed at small scales you'll see all points, then
as you zoom in past a certain threshold you'll suddenly lose the
outside points when the grid shift kicks in. That's definitely going
to lead to user confusion. It also won't help with other
transformation tasks like layer exports, because we don't know the
intended scale for the output we'd always have to use the
user-specified grid based operation (and result in more bug reports:
"i can see the points in the canvas, but when I save the layer I only
get some from the centre of my map in the saved file").

Nyall