Take Traffic Calming Road Furniture Into Account

[daniel-j-h]

I was asked today why we don't support road bumps / humps for deriving maxspeeds.

• http://wiki.openstreetmap.org/wiki/Key:traffic_calming
• http://taginfo.openstreetmap.org/keys/traffic_calming#values
• http://wiki.openstreetmap.org/wiki/Tag:highway%3Dspeed_camera

Update: related tags:

• http://wiki.openstreetmap.org/wiki/Key:crossing
• http://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
• http://wiki.openstreetmap.org/wiki/Key:barrier (lift_gate etc.)

Architectural question here: this is one of many scenarios where a node influences a the property for the way(s) it's in. We can't handle this in profiles at the moment, nodes and ways don't know about each other. I don't think it's easy to change that, though, with how we parse OSM objects at the moment.

[MoKob]

With the current approach, we need to add each traffic_calming feature into a structure similar to the traffic-signals. The graph compressor cannot compress these. After we can add the penalty for the traffic-calming into a specific turn-penalty for continuing along the way.

In my personal opinion, this level of detail is not necessary, though. I personally feel we should just be adding such penalties to a general penalty travelling along the way. After all, the only error we get is that we don't pass every traffic light, unless we traverse the full way. So a road that is not traversed in full could add an additional penalty (e.g. currently 2 seconds) to the ETA which we don't actually need (scaled by the length of the way).

We introduce a lot of additional complexity due to the intermediate intersections that we only have for traffic lights, I would hate to add such an item in for traffic calming as well.

[TheMarex]

On an implementation side this might go well with #1490.

@MoKob can you give more context on why do you think this increases the complexity w.r.t intermediate intersections? From my understanding this would increase the number of intermediate intersections, but when done in a general manner does not need special handling.

[MoKob]

On every traffic light/calming feature, we introduce an artificial intersection.

So instead of a single sharp turn, we now have two less sharp turns, modifying the turn penalty. Also, if we want to announce the turn, we now rely on collapsing (which will make post-processing more complicated) since we have a suppressed slight left, turn left instead of a single turn left.

If there are traffic lights as well, we end up with three turns, given that they are not at the same node.

All detections for forms of intersections simply get far more complicated by making every intersection consist of very short connected roads. This influences turn penalties, instruction in pre- and post-processing, intersection arrays in the output (which we could potentially call a bug).

[MoKob]

To give a bit more context: I know that it works right now with traffic lights. But it's kind of brittle as it is and makes handling items more complicated. It can actually reduce the amount of turn-lanes we can handle/turn angle quality.

If we make this a general thing, we need to seriously invest time to make the code handle skipping over these situations, suppressing turn penalties and extracting full paths through the graph instead of a single edge.

[TheMarex]

@daniel-j-h and I came up with a possible solution here that would require us to load node penalties to the server, but would address @MoKob's concerns:

1. Compress all degree 2 nodes away, penalty or not
2. When calculating the weight of the edge-based-edge walk over all nodes of the geometrie and sum up all the penalties
3. When calculating the offset for the PhantomNode on the server side, do the same
4. When updating speeds reset node penalties if the adjacent segments where updated with real speed data

Since node penalties are very sparse, we are confident that we could pull this off without significant changes in memory consumption.

[daniel-j-h]

Linking related tickets:

• Stop Signs for Profiles #2652
• Allow penalties for arbitrary nodes #1490

[daniel-j-h]

Relevant talk thread https://lists.openstreetmap.org/pipermail/talk/2017-May/077982.html

[chaupow]

Another context discussed in #4775 (comment) are e.g. wheelchair routing that would like to exclude roads with traffic_calming:bumps
When osrm is able to regard and identify traffic_calmings, it would be nice to find a way to expose it to the lua profiles too.