And add a new target CRS argument to parameterAsExtent. If set, and
the source CRS of the rectangle parameter can be determined, then
the returned value will be the rectangle automatically reprojected
to the desired target CRS.
Ownership of Python subclass algorithm instances was getting
mangled due to passing through multiple functions with /Factory/
annotations.
As per Phil Thomson's advice on
https://www.riverbankcomputing.com/pipermail/pyqt/2017-July/039450.html:
"
/Factory/ is used when the instance returned is guaranteed to be
new to Python. In this case it isn't because it has already been
seen when being returned by createInstance(). (However for a different
sub-class implemented in C++ then it would be the first time it was seen
by Python so the /Factory/ on create() would be correct.)
You might try using /TransferBack/ on create() instead - that might be
the best compromise.
"
Changing to /TransferBack/ indeed fixes the error for me.
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).
parameters to an algorithm
QgsProcessingAlgorithm::addParameter() has a new createOuput
argument (true by default).
If the createOutput argument is true, then a corresponding
output definition will also be created (and added to the
algorithm) where appropriate. E.g. when adding a
QgsProcessingParameterVectorDestination and createOutput is
true, then a QgsProcessingOutputVectorLayer output will be
created and added to the algorithm. There is no need to call
addOutput() to manually add a corresponding output for this
vector. If createOutput is false then this automatic output
creation will not occur.
This should simplify declaration of outputs for algorithms
as it avoids the need to manually declare these corresponding
outputs.
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.
destroyed by the python garbage collector
The code generated with the /Factory/ annotation was not sufficient
to correctly transfer the ownership of objects created in Python
back to c++ (despite mailing list messages which hint that it
is).
Anyway, this awful abomination works. Let's all move on to more
useful ways to spend our time...
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.
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.
Instead, parameters evaluate to QgsFeatureSource, which are
used for retrieving features, feature count, crs, wkb type,
etc.
This abstracts away the actual feature source, so that
algorithms may potentially operate from non-layer
feature sources.
It also helps remove the need for specialised QgsProcessingUtils
methods like getFeatures, featureCount, and createSpatialIndex.
Instead the standard API methods using QgsFeatureSources can
be used instead.
input to a processing algorithm.
This allows parameter inputs to encapsulate extra information
relating to a feature sink input, such as destination file
encoding and whether the sink layer should be loaded into
the project on completion
