Make sure that results from a feature counter will only be delivered on
the main thread and that they will be discarded if the layer is deleted
meanwhile.
This algorithm is no longer required - it's been replaced by
the 'Promote to multipart' and 'Collect geometries" algorithms.
Tagged as feature to remember to include in release notes
This is basically the equivalent of the dissolve algorithm, but
instead of a dissolving overlapping geometries the geometries
are instead just collected together into a multipart geometry.
It's designed to slot between the 'promote to multipart' algorithm
(which performs no collection of geometries - it just converts
singleparts to multiparts with 1 part) and the more complex
all-encompassing 'aggregate' algorithm.
This algorithm is basically the equivalent of the ST_Multi(...)
command - it forces a feature's geometry to become multipart,
regardless of the input geometry type.
If input geometries are singlepart, they will output as
multipart with just 1 part. If they are already multipart,
they will be output unchanged.
Tagged as feature to be included in release notes.
Because:
- The use case for this algorithm is very unclear for users - the name
does not describe what the algorithm does, and there's no help
documentation available for the algorithm either. Given this I suspect
that the algorithm is not being put into use.
- The algorithm needs enhancement to be more useful. There's no logic
in place which dictates how neighbouring features are chosen to
dissolve into the selected feature (it's effectively random - you're
just as likely to get a huge narrow polygon stretching across a map as
you are a nice compact cluster). To be more useful the algorithm would
need logic to either minimise the area of the dissolved feature, or
minimise the total number of dissolved features, or ... ?
In practice this turns out to be undesirable - snapping changes
are more of a semi-permenant interface setting as opposed to something
which should be stored in the layout's undo history.
If a subset string is set on an OGR layer, the feature iterator returns features with ids taken from a sequence starting from 0, regardless of the original feature id.
This causes a mismatch in the data shown by the identify results table and the attribute widget.