Instead of returning a single QgsFeature from processFeature, we now
return a list of features.
This allows feature based algorithms which return multiple features
per input feature, e.g. "explode" type algorithms which split a
single input feature into multiple output features.
Since it's much more useful. Also add a prompt for layer name, so that
you can save the results of an algorithm into an existing geopackage
without wiping existing layers.
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.
have specific icons, instead of generic qgis icon
We consider these 'top level' algorithms, and using the
standard algorithm icon should help reflect this and
differentiate them from 3rd party algorithms.
Algorithms and other processing code should use this method
(instead of dataobjects.getLayerFromString) to
retrieve layers from a string, as it considers the processing
context and allows resolving strings to temporarily stored layers.
This permits processing models to function correctly when
intermediate results are stored as memory layers. Subsequent
model algorithms can then access these temporary layers as inputs.
All temporary layers will be removed when the context object
is destroyed after the model algorithm is run.
Also
- simplify and add tests
- remove large memory leak (persistant store of all non-project layers)
- remove broken support for direct loading postgres/virtual layers
by string (Python version was very broken and would never match
a postgres/virtual layer)
This adds a new input type for expression inputs. Expression
inputs can be linked to a parent layer so that the builder
shows the correct fields and layer variables.
It's designed for two use cases:
1. to be used when an algorithm specifically requires an expression,
eg Select by Expression and Extract by Expression.
2. to be potentially used as a replacement input instead of string
or number literals in algorithms. Eg - if the simplify algorithm
tolerance parameter was replaced with an expression paremeter, then
this expression would be evaluated for every feature before
simplifying that feature. It would allow parameters to be calculated
per feature, as opposed to the current approach of calculating
a parameter once before running the algorithm. It would also
mean algorithms like "variable distance buffer" would no longer
be needed, as a single "buffer" algorithm could then be used
for either a fixed distance, field based, or expression based
distance.
This algorithm updates existing geometries (or creates new
geometries) for input features by use of a QGIS expression. This
allows complex geometry modifications which can utilise all the
flexibility of the QGIS expression engine to manipulate and create
geometries for output features.
