Run clang-tidy modernize-use-override to remove all the redundant
virtual keywords from overridden methods, and add some missing
overrides.
Another benefit is that this has also added the overrides
on destructors, which will cause a build failure if a base
class is missing a virtual destructor.
to use for their algorithm's parameters
Because some providers do not have support for all output types,
we need to give providers a way to restrict the default format
choices to those which are supported by the provider.
Instead of showing the progress reports for each child algorithm
individually, which leads to repeated 0->100% progress for every
step of a model, we proxy the progress reports and account for the
overall progress through a model as well. This means that
the progress accounts for both the progress within the current
model step AND the total number of steps left to execute.
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.
And use it when we need to clone parameters (instead of more fragile
conversion to and from variants)
This fixes model loading which use algorithms which create python
subclasses of parameter definitions
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).
