Talk:Tag:highway=traffic signals

From OpenStreetMap Wiki
Jump to navigation Jump to search


In most cities, every traffic light installation has a number as identifier. Normally, this number is visible for everyone. May be a number tag could be advantageous. Let's call it traffic_signal_id... --Gypakk 11:50, 12 June 2008 (UTC)

Numbers for traffic signals? Well, I know there is a number. But should we tag this?? This is like taging the number of power towers. Ups, I do this. We don't need a new tag. take ref=* instead. --Bahnpirat 12:13, 12 June 2008 (UTC)
Yes! The ref tag will do it. Thanks! --Gypakk 06:18, 23 June 2008 (UTC)

Suggested tag sound=yes/no

Lulu-Ann proposed this tag. I agree that this tag would be very helpful when generating maps for automatic navigation systems for handicapped people. But, should we use sound as a name for this tag? The word sound has several other meanings. In addition to this, several newer traffic lights have tactile signals instead of acoustic ones, i.e. there is no "sound". I'd name this tag visually_handicapped or blind, e.g. This tag could be used for highway as well if there are grooved ground plates built into the side walk. --Gypakk 06:18, 23 June 2008 (UTC)

As the people have different handicaps and not everybody can use every kind of helping signal, I think that it is important to state the kind of support. Maybe another value is "vibration". --Lulu-Ann 20:50, 29 June 2008 (UTC)

May be it's better, we use a generic term and additional values for sound and tactile devices? Often, you can find a combination of both: sound (tacker) which gives blind people a guess where they can find the tactile signal. And the tactile signal itself which vibrates as long as green light is shown.

Another question: how do we deal with the fact that not all pedestrian crossings of a single intersection are supplied with such signals? That's the normal case. :-( --Gypakk 22:34, 29 June 2008 (UTC)

