Talk:Tag:highway=traffic signals

From OpenStreetMap Wiki
Jump to: navigation, 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)

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)

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)

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.

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)