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 https://github.com/Project-OSRM/osrm-backend/issues/1317#issuecomment-67815207.

[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 https://github.com/Project-OSRM/osrm-backend/issues/2652#issuecomment-360636395, 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.

https://github.com/Project-OSRM/osrm-backend/blob/f7478ba80f04ee6777556661f93edff5bef85c90/src/extractor/edge_based_graph_factory.cpp#L572-L581

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. https://github.com/Project-OSRM/osrm-backend/blob/f7478ba80f04ee6777556661f93edff5bef85c90/include/extractor/extraction_containers.hpp#L63-L64

[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.

[kaligrafy]

Yes, I'm for 2 too :-)

[kaligrafy]

Huge thank you for this!!!

[GitBenjamin]

I read the previous discussion. The earliest proposal:

1. add traffic_signals: direction on node‘s info.
2. add the relation:between traffic_signals_node and the affected road.

Why did you finally choose Plan one? Isn't that going to cause the problem of ambiguous signal direction?traffic_signals:direction#Tagging

If we use Plan one, how should we compile OSM data to avoid ambiguity? Is that the way to go?

For example:

How should I express this to be better supported by Support OSM traffic signal directions ?

Looking forward to your answer.

[GitBenjamin]

@mjjbell i try to express the example OSM data, the file: example.xml

[mjjbell]

Why did you finally choose Plan one? Isn't that going to cause the problem of ambiguous signal direction?traffic_signals:direction#Tagging

The solution to ambiguous traffic signals is to not tag ambiguously 🙂

Following the suggestion in the page you referenced and the guide to tagging traffic signals at complex intersections will achieve that.

As mentioned above, #6153 makes an opinionated choice about what to do if OSRM sees an ambiguous tag (which it inevitably will).

2. Include the signal for all intersecting ways in the specified direction

[GitBenjamin]

Why did you finally choose Plan one? Isn't that going to cause the problem of ambiguous signal direction?traffic_signals:direction#Tagging

The solution to ambiguous traffic signals is to not tag ambiguously 🙂

Following the suggestion in the page you referenced and the guide to tagging traffic signals at complex intersections will achieve that.

As mentioned above, #6153 makes an opinionated choice about what to do if OSRM sees an ambiguous tag (which it inevitably will).

2. Include the signal for all intersecting ways in the specified direction

Thanks, i see. I have read the guide, but I still don't understand it. If possible, could you please provide the OSM file about nodes and ways in the direction of traffic_signals?

[GitBenjamin]

I read the previous discussion. The earliest proposal:

1. add traffic_signals: direction on node‘s info.
2. add the relation:between traffic_signals_node and the affected road.

Why did you finally choose Plan one? Isn't that going to cause the problem of ambiguous signal direction?traffic_signals:direction#Tagging

If we use Plan one, how should we compile OSM data to avoid ambiguity? Is that the way to go?

For example:

How should I express this to be better supported by Support OSM traffic signal directions ?

Looking forward to your answer.

How many traffic_signal nodes should I use in this example? Because the traffic_signal node and the intersection node overlap.

[mjjbell]

You need to explain what behaviour you wish to achieve before we can help you.

For which directions/turns should the traffic signals apply?

[GitBenjamin]

You need to explain what behaviour you wish to achieve before we can help you.

For which directions/turns should the traffic signals apply?

For example, Node B, C, F, G are junction nodes and also the traffic signal nodes. But, each node influences a particular way and direction. Now, I want to know how to express node G and node C in OSM, and how to express way LG, way GC, way CJ and way DC. At the same time, the traffic signal node can be associated with the corresponding way. And I want to make sure that when I go from node L to node J, I don't count traffic light penalty twice.

I don't know if I'm making myself clear.

[GitBenjamin]

You need to explain what behaviour you wish to achieve before we can help you. For which directions/turns should the traffic signals apply?

For example, Node B, C, F, G are junction nodes and also the traffic signal nodes. But, each node influences a particular way and direction. Now, I want to know how to express node G and node C in OSM, and how to express way LG, way GC, way CJ and way DC. At the same time, the traffic signal node can be associated with the corresponding way. And I want to make sure that when I go from node L to node J, I don't count traffic light penalty twice.

I know that you already support OSM traffic signal directions, how should I express OSM to be compatible with this functionality. 🙂

[kaligrafy]

In this case, the traffic signal nodes must be on the stopping lane, before the intersection nodes:

Like this example: https://projets.chaire.transition.city/id/#disable_features=address_interpolations,barriers,boundaries,buildings,landuse,trees&map=20.28/45.55844/-73.74543

This way, there is never double counting of traffic lights and it even helps autonomous vehicles to estimate the stopping line location when there are fading lines or snow covering the asphalt.

I understand that most intersections are not mapped correctly like this, but I think OSRM should encourage correct mapping instead of ambiguous one.

Pierre-Leo Bourbonnais, Eng. Ph.D. Research Associate and Lecturer Polytechnique Montreal | Civil Engineering Mobility Chair

On Sep 27, 2022, at 11:01 AM, Monday @.***> wrote:

You need to explain what behaviour you wish to achieve before we can help you. For which directions/turns should the traffic signals apply?

https://user-images.githubusercontent.com/51102038/192558463-a051fb20-4d79-479e-bc34-87e65a36b3cf.jpg For example, Node B, C, F, G are junction nodes and also the traffic signal nodes. But, each node influences a particular way and direction. Now, I want to know how to express node G and node C in OSM, and how to express way LG, way GC, way CJ and way DC. At the same time, the traffic signal node can be associated with the corresponding way. And I want to make sure that when I go from node L to node J, I don't count traffic light penalty twice.

I know that you already support OSM traffic signal directions, how should I express OSM to be compatible with this functionality. 🙂

— Reply to this email directly, view it on GitHub https://github.com/Project-OSRM/osrm-backend/issues/1317#issuecomment-1259637749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGWX6BAFO2NSBIAUWWYTNDWAMD3LANCNFSM4AZLSSMQ. You are receiving this because you authored the thread.

[GitBenjamin]

In this case, the traffic signal nodes must be on the stopping lane, before the intersection nodes: Like this example: https://projets.chaire.transition.city/id/#disable_features=address_interpolations,barriers,boundaries,buildings,landuse,trees&map=20.28/45.55844/-73.74543 This way, there is never double counting of traffic lights and it even helps autonomous vehicles to estimate the stopping line location when there are fading lines or snow covering the asphalt. I understand that most intersections are not mapped correctly like this, but I think OSRM should encourage correct mapping instead of ambiguous one. Pierre-Leo Bourbonnais, Eng. Ph.D. Research Associate and Lecturer Polytechnique Montreal | Civil Engineering Mobility Chair … On Sep 27, 2022, at 11:01 AM, Monday @.***> wrote: You need to explain what behaviour you wish to achieve before we can help you. For which directions/turns should the traffic signals apply? https://user-images.githubusercontent.com/51102038/192558463-a051fb20-4d79-479e-bc34-87e65a36b3cf.jpg For example, Node B, C, F, G are junction nodes and also the traffic signal nodes. But, each node influences a particular way and direction. Now, I want to know how to express node G and node C in OSM, and how to express way LG, way GC, way CJ and way DC. At the same time, the traffic signal node can be associated with the corresponding way. And I want to make sure that when I go from node L to node J, I don't count traffic light penalty twice. I know that you already support OSM traffic signal directions, how should I express OSM to be compatible with this functionality. 🙂 — Reply to this email directly, view it on GitHub <#1317 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGWX6BAFO2NSBIAUWWYTNDWAMD3LANCNFSM4AZLSSMQ. You are receiving this because you authored the thread.

Yes, you got it. Thank you for your answer！ And the most intersections are not mapped correctly like you said. So, I have new question about it.

Same example as above: Can I insert a new node G' and node C' in OSM, whose coordinates are the same as node G and node C. But their node_id is unique. And, the way_LG was made of node L and node G. Now, the way_LG is made of node L, node G' and node G.

It looks like this:

As mentioned in the wiki