[mapserver-dev] RFC-60: Label enhancement to skip ANGLE FOLLOW labels with overlapping chars

Daniel Morissette dmorissette at mapgears.com
Fri Aug 27 11:58:29 EDT 2010


To undertsand this, you have to realize that there are two types of case
we are dealing with:

- characters overlapping because they are placed inside the curve. In
this case the difference of angle between a given char and the char that
follows it (and overlaps it) is negative. See the label "South Avenue"
in Alan's example.

- characters that are spreading apart (the reverse of overlapping?)
because they are drawn on the outside of the curve, in this case the
angle difference is positive. For example, the "North Avenue" and
"Whites Creek Lane" labels in Alan's image fall in that case.

The initial implementation was using a fabs() of the angle difference to
filter out both cases, but what Alan is proposing is that there could be
three possible behaviors:

- MAXOVERLAPANGLE 0 : turns off filtering

- MAXOVERLAPANGLE > 0 : Use fabs() on the angle difference, which means
filtering out both cases (labels with characters overlapping inside of
the curve and characters spreading apart outside of the curve)

- MAXOVERLAPANGLE < 0 : Filter out only characters overlapping inside
the curve, i.e. those where the angle difference is negative.

Hopefully this explanation makes sense.

Daniel


Alan Boudreault wrote:
> Daniel and I discussed about this issue... and something we could do is to let 
> the user the ability to ONLY discard labels that are overlaping themself by 
> the interior of the line (Not sure how to explain that term) by setting a 
> negative value to MAXOVERLAPANGLE. Here's the behavior in images:
> 
>  http://dl.mapgears.com/ab-tmp/maxoverlapangle.png (Check the labels Whites 
> Creek Lane, South Avenue and North Avenue)
> 
> Thanks,
> Alan
>  
> On August 27, 2010 10:44:20 am Stephen Woodbridge wrote:
>> On 8/27/2010 9:52 AM, Smith, Michael D ERDC-CRREL-NH wrote:
>>> Jeff et al,
>>>
>>> My recommendation would be that if its a change in behavior, the make it
>>> explicit to turn it on, not explicit to turn it off.
>>>
>>> I do think this will be a very important addition to labeling.
>> I think we need to take into account the bigger picture for this
>> release. 6.0 is a major release and we expect that there will feature
>> changes that will break backwards compatibility. I think we should make
>> this decision based on what other things are also changing. For example
>> do we have other mapfile changes that will break compatibility? Will the
>> rendering changes break compatibility? Others changes. If this is the
>> only significant change to the mapfile that might break compatibility
>> then I might be more persuaded to to worry about backwards compatibility.
>>
>> I think one of the on going goals for mapserver is to simplify mapfiles
>> going forward. If I have to add a new keyword to activate every new
>> feature this is not going to meet that goal.
>>
>> While I am one that usually fights for backwards compatibility, I do not
>> think it is a simple decision on a major release like 6.0.
>>
>> -Steve W
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
> 


-- 
Daniel Morissette
http://www.mapgears.com/


More information about the mapserver-dev mailing list