The 3D scene's CRS is not necessarily the same as the project's
CRS. For example, it can be "EPSG:3857" if the project's CRS is
geographic.
The stored extent in the settings is always the 3D scene's extent.
See:
b0d1a4f8b1
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%.
