TauDEM is quite specific set of tools and it requires installation of
some additional tools. So we decide to turn it into separate provider,
reducing core codebase size and maintenance efforts.
Tagged as feature to not forget mention in changelog and documentation
Intended as a registry for the various processing components,
including providers, algorithms and various parameters and outputs.
Currently handles only registration of providers, as a step toward
removing processing's algList (this requires first porting
the algorithm class to c++)
A QgsProcessingRegistry instance is attached to QgsApplication,
and is retrieved by QgsApplication::processingRegistry()
Nothing particularly exciting here yet, but this commit
moves the definition of the provider base class to a c++
QgsProcessingProvider abstract base class.
As part of this some existing python methods were renamed
to make their use clearer and to fit with the QGIS c++
api conventions:
- getName was renamed to id
- getDescription was renamed to name
- getIcon was renamed to icon
These API breaks are documented
These variables take a lot of time to calculate and cause lots of
lengthy hangs in processing. (Eg add some moderately large rasters
to a project, then try to run any processing algorithm and QGIS
will freeze).
The layer extent can already be used in expressions via the
layer_property function, which only evalutes the extent if required
and only for layers it is used for.
The band stats for raster layers should be moved to a
band_statistic function in core which behaves the same way.
This adds a new input type for expression inputs. Expression
inputs can be linked to a parent layer so that the builder
shows the correct fields and layer variables.
It's designed for two use cases:
1. to be used when an algorithm specifically requires an expression,
eg Select by Expression and Extract by Expression.
2. to be potentially used as a replacement input instead of string
or number literals in algorithms. Eg - if the simplify algorithm
tolerance parameter was replaced with an expression paremeter, then
this expression would be evaluated for every feature before
simplifying that feature. It would allow parameters to be calculated
per feature, as opposed to the current approach of calculating
a parameter once before running the algorithm. It would also
mean algorithms like "variable distance buffer" would no longer
be needed, as a single "buffer" algorithm could then be used
for either a fixed distance, field based, or expression based
distance.
Tags are used while searching in the toolbox. This should help with
finding algorithms when the exact name is not known, eg
you could search for "envelope" or "bounds" and find the
'Polygon from Layer Extent' algorithm.
At the moment it's quite hard to discover algorithms which exist
when you don't know what their called and have to instead search
for every possible naming variant which could exist...
