We no longer require the seperate CRS parameter, because the extent
parameter contains the CRS information itself. This means the algorithm
is simplified to just picking the layer and drawing the desired area
on the canvas.
generated filename for outputs
Previously they were just echoing the input parameter value,
which isn't always a string and accordingly was broken for
temporary outputs. This caused models to break when the output
of a GDAL algorithm was used in a subsequent model step.
The "comments" PR 8831 added support for postgres only
(and broke all the others backends).
I'd be in favor of a revert of the whole original PR but
this patch restores functionality and could be an acceptable
temporary fix until the comments PR is reworked in a more
maintainable and elegant way.
Fixes#21151 btw
Brings back QGIS 2.18's ability to directly convert a Processing model
to an equivalent Processing Python script algorithm, correctly
updated and working in the 3.x API.
Available from the model dialog, and from the right-click context
menu on an existing model.
Sponsored by Solspec
- fix parameter can get converted to plain number parameter after edits
- allow parameter to be linked to parent parameters, so that the
correct distance unit and choices are shown for the parameter
of main algorithm
Using code like:
buffered_layer = processing.run(..., context, feedback)['OUTPUT']
...
return {'OUTPUT': buffered_layer}
can cause issues if done as a sub-step of a larger processing algorithm. This
is because ownership of the generated layer is transferred to the caller
(Python) by processing.run. When the algorithm returns, Processing
attempts to move ownership of the layer from the context to the caller,
resulting in a crash.
(This is by design, because processing.run has been optimised for the
most common use case, which is one-off execution of algorithms as part
of a script, not as part of another processing algorithm. Accordingly
by design it returns layers and ownership to the caller, making things
easier for callers as they do not then have to resolve the layer reference
from the context object and handle ownership themselves)
This commit adds a new "is_child_algorithm" argument to processing.run.
For algorithms which are executed as sub-steps of a larger algorithm
is_child_algorithm should be set to True to avoid any ownership issues
with layers. E.g.
buffered_layer = processing.run(..., context, feedback, is_child_algorithm=True)['OUTPUT']
...
return {'OUTPUT': buffered_layer}
For algorithms with multiple parameters depending on a vector layer parameter, the code that loads the layer in the background is called repeatedly, impacting performance. A small layer cache is implemented with these changes, so the dialog only tries to load the layer once.
