uses expressions for parameter values and contains variables
generated by another step in the model
We were showing links for these in the model designer so it
appeared as though the dependencies were there, but at actual
execution time there was nothing forcing the child which generated
the variable to be run before the child using the variable.
At model debug log level we'll show all the generic
logs for step preparation, inputs and outputs for every
child algorithm, including those which we normally skip
(eg raise warnings/outputs, string concatenation, etc).
This gives model designers more useful information to
debug their models.
Use this new log level when running models through the
model designer window.
This adds a new "Reorder Model Outputs" action to the model designer
menu (to accompany the existing "Reorder Model Inputs" action).
Selecting this option allows model creators to set a specific order
which the outputs from their model must use when loading the results
into a project. This gives the model creator a means of ensuring
that layers are logically ordered, eg placing a vector layer over
a raster layer and a point layer over a polygon layer.
Optionally, the model creator can also set a "Group name" for the
outputs. If this is specified then all outputs from the model will
be placed into a (newly created if necessary) layer tree group
with that name.
Sponsored by the QGIS Germany User Group
efficiently for many calls
Allows retrieval of some basic algorithm properties (display name,
icon) in an optimised way for many calls. (Avoiding multiple
expensive algorithmById lookups)
This enum can be used in the QgsProcessingUtils::mapLayerFromString()
and parameterAsPointCloudLayer() calls to control layer loading, e.g.
skipping index generation or not applying default style, etc.
This change adds a new "feature filter" option alongside the
existing feature limit and invalid geometry handling options
available for all vector inputs to processing layers.
It allows users to enter an expression to subset the layer dynamically
when running the tool, avoiding the need for separate steps to
set layer filters or create layer subsets.
Sponsored by City of Canning
Instead of forcing all steps in the batch processing dialog to execute
in the main thread, we now run each step as a separate task whenever
possible. This keeps the UI nice and responsive, and permits
responsive cancelation and progress reporting.
Individual steps are still run sequentially, not in parallel (yet!)
also update the internal name of that parameter and all child algorithms
in the model accordingly
Before we just "faked" this by changing the parameter's description
only, but that meant that the old name was permenantly stuck and
had to be used in qgis_process or when calling the model via
python.