Oops. I have not seen any crossing like that, but if such cases exist, we would need to identify single components of traffic signal sets... :-( I agree to handicapped=sound;vibration;grooved_ground;handrail;elevator;lowered_kerb;ramp;whatever makes sense. --Lulu-Ann 08:12, 30 June 2008 (UTC)

Are there places where traffic signals for cars (as opposed to pedestrian crossings with traffic signals, that is highway=crossing + crossing=traffic_signals) have sound/vibration signals? I think that's a case for a highway=crossing add-on tag instead. --Tordanik 21:59, 13 September 2009 (UTC)

These cases are now represented by traffic_signals:sound=* and similar. --Lulu-Ann 13:26, 18 November 2010 (UTC)

How do you tag a street crossing where there are sound signals for one pedestrian direction, but not for another? Creating separate traffic_signals nodes for each pedestrian way would be unpractical. I would suggest to put a traffic_signals:sound=partial tag on such street crossings. --Head 09:48, 30 June 2011 (BST)

Set of traffic signals

Set of traffic signals
(Click to magnify)

The problem: At highway intersections with more than one node you normally have to tag every node with highway=traffic_signals. The renderer does not know if these traffic signals belong to one intersection. Maybe it paints one traffic signal icon, maybe it paints two or some more - in dependence of the present scale. Furthermore, navigation systems cannot suggest "Please turn right at the second intersection with traffic lights!" because they cannot determine if the second traffic_signals tag represents a separate intersection in reality.

As a solution, I'd like to propose the usage of the area tag. As a result, the renderer knows that this is an intersection with a closed set of signals. Navigation systems can interpret this area as a homogeneous signal controlled intersection in correct manner as well because the area shares its nodes with every inbound highway.

--Gypakk 14:42, 24 June 2008 (UTC)

In a more elaborated form uploaded as Proposed features/Set of Traffic Signals. --Gypakk 14:02, 27 June 2008 (UTC)

Suggested tag: Part Time Signals

A number of traffic lights in England are only part time. Is it worth flagging these with maybe a new tag such as part_time=yes? --Pobice 23:00, 7 March 2009 (UTC)

or maybe night_off=yes? --Cbm 14:44, 9 March 2009 (UTC)
Most of the ones I've seen only operate at peak hours (ie off during the middle of the day as well). Could possibly use peak_time_only=yes --Pobice 17:00, 9 March 2009 (UTC)
Better use the opening_hours scheme. --Lulu-Ann 17:04, 10 March 2009 (UTC)
Best way maybe using "Access time restrictions"
<tag k="date_on" v="YYYY-MM-DD"/> Sets the start date for an access closure
<tag k="date_off" v="YYYY-MM-DD"/> Sets the end date for an access closure
<tag k="day_on" v="saturday"/> Closure each week starts at the beginning of this day
<tag k="day_off" v="sunday"/> Closure each week ends at the end of this day
<tag k="hour_on" v="HH:MM:SS"/> Closure starts at this time
<tag k="hour_off" v="HH:MM:SS"/> Closure ends at this time
Access time restrictions are limited, you cannot, for example, tag multiple intervals. So if the traffic lights are only active during morning and evening rush hours, access times restrictions won't work. --Tordanik 19:29, 10 March 2009 (UTC)
You're right. But that's in general a lack of the "access restiction" at the momentt and no specific problem for traffic_signals or other crossing-situations. --Cbm 19:57, 10 March 2009 (UTC)
Problem is I'm not sure where you could get said data from. Most are labeled simply as part time signals with no indication of when they will actually be in operation. --Pobice 20:17, 10 March 2009 (UTC)

Signal Time

Perhaps there should be a value for length of time for the light to switch? i noticed in indonesia some of the stoplight have a digital count down clock for the red / green signals. perhaps this could be useful for routing applications?--Jerjozwik 11:40, 1 June 2009 (UTC)

Here in India, we too have the countdown for most traffic signals in metro cities. The signal times in the map could also help the routing engine to plan better. thevikas 09:17, 3 December 2010 (UTC)
It would make sense to map the time that is needed for a full change of all lights until the same status is visible again. We also need an information if the lights are controlled dynamically. --Lulu-Ann 10:09, 6 December 2010 (UTC)
Would be nice to have. For the data to be best usable for routing I think we need to have an average waiting time.
If a signal has a fixed schedule of 60 seconds red (Tred) and 15 seconds green (Tgreen), that would be 26 seconds (Tavgwait); Tavgwait = Tred/2 * (1 + Tred) / (Tred + Tgreen)
Emvee (talk) 14:48, 9 November 2019 (UTC)

Induction / Weight sensors / On Demand

Some traffic lights are connected to weight sensors, what usually results to more flexible traffic flow. Sensors can also be found in pedestrian crossings. As a cyclist, you could just slow down a bit before a crossing and lights are turned to green automatically (no need to stop and reach for pedestrian signaling buttons). Perhaps even routing programs could take benefit of this information? How about simply tagging this like weight_sensor=yes/no? -- lazzko 14:37, 13 June 2009 (UTC)

Just sensor=yes/no might be best to cover the various different types. However from what I've seen just about all traffic lights around here have sensors these days. Also do they always turn green? I know pedestrian crossing round here can make you wait a while if you are unlucky enough to try and use them shortly after someone else. --Pobice 22:38, 12 September 2009 (UTC)
Induction circuits are not weight sensors ! Better use on_demand=yes/no or on_demand:induction=yes/no, on_demand:camera=yes/no, on_demand:button=yes/no etc. --Lulu-Ann 11:13, 13 September 2009 (UTC)
Agree that this could be a useful feature. Induction sensors are becoming more common where I do mapping. They often do not sense cycles/bicycles, while some do, especially if one aligns with the loop. The "On Demand" tag sounds logical, incorporating buttons as well. Having said that, "On Demand" sounds a bit too good to be true, though, especially in relation to the reality experienced by pedestrians and cyclists. But knowing the locations and numbers of those sensors is no less useful, in spite of the design shortcomings. Perhaps add on_demand:cyclefriendly=yes/no MortenLange (talk) 01:47, 21 July 2013 (UTC)
I'm ok with sensor=yes/no, I think it's more explicit than on_demand:induction=yes/no, that is currently used for transport "on demand". On the other hand "sensor=yes" indicates that the signal is connected to a sensor but doesn't indicate that it needs an event from the sensor to change its state.
I've used traffic_signals:sensor=remote_sensing/yes at the locations of the sensors, when visible. Sometimes that is somewhere before the signals, where the asphalt has been fixed when the induction sensor loops were installed, or sometimes (for "remote_sensing") it's at the actual location of the signals, where such detectors usually are. I've used remote_sensing, because I don't know for certain (or care) which technology they use here, or elsewhere, but the function is the same: detect the vehicles from some distance away (as opposed to induction sensors where you have to pass right above the sensor). If known, one could then add remote_sensing=infrared or remote_sensing=radar, or similar.) For what it's worth, the tag on_demand seems to have most uses (so far) on bus route relations, so out of the tags mentioned here, there does not yet seem to be a massive existing database/majority for any tag. Alv (talk) 08:24, 22 July 2013 (UTC)

