Talk:Proposed features/Traffic Signal Timings
Verifiability and complexity
I have strong doubts regarding the verifiability and observability of these properties. There was a discussion recently about tagging the length of light phases, which had the same issues.
The problem is that in larger cities, the interaction of traffic lights is much more complex than having a night and a day mode.
To give an example, in Berlin each junction can work autonomously if the communication to other junctions fails. Already in this mode, there are several programmes for different times of the day (rush hour inbound, day time, rush hour outbound, night, sunday/holiday, etc). With communication established, these programmes are synchronised in clusters, which might help to create a green wave, and these clusters are controlled from the traffic monitoring centre that sits in the former airport Tempelhof buildings, which can change/override anything, e.g. to switch a green corridor for a state visit.
In consequence, whatever behaviour of the traffic light a mapper observes at any given time, she cannot know in which of the programmes and in which of state of connectivity the system is currently in. --Polarbear w (talk) 10:54, 11 November 2017 (UTC)
- I second Polarbear comment. This is barely verifiable and is more relevant to operating information than physical descriptive data we aim to gather in OSM.
- Anyway, the concern this proposal is pointing out is real and traffic lights operating information should be publicly available. Then we'll need a strong model to use them, nevertheless out of OSM Fanfouer (talk) 14:20, 11 November 2017 (UTC)
- I grant that many systems are more complex than this proposal can model, and that on them it would be difficult to verify the most granular forms. However even on those systems I feel like a simplified modelling would be useful.
- If I use an example from Folsom California, about a third of the intersections there are on a much shorter cycle than the rest. All of them have traffic sensors and the like, but about one third have a cycle where left hand
- turns are included with forward motion, and the rest have it as a separate phase. In that case, you would merely need to say strict=no, and you have a useful heuristic for navigation apps to use. This does not work
- for some Dutch models which have since been pointed out to me, where every part of the intersection is activated on an as-needed basis.
- Nonetheless, I feel like a model for the simpler intersections, as are in my town and many others, is fairly useful. And I feel like in using this model we'll be able to find its shortcomings and extend it to work on more
- complicated intersections.
- For those more complicated ones, I fear that you may end up having to rely on city imports. However, I'm not sure that it detracts from the rest of the proposal, given that I'm explicitly not trying to cover those cases,
- and said so at the top of the proposal. I would be very interested if you could tell me why you disagree. Gappleto97 (talk) 17:17, 11 November 2017 (UTC)
I have previously proposed something similar. Proposed_features/Traffic light red green cases by junction. Erkin Alp Güney (talk) 16:36, 11 November 2017 (UTC)
- The timing can be verifiable now in some places, such as in parts in Asia (such as Thailand, Philippines, Indonesia, China), where traffic light timing is shown on timers placed beside the lights (see images below), yet, it will be barely verifiable in other places. This proposal can be useful to map traffic light timings by directions in many traffic lights in Philippines, which now include timers that show the time per signal phase. I still understand that signal phase timings can be difficult to verify, unless it is indicated, such as on the timers in the images I given below for evidence. And the page clearly says that the proposal will not apply on those with timings affected by emergency vehicles and time of day (such as longer phase times in one or two directions during rush hours or daytime hours), that we cannot use that relation type on all cases.