A few releases ago a bug fix was implemented which forced conversions
of multi-layer sources. This was a valid bug fix, but the consequence
was that any algorithm using this api with a source file containing
multiple layers (e.g. gpkg) performed a complete copy of the target
layer to a new file, severely impacting performance.
This commit adds new API to retrieve a compatible layer path in the
case when an algorithm CAN correctly handle specific target layer names.
In this case, the forced copy of the source layer is avoided when
using multi-layer inputs like geopackage.
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.
output format
This setting is still used and required in some circumstances, e.g.
it is used as the default selection in outputs file pickers when
the previously used format is not valid.
to have a file filter string defined
Previously only an extension was settable, which prevented use when
multiple extension types are possible. A file filter string allows
for flexible file selection instead.
In processing, if an algorithm has a boolean as an output, it cannot be defined as boolean but as a number.
To be more precise in algorithms description, the commit add QgsProcessingOutputBoolean.
which will be available to a parameter when it is evaluated.
Specifying variables via this method is for metadata purposes only.
It is the algorithm's responsibility to correctly set the value of
these additional variables in all expression context used when evaluating
the parameter, in whichever way is appropriate for that particular variable.
This adds a new parameter type specifically for map scales,
QgsProcessingParameterScale. The values are evaluated using
self.parameterAsDouble, which returns the map scale
denominator (matching the standard in other parts of the
QGIS API).
Scale parameters are displayed to users using the standard
QgsScaleWidget, which includes the combo box of predefined
scales and a shortcut button to match the current map scale.
Returns a descriptive list of the possible string values acceptable
for the parameter.
E.g. for a QgsProcessingParameterVectorLayer this may include
"Path to a vector layer", for QgsProcessingParameterBoolean
"1 for true, 0 for false" etc.
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!
Instead of requiring clients to generate temporary file names themselves,
(or use the cryptic "memory:" string!), this PR adds a static constant
QgsProcessing.TEMPORARY_OUTPUT
If a layer/sink output parameter is set to QgsProcessing.TEMPORARY_OUTPUT,
then the temporary output filename will be generated automatically at
algorithm run time. This means callers don't need to mess around with
finding appropriate temporary folders and paths.
Another benefit is that TEMPORARY_OUTPUT is stored in the processing
history, so if you re-run a previous algorithm which was set to
output to a temporary file, it no longer tries to use that same
previous temporary path and instead generates a new one.