Had a look on taginfo (2020-07-12) on which tags are used and currently see the use (in combination with highwat=traffic_signals) is pretty low:

Key Value(s) Count Count (combined with highway=traffic_signals
on_demand yes/no/only/commuter 2365 42
crossing:on_demand no/yes 1754 2
on_demand:induction yes 4 0
traffic:sensor loop 797 0

Almost all traffic signals in the Netherlands have induction loops to detect vehicles and bicycles so adding a tag to indicate this seems reasonably useless. Emvee (talk) 13:14, 12 July 2020 (UTC)

Same here in the US, at least in newly constructed areas on the left coast. I have never seen a weight sensor controlling a traffic signal. How would it work? Advance detector loops can be micromapped when you know where they are (you see the marks of their construction in person or from aerial imagery). -- T99 (talk) 08:25, 13 October 2020 (UTC)

More Hierarchical Solution

I would like to propose that when this draft gets rewritten as a relation, that it be combined with stops/yields, as a more general relation of "type=traffic_control" with "traffic_control=traffic_light" or "traffic_control=stop" or "traffic_control=yield" or even "traffic_control=no" if explicit designation of an uncontrolled intersection is desired. They all appear to me to have similar characteristics, both in function and in topology. I have placed a similar suggestion on the "stop" proposal page. This would of course require coordinating the whole node vs. way issue with another group of editors, but I think it would be worth it, and would probably make rendering/routing more efficient, since a search would only need to address a single tag value (i.e., if a traffic_control" relation doesn't appear, you don't have to search for the various categories. -- turbodog10:50, 3 October 2009 (UTC)


How do I tag a traffic signal which is only for one direction ? --User:Skyper 13:18, 5 November 2009 (UTC)

traffic_signals:direction=forward/backward/both ??--Sergionaranja 09:13, 20 October 2011 (BST)
won`t work for a node, but that is what we are talking about. --Skyper 17:08, 27 June 2013 (UTC)
it works for a node, see traffic_signals:direction=* -- Emvee (talk) 13:18, 5 January 2020 (UTC)

Emergency signal?

Ok, how do you tag a signal that's usually inactive (blinking yellow = "proceed with caution") but can be activated (red = "stop") to clear the intersection for emergency vehicles? See example.

I'll second this. I know of a few around here. Heck, this could also be used for Highway tunnels where there are traffic lights that stay always green unless the tunnel has to be closed encase of an emergency. On second thought, this sounds like a good idea for a new proposal. -- rickmastfan67 10:51, 12 January 2011 (UTC)
What do you need a new proposal for? Sounds like traffic_signals:emergency=yes to me. --Lulu-Ann 18:49, 16 January 2011 (UTC)

Traffic flow control signal

Yet another different kind of traffic signal: a signal to cap the volume of traffic entering a freeway from a ramp during rush hour; only one car per lane may proceed during each cycle of green light.

See traffic_signals=ramp_meter -- Emvee (talk) 16:57, 18 January 2020 (UTC)

Location of the signal node

Many simple intersections have the traffic_signals tag at the single node where the ways intersect. In very simple cases, this is probably adequate.

As soon as at least one of the ways is a divided highway, there is no longer any single node that could represent the entire intersection. I have seen traffic signal nodes added in the middle of interesections where they belong to only one or even none of the ways.

I have preferred a method of adding the traffic signal tag to all nodes where two or more of the ways intersect. I quickly realized that the tags were unnecessary in nodes where the traffic is only exiting the intersection, not entering it (such as the 4th node in a T-intersection of two divided highways).

After starting to add more detail, specifically the locations of pedestrian crossings, I realized the above method is still too simplistic. IMHO, the traffic signal nodes should be added to each way at the point where traffic actually must wait for the signal. This is when approaching the intersection but before entering the pedestrian crossing if present. The location is often (not always) marked by a solid white line (similar to that for a stop sign) across the lane. If you have high-resolution USGS Ortho (or even NAIP) imagery available, these lines can be seen clearly.

If there is a right-turn lane that bypasses the signal (being separated by an island), you can add a separate way for that. (Can we have highway=secondary_link and highway=tertiary_link added to the presets please?) There is often a ped xing across this lane, and if the turn lane doesn't lead onto a dedicated merge lane, it should have a yield sign. (Can we have highway=give_way added to the presets please?)

also, putting the traffic signal on one node in the middle of a junction might be ok for american roads, since often that is where they are actually positioned, but here in austria for example the traffic lights are places near the stop line for the cars. so basically every simple junction has already four nodes mapped with traffic_signals. this also leads to the problem that there is no information for which direction of the highway a traffic_signals node is intended. so there is also the need for a second tag: traffic_signals:direction=forward/backward/both . --Flaimo 01:18, 23 March 2011 (UTC)
IMHO, the traffic signal nodes should be added to each way at the point where traffic actually must wait for the signal. This is when approaching the intersection but before entering the pedestrian crossing if present. The location is often (not always) marked by a solid white line (similar to that for a stop sign) across the lane. I like this idea. --PJ Houser 02:12, 3 August 2011 (BST)
PJ Houser, while that would work perfectly for divided highways intersecting other divided highways, it wouldn't work for 2 lane road intersecting each other. For those types of roads, the traffic signal node should still be at the intersection itself, otherwise you'd have 4 separate nodes with it tagged at a simple intersection, kinda like what's happening in Austria like Flaimo mentioned above. -- rickmastfan67 10:57, 3 August 2011 (BST)
i 100% agree with Flaimo traffic_lights should be placed a the spot you whait for the signal to change. This way it makes sense tagging also if there is a crossing there or not. and as he says the only thing misssing is how to differentiate in two way lanes wich direction the traffic light is affecting (traffic_signals:direction=forward/backward/both). with this two changes almost any traffic lights crossing can be mapped more precisely. An intersection of 2 way ways will have 4 nodes with traffic lights.--Sergionaranja 10:24, 3 September 2011 (BST)
Xtrafficlights true.png Xtrafficlights true sat.png

Any thoughts on using Relation:system? --Panther37 17:12, 25 April 2012 (BST)

Camera Enforcement

See Enforcement for enforcement.

Basic question about traffic lights

Hi there! I'm pretty new, so please bare with me :)

If I understood well, a real-life single traffic light that regulates cars and pedestrians crossing has to be tagged as two different nodes on the highway? (One with highway=traffic signals and another one with highway=crossing + crossing=traffic signals)

Is that right? Seems crazy to me that one object has to be separated in two nodes. Chtfn (talk) 01:00, 21 June 2013 (UTC)

All you need is highway=traffic signals --Panther37 (talk) 05:41, 21 June 2013 (UTC)
That's not the whole truth. There simply is no established mapping for traffic lights "belonging together", so with some mapping techniques e.g. at a typical plus-shaped junction you will often have the highway=traffic signals at the central node and highway=crossing + crossing=traffic signals nodes at 1-4 ways connecting to it, depending on the real-world situation. Unfortunately, there's generally nothing linking these nodes together, so from a car's perspective it might seem as if it had to pass multiple traffic lights at that junction.
Chtfn, I'm not really sure whether you had a specific situation in mind? It may be that I'm imagining the on-the-ground situation incorrectly. --Tordanik 09:39, 21 June 2013 (UTC)


what about traffic signals for a bridge that raises for boats?

99.9% of the time they are green, but turn red when the bridge raises. I'm uncertain how to tag this.

I'll say; map what is there, that is map the traffic_signals. If you wan to, invent a new value for traffic_signals=*, maybe =boat_priority. If you are into more advanced stuff with relations , it could get interesting :-) /Johan Jönsson (talk) 11:10, 1 August 2014 (UTC)

Right turn on red?

In my locality, you are allowed by default to make a right turn on red signal after a full stop (you may also make a left turn between two one-way streets but you may not continue straight along the uninterrupted lane through a tee intersection). However, in some cases this is explicitly prohibited by a sign (usually, "no right turn on red"). How does one map this? One suggestion would be to add a right_turn_on_red=no tag to the applicable signal node. --T99 (talk) 17:22, 31 August 2014 (UTC)

In the Netherlands there a special signs for bicycles to allow to turn right on red:
Rechtsaf voor fietsers vrij

On what kind of tag to use, it would be good for routing software to understand this and thinking of that a relation might make sense just like a restriction.
For example: from for the way the traffic signal is part of, via for the traffic signal node itself and to for the way your are free to go to on red.
Emvee (talk) 20:00, 11 October 2019 (UTC)
Found that the German wiki indicates to use red_turn:right=*. Checking the usage I see it is currently 1300 times used, 1173 times in Dresden.
Emvee (talk) 15:04, 5 January 2020 (UTC)
Found that Proposed_features/turn_signals also has a proposal, see Right turn on red, it has also a proposal for cyclist that may turn right on red. Not that much used tough it seems, currently about 60 times. Emvee (talk) 23:31, 23 January 2020 (UTC)

How to add a floor light for pedestrians?

Recently settled in Rosario (Argentina) as well as other countries (the Netherlands, Germany, China, etc.), a floor light for pedestrians. Basically, the purpose of these traffic lights is to warn pedestrians to go looking down the mobile phone.

My question is, how do I tag these traffic lights? Following the scheme of traffic_signals:floor_vibration=*, I have decided to put it as traffic_signals:floor_light=*

I would like to know what you think about this.

Some news:

- Mweper (talk)

Signals with time counters

Some traffic lights display a countdown of the remaining time to wait or the time remaining where crossing can be started.

  • Shouldn't we have some traffic_signals:countdown=yes, with possibly some other value to indicate that the counters indicate the time to wait only, or to start passing, or both ?
  • I don't think we need to indicate the max time for each phase, it may be variable depending on hours.

Time counters is a great help for people with walking disabilities (these counters may also be voiced or could sound audible bips when reaching the last few seconds of countdown). They may reduce accidents caused when people ignore the classic signals and attempt to pass the crossing even if the trafic light is still "red/stop" and the wait time is long (more than about ~2 minutes, for example when there are more than 4 directions from which the competing vehicles may come to pass through the crossing each direction adds a minimum delay of ~30 seconds where they can pass, and those waiting to cross have difficulties to check all these at once to see if it's safe to cross). — Verdy_p (talk) 18:05, 10 January 2018 (UTC)

Sounds good. The countdowns also exist for vehicle traffic (to turn engine off) which display wait time. The distinction wait/crossing can be made by value. traffic_signals:countdown:vehicle/foot=yes/waiting/crossing/waiting_and_crossing --Jojo4u (talk) 15:28, 27 January 2018 (UTC)
Is the genitive necessary, can we shorten the values ? traffic_signals:countdown:vehicle/foot=yes/wait/pass/both
(The value "yes" may indicate one of the three other values it is generally "wait" in most cases), the value "no" may eventually be used in places where countdowns are common but not all trafic lights are equiped and we know there's no countdown, but the default in most places is usually "no", we could say that the absence of this tag means we don't know if there are countdowns)
A small clock icon is easy to design to decorate the trafic light icon: it would be a single black clock for "yes", a red clock for "wait" (possibly drawn where there's a red disc on the traffic light icon), a green clock icon for "pass" (possibly drawn where there's a green disc on the traffic light icon), two (red and green) clock icons placed for "both". This is just a suggestion, the rendering would depend on how we currently represent the traffic lights (ignoring countdowns).
Verdy_p (talk) 21:04, 28 January 2018 (UTC)

Pedestrian crossing without intersection

Why should highway=traffic_signals + crossing=traffic_signals contain less information than highway=crossing + crossing=traffic_signals? Shouldn't it be the other way round? --SelfishSeahorse (talk) 20:10, 27 March 2018 (UTC)

I don't know why this text was added, and I don't think any of these "contains more information" than the other. The reason to use highway=crossing for pedestrian crossings without intersections is simply that it's the tag designed for that purpose, imo. --Tordanik 14:48, 3 April 2018 (UTC)

I've noticed that the first version makes it show up on the map, while the second one makes it show up with a different icon in OsmAnd (a red-green traffic signal). The first version makes it show up with the usual red-yellow-green icon.

It seems that the app recognizes the second version semantically (and probably takes into account a shorter stop when routing), but annoying the first version simply doesn't show up on This makes a less than useful aid in charting traffic lights in a city... Rostaman (talk) 03:40, 5 January 2020 (UTC)

The current text for "Traffic signals for pedestrians" is confusing and I think misguiding people.
For detailed mapping, "Tag all incoming ways" the normal scheme should be followed, that is the place of the traffic signal/where one has to stop should be mapped with highway=traffic_signals and the crossing(s) with highway=crossing + crossing=traffic_signals. Tags like button_operated should be placed on the node with highway=traffic_signals.
For pedestrian crossings without intersection, it does not make sense to add tags like button_operated or traffic_singals:* because that node is mapped not on the footway but on the road and these tags do not apply for cars.
Emvee (talk) 09:30, 5 January 2020 (UTC)
Emvee, would you do all incoming ways here for example? It's a single roadway with traffic in both directions and a push-button operated crossing. I'd have to mark two signals for cars and one for pedestrians within 5 meters. Yet because I don't, I don't get an icon on, etc. Before I installed OsmAnd which shows these signals, I logged more than a few times into to add a missing traffic signal only to find out it's already there but invisible! Rostaman (talk) 20:31, 5 January 2020 (UTC)
I would map footways the same as cycleways, that is with explicit/separate highway=traffic_signals, see
On the OSM map only highway=traffic_signals is visible which does make sense to me, highway=crossing + crossing=traffic_signals only indicates to me that crossing is protected using traffic signals but the location where to stop is mapped using highway=traffic_signal and that is what is of interest.
Screenshot 20200105 224808.png
The situation you point out is strange in a sense that the sidewalk left of the road (the side of the park) is mapped as separate footway but the sideway right of the road (on the side of the houses) is not mapped. If both would be mapped I would add four times highway=traffic_signals on the places pedestrians and cars have to stop. If no sideway at all would be mapped I would use only highway=crossing + crossing=traffic_signals as it is right now.
Emvee (talk) 21:51, 5 January 2020 (UTC)
Thanks for the help. I'm not sure if there's a point to marking that sidewalk, it's simply much wider than the one on the other side of the street and the street has unusually high curbs. I guess there's nothing to do then but get used to having the icon missing on Rostaman (talk) 01:46, 7 January 2020 (UTC)

Bicycle early release

A number of new traffic lights within the city I live now have an additional light specifically for cyclists which turns green ahead of the other standard lights for all traffic. There was already a tag used once traffic_signals:bicycle_early_release which I've created a page for. I hope that is ok and I wasn't sure if this should be added to the main traffic signals page?

Hi I added on Talk:Key:traffic_signals:bicycle_early_release. Yes. Also, add a highway=traffic_signals on the highway=cycleway (Tag:highway=traffic_signals#Tagging_also_cycleway_traffic_signals)? You may also want to look into crossing:*=*. ---- Kovposch (talk) 11:55, 23 December 2020 (UTC)