std::sort is returning a slightly different sort order when
label z order (or label cost) is equal
Given that the order in these cases is effectively arbitrary
I've updated the test masks to accept either order.
(only works with Cartographic point label placement). When this
setting is active, the label distance applies from the bounds
of the rendered symbol for a point, instead of the point itself.
It's especially useful when the symbol size isn't fixed, eg if
it's set by a data defined size or when using different symbols
in a categorised renderer.
Sponsored by Andreas Neumann
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.
