[mapserver-dev] Label Angle Auto Issue (Trac #1688)

[Chris Hodgson]

Hi Devs,

The issue is Trac #1688 [1] - it's kinda long, so in summary: we want a 
way to be able to force labels to be drawn upside down, based on the 
angle of the line. The existing "ANGLE AUTO" function is "smart" and 
always tries to render them right-side up, but in our client's case the 
line segments have been specifically made to define the location of 
individual characters for labeling actual map features, and if the 
segment goes from right-to-left it intends for the character to be 
rendered upside down (manually defining the placement of characters for 
a result that looks something like "ANGLE FOLLOW").

I believe this issue has been hanging around (for 4 years) because 
no-one has tried hard enough force a consensus on how to implement the 
configuration of this feature - that's why I'm bringing it out of Trac 
and onto the dev list, my apologies if this is not appropriate.

Dan suggested the following a couple years back:

Here is an idea: instead of adding a new autoanglealgorithm member in 
the labelObj as was proposed in the auto2.tar.gz patch, we could get rid 
of autoangle and autofollow and combine all of them into a single 
label->anglemode member with the following possible values:

- 0, the default means that the angle value is either static or bound to 
an attribute
- MS_AUTO
- MS_AUTO2 (the new algorithm)
- MS_FOLLOW

Steve, do you expect any problem with that approach? I can take this 
ticket if you want, just reassign to me.

Steve replied with:

Dan, I think that would work. MapScript would be simplified 
($label->anglemode = ...) and I assume we'd keep the mapfile syntax the 
same (e.g. ANGLE AUTO2). We could allow explictly setting the anglemode 
in the mapfile as well with the idea of depricating ANGLE AUTO sometime 
in the distant future if necessary.

But no-one ever got around to implementing this. More recently Alan 
picked up it for a look, but it doesn't look like he's taken it anywhere 
yet. Our client, GeoBC, would really like to see this get into the next 
release, seems like we should be able to slide it into the 6.0 schedule? 
So I'd like to confirm that Dan's earlier proposed method is still an 
acceptable solution, and then go ahead and implement it and submit a 
patch. I'd also appreciate any guidance or warnings about gotchas that I 
might encounter with this approach.

Thanks,
Chris

[1] http://trac.osgeo.org/mapserver/ticket/1688