The expression is evaluated just before the child algorithm is
executed, so can utilise results already calculated by other
children in the model through the use of expression context
functions
converted to QgsMapLayer objects with the ownership transferred
to the Python caller
This should make it super-easy for PyQGIS scripts to run processing
algorithms and immediately utilise the results, even if they
are memory layers. They call processing.run(), and get a dict of
results back which includes those layers ready for adding to the
current project or doing some other processing or operations
with, and if they don't transfer to ownership off then these
layers will be correctly garbaged collected by Python.
- remove temporary layers from context, delete them as soon as they
are finished with
- directly remove features via data provider, instead of selecting
and using edit buffer
- use native geometry methods for splitting to single features
and removing rings
Since it's safe to evaluate parameters in background threads
now, it's usually going to be ok to evaluate everything in
the processAlgorithm step.
This keeps the algorithm code as simple as possible, and will
make porting faster.
Note that the prepare/postProcess virtual methods still exist
and can be used when an algorithm MUST do setup/cleanup work
in the main thread.
We only emit the progress changed signal when there's been at
least a 0.1% change since the last progress report. Otherwise
it's possible that things like processing algorithms which
are reporting feedback every feature in a 500k feature dataset
cause a gazillion signals to be emitted and everything to
slow to a crawl
add to the current context
With appropriate note and tests to ensure that both the current
context and that which the results being taken from share the
same thread affinity
- take a clone of algs before running them. This avoids issues
if the algorithm is removed or edited while a background task
is running
- accept an optional existing feedback object
