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
to control whether selected features only are to be used
Replaces the old global setting and makes it immediately obvious
to users when the selection will be respected
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...
While the processing API is in such a state of flux it's
become unmaintainable to port these algorithms change-by-change.
Instead, disable them all until the API is fixed, and then we
can port them algorithm by algorithm and reactivate each
test in turn.
