-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Comments
adding a |
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. 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!
|
Not convinced that this is reasonable. |
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" |
there's a issue for the idea of using way types in the lua turn function at #592 |
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. |
Performance is not a concern, but the modeling is rather unsound. |
Per #2652 (comment), there’s a similar phenomenon for stop sign tagging. |
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. |
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 |
OSRM represents a traffic signal as a turn penalty between the directed edges connected by the signal node.
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
Implementing this will require knowledge of the 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 osrm-backend/include/extractor/extraction_containers.hpp Lines 63 to 64 in f7478ba
|
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:
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. |
Yes, I'm for 2 too :-) |
Huge thank you for this!!! |
I read the previous discussion.
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? How should I express this to be better supported by Support OSM traffic signal directions ? Looking forward to your answer. |
@mjjbell |
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).
|
Thanks, i see. |
How many traffic_signal nodes should I use in this example? Because the traffic_signal node and the intersection node overlap. |
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, I don't know if I'm making myself clear. |
I know that you already support OSM traffic signal directions, how should I express |
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! Same example as above: As mentioned in the wiki |
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
The text was updated successfully, but these errors were encountered: