RFC 11: Curved Labels

[Bill Binko]

Guys: this all sounds wonderful!  Can I see some images from it?  Or do 
I have to apply the patch and try it out

;-)

Benj Carson wrote:

>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
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20060216/91b19e8b/attachment.html