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).
For now it's only for WMS but you get the idea.
There is a new abstract base class for the source select
dialogs, that will grow with common behavior for all
the select dialogs.
Signals are forwarded from the (root) data items to the
app and then delivered to the various browser instances
and to the unified layer dialog.
A change in one of the browser items should trigger a
refresh in all the other browsers and dialogs.
When methods are called that use GEOS to create new geometries, the
result geometries now contain information about what has gone wrong in
case of an error.
In practice, this means it's possible to give more detailed information
in place (and not only in the message log) when things like processing
algorithms fail.
This allows optional outputs (such as null geometry features detected
by the Remove Null Geometries algorithm) to be skipped by default
when desirable.
The layer expression context (which is required for aggregate
calculation to work) was not being added to the context used
by vector layer feature iterators.
Fix#15930
Allows setting symbols other map item sizes to Map Units in Meters. This allows setting the size always in meters, regardless of what the underlying map units are (e.g. they can be it geographic degrees). The size in meters is calculated based on the current project ellipsoid setting and a projection of the distances in meters at the center of the current map extent.
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.
Instead of relying on forward declared c++ classes from
gui in QgsLayoutItemRegistry, instead create a
QgsLayoutItemGuiRegistry which handles registration
of all the GUI specific behavior relating to layout items.
Remove all GUI related code from QgsLayoutItemRegistry.
This creates a cleaner split between core/gui code, and
given that there'll be a lot of gui specific behavior
which needs to be handled by a registry it makes sense
to keep this isolated in gui.
It also plays nicer with the sip bindings, which can't
handle forward declared gui classes in core.
c++ QgsLayoutItem metadata classes can directly register
a function which creates a QgsLayoutViewRubberBand for the item
subclass.
Python code cannot utilise this shortcut (due to inaccessibility
of forward declared gui classes from core Python classes), so
there's a separate gui registry utility class added for registering
prototypes for rubber bands for already registered item types.
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
The previous naming was too easily confused with processing outputs.
Rename them to QgsProcessingParameterFileDestination, etc... to
make it clearer what they are used for.
