<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys: this all sounds wonderful! Can I see some images from it? Or do
I have to apply the patch and try it out <br>
<br>
;-)<br>
<br>
Benj Carson wrote:
<blockquote
cite="mid200602161130.36677.benjcarson+mapserver@digitaljunkies.ca"
type="cite">
<pre wrap="">On Thursday 16 February 2006 05:44, Stephen Woodbridge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
This is certainly feasible, but it is beyond what is currently done in the
proposed solution.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>