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.
Contains variables for model parameters, algorithm results for
other child algorithms which are not dependent on the
algorithm.
Allows removal of final pieces of ModelerAlgorithm code
converted to QgsMapLayer objects with the ownership transferred
to the Python caller
This should make it super-easy for PyQGIS scripts to run processing
algorithms and immediately utilise the results, even if they
are memory layers. They call processing.run(), and get a dict of
results back which includes those layers ready for adding to the
current project or doing some other processing or operations
with, and if they don't transfer to ownership off then these
layers will be correctly garbaged collected by Python.
require all input layers to be in the same CRS
The default behaviour is to assume that algorithms are well behaved
and can handle multi-CRS inputs, but algs have the option to
flag that they do not allow this and require the input CRS check.
Those algs should document that they require all inputs to have
matching CRS - processing 3.0 behaviour is to assume that algs
can handle this.
flexible QVariantMap creatOptions parameters which include an
optional fileEncoding value
More flexible, allows sinks to be created using any creation
option which is passed to the underlying provider
This somewhat changes the meaning of outputs from processing 2.x.
In 2.x processing outputs were used both as a method of specifying
inputs to algorithms (file paths to destination layers created
by the algorithm) AND pure outputs (such as statistics calculated
by the algorithm).
This is now split. The old input-type-outputs (destination layers)
are now input parameters (since the parameter value IS an input to the
algorithm). To differentiate them from parameters indicating pure
input layers a new "isDestination()" method was added to
QgsProcessingParameterDefinition.
Output definitions are now purely indications of values CREATED
by the algorithms. Suitable candidates are the existing calculated
stats and actual file path/URI of any layers created by the algorithm.
Moving forward we should ensure all algorithms output as much
useful information as possible - e.g. number of features processed,
number of skipped features, count null geometries encountered, etc...
