- Output interpolated points when travel cost falls mid-way along
an edge
- Output all intermediate reachable points also
- Make outputting upper/lower bound points optional, and non-default.
Now by default we just output all definitely reachable points and
the interpolated points along edges which correspond to the travel cost.
This allows the output to be used to correctly generate service areas
e.g. by concave/convex polygons and all reachable nodes will be
included in the area.
- Allow algorithm to optionally output a line layer (and make the
point layer optional too, and default to just the line layer output)
containing all reachable line segments (including interpolated
segments of lines when the travel cost sits midway along that
edge). This output is more easily understandably for users.
their unique id()
This is used when generating the QgsHelp url for algorithms
attached to the providers.
Implement helpId overrides for the native and 3d providers so
that they return 'qgis' helpIds, meaning that all QGIS processing
algorithm documentation can be kept within the same url path
regardless of which QGIS provider library it sits within.
This also allows us to freely move algorithms from the Python
'qgis' provider to c++ 'native' provider in future releases
without breaking the help URLs.
Fixes#17231
* detect SIP version to add DefaultDocstringSignature directive
SIP doesn't handle any kind of preprocessing, so there's no better solution than configuring the SIP files from CMake.
SIP 4.19.7+ supports %DefaultDocstringSignature to prepend auto-generated Python signature to existing Docstrings
Run clang-tidy modernize-use-override to remove all the redundant
virtual keywords from overridden methods, and add some missing
overrides.
Another benefit is that this has also added the overrides
on destructors, which will cause a build failure if a base
class is missing a virtual destructor.
when snapping line layers
Because the default behavior of the snapper is to insert extra
vertices into the snapped geometry in order to make it 'follow'
the reference geometries exactly, this can result in unwanted
results for line layers where the resultant snapped layer
has overlapping line segments.
Since we can't always know what the desired result is that the
user wants (maybe they do want overlapping lines), instead
give them control over the result by exposing extra enum
options which never insert extra vertices.
Because:
- it's unused in master, and is more code to maintain
just for possible use by plugins
- it's unmaintained, and has had no work done (beside compilation
fixes) in the recent past
- there's no unit tests or detailed documentation to show
how the class should be used
Instead of just forcing writing the triangulation to a shapefile (boo!)
change the parameter to use a QgsFeatureSink, so that anything
which implements the QgsFeatureSink interface can be used for
storing the triangulation.
These classes still need a lot of cleanup (e.g. use of proper
3d geometry classes instead of their own 3d line classes, etc)
and we don't want them locked into the 3.0 API.
Better to remove them from the API and reintroduce them after
they have been cleaned up (in >3.0). They are mostly implementation
details anyway, and unlikely to be used outside of the high
level interpolation classes.
We don't want these part of stable API - this namespace really shouldn't
exist, as it mostly contains code which is duplicated in other
parts of the API (with better maintained and tested versions).
These classes are unused in the master QGIS code, and are
unmaintained and with no unit tests or other QA, and
have inflexible API (e.g. always requiring writing outputs
to shapefiles)
They all have equivalent algorithms available via Processing
(where the algorithms are unit tested and maintained). We should
be pushing all QGIS api users to use the Processing algorithms
instead.