Turns out this index is MUCH (magnitudes) faster for use in pal. So
grab an updated version of the upstream library and place in external libs,
and use this for indices in pal.
(we should probably investigate whether this is faster for snapping and
other index use too!)
Because GEOS prepared predicates are "stubbed out" for many relation types,
such as overlaps and touches, we can get a HUGE speedup by reworking
the obstacle boundary check to utilise an intersects and within check instead
(with the same results)
they collide with an obstacle feature of greater weight when compared
to the label's priority
Previously, obstacle weight was used ONLY to rank a features' label
candidates relative to each other, but was never used to actually prune candidates
completely. This meant that the labeling obstacle functionality was
confusing and frustrating for users to work with -- because despite
setting layers as the maximum possible blocking weight, you'd still
see labels being placed over these features (e.g. where the labeling
engine had no other choice).
Now, (when a project is set to v2 labeling engine mode), labels will
NEVER be placed over obstacles of greater weight. This means that
labels will potentially be omitted if the only choice is to place
them over a high weighting obstacle. But ultimately, that's much
more understandable for users -- they've manually set a particular
layer to a high obstacle factor, so we should respect that and
never place labels on these features.
In the end, this change makes the labeling placement much simpler
to understand for users, and should give power users a much
nicer experience all round.
Funded by the QGIS grants program
We can dramatically speed up label overlap detection on this common case, since
it reduces to overlap of two axis-aligned rectangles.
Speeds up rendering of labels on complex maps
- remove use of namespace blocks (avoids unnecessary indentation)
- cleanup includes
- remove old std::cout debugging blocks
- move some documentation from cpp to headers
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
Fixes curved label candidates not being marked as in conflict with
polygon obstacles when letters other than the first letter conflict
with the polygon.
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.
Test was incorrectly checking for intersection of the candidate
and polygon obstacle, when it should have been checking for
overlapping or touching obstacles.
