VectorImage: Label decluttering should take label rotation into account

[Rskut]

Current behaviour:
If I rotate a label in a polygon the decluttering function still works like the bounds are the same,
even if the label would fit withing the bounds of the polygon.

Wanted behaviour:
recalculate the bounds if the label rotation changed

[mike-000]

I presume you mean the overflow property of the style ( labelled as exceed length in https://openlayers.org/en/latest/examples/vector-labels.html ) always uses the unrotated width of the geometry at the label point, which is not the same as decluttering. If view rotation was passed to the builders it might be sufficient to clone and rotate the geometry when calculating widths, but there would be a performance overhead.

[Rskut]

Yes exactly I mixed them up, sorry.
Why it have something to do with the view rotation? I do not rotate the view, just the labels.
Is there a way to customize this?

[mike-000]

Rotated labels with unrotated view has the same problem as unrotated labels with rotated view.

[ahocevar]

A more performant fix would be to rotate the extent rectangle in ol/geom/flat/interiorpoint, and create a rotated line instead of a straight line that crosses the geometry at half of the height of the (rotated) extent. @mike-000, would you be interested in attempting a pull request with such a fix? I think instead of flatCenter, the ol/geom/flat/flatInteriorPoint functions should then be called with that line. And the getFlatInteriorPoint() method of ol/geom/Polygon would need a rotation argument. Same for MultiPolygon and RenderFeature.

[mike-000]

I don't think a method based on extent would fix cases such as this

[ahocevar]

The algorithm works like this:

The dashed line (center line of the label) crosses the geometry at half of the height of the extent, and the longest segment that's inside the geometry is used for the label. So when you rotate the extent, the dashed line won't have a constant y any more, but be expressed by a simple line equation (y = k * x + d). So the calculation of the candidate segments will be a little bit more involved (i.e. solve the equation instead of using a constant y), but overall it is much less computation effort than using a straight extent on a rotated geometry.