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.
The 'layercount' attribute was not used anyway and the calculated number could already be outdated when loading the project file again due to changes to embedded projects.
This change makes it possible to have a different geometry used
for labeling obstacle detection to the geometry used for generating
label position candidates.
Also fixes parts of multipolygon features were not treated as
obstacles when "label only largest part" of polygon was checked.
Some inefficiencies in pal were also fixed (eg avoiding adding
features/obstacles to pal rtree indexes when they will never
be used).
Sponsored by City of Uster
Fixes issues like rule based labelling registering two labels for
a single feature which was resulting in each label colliding
with the feature's geometry registered by the other label. This
resulted in poor placement for these labels.
Sponsored by City of Uster
Previous test was just checking point in polygon for the corner,
mid points and center. This test was not sufficient for narrow
or small polygons which were not covered by these points
but were still covering parts of the label candidate.
Now, the area of the intersection between the obstacle polygon
and the label candidate is used to calculate the obstacle
cost.
