Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

traffic_signals:direction for traffic signal penalties #1317

Closed
kaligrafy opened this issue Dec 20, 2014 · 25 comments · Fixed by #6153
Closed

traffic_signals:direction for traffic signal penalties #1317

kaligrafy opened this issue Dec 20, 2014 · 25 comments · Fixed by #6153

Comments

@kaligrafy
Copy link

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
Copy link
Contributor

emiltin commented Dec 20, 2014

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

@DennisOSRM
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Contributor

emiltin commented Dec 22, 2014

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

@kaligrafy
Copy link
Author

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
Copy link
Collaborator

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

@1ec5
Copy link
Member

1ec5 commented Jan 26, 2018

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

@kaligrafy
Copy link
Author

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
Copy link

flohoff commented Jun 5, 2021

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
Copy link
Member

mjjbell commented Jun 5, 2021

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.

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.

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

@mjjbell
Copy link
Member

mjjbell commented Oct 22, 2021

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
Copy link
Author

Yes, I'm for 2 too :-)

@kaligrafy
Copy link
Author

Huge thank you for this!!!

@GitBenjamin
Copy link
Contributor

GitBenjamin commented Sep 27, 2022

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?

image

For example:
image

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

Looking forward to your answer.

@GitBenjamin
Copy link
Contributor

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

@mjjbell
Copy link
Member

mjjbell commented Sep 27, 2022

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

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

@GitBenjamin
Copy link
Contributor

GitBenjamin commented Sep 27, 2022

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

  1. 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
Copy link
Contributor

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?

image

For example: image

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
Copy link
Member

mjjbell commented Sep 27, 2022

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
Copy link
Contributor

GitBenjamin commented Sep 27, 2022

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

For which directions/turns should the traffic signals apply?

example

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
Copy link
Contributor

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

example

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
Copy link
Author

kaligrafy commented Sep 27, 2022 via email

@GitBenjamin
Copy link
Contributor

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:
image

As mentioned in the wiki

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants