Opened 19 years ago

Closed 19 years ago

Last modified 19 years ago

#1135 closed defect (fixed)

Labels not rotated with maps when maps rotated

Reported by: warmerdam Owned by: warmerdam
Priority: high Milestone:
Component: MapServer C Library Version: 4.4
Severity: normal Keywords:
Cc: jmckenna@…, flavio@…

Description

When a rotation ANGLE is providing in a MAP file for the map as a whole, 
the labels are not rotated along with the map, though they clearly should
be in at least some applications.  However, it is reasonable to assume that
in some situations you would *not* want the labels rotatated, so some sort
of configuration control will be required for this.

Change History (18)

comment:1 by dmorissette, 19 years ago

Cc: dmorissette@… added

comment:2 by fwarmerdam, 19 years ago

Status: newassigned
I have a preliminary patch working to resolve this problem but it involves
changing the msAddLabel() argument list.  I'm not sure that we will be able to
backport this into 4.4.1 from 4.5 due to the breadth of changes.  

I would add that similar issues may arise with symbol angles.   

Fow now no changes have been committed to CVS, but I plan to work on it further
over the weekend. 


comment:3 by fwarmerdam, 19 years ago

I have added a new ability to rotate labels with the map in msDrawShape(). 
Currently this is controlled by the LABELS_ROTATE_WITH_MAP processing option
which may be true or false (default is false).  

Currently this mode does *not* apply to msMapDrawPoint(), or anything else that
draws labels.   But it *should* apply to all msDrawShape() modes. 

This change required a substantial number of changes in the sensitive 
msDrawShape() function, as well as a small alteration in the msAddLabel() 
call to add a labelObj.   I am dubious whether this change ought to be
retrofit into 4.4.2 due to the number of changes, and the fact that this is
really a new feature, not just a bug fix.  So far I have only committed changes
in 4.5.



comment:4 by dmorissette, 19 years ago

Frank, in what kind of situation would you not want the labels rotated? 

I think the rotation should be on by default since in all cases that I can think
of, if a layer has TRANSFORM TRUE (i.e. if it's not just a copyright notice or
something like that) and has an ANGLE ITEM then it is likely that the angle
relates to the orientation of the geographic features and then you want the
labels to be rotated as well.

comment:5 by fwarmerdam, 19 years ago

Daniel, 

The map angle is added to the label angle even in cases where there is no 
angle item (in which case the starting angle is zero).  So for default
horizontal angles, it might not be desirable to rotate them with the map as 
they would be harder to read than if left horizontal.

However, it might make sense to rotate all labels that have an explicitly set
angle, or an angle item while leaving all labels without an angle setting 
unchanged.  One problem with doing this is I have no way of telling the 
difference between a feature with "ANGLE 0" and those with no ANGLE setting at 
all. 


comment:6 by dmorissette, 19 years ago

Could we base the decision to rotate or not on the presence or not of a explicit
LABELANGLEITEM or ANGLE value in the layer's style definition? Is that
information available to the code that handles label rotation? 

I assume that the mapfile parser returns ANGLE 0 by default if there is no
explicit ANGLE or LABELANGLEITEM set in the mapfile? Perhaps the rule could be
that ANGLE 0 is not rotated, but any ANGLE > 0 (including ANGLE 360) is rotated.
And also if a LABELANGLEITEM is explicitly set then rotation is on as well.

What I care the most about is that the default behavior should accomodate the
most common uses. But am I making this more complicated than it needs to be? I
think that at a minimum we should make sure that the requirement for this
PROCESSING directive is very well documented together with the other rotation
options.

comment:7 by flavio@…, 19 years ago

to me that is not logic to rotate only parts. if I rotate a map I want to 
rotate everything and not just parts. it should be default that anything is 
rotated in any case. exceptions for labels can be an option but not default. 
such as if somebody rotates a map he wants to rotate everything
(that's indeed what all our clients want, if it is a raster with
"embedded labels" this is the case anyway). so, again, rotate labels as well
should be the default setting. again, false is in this case clearly the 
exception!

comment:8 by fwarmerdam, 19 years ago

I am fine with changing either sticking to the current arrangement but
making the default "TRUE" or Daniel's idea about applying rotation
to features with ANGLEITEM set or ANGLE non-zero.

I do really think it would be common for folks to rotate maps, but
want labels to stay horizontal (the ANGLE 0 case).  But I kind of hate
the fact that we can't distinguish between ANGLE 0 and having no angle
set at all.

How about I change things so that LABELS_ROTATE_WITH_MAP can take 
3 values:
 o AUTO: the default, operates according to Daniel's rule.  
 o ON: All features are rotated, even if they have no angle set.  
 o OFF: No features are rotated with the map. 

