#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 , 19 years ago
Cc: | added |
---|
comment:3 by , 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 , 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 , 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 , 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 , 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 , 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 , 19 years ago
Cc: | 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 , 19 years ago
OK, Flavio has also agreed, so I will proceed. I should have the updates in this afternoon.
comment:11 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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 , 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 , 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 , 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 , 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 , 19 years ago
Cc: | added |
---|
comment:17 by , 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. :-)
Note:
See TracTickets
for help on using tickets.