For the "Around point" and "Cartographic" placement modes, this
adds a new optional setting for the maximum distance of the labels from
the feature. It's used together with the existing distance setting
to define a range of distances at which labels may be placed
from their corresponding point features.
This adds more flexibility to the placement for these layers,
ultimately allowing for more labels to be placed in busy maps.
When the layer is set to the "around point" mode, then label
candidates which are closer to the point will always be prefered
over those which are further away.
When the layer is set to the "cartographic" mode, then the default
behavior is also to prioritize closer labels. A new combo box
allows users to control the priority, with an option for
prefering position ordering. If this option is set, then candidates
at the corresponding positions (eg top left) are preferred regardless
of how far they are from the point, with the labelling falling
back to alternate positions only when no labels can be placed
up to the maximum label distance.
Sponsored by Rubicon Concierge Real Estate Services
This change is similar to the one introduced in the previous
commit for `QgsAttributes` . The python call of `setAttribute` expects
a `QVariant` as input. sip is able to directly handle `QVariant` but
this allocation can be slow.
In some cases, it is possible to speed-up the `setAttribute` call by
checking the type of the attribute. If the attribute is a boolean, an
integer, a float or a string, it is possible to avoid the intermediate
sip QVariant allocation done by `sipConvertToType`.
Based on some testing, this allows to speed-up a python `setAttribute`
call up to 80%. If the python attribute is already a `QVariant`, then
one get the same time.
The python `QgsFeature.setAttributes()` calls is relatively slow
because of the call to `sipConvertToType` which needs to make in
intermediate allocation for each attribute QVariant creation.
This change aims to speed up this call by avoiding the call to
`sipConvertToType` for the most common types.
The change itself is quite simple. If the input attribute is a
boolean, an integer, a string or a floating, a QVariant is directly
created by using the python C API instead of calling
`sipConvertToType`.
Based on some testing on lists which can contain between 5 and 10
elements, I have measured an acceleration up up to 70%.
This allows us to control the sort order and limit for each expansion,
and gives us more flexibility in future to eg handle per expansion
filter strings
This change allows SensorThings entities to be expanded to contain
their related child feature attributes, exposing the relational
SensorThings model as a traditional "flat" GIS-friendly table
structure.
Eg when selecting Location entities, you can now opt to expand
to "Things > Datastreams > Observations". This would result in
multiple "stacked" point location features, one corresponding
to each observation, with the attributes for each point feature
containing the location, thing, datastream and observation
attributes.
(Best used combined with some extent, feature limit, or custom
filter option, as this can otherwise result in very heavy
requests to the backend service!)
Fixes#56805