I do agree with Flavio that if specific angles have been set it is likely
to get a particular orientation relative to features, and it only makes 
sense that we would want to default to keeping those labels oriented properly
as the map rotates. 

Alternatively, I could get rid of the preference entirely, and just
operate in "AUTO" mode.  If someone wants to have a feature that is
horizontal at map angle 0 but rotates with the map they would need to
assign a slightly non-zero angle (0.01 would be fine) to it.  I think
in Flavio's case he uses an ANGLEITEM so the features would always be
rotated. 

I like getting rid of the option all-together because it is expensive to
evaluate (though I only do this if the map angle is non-zero), and 
because it saves us having more cryptic mapfile options. 

OK, as I type this i have convinced myself that I would like to get rid of
the option, and follow the auto rules.  To re-iterate the auto rules are:
 o Add map angle if the ANGLE is non-zero. 
 o Otherwise the label is not rotated with the map (ANGLE 0 or no 
   ANGLE specified). 

(I'll email the above to Flavio since I see he isn't in the cc list). 

comment:9 by dmorissette, 19 years ago

Cc: flavio@… added
Your new plan sounds great to me. 

(I also took the liberty of adding Flavio to the CC of the bug.)

comment:10 by fwarmerdam, 19 years ago

OK, Flavio has also agreed, so I will proceed.  I should have the updates
in this afternoon.

comment:11 by fwarmerdam, 19 years ago

Resolution: fixed
Status: assignedclosed
Changes applied as discussed.  

 o PROCESSING option removed.
 o Apply map rotated to labels if the angle is non-zero or there is
   a labelangleitem.

Also added a labelrot.map test in msautotest/misc.  This does *not* 
test the labelangleitem aspect since I didn't know how to fake up 
attributes with inline features. 

Closing this bug now - please reopen if there are additional issues. 

comment:12 by dmorissette, 19 years ago

I think these label rotation rules needs to be documented somewhere.
Unfortunately the Wiki page at
http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?MapRotation cannot be updtaed
because the wiki has editing disabled. I also noticed that the "ANGLE" map-level
parameter isn't listed in the 4.4 mapfile-reference docs.

I have filed bug 1165 to make sure we don't forget docs.

comment:13 by sdlime, 19 years ago

We may have to come up with a way to distinguish between ANGLE 0 and no angle 
at all for other reasons. The pie chart support I've been screwing with being 
one of them. Could pick some obscure value and set as constant:

#define MS_ANGLE_NOT_SET -999999

and then use that in labels and styles.

I do think there are instances when you wouldn't want to rotate a label, a 
copyright statement or a map title. The the various processing states make 
sense.

I'm assuming that this ANGLE AUTO was taking care of this simply because the 
feature itself was rotated. What spots in the code does this touch?

Steve 

comment:14 by fwarmerdam, 19 years ago

Steve,

Yes, the ANGLE AUTO works because the feature itself is rotated.  So I just
take care to not apply the map rotation "again".  

If we are going to use a marker value, I would like it to be a multiple of 360
degrees so that if some code doesn't realize the distinction using it will still
equate to an angle of 0.  For instance, using 3600 as the special value would
work out well in this regard I believe.  

Alternatively we could add another flag like the autoangle flag indicating
if the angle has been explicitly set. 

As for places that the changes affect, they currently just affect 
msDrawShape().  The (many!) cases of placing labels now all need logic to 
see if the angle should be altered.  

I also had to add a labelObj argument to msAddLabel() so that I could provide
an altered angle without changing the original angle in the labelObj of the
style itself. 

comment:15 by jmckenna@…, 19 years ago

have just been doing some testing with this in order to document it, and have
found that if i specify an ANGLE for the map of 45, and then have a
LABELANGLEITEM of 45, the resulting label will NOT be rotated (because the label
is rotated counter-clockwise and the resulting map is rotated clockwise).  As a
user i would think that the labelangleitem would always override any map angle
setting.  but i guess i am wrong in thinking that? 

comment:16 by jmckenna@…, 19 years ago

Cc: jmckenna@… added

comment:17 by fwarmerdam, 19 years ago

Jeff,

I believe the LABELANGLEITEM is assumed to be relative to the map orientation,
not the user view. So, no, I don't believe that LABELANGLEITEM should override
the map rotation ... instead they need to be composed (added together). 

So I believe that things are working properly.  Your challenge is to explain
it carefully and clearly. :-)

comment:18 by jmckenna@…, 19 years ago

k thanks Frank, i'll do my best :)
Note: See TracTickets for help on using tickets.