Rotating icon with MapCSS

[Aun Johnsen <lists@…>]

On some instances it would be desirable if an icon could be rotated. Either by the direction of the road (i.e. a pedestrian crossing) or completely independent

node[highway=crossing]:connected {
    icon-image:    "presets/pedestrian_crossing.png";
    icon-rotation: way;
}

this turns the icon to follow the direction of the way

node[mykey=value] {
    icon-image:   "arrow-symbol.png";
    icon-rotation: 60;
}

this rotates the icon 60 degrees clockwise.

If the syntax doesn't quite fit, feel free to improve

[Don-vip]

Simon, it's ok to apply the patch if it works :)

[bastiK]

For pedestrian crossing: There is often a highway=residential and a highway=footway crossing at 90 degrees angle. You probably want to have the icon oriented in one specific direction. This could be achieved with an eval expression as we have the selected parent object in the environment:

way[highway=residential] > node[highway=crossing]:connection {
    icon-image:    "presets/pedestrian_crossing.png";
    icon-rotation: parent_way_angle();
}

[Don-vip]

move tickets to next milestone

[plepe]

I'm thinking ... All the trigonometric functions in JOSM returns angles in radians. If parent_way_angle() really returns the angle in degrees, this could raise consistency problems. Maybe it should be used here too?

On the other hand, degrees are much more human readable.

In pgmapcss I added an option to choose between degrees and radians globally, all functions will adhere to this setting.

[Aun Johnsen <lists@…>]

If the angle need to be in radians, maybe functions like degree_to_radian() should be implemented also, if an object is mapped with an angle, it is likely to be tagged in degrees. Very few people are able to relate to angles in radians just by observations, most people would need a tool to convert it to something more familiar.

Maybe also worth having a cardinal_to_radian() function as well, though I cannot think of any use cases where the creator of the stylesheet can't convert cardinals to degrees himself (north = 0, north east = 45, etc.)

[plepe]

Absolutely. Usually I think those functions are called *_radians() not *_radian().

It would also be interesting to specify the unit, so that JOSM can convert it to the correct angular system, e.g. "45°" or "3.14156rad", similar to MapCSS 'metric' function, which converts a length value to pixels (e.g. "30m", "5km", "3in"). (This function is currently not supported by JOSM).

I think, a cardinal_to_radians() function is very useful, because people would need to re-implement it over and over.

[Klumbumbus]

New different crossing icons in #10831 waiting for rotation :)

[simon04]

In 8199/josm:

see #10217 - Enable rotating icons with MapCSS

The corresponding key is icon-rotation and takes angles in the following forms:
[rad], [rad]rad, [deg]°, [deg]deg, or a cardinal direction
(e.g., northeast, sw).

In addition, the following MapCSS functions are provided:
degree_to_radians, cardinal_to_radians

[simon04]

Rotating icons should be possible now; further extensions like parent_way_angle() would be best discussed in separate tickets?

[plepe]

Cool :-) Hope to implement compatibility in pgmapcss soon!

[Klumbumbus]

The rotation resets as soon as you hover an object or click in the mapview.

edit: ... if icon-rotation is in another mapcssfile than the icon path of the node.

Revision: 8199
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: simon04
Last Changed Date: 2015-04-15 23:51:33 +0200 (Wed, 15 Apr 2015)
Build-Date: 2015-04-16 01:31:12
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8199

Identification: JOSM/1.5 (8199 en) Windows 7 32-Bit
Memory Usage: 742 MB / 742 MB (252 MB allocated, but free)
Java version: 1.8.0_31, Oracle Corporation, Java HotSpot(TM) Client VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:C:\Program Files\Java\jre1.8.0_31\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,768m, -Djnlpx.splashport=61388, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found

[simon04]

To me it seems like a caching issue, i.e. commenting out the following code circumvents the problem:

src/org/openstreetmap/josm/gui/mappaint/ElemStyles.java

@@ -127 +127 @@
         }
         StyleCache style = osm.mappaintStyle != null ? osm.mappaintStyle : StyleCache.EMPTY_STYLECACHE;
         try {
-            osm.mappaintStyle = style.put(p.a, p.b);
+            //osm.mappaintStyle = style.put(p.a, p.b);
         } catch (StyleCache.RangeViolatedError e) {
             throw new AssertionError("Range violated. object: " + osm.getPrimitiveId() + ", current style: "+osm.mappaintStyle
                     + ", scale: " + scale + ", new stylelist: " + p.a + ", new range: " + p.b, e);

[simon04]

Concerning radians vs. degree: The most frequently used numeric values for the key direction are in degrees: ​https://taginfo.openstreetmap.org/keys/direction#values …

[simon04]

In 8238/josm:

see #10217 - Fix reset/flickering/cache issue wrt rotated MapCSS icons

[simon04]

After this bug hopefully being fixed, the remaining question is whether to stick with radians as default unit (see my comment:22)?

[plepe]

Concerning units: As I wrote before, I see a problem if different trigonometric functions use different angular systems. I think this can only lead to inconsistencies and confusion.

In pgmapcss I added an option to change the global angular system for the current stylesheet. Maybe this would be an option (but, for sure, this would be a bigger change): ​https://github.com/plepe/pgmapcss/blob/master/doc/config_options.md (Option "angular_system").

I think, if you can write "icon-rotation: 90°;" or "icon-rotation: 90deg;" this manageable, don't you think?

Btw, maybe it would be interesting to also add "gon" resp. "grad"? This seems to be quite common with land surveyors. It's similar to deg, but 100grad = 90°. See: ​http://en.wikipedia.org/wiki/Gradian . Most calculators also know these three angular systems: deg, rad, grad.

[bastiK]

I like the use of units, this is very CSS-like. In principle, the MapCSS parser could recognize numbers with units on a syntactical level (better performance at runtime). It would be nice to allow negative numbers and maybe add the grad and turn unit (see ​https://developer.mozilla.org/en/docs/Web/CSS/angle).

[plepe]

Interesting. I always like the idea of keeping to standards. So the solution would be, to not have a default unit.

Then trigonometric functions, e.g. parent_way_angle() should return a value with a unit, e.g. "0.1234rad".

[bastiK]

I think it is common convention that numbers without explicit unit are interpreted as rad. This would be a backward compatible extension to the standard and would simplify the use of eval expressions and arithmetic in our case.

[simon04]

In 8251/josm:

see #10217 - MapCSS rotation: add grad and turn units

[Klumbumbus]

Icon-rotation would be really usefull, if dependent on way direction.(crossing icons, highway=passing_place,...). However this is maybe not trivial for nodes belonging to multiple ways.

[plepe]

@Klumbumbus: See the example above:

way[highway=residential] > node[highway=crossing]:connection {

icon-image: "presets/pedestrian_crossing.png";
icon-rotation: parent_way_angle();

}

With this you define to which way the icon should be rotated. Sure, the node could still be connected to several highway=residential roads. In that case, the "first" way (which is found) will be used.

Btw: is ":connection" really necessary? Because due to the "way > node" relation, the node has to be member of a way anyway?

[Klumbumbus]

don't confuse :connection with !:unconnected ​http://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation#PseudoClasses

[bastiK]

In 8260/josm:

see #10217 - move unit handling to parser
adds support for negative angles
new: length units px,cm,mm,in,q,pc,pt as in CSS (immediately converted to px)

[bastiK]

In 8262/josm:

see #10217 - "fix" test