How to tag traffic signals timings?

Help and support
, ,
1

Hi. I couldn’t find a way to tag traffic signals timing.
I have seen some traffic signals with long timing for red light, so maybe start tagging them, so they could be useful for routing engines to avoid them.

Another related case is some other traffic signals which are near but synchronized in a way that you always get a red light in one or both of them.
Again, routing engines could use it to avoid them or improve the estimated time.

There exists a tagging scheme or proposal for this kind of data?

2 Likes
2

I encountered a case like this last year in the New Orleans area. I estimated that I sat behind that light for about 5 minutes and tagged it interval=00:05. This should be straightforward for a routing profile to incorporate into driving time estimates. OSRM already interprets duration=* on any element as a delay, so maybe interval=* could work similarly. This is the only highway=traffic_signals node in the whole world with an interval=* tag, so maybe others have gone with a different approach.

An example of this is a queue-cutter signal that prevents traffic from backing up onto a railroad crossing:

A relation would be a good way to model synchronized traffic signals. There are hundreds of traffic_signals_set relations, but I think those are mainly about helping renderers cluster synchronized signals at the same intersection, not larger synchronization systems. Maybe there should be a distinct traffic_signal_coordination relation type.

Similarly, there’s a perennial question about how to map a green wave, especially when signposted:

Here’s an idea for tagging the target speed on the roadway, not yet in use:

  1. Tag the roadway with maxspeed:advisory=25 mph maxspeed:advisory:reason=green_wave
  2. Create an enforcement relation with enforcement=maxspeed:advisory (a little oxymoronic, but it’s a form of practical regulation rather than legal regulation) and add each traffic signal to it as with the role device
3

interval= is ambiguous whether it’s the cycle length, or that =traffic_signals light’s green time (then you have to think about traffic_signals:turn= , with its own problems). Proper terms are better used to avoid these confusion.

1 Like
4

There have been a few attempts, though none got anywhere. Afaict, there are two main problems with tagging these timings:

Measuring them in the first place

Some traffic lights are adaptive, so don’t have any kind of fixed timings. Others vary their timings over the course of a day - think rush hour, off-peak, night time. Measuring any individual timing at some point in time might not be accurate at other times, since signal timings are usually determined on a case-by-case basis.

Verifying them

Let’s say you did all that work, carefully measured all timings, entered them, etc. How does someone else verify that it’s actually correct (and not out of date, which can also quickly happen with timings)?
Basically, they have to do all of that themselves too. I don’t think that any city anywhere publishes those timings, so survey it is. Thus, nobody wants to maintain it.

Apart from that is the issue that traffic lights themselves don’t have a tagging scheme detailed enough to even ascribe attributes to each of them. That would need to happen first before timings can be added.

This only makes sense in comparison to the green duration. If the traffic light is 10s red and 10s green, that’s basically the same as 5m red and 5m green. A router doesn’t know signal timing, so both cases have a 50% chance of red and green when you arrive (not considering the yellow time to simplify).

This is basically the conditional probability version of the other case (If I got green at this traffic light, what is the probability that the other one is red or green?). This is a bit simpler because it doesn’t require absolute information.

Some further thoughts

The usefulness for routers is somewhat limited by the fact that they can’t predict the future. Most of the time, they aren’t that wrong because the problem space is pretty much continuous (start 1 minute later => reach the end 1 minute later). Traffic lights are discontinuities - start 1 minute later, reach the end ??? minutes later.
This is incidentally also true for public transport stops (start 1 minute later => potentially miss your bus/train/flight). We can still work with it, because every single “signal timing” (stop duration) is written down on the time table. Traffic signal timings are basically time tables. With every single traffic light being a stop.

5

Any suggestions? This light I mapped spends upwards of 5 minutes in the red phase for every 5 seconds or so in the green phase – an extremely narrow window in my experience. On nearby lights that a router could easily suggest instead, the green-to-red ratio is nearly the inverse.

Admittedly, I was mainly thinking about this light as opposed to how it would fit into a broader mapping campaign. I reached for a generic term rather than something specific to signal timing, to avoid getting bogged down in a discussion overthinking how to map signal timing comprehensively. I could’ve tagged a note=* instead, but the note would’ve languished in obscurity, a bit of a waste if you ask me.

From a theoretical standpoint, most routers are fundamentally unreliable anyways because they don’t do continuous optimization, but tell that to the people who rely on routers in their travels. Most routers already apply a penalty to highway=traffic_signals based on an assumed average waiting time. In each case, the developers pulled this delay out of thin air, because no one has mapped enough signal timings to be able to make an empirical generalization. Yet even this guesstimated penalty makes a big difference in the usability of certain kinds of routes. Delivery drivers tend to have short routes in urban areas. They have a low tolerance for error in travel time estimates, to the point that stop signs become relevant, let alone traffic lights.

We already have several established tags for traffic lights that take relatively little time or go red relatively infrequently: continuous_green, blink_mode, emergency, ramp_meter, and more. There’s an outstanding request for OSRM to decrease the penalty for these tags. But we don’t have any tag for the opposite case in which a light takes a relatively long time or goes green relatively infrequently, since this is usually for one-off reasons. While a general tagging scheme for measured wait times would be better than a subjective traffic_signals=long_red, I don’t think it necessarily means we have to come up with the perfect methodology for recording every traffic light out there. That’s just scope creep.

6

With statistics and averages, one can get quite close to a good estimate. The point was that routers can’t make use of too much detail without major changes. Though that’s besides the request of OP, I admit that.

I feel like this is going to lead to value clashes at some point. Unless we want to allow something like traffic_signals=continuous_green;long_red which seems paradoxical. But in the meantime, it’s probably fine.

Perhaps the title would benefit from a corresponding scope reduction.

OT

Is that why they ignore signs and traffic lights? Because routers ignore them too and they don’t keep to their estimated travel time otherwise? :wink:

7

The initial post was because I knew a couple of traffic signals whose timings are very different compared with all others around them, and is better to avoid them most of the time, so solution to these cases could be based on “long_red” as you point out. In this scenario only a few traffic signals would be tagged as such. That could be easy for the mapper and useful for data consumers.

@Jofban the problem in these cases is that probability is not 50-50, with these long reds the chance of stopping in a red light its much bigger.

8

I’d suggest adding dedicated keys, e.g. traffic_signals:red_time=*, traffic_signals:green_time=*, traffic_signals:cycle_time=*… Here you could enter either a qualitative value like short, long, or a specific time value with unit like 30 seconds (in case of a fixed-time controller; for a vehicle-actuated controller perhaps the minimum and maximum values could be entered as a range).

Edit: If you want to avoid subjective values like long and short, but also don’t want to measure everything with a stopwatch, I’d recommend to tag the number of phases of the signal controller. This is a objective, qualitative number that allows for a decent estimate of how long you’d have to wait, while it is also easy to measure and verify. To calculate it, you only need basic knowledge of the intersection layout and which directions can/cannot have simultaneous green.

3 Likes
9

Oh, you immediately hit on a common terminology problem. Is it a “phase”, or stage? Then there’s “phase group” and “signal group”. US and UK looks at them differently with a ring-and-barrier diagram, or a sequential staging diagram. A US “phase” is a group of non-conflicting movements, so that there are 8 “phases” when you may expect it to be 4 with protected left turns on both roads. Furthermore, there are skipped phases, or re-serviced phases, so even that can be difficult to define.
Anyway. let’s at least not use =short and =long , which are subjective without a reference. Preferably with a cycle length, the green split could be qualified with OSM terms =main , =partial , =limited as majority or minority.
For a strict format, they might be separated. There’s actually maxspeed:variable:max= and maxspeed:variable:min= being used for the highest and lowest possible speed at a VSL.
For the topic here, I’m not sure what situation =long_red refers to exactly. Is it long cycle length, semi-actuated where the minor road only gets served with a long gap after the demand appears, or some intersections held at all-red by default. If it’s semi-actuated, the =long_red subjectivity doesn’t have to be used.
Overall, the first difficulty, before the exact timing, is actually to to find out whether it’s fixed-time / pre-timed (with time-of-day plans), semi-actuated, fully-actuated, traffic-responsive (selects and vary a pre-timed plan based on traffic), or adaptive; and at what time periods. Can’t even know at what times you must measure together!

1 Like
10

You joke, but when I was on a team starting to build navigation software several years ago, we were indeed concerned that overly optimistic arrival time estimates would incentivize reckless driving and potentially expose our customers to liability. For example, even when our telemetry data demonstrated that the historical free-flow speed along a given highway was well above the speed limit, we would assume the speed limit in our arrival time estimates.

To be clear, I wasn’t actually suggesting traffic_signals=long_red. I just wanted to highlight the fact that we can easily communicate “short reds” to the router but not the opposite. My preference is for a quantitative value, even if estimated.

This is an elegant idea. It would enable routers and traffic simulators to rank traffic signals against each other. Unfortunately, I suspect it would be less than straightforward to implement in a routing profile, since the profile usually evaluates a given edge without context about nearby edges. So the profile would resort to multiplying the cycle count by whatever it assumes for a standard light.

In the case I described near New Orleans, three approaches converged on the intersection. The intersection layout ensured that I couldn’t see the other two signals, which alternated several times between them while I was stuck behind an unchanging red. As Murphy’s law would have it, there was little traffic coming from the other approaches, but a cop was waiting in a nearby parking lot, in a good position to spot anyone violating the posted No Turn On Red restriction. So I couldn’t actually tell exactly how many cycles it went through before I got a green light.

The next morning, I spotted someone gingerly reversing out of that slip lane in order to wait at a different stoplight.

I’ve seen those signal diagrams but don’t know the first thing about them. If we take a scientific approach to signal timing, I think we’re going to need some very careful step-by-step documentation to avoid confusion.