Rationale:
- the correct use for this option is unclear, and users are
mistakenly using it as a 'tolerance' option
- it's very likely to generate invalid geometries as a result
of the snapping, causing unreliable results
Given these substantial issues, it's safer to remove this
option and require that users who need the snap to grid
precision change explicitly do this via an extra model
step before running the algorithm.
Changes:
- handle different CRS transparently
- don't build a spatial index on the selection layer. Instead
only use feature requests to fetch features which are within
the desired bounds, and rely on the presence of an appropriate
spatial index at the provider's backend. Otherwise, we force
every user of this algorithm to have a full iteration of the
source table, regardless of how large the table is. That means
that trying to select a set of addresses which fall within
a specific locality from a table which contains the addresses
for a whole state will FORCE every address in the state to
be initially read before any calculation begins. With this
change only those features within the bounding box of the
selected localities will ever be fetched from the provider,
resulting in huge speed improvements for the algorithm.
- use prepared geometries for the spatial relation tests.
This dramatically speeds up the algorithm in the case
where the intersection layer features cover multiple
features from the 'selection' layer.
- Add a 'select within current selection' mode
- Optimise feature requests for efficiency (especially
with respect to the 'disjoint' selection mode)
- allow non spatial inputs
- allow calculation of stats on any field type, with specific
string and datetime stats calculated when field type matches
- output a full set of stats for numeric fields (including median
, quartiles, etc)
- also calculate stats for 'null' category
It's possible to re-use the last 10 display expressions in the form view
of the attribute table.
The expressions will also be persisted in the project file.
Using fields will now show field aliases instead of column names where
available.
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 ... ?
