QgsProcessingFeatureSink, not all QVariant types
Only strings/QgsPropertys are valid anyway, so instead of strings
use static properties. This makes it clearer what possible
values are permitted for the underlying source/sink definition.
flexible QVariantMap creatOptions parameters which include an
optional fileEncoding value
More flexible, allows sinks to be created using any creation
option which is passed to the underlying provider
input to a processing algorithm.
This allows parameter inputs to encapsulate extra information
relating to a feature source input, such as whether only
selected features from the source layer should be used.
Instead, parameters evaluate to QgsFeatureSource, which are
used for retrieving features, feature count, crs, wkb type,
etc.
This abstracts away the actual feature source, so that
algorithms may potentially operate from non-layer
feature sources.
It also helps remove the need for specialised QgsProcessingUtils
methods like getFeatures, featureCount, and createSpatialIndex.
Instead the standard API methods using QgsFeatureSources can
be used instead.
input to a processing algorithm.
This allows parameter inputs to encapsulate extra information
relating to a feature sink input, such as destination file
encoding and whether the sink layer should be loaded into
the project on completion
This somewhat changes the meaning of outputs from processing 2.x.
In 2.x processing outputs were used both as a method of specifying
inputs to algorithms (file paths to destination layers created
by the algorithm) AND pure outputs (such as statistics calculated
by the algorithm).
This is now split. The old input-type-outputs (destination layers)
are now input parameters (since the parameter value IS an input to the
algorithm). To differentiate them from parameters indicating pure
input layers a new "isDestination()" method was added to
QgsProcessingParameterDefinition.
Output definitions are now purely indications of values CREATED
by the algorithms. Suitable candidates are the existing calculated
stats and actual file path/URI of any layers created by the algorithm.
Moving forward we should ensure all algorithms output as much
useful information as possible - e.g. number of features processed,
number of skipped features, count null geometries encountered, etc...
when changing current band
Now the widget asks users if they want to delete existing categories
when they switch a band, just like how the categorized renderer
widget asks when the categorized field is changed.
