Creates a new layer with a single feature with polygon geometry
covering the extent parameter value.
This is designed for use in models where some child algorithms require
a layer based input, while others require an extent based
parameter
This is basically the equivalent of the dissolve algorithm, but
instead of a dissolving overlapping geometries the geometries
are instead just collected together into a multipart geometry.
It's designed to slot between the 'promote to multipart' algorithm
(which performs no collection of geometries - it just converts
singleparts to multiparts with 1 part) and the more complex
all-encompassing 'aggregate' algorithm.
This algorithm is basically the equivalent of the ST_Multi(...)
command - it forces a feature's geometry to become multipart,
regardless of the input geometry type.
If input geometries are singlepart, they will output as
multipart with just 1 part. If they are already multipart,
they will be output unchanged.
feature based algorithms
Instead of algorithms which handle both whole layers/groups
of features/individual features, we leave the whole layer
and group of features handling to the "Minimum bounding
geometry" algorithm.
The feature-by-feature algorithms are now native c++
algorithms.
This affects:
- bounding boxes
- convex hulls
- minimum enclosing circle
- minimum oriented rectangles
An abstract QgsProcessingAlgorithm base class for processing algorithms
which operate "feature-by-feature".
Feature based algorithms are algorithms which operate on individual
features in isolation. These are algorithms where one feature is
output for each input feature, and the output feature result
for each input feature is not dependent on any other features
present in the source.
For instance, algorithms like "centroids" and "buffers" are feature
based algorithms since the centroid or buffer of a feature is
calculated for each feature in isolation. An algorithm like "dissolve"
is NOT suitable for a feature based algorithm as the dissolved output
depends on multiple input features and these features cannot be
processed in isolation.
Using QgsProcessingFeatureBasedAlgorithm as the base class for feature
based algorithms allows shortcutting much of the common algorithm code
for handling iterating over sources and pushing features to output sinks.
It also allows the algorithm execution to be optimised in future
(for instance allowing automatic multi-thread processing of the
algorithm, or use of the algorithm in "chains", avoiding the need
for temporary outputs in multi-step models).
Enhancements:
- add a new optional output for null geometries, and make
the non-null geometry output optional. This allows the algorithm
to act as a router for features with null/not null geometries
inside of a model
initAlgorithm() method
This allows 2 benefits:
- algorithms can be subclassed and have subclasses add additional
parameters/outputs to the algorithm. With the previous approach
of declaring parameters/outputs in the constructor, it's not
possible to call virtual methods to add additional parameters/
outputs (since you can't call virtual methods from a constructor).
- initAlgorithm takes a variant map argument, allowing the algorithm
to dynamically adjust its declared parameters and outputs according
to this configuration map. This potentially allows model algorithms which
can be configured to have variable numbers of parameters and
outputs at run time. E.g. a "router" algorithm which directs
features to one of any number of output sinks depending on some
user configured criteria.
and pure virtual createInstance
Allows us to add logic which always need applying within
create(), leaving createInstance() free to just return a
raw new instance of the class
Since it's safe to evaluate parameters in background threads
now, it's usually going to be ok to evaluate everything in
the processAlgorithm step.
This keeps the algorithm code as simple as possible, and will
make porting faster.
Note that the prepare/postProcess virtual methods still exist
and can be used when an algorithm MUST do setup/cleanup work
in the main thread.
The returned geometry will be a collection containing subdivided parts
from the original geometry, where no part has more then the specified
maximum number of nodes.
This is useful for dividing a complex geometry into less complex parts,
which are better able to be spatially indexed and faster to perform
further operations such as intersects on. The returned geometry parts may
not be valid and may contain self-intersections.
This commit adds the virtual method for running processing algs
to the base c++ class, and adds the initial framework
for c++ algorithm parameters.
When running an algorithm, a QVariantMap is passed
as the algorithm parameters. The high level API provided
by QgsProcessingParameters should be used to retrieve
strings/layers/doubles/etc from this QVariantMap.
This allows advanced use cases, such as passing QgsProperty
with the QVariantMap for "dynamic" parameters, where the
value should be evaluated for every feature processed.
E.g. if the buffer algorithm uses a dynamic property for distance,
then the distance could be bound to either a field value or
to a custom expression. This gets evaluated before buffering
each feature to allow for advanced variable buffering.
Support for dynamic parameters will be "opt in", and non default.
So algorithms will need to specifically add support for
dynamic properties as required.
