RFC 11: Curved Labels

[Steve Lime]

I have committed the most recent patch Benj had posted for bug 1620. Now we can move forward and make adjustments as necessary...

Steve

>>> Yewondwossen Assefa <assefa at DMSOLUTIONS.CA> 02/17/06 8:16 AM >>>
+1 form me.

Steve Lime wrote:
> A quick note about POSITION AUTO. For lines that means only 2 possiblities- UC and LC. That's how it is now anyway. The thought being that you wouldn't one some on the line and some above, for instance, but some above and some below looks ok. So there are really only 2 possible paths. Following the way the label cache works now, if position=AUTO we could compute UC by default and store enough information to recompute the path in the labelPathObj...
> 
> CC is not used for any AUTO placement, but is the default otherwise.
> 
> Steve
> 
> 
>>>>Benj Carson <benjcarson+mapserver at DIGITALJUNKIES.CA> 02/16/06 12:31 PM >>>
> 
> On Thursday 16 February 2006 09:40, Yewondwossen Assefa wrote:
> 
>>Steve,
>>
>>  That is great.  The only question I have was :
>>
>>   * what happens with the position parameter in the label ? would the
>>values ul, uc, ... would be respected giving control on where the label
>>is postionned.
>>
> 
> 
> Currently the position parameter is ignored for curved labels.  Support for 
> it could be added fairly easily (simply by offsetting each character from 
> the feature when computing the label's path).  There is one caveat to this 
> though: POSITION AUTO would require re-computing the entire path at each 
> alternative position, which could be computationally expensive.  Perhaps a 
> solution would be to disallow POSITION AUTO for curved labels, with the 
> default being MS_CC?
> 
> 
> 
> Benj


-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------