and add new QgsGeometry::fromPolyline which uses QgsPoint
We want to encourage people not to use the QgsPointXY method, as it drops
Z/M values. So it's moved across to a different name to make way
for a new QgsGeometry::fromPolyline which uses a QgsPoint list
instead of QgsPointXY, thus keeping Z/M values intact.
Similarly, QgsPolyline now is a list of QgsPoint (keeping z/m values)
and the old 2d QgsPolyline type was renamed to QgsPolylineXY.
Making the QgsPoint method the "preferred" method and making linestrings
just as easy to create from z/m dimensioned points as 2d points is
important to push people to write code which does not discard
these important dimensions.
As a bonus, the QgsPoint methods are more efficient anyway, since
they don't require creation of a temporary list.
input layers with Z or M values present
Also ensure that written geometries are always multitype, to
match the created layer geometry type (before the layer was
being created as a multi* layer, but single part geometries
were sometimes created. This causes errors with some data
providers)
Like the main Join Attributes by Location algorithm, this algorithm
takes two layers and combines the attributes based on a spatial
criteria.
However this algorithm calculates summaries for the attributes for
all matching features, e.g. calculating the mean/min/max/etc.
The list of fields to summaries, and the summaries to
calculate for those, can be selected.
Improvements:
- transparently handle different source/join CRS
- added option to create output feature for EVERY joined
feature (i.e. 1 to many type join)
- added option to select joined fields to take
- optimised performance of algorithm
The previous option to create a summary of joined features has been
removed, and will be moved to a separate 'Join by location (summary)'
algorithm.
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)
