RFC 11: Curved Labels

[Benj Carson]

On Thursday 16 February 2006 05:44, Stephen Woodbridge wrote:
> Great work guys! I look forward to this.
>
> I couple of comments, which might be too detailed for the rfc, or not.
>
> 1) What is the behavior when the label extends beyond the feature?
>

In the proposed patch this case is handled by comparing the length of the 
label to the length of the longest line segment in the feature.  If the 
label is less than 1.5 times as long as the feature then it is drawn, 
otherwise it is skipped (unless the label is forced, in which case it is 
drawn anyway).  The value of 1.5 is simply hardcoded at the moment.  It 
seemed to give me pretty decent results, but it may need some adjustment.


> 2) Would it be appropriate to be able to control long labels on short
> features? - I know we don't do this today so it might be outside of
> scope.

This is certainly feasible, but it is beyond what is currently done in the 
proposed solution.

> 3) What plans if any do you have to deal with right side up-ness 
> of a label that is curved, I proposed a fast algorithm for that in the
> bug :) The problem being that while the first character rendered might be
> right side up, the remaining might be mostly upside down so a quick scan
> of the feature is needed to determine what is right side up.
>

I have integrated an algorithm similar to the one you described on the bug 
page into the patch.  Instead of taking the cross product of each segment 
with a vector perpendicular to the map, I'm comparing the x values of the 
endpoints of each segment that is covered by the label (which I think is 
equivalent to taking the cross product in terms of determining direction).  
If most of the segments are left to right, the label can be drawn on it 
directly and it will be mostly right-side up (since this is what GD 
expects).  If the feature is mostly right to left, the line is processed in 
reverse order producing a label path that progresses left to right.

So, the whole feature *is* scanned in order to determine which way is up, 
and the results are much better than the initial implementation.  The 
algorithm can still produce some so-so results if there is one long left to 
right segment and several right to left segments (e.g. in a line shaped 
like the number "7"), but for the most part nothing is completely upside 
down.

For the nitty-gritty details:  All of this is in mapprimitive.c in the 
msPolylineLabelPath() function once the patch is applied.


Benj