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
Only create and prepare the GEOS representation for intersection
layer features when we encounter a feature in the target layer
within that feature's bounding box.
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
because using this more consistently throughout the codebase makes it
easier to maintain code.
We also do not want to call the copy constructor on them, using pointers
just makes this more obvious. Further, casting is also something
that's commonly done on pointers and not references.
And if you want a value or a reference, just use QgsGeometry, it's meant
to be handled like this.
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).
This allows optional outputs (such as null geometry features detected
by the Remove Null Geometries algorithm) to be skipped by default
when desirable.
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.
