Traffic Signal Penalty based on a Way's Direction

[daniel-j-h]

Opening a ticket to clarify how we currently handle traffic signal penalties. The following questions came up during looking into how we could implement Stop Signs in #2652.

My understanding so far:

• In the profile we mark ExtractionNodes as traffic light
• In the EBGF we penalize all turns over a traffic light node

From what I can tell, this does not take into account the direction the traffic light applies to.

Imagine a scenario where a single traffic signal (x) only applies to the way coming from the left:

      |
----x   -----
      |

At the moment we still penalize turns from the top, right and bottom into the left way.

---

Now here is the same situation for stop signs:

• https://www.openstreetmap.org/node/3880659211
• https://www.mapillary.com/app/?lat=52.50494326588188&lng=13.422097224584917&z=17&focus=photo&pKey=upgECljcFxrpxkzOVhCKUA

This stop sign only applies to the forward direction of Adalbertstr coming from the south at that intersection. If we implement stop signs similarly to traffic lights, we're facing the same issue that we would penalize all turns at that intersection.

References:

• http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals
• http://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction

[MoKob]

Do you have an example in the data where a traffic light in one direction is not accompanied by a traffic light in the other direction as well?

Might be naive, but I'd expect a traffic light showing green to imply a traffic light showing red for crossing traffic. In stop-signs you would have the right of way sign at the other road, so we don't want to penalise that. But can traffic lights actually be without other lights?

[emiltin]

Often it's not at all clear that you have two opposing directions. Consider for example bikes and busses in these intersections:

http://www.openstreetmap.org/#map=19/55.68196/12.55779
http://www.openstreetmap.org/#map=19/55.69097/12.57129

Not all traffics lights have been added to OSM for these intersections. But in the second example, you have a traffic light on Fredens Bro going northwest just before the merge. This is not the case in the other direction.

[MoKob]

@emiltin if you say not all have been added, this would inherently describe a mapping problem in my view. So the use of traffic signals should not try to fix mapping errors in our profiles.

In your second example, I can see traffic lights on all incoming ways. I'd say that we look at one of two possibilities, without inspecting the intersection further:

• this complex is probably a full intersection working together? So the merge will only be allowed by the traffic light if through traffic is not allowed.
• or, the second possibility, it is a pure crossing for pedestrians. So in this case, pedestrian vs car still follows the applies to both directions paradigm.

In any of both cases, applying a penalty would be reasonable.
The case @daniel-j-h is describing would be a case where a traffic light blocks of traffic under certain conditions.
The only situation I know that would come close is traffic signals limiting merges onto a highway. But even they can be treated just the same as traffic lights for pedestrian crossings.
I know of not a single traffic light that behaves just the same as a stop / right of way combination.

[MoKob]

One thing that might be considered is road-priority on traffic lights. So pedestrians are most likely to experience longer waiting periods than cars (on average) if we consider a major road.
Minor roads (due to buttons activating the light for pedestrians) could shift the delay slightly in favour of pedestrians.

The same can be said for major over minor roads. If you consider a primary vs residential crossing, the expected wait period for the primary road should be much less than the one for the residential road.

[emiltin]

I agree that we should not try to guess missing traffic lights. I was just noting that these example intersection might miss traffic lights.

This traffic light http://www.openstreetmap.org/node/1415460620#map=19/55.69110/12.57131 is not due to a pedestrian crossing, but rather due to two roads merging. It's a bit similar to a dosing signals on ramps into highways. There is no directly corresponding signal in the other direction as can be seen here:
https://www.google.dk/maps/@55.6911731,12.5711044,3a,75y,243.94h,69.41t/data=!3m6!1e1!3m4!1s8EtOoeyO3ut5dKf3Gmkz6A!2e0!7i13312!8i6656

But it's probably coordinated with the traffic lights in the main intersection.

[MoKob]

Well. Even if it weren't, the case @daniel-j-h described would require an actual road at the traffic light that is not affected by it.

I would believe the text-based example in #2758 (comment) to be non-existent for traffic lights or a potential modelling issue, since the traffic light should then be given only in relation to the way it applies to.
So in the form a -- TS -- b with TS noting the location of the traffic light.

[MoKob]

Related: http://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Complex_intersections

#1317

[MoKob]

From voice discussion. This issue is more a stop sign issue than a traffic sign issue. Closing here in favour of #2652. The general problem description here simply says that stop-signs cannot be modelled the same as traffic signals.

[sudhabhise]

UK Power Networks and Traffic Group tests smart traffic lights in Kent
https://technoidhub.com/technology/uk-power-networks-and-traffic-group-tests-smart-traffic-lights/15369/