1. Remove redundant sort operations
2. Rename classes and methods for clarity
3. Don't overwrite polygon candidate costs with new costs based solely
on the ring distance cost -- instead just increase the existing cost
by the ring distance cost, so that already calculated costs such as
obstacle overlap costs aren't lost
4. Remove unused code
Seems to be trimming the candidate list early and artificially
resetting all candidate costs if they are too high?
I believe this code is wrong, or has been made redundant by other
changes to the logic of the labeling engine. At this stage we have
not completely calculated the costs for label candidates, so
sorting and truncating the candidate list here is premature and potentially
removes nice candidates.
Avoids crashes caused by super-heavy labeling jobs, where a huge
number of candidates causes the rtree to branch out to a level
where the leaf size becomes comparable to float epsilon values
Candidates furthest from any obstacles were being preferred, even
when this resulted in labels being located around the edges of polygon
features.
The correct logic should be only to consider direct overlaps of the
candidate with an obstacle as a conflict, and if a candidate does
NOT overlap and obstacles then we rely on the "put labels furthest
from edges as possible" rule.
to be placed on the maximum number of point, line and polygon candidates
which are generated for label features
These settings are set via the core\rendering\label_candidates_limit_*
settings, and allow for global limits to be set on the maximum number
of candidates allowed for label features. Placing these limits can
improve map rendering time, at the expense of worse label placement or
potentially missing map labels. (By default no global limit is set, which
means the labeling engine auto calculates the limit or uses the project
level settings)
The intended use case is for server administrators who are seeking for
maximum rendering speed to globally set these limits, causing them to
apply to all projects without the need for project-specific tweaks.
settings and logic
The previous approach of a single fixed value which applied to ALL line and ALL polygon
features was... not ideal. It meant that all line features would be assigned the same
number of candidates, regardless of length. So a road of length 1 cm on the rendered
map would have an identical number of candidates as a 30cm road covering the length of the
whole map!! This resulted in both a lot of wasted calculations (generating a ridiculous
number of candidates for small lines at barely discernable distances from each other)
AND an insufficient number of candidates for lengthy features (resulting in worse label
placement for these features).
(The situation was similar, but even worse for polygons)
Now, the setting is reworked to "Number of line candidates per cm" and "number of
polygon candidates per cm2". This means that small features get much less candidates,
and large features get much more features! Both a win for map rendering speed in many
circumstances AND good cartography... now that's a nice Christmas gift for QGIS :)
Fix dependency inconsistency to project from QgsRelationManager
by forcing 'QgsRelation::createFromXml' to rely on project passed
to 'QgsRelationManager' instead of using 'QgisProject::instance()'
to use when reprojecting vector layers via the "Reproject Layer" algorithm
On proj 6+ builds only!
Allows users to set a specific operation to use for a particular reprojection
task, instead of always forcing use of the current project's transformation
settings.
Useful when reprojecting a particular layer and control over the exact transformation
pipeline is required.
