Instead of just silently return "0", which is misleading and
can result in data corruption/incorrect analysis results. Better
to be safe and force callers to handle transformation errors
appropriately.
In this case we:
- raise QgsProcessingExceptions when the failed measurement is coming
from a processing tool, so that the user is forced to deal with the
issue and we aren't providing meaningless/misleading measurements
- report evaluation errors if the measurement is coming from a
QGIS expression, so the user must appropriately handle the situation
- for all other cases we currently just write a console error and
maintain the current behavior of treating the measurement length
as 0. TODO notes have been added to handle this cases better.
these are always gracefully caught
Avoids some unwanted "unhandled exception" message boxes which
can pop up while moving the mouse around outside of the valid bounds
of the current map projection
calculations
Since GRASS upstream is moving away from the previous calculations which
all of QGIS' ellipsoidal distance/areas formulas are based on, let's
follow suit and delegate all these calculations to the GeographicLib
routines exposed through the PROJ api.
Refs https://github.com/OSGeo/grass/pull/1283
at the antimeridian
Whenever line segments in the input geometry cross the antimeridian, they
will be split into two segments, with the latitude of the breakpoint being
determined using a geodesic line connecting the points either side of this
segment.
If the geometry contains M or Z values, these will be linearly interpolated
for the new vertices created at the antimeridian.
Better to use QVector here, because the QgsLineString/QgsGeometry
methods all use QVector too, and we want to avoid unnecessary
list->vector conversions.
