And allow execution of just a subset of child algorithms from
a model, using the initial state as a starting point
This will allow "resuming" a model, running part of a model using
the state from a previous execution.
Even when the model execution fails, store the child inputs and
results for all steps which successfully completed in the context.
This gives more debugging information to a user when a model fails,
because these values will now be reflected in the model designer
view for all steps which completed.
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.
add an explicit log level getter/setter to QgsProcessingContext which
algorithms can use to determine an appropriate level of feedback
to push to users.
Initially the verbose log only triggers the full verbose output
of model executions (which is also used when running models through
the model designer), but the intention is that more algorithms
will fine tune their output based on the logging level.
qgis_process also gains a new --verbose switch to enable verbose
log output.
[processing] Infrastructure for QgsMeshLayer to add processing algorithms, dataset group paramater and dataset time parameter to allow the user to easily choose a dataset.
always avoid using temporary file names, and then set this option as
enabled by default.
Also change the setting key so that existing users will also get the new
default value.
Fixes#32591
These methods return a file extension to use when creating vector/raster outputs (e.g. "tif"). Generally,
it is preferable to use the extension associated with a particular parameter, which can be retrieved through
QgsProcessingDestinationParameter::defaultFileExtension(). However, in some cases, a specific parameter
may not be available to call this method on (e.g. for an algorithm which has only an output folder parameter
and which creates multiple output layers in that folder). In this case, the format returned by this
function should be used when creating these outputs.
It is the algorithm's responsibility to check whether the returned format is acceptable for the algorithm,
and to provide an appropriate fallback when the returned format is not usable.
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
