It's rather jarring that the move label and rotate label tools
don't follow the rest of the application in using click-click
to move and rotate and rotate labels, and instead use the older
click-and-drag behaviour. This commit reworks the tools to use
click to start, click to end behaviour instead.
It also makes them respect the same conventions as the move
and rotate features tools, where a right click cancels the
move/rotate, and same with pressing "esc" mid-operation.
Require at least 6.1.0. We need proj_normalize_for_visualization,
and the workarounds for building without it are too extensive,
too fragile, and result in too much spaghetti code.
Gotta make the hard call here ;)
base them on normalized operations
QGIS doesn't need (or want) to care about strictly following
projection definitions here, we ALWAYS want X/Y to be X/Y
- A coordinate transform cannot be created, e.g. due to not making
sense (transforming earth coords to mars coords)
- A coordinate transform cannot be created due to a missing grid
file (along with links to download the grid if available)
- A coordinate transform was created, BUT a better one is possible,
it just is missing some prerequisite on the user's system (again,
with links to download if available)
Sponsored by ICSM
for transforms, even if grids are not available.
And then use custom handlers or message log to warn users that
better operations are possible, just not available on their system.
Also use similar approach to raise errors when either no operation
is possible between two coordinate systems, or only ONE is yet
it is not available on the current system (e.g. due to missing
grid file)
Sponsored by ICSM
Now, proj will search in the current user profile "proj" folder (e.g.
.local/share/QGIS/QGIS3/profiles/default/proj" on linux) for
grid files and other proj helper files.
This allows users (and plugins) to install grid files and make them
available for use in QGIS without requiring administrator access
to the system.
This reworks (on proj 6 builds only!) QgsCoordinateTransformContext
to use proj strings of proj coordinate operations to handle the
users' preferred list of operations when transforming coordinates
between two CRSes.
Previously, the context heavily utilised internal transform ID
numbers, which were QGIS specific and relied on matching entries
from the QGIS srs.db file. This approach was undesirable because
it meant QGIS had to maintain and carry it's own table of
possible transform pathways between CRS pairs (which was difficult
to update, impossible to track, and most likely severely out of
date).
Now we can utilse Proj 6's (wonderful!) logic for determining the
best coordinate operation to utilise between two CRSes. All the
old API has been deprecated and no longer works under proj 6, but
that's unavoidable (and unlikely to be in use by plugins anyway,
it's VERY low level stuff).
A further bonus of this work is that QgsCoordinateTransform no
longer relies on proj strings of the source/dest CRS to build
the transform -- the issue with that approach was that proj
strings are lossy (and not always possible to generate), so
now by default we are generating better pathways between CRS
pairs.
This resolves issues with transforms which rely on pivot datums,
such as GDA94 - GDA2020 conversions.
Sponsored by ICSM
