traffic_signals:direction for traffic signal penalties

[kaligrafy]

Would it be possible to use traffic_signals:direction informations when possible to avoid double count of traffic signals for complex intersections? see http://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Complex_intersections

[emiltin]

see also #31 and #1250. using relations for grouping singals is another possible way to handle it.

[DennisOSRM]

adding a :direction has certain issues as a node does not have a direction. It's unclear what should happen if two (or more) roads connect at a node. We will revisit this once relations parsing is stable.

[kaligrafy]

In fact, if two roads connect at a node with a traffic signal with direction forward or backward, it should be ignored since the tag would be considered unprecised or invalid.
A traffic signal with direction should only appear on a single way (or maybe at a pedestrian crossing, in which case the penalty would be always applied to pedestrians but cars would be penalized only on one direction)

Also, it would be great if the turn function in lua would include way before, way via and way after in the function, so we can use more pecise information like the number of turning lanes and prioritized traffic signals for left/right turns to reduce/increase turn penalty.

With more open data coming from cities, we may eventually be able to have an approximate of the traffic signal phasing (like green/red time for all directions), but that is not a priority right now for sure!

On Dec 22, 2014, at 4:02 AM, Dennis Luxen notifications@github.com wrote:

adding a :direction has certain issues as a node does not have a direction. It's unclear what should happen if two (or more) roads connect at a node. We will revisit this once relations parsing is stable.

—
Reply to this email directly or view it on GitHub #1317 (comment).

[DennisOSRM]

In fact, if two roads connect at a node with a traffic signal with direction forward or backward, it should be ignored since the tag would be considered unprecised or invalid.
A traffic signal with direction should only appear on a single way (or maybe at a pedestrian crossing, in which case the penalty would be always applied to pedestrians but cars would be penalized only on one direction)

Not convinced that this is reasonable.

[kaligrafy]

That's how they are mapped on the wiki: http://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Complex_intersections under "Tag all incoming ways"
In the Montreal area, I am following this guide anyway. Hard work, but we need this for correct bus routing.
Until we have traffic signal sets, I think we should follow the existing wikis.

[emiltin]

there's a issue for the idea of using way types in the lua turn function at #592

[kaligrafy]

Maybe implement a turn_function_with_ways and by default ignore it when parsing for better performance. If the function is created in the lua file, then performance will decrease, but at least, it is available.

[DennisOSRM]

Performance is not a concern, but the modeling is rather unsound.

[1ec5]

Per #2652 (comment), there’s a similar phenomenon for stop sign tagging.

[kaligrafy]

Any news on this? I see more and more osm intersections with the forward/backward tags (same for stop signs) and I think it is the more complete and precise way to tag intersections nowadays.

[flohoff]

I was just looking into this as this is getting more important as more people pumping up the detail of the map. We need a generic method of knowing the direction of the way in relation to the node beeing processed.

Not only do we have different penaltys for traffic_signal but also for stop. People around here have started tagging railway lights as seperate traffic_signals with tram_priority which imho is a little bit too much but for ignoring, or handling them correctly one would need to process the direction of the traffic_lights.

From not knowing much about the inners of OSRM i guess in case of directional tags on the node we most likely need to extend the graph with more vertexes beeing oneway.

Flo

[mjjbell]

OSRM represents a traffic signal as a turn penalty between the directed edges connected by the signal node.

OSM
a<--->b(signal)<--->c

OSRM
a--(turn+signal_penalty)-->b--(turn)-->c
a<--(turn)--b<--(turn+signal_penalty)--c

Directional traffic signals fit into this nicely - just apply the penalty to the relevant turns only.

osrm-backend/src/extractor/edge_based_graph_factory.cpp

Lines 572 to 581 in f7478ba

	const auto is_traffic_light = m_traffic_lights.count(intersection_node);
	const auto is_uturn =
	guidance::getTurnDirection(turn_angle) == guidance::DirectionModifier::UTurn;
	ExtractionTurn extracted_turn(
	// general info
	turn_angle,
	road_legs_on_the_right.size() + road_legs_on_the_left.size() + 2 - is_uturn,
	is_uturn,
	is_traffic_light,

Implementing this will require knowledge of the way in which a traffic signal is contained to correctly orient the traffic_signals:direction value, from which the adjacent nodes can be found to generate the from-via-to turns the signal applies to.

In some respects, a directional traffic signal could be viewed as a special type of via-node restriction, so it might be worth evaluating if TurnRestrictions can be extended to support it.

OSM nodes are processed independently and without any way context. Changes would be required in the extraction phase to construct the signal turns. There is already a mapping from way -> [ordered nodes] that could be useful.

osrm-backend/include/extractor/extraction_containers.hpp

Lines 63 to 64 in f7478ba

	// Offsets into used nodes for each way_list entry
	WayNodeIDOffsets way_node_id_offsets;

[mjjbell]

I have a working implementation of this based upon the above idea. It changes the representation of traffic signals to include direction (bidirectional, forward, backward), and exposes this to the lua scripts.

It's unclear to me what to do when the signal direction is ambiguous (e.g. when tagged on a junction node). The options are:

1. Treat the signal as bidirectional (the current behaviour due to lack of direction support)
2. Include the signal for all intersecting ways in the specified direction
3. Limit signal to one direction on one way
4. Ignore the signal

I'm leaning towards 2. as it's probably the easiest to implement, but I'm interested to hear if anyone has other preferences for their use-cases.