rework oneway arrows

[nebulon42]

This PR moves rendering of oneway arrows from a dasharray representation towards a SVG marker symbolizer. This has the disadvantage of losing the ability to have bent arrows but results in a clearer representation, improves arrow positioning and avoids overlap with road labels. Additionally, rendering arrows for construction roads are dropped and arrows are coloured corresponding to either the casing colour or the fill colour of the road type they are rendered on, which leads to more visual consistency.

Fixes #606 by using SVG markers.
Fixes #681 as using markers prevents collision with labels.
Fixes #597 by dropping arrows for highway=construction.

Might fix #595 and #284, but I cannot definitely confirm, testing is welcome.

I think there is no change for #706.

Possible problems: roundabouts?

Previews (all examples within Vienna, Austria or close by)

motorway

trunk

primary

secondary

tertiary/residential/unclassified/road/living_street/pedestrian

service/raceway

track

footway/path

cycleway

steps

------- outdated, only for reference --------

Minor tweak to the new road style that was discussed e.g. in #1736 (comment).

Instead of using the same colour for all road types chroma and hue for the arrows are taken from the casing colour of the respective road type, residential/tertiary is kept unchanged. This leads to minor differences in colour, but increases visual consistency.

Previews:
motorway
https://cloud.githubusercontent.com/assets/3531092/9944605/b48a5364-5d88-11e5-83f9-83fd25588277.png

trunk
https://cloud.githubusercontent.com/assets/3531092/9944607/b74515f8-5d88-11e5-8ca6-17ce30431f0a.png

primary
https://cloud.githubusercontent.com/assets/3531092/9944608/b976ddde-5d88-11e5-81ff-be0ef0a0e0d9.png

secondary
https://cloud.githubusercontent.com/assets/3531092/9944612/bdba7f0e-5d88-11e5-9e50-625d1a32b400.png

residential/tertiary
https://cloud.githubusercontent.com/assets/3531092/9944616/c2ffca28-5d88-11e5-8100-776bab241ec6.png

[matkoniecz]

What about highway=cycleway/track/footway/living_street/pedestrian ?

[matkoniecz]

Overall this change is OK for me, though motorway arrows seem less noticeable (on the other hand oneway arrows on motorways are not so important).

[gravitystorm]

I like the concept of tying the colours together. My feeling is that the arrows are too dark, perhaps an L closer to the casing would work better?

It has also reminded me how terribly hard-to-read the arrowheads are!

[nebulon42]

Maybe using a SVG marker would help? (no colour change yet)

Will look into other road types as well. I have picked the same L as the previous colour had, but changing it might be worthwhile, I will experiment some more.

[HolgerJeromin]

the svg markers are nice. What is the minimal supported version of mapnik for them?

[matkoniecz]

Personally I would prefer darker arrows than presented here rather than lighter (though note, I did no testing).

Also, generating oneway colours in https://github.com/gravitystorm/openstreetmap-carto/blob/master/scripts/generate_road_colours.py may be desirable (easier tweaking/changing road colors).

[matkoniecz]

Svg marker for oneway arrows would solve #606

[matthijsmelissen]

Related: #595 #284 #681 #597 #706.

[nebulon42]

@HolgerJeromin I do not see compatibility issues as it's a marker symbolizer (just like POIs) with marker-placement: line.

I think I will go down that road because the marker symbolizer approach seems to solve #284 and #681, although I'm not sure if it might be a Mapnik 3 positioning thing in my setup.

[pnorman]

Maybe using a SVG marker would help? (no colour change yet)

Is the change in visibility the SVG marker, or because you made part narrower?

With dasharrays for arrows we get arrows that are curved on curves, which we won't get with SVGs

[nebulon42]

Is the change in visibility the SVG marker, or because you made part narrower?

The preview depicts the marker. I tried tweaking the dash-array arrows, but it's a bit complicated. I don't know why they are appearing so thick as the base line width is only 1. With this approach we also will always have a jagged arrow head.

With dasharrays for arrows we get arrows that are curved on curves, which we won't get with SVGs

Yes, that is something that we would lose. But currently I see far better positioning with symbolizers. I have updated the branch with the SVG markers for reference. The pull request is not finished yet.

[nebulon42]

Implementation is complete, please test and give your feedback. Thanks.

[pnorman]

I tried tweaking the dash-array arrows, but it's a bit complicated. I don't know why they are appearing so thick as the base line width is only 1. With this approach we also will always have a jagged arrow head.

Did you try reducing the width?

[nebulon42]

It would be possible to improve the arrow also by tweaking the dasharray as you can see below:

I'm not sure if we could get rid of the jagged head by moving from bevel to miter joins. (correcting myself, that's not the way how joins work) I have currently no set-up to do a SVG export and see how it looks. #284 could be solved by adjusting the start gap of the arrow (currently 12) to a much higher value, let's say half the space before and half the space after. But I think with this approach there is no easy way to solve #681.

Roundabouts do not necessarily look better with the dasharray approach.
dasharray

SVG

(Something is wrong with my dasharray implementation as arrows point in the opposite direction, but you get the idea.)

[matthijsmelissen]

See also this comment by @gravitystorm: #606 (comment)

Personally I'd prefer to move to svg arrows.

[matkoniecz]

After initial review of how new style works - colour change is not particularly noticeable. New shape is way more readable. Loss of curving of arrow seems to not have a significant effect.

I noticed that positioning of arrows is significantly changed - I still have to check how new positioning works but it seems smarter. Oneway arrows are now rarer, overall without reducing information In some case ways properly showed before as oneway are no longer marked but also some ways previously not marked as oneway are now with arrows. Arrows disappeared from really short ways solving #284.

Overall it is an improvement though I would prefer to test further and check whatever it is possible to tweak how positioning works - is it possible to increase how many oneway arrows are displayed?

[nebulon42]

is it possible to increase how many oneway arrows are displayed?

The spacing is controlled by marker-spacing, I have set it to 180 which is a bit higher than the ~150 used by the dasharray approach. Additionally, there is marker-max-error, which controls the flexibility of the renderer in handling collisions or how strictly marker-spacing is interpreted. I oriented myself a bit on how OSM Bright handles this.

[kocio-pl]

After initial review of how new style works - colour change is not particularly noticeable. New shape is way more readable. Loss of curving of arrow seems to not have a significant effect.

👍

I would like to have at least 2 arrows on the opposite sides of roundabouts (more important) and more visible arrows on tracks (less important), but in general I am pleased with the result.

[matthijsmelissen]

Thanks! As always, further tweaks are welcome, but I think the general idea is good enough to merge.

I like the crispness of the new arrows.

I also see the problem with arrows on roundabouts. Google seems to solve this in part by making the 'line' part of the arrow very short - maybe we also can reduce this? We could also decide to drop arrows on roundabouts.

[gravitystorm]

We could also decide to drop arrows on roundabouts.

Arrows on roundabouts are good mapper feedback. When mapdust was a thing I found 10 bugs all on one roundabout with no explanation, and it took a while to figure out it was the wrong way around.