Talk:Tag:highway=traffic signals

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)

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)

I documented the in use tag traffic_signals:operating_times=* for such cases. Nielkrokodil (talk) 11:56, 26 October 2024 (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)

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)

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)

drawbridge

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:

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)

There are multiple comments at Talk:Red turn#Use Relation:restriction instead suggesting that the tagging schemes suggested by DE:Tag:highway=traffic_signals, Red turn, and Proposed features/turn_signals#Right turn on red are all problematic. – Minh Nguyễn ^💬 01:43, 8 July 2021 (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:

• http://rosarionoticias.gob.ar/page/noticias/id/77308/title/Se-puso-en-funcionamiento-el-primer-sem%C3%A1foro-peatonal-de-piso-del-pa%C3%ADs
• https://www.thelocal.de/20160422/german-city-creates-floor-traffic-lights-for-smartphone-addicts
• http://www.dutchnews.nl/news/archives/2017/02/dutch-town-launches-traffic-light-for-zombie-smartphone-users/
• http://rimias.com/2016/09/09/pavement-traffic-lights-perfect-for-the-smartphone-era/

- 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 OSM.org 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 OSM.org. This makes OSM.org 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 OSM.org, OSM.de etc. Before I installed OsmAnd which shows these signals, I logged more than a few times into OSM.org 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 https://www.openstreetmap.org/node/5343665410

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.

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 OSM.org. Rostaman (talk) 01:46, 7 January 2020 (UTC)

Wrong icon in screenshot?

Apart from the discussion above: IMO the two screenshots in this example are very strange or even logically wrong:

According to the text of the example, the node in the middle has (in both cases) the tags highway=crossing + crossing=traffic_signals, but the icon in the 2 screenshots is different! The first variant should also show the small traffic signals icon (with red and green) of the second variant, or am I missing something? These seem to be screenshots from JOSM with the style "JOSM Standard (MapCSS)" (by the way: this could also be mentioned somewhere ... or any other source, if it's not from JOSM). And in JOSM, the icon in the screenshot of the first variant is only shown with highway=traffic_signals + crossing=traffic_signals – this is the "some mappers use...“ code variant mentioned in parentheses. Shouldn't this be corrected? (It is very confusing and misleading.) The screenshot could be changed or there could be 2 screenshots in the first variant (one for highway=crossing + crossing=traffic_signals and one for the "some mappers use...“ variant highway=traffic_signals + crossing=traffic_signals)? And perhaps also remove this confusing text "which contains less information" (without any explanation)? --Goodidea (talk) 19:37, 20 September 2021 (UTC)

My eye did never fall on that text for highway=traffic_signals + crossing=traffic_signals, but agreed, it is confusing and misleading, just make the choice either highway=traffic_signals OR crossing=traffic_signals but not both. Unfortunately it is used quite a lot, but I would agree changing the text. -- Emvee (talk) 21:19, 20 September 2021 (UTC)

I did spot the same just yesterday, the JOSM icon in the image is that of "double" traffic lights, the one that in the text is in parentheses. --Hungerburg (talk) 09:24, 24 September 2021 (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)

Bus, Fire and Railroad Premption

I am looking for a method of mapping MDOT SHA signals in OSM. In addition to types you'd expect to find in the traffic_signals=*, we maintain data on signals that can be changed by special vehicles, e.g. fire engines, public transit buses, and railroad locomotives (where a railway=level_crossing shares an intersection with automotive traffix). This is called Traffic Signal Preemption and Wikipedia has a nice article about it.

There does not appear to be a good tag for this sort of thing, so I'm thinking something like premption=psv,emergency,railway,etc.. How would you, the community, add this sort of thing? --ElliottPlack (talk) 22:35, 14 September 2021 (UTC)

Buses usually receive higher/medium priority only, not always an absolute highest order using hurry call. ---- Kovposch (talk) 05:10, 15 September 2021 (UTC)

psv=* includes taxis and others, but bus=* probably also includes other buses not actuated/detected for priority by the signal controller. ---- Kovposch (talk) 05:12, 15 September 2021 (UTC)

Pedestrian crossings "not" separately mapped ?

This is quite misleading - The mappings introduced under this do not map any pedestrian crossings at all, not just "not separately". In order to map a pedestrian crossing, highway=crossing must not be omitted, otherwise, its just traffic lights with no way to tell, apart from guessing, that these protect a pedestrian crossing. --Hungerburg (talk) 09:24, 24 September 2021 (UTC)

I don't understand clearly what you mean ... Could you be more precise? Are you talking about the examples under "How to map" which have the text ”Pedestrian crossings separately mapped" in the headline? Because in these examples, all the pedestrian crossings (= small traffic signals icons) seem to be separately mapped as highway=crossing + crossing=traffic_signals (separate from nodes with highway=traffic_signals + crossing=traffic_signals). Or did I miss something? --Goodidea (talk) 21:13, 9 November 2021 (UTC)

I'm talking about the "Pedestrian crossings not separately mapped": There only the kind of crossing is specified, but the fact of the node representing a highway=crossing is not given. One might consider this a shortcut, because, after all, why would anybody give the type of crossing, if there was no crossing? Still, I consider this bad practice, because the matter of fact is now only available to those, that follow some logic, that is nowhere specified, that's why I wrote "do not map any crossings at all"; the examples where it says "not separately mapped", that is. --Hungerburg (talk) 22:49, 9 November 2021 (UTC)

Finally, I got it, the heading is in error, updated. Thank You @goodidea. --Hungerburg (talk) 22:58, 9 November 2021 (UTC)

Traffic signals that apply to trams, trolleybuses and buses only

What tags can be used for traffic signals that apply to only to trams, trolleybuses and buses? They can vary from country to country. In some countries they consist of four white/yellow lights (https://commons.wikimedia.org/wiki/File:%C4%8Co%C4%8Dky_tram_rovn%C4%9B_a_vlevo.jpg). In other countries they are a variation of the standard traffic signal (https://pxhere.com/en/photo/1132353). There may be more variations for which I'm not aware. Dimitar155 (talk) 11:57, 5 November 2021 (UTC)

Proposed_features/turn_signals#Traffic_signal_only_applies_to_a_specific_transportation_mode would make them as traffic_signals:turn:tram=left|through and traffic_signals:turn:bus=all (if I understand the meaning correctly).

Could add traffic_signals:tram=* (223 instances) and traffic_signals:bus=* (23 instances).

traffic_signals:tram=*

More details at taginfo

More details at taginfo

traffic_signals:bus=*

More details at taginfo

More details at taginfo

---- Kovposch (talk) 12:43, 5 November 2021 (UTC)

The first photo resembles only one of their possible signals. This photo (https://slideplayer.bg/slide/17536455/103/images/67/5.+Светофар+за+трамваи.+(Светофар+за+регулиране+на+движението+на+ППС+за+обществен+превоз+на+пътници).jpg) shows all possible variants. I'm not sure if the current tagging schema can support such thing. These signals looks exactly the same and apply only to public transit, so adding traffic_signals:tram=*, traffic_signals:trolleybus=* and traffic_signals:bus=* to each one of them seems a bit too much (in my opinion). Maybe traffic_signals:psv=* could do the job? Dimitar155 (talk) 13:08, 5 November 2021 (UTC)

For trams it would make sense to follow what is done for trains I think, see railway=signal -- Emvee (talk) 15:25, 5 November 2021 (UTC)

The problem is that it's one kind of traffic light and I would like to use the same tags for all of it's instances. Dimitar155 (talk) 12:13, 6 November 2021 (UTC)

That may not be possible. railway=signal will include other lights not at an intersection, such as a switch position indicator. In some countries, they look different.

Conceptually they are connected on a highway=traffic_signals, and timed by the same man_made=street_cabinet + street_cabinet=traffic_control controller.

---- Kovposch (talk) 08:33, 7 November 2021 (UTC)

traffic_signals:psv=* won't work. psv=* includes taxi=*, not to mention the confusion and variety over its definition in different countries for what bus it includes. It's for road vehicles only, not rail. ---- Kovposch (talk) 08:33, 7 November 2021 (UTC)

Traffic signal warning lights

How do we map / what do we call lights that warn that you are coming up to traffic signals e.g. https://www.google.com.au/maps/@-28.0931788,153.4536711,3a,52.7y,42.42h,86.46t/data=!3m6!1e1!3m4!1sptqCoytF8qSPbF_cI1QHkA!2e0!7i16384!8i8192?hl=en&coh=205409&entry=ttu?

They are linked to the traffic signals, that in this case are around the blind bend, & flash yellow when those lights turn red, to warn you to start slowing down, as you'll be coming up on stopped traffic.

Are they also traffic signals? --Fizzie41 (talk) 00:38, 12 January 2022 (UTC)

There are 12 traffic_signals=warning instances.

traffic_signals=warning

		$1%
		$1%
		$1%
		$1%

More details at taginfo

More details at taginfo

Probably have to add it without highway=traffic_signals. traffic_signals=blinker has been discussed with highway=stop and highway=give_way, when someone suggested traffic_signals=stop. https://osmus.slack.com/archives/C2VJAJCS0/p1631025261175100

---- Kovposch (talk) 04:35, 12 January 2022 (UTC)

Thanks for that. Did some searching & it appears that 11 of the 12 were added by one mapper around Sofia in Bulgaria. Looking closer, they would appear to just be "normal" traffic signals eg https://www.google.com/maps/@42.7091713,23.2875673,3a,90y,43.53h,90.17t/data=!3m7!1e1!3m5!1snSybfm6SE4q402-ljYwSnQ!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fpanoid%3DnSybfm6SE4q402-ljYwSnQ%26cb_client%3Dmaps_sv.share%26w%3D900%26h%3D600%26yaw%3D43.53%26pitch%3D-0.1700000000000017%26thumbfov%3D90!7i16384!8i8192?coh=205410&entry=ttu. Might have to raise it on the tagging list & see what more people think? --Fizzie41 (talk) 23:40, 12 January 2022 (UTC)

Actually no. I understand these are 3-light but only flash for the crosswalk with the pedestrian pictogram. Maybe they should be traffic_signals=blinker, despite having more than 1 section. They aren't traffic_signals=blink_mode.

Since these and "warning" may be mixing up the form and function with the ambiguity, another possibility is to learn from OpenRailwayMap/Tagging/Signal, which has a *=distant value. We are already sharing crossing=* with railway=crossing, so it should be reasonable to use common tagging if appropriate. ---- Kovposch (talk) 08:51, 13 January 2022 (UTC)

I should emphasize "warning" is unclear here. One is the static warning of a facility shown by this; the other is the advanced signal following the main signal downstream dynamically in your question. ---- Kovposch (talk) 09:35, 13 January 2022 (UTC)

@Kovposch and Fizzie41: traffic_signals=stop was suggested for intersection control beacons at all-way stops, under the assumption that traffic_signals=blinker is only for two-way stops. However, traffic_signals=blinker has never been documented as being limited to two-way stops, and I'm pretty sure that in practice, most uses are at all-way stops. Besides, someone looking at the values stop and blinker would be unlikely to intuit that distinction.

Neither example you linked to is an intersection control beacon, because it doesn't appear at the intersection itself. The example from Australia is a different kind of flashing beacon, which can be mounted on any kind of warning sign, not just advance warning signs about intersections. I'd probably tag the traffic_sign=AU:W3-3 node itself with flashing_lights=yes. I don't think it's necessary to associate the sign with "traffic signals" at all.

The example from Bulgaria appears to perform the same function as the flashing pedestrian crossing beacons that would be tagged flashing_lights=yes on a highway=crossing node and/or footway=crossing way. However, a similar-looking pedestrian crossing signal that turns red and requires the motorist to stop for a fixed amount of time [1] would be tagged as a highway=traffic_signals with a reasonably descriptive value such as traffic_signals=pedestrian_crossing.

 – Minh Nguyễn ^💬 09:01, 13 January 2022 (UTC)

None of the flashing_lights=* shows it changes according to the main signal.

I wonder whether crossing:light=* from railway=crossing could be adopted for use on highway=crossing.

---- Kovposch (talk) 09:39, 13 January 2022 (UTC)

@Kovposch: flashing_lights=* doesn't require a specific condition for the lights to flash or not flash, only that there be a beacon with flashing capability. It was coined for use immediately at a pedestrian crossing for the same reason that crossing:light=* was coined for use immediately at a railroad crossing. Granted, crossing:light=* has the advantage of not implying a particular pattern of illumination: perhaps some places don't have flashing or wig-wagging lights but instead display a steady light. The example I gave from the U.S. does display a steady light, but it's a timed stoplight, so the ordinary highway=traffic_signals tag applies in that case. But anyways, crossing:light=* is irrelevant to the example from Australia, which is mounted on an advance warning sign rather than immediately at the intersection. Such beacons are commonly mounted on all sorts of warning and indication signs, not just crossing signs, such as "Tune Radio to 530 AM When Flashing". – Minh Nguyễn ^💬 21:13, 13 January 2022 (UTC)

Ah, you were referring to railway=crossing; hope you don't mind that I fixed the typo in your comment. It would be nice to unify how we tag control devices on crossings regardless of what they cross, but I don't think that should prevent anyone from using flashing_lights=yes today where it makes sense to. I think it happens to apply in more places than crossing:light=* would, even if the latter were redefined, but only because flashing and wig-wagging patterns are so common. – Minh Nguyễn ^💬 21:18, 13 January 2022 (UTC)

Pedestrian as highway=traffic_lights

I highly oppose this statement. Routing/Navigation has a very different penalty for highway=traffic_lights than highway=crossing/crossing=traffic_lights. This is the correct way as a normal crossing has this regular and thereby statistically existant penalty whereas a pure Pedestrian Crossing is typically "by request only" and does not induce such a penalty.

By inviting mappers to map pure pedestrian crossings with highway=traffic_lights you break routing by inducing non existant delay/penalties. Flohoff (talk) 17:55, 28 February 2022 (UTC)

I agree. There should be a clear distinction between regular traffic lights and traffic lights specifically for pedestrians. --scai (talk) 09:38, 1 March 2022 (UTC)

So, what would be the correct way to map complex intersection like the one in the image above? It would be nice if there is an accurate representation not only for cars but also for bikes with regards to the penalties that the router needs to take into account? If we only tag nodes C+D with highway=crossing/crossing=traffic_lights, then we don't take into account the fact that this is not only a pedestrian crossing. If we tag all the nodes A+B+C+D+E, then there is redundancy, e. g. points E+C or points B+D+C. This risks that there will be too high penalty and hence the router might prefer a longer router around the intersection because it counts 3 traffic lights (B,D,C), where there actually is only 1 (B). Martianfreeloader (talk) 11:45, 1 March 2022 (UTC)

I think the point is being made about the simplest cases. Around here simple pedestrian crossings (crossing=traffic_signals) are being "improved" by adding "highway=traffic_signals + crossing=no" on either side at stop positions as currently "recommended" for simple pedestrian crossings. As pointed out, a router would need to use heuristics to determine that the extra highway = traffic_signals can be ignored. It would be better to add road_marking = solid_stop_line if the goal is to accurately map stop positions. The whole "Pedestrian crossing without intersection" section is confusing, not least because "highway=crossing + crossing=traffic_signals" and "highway=traffic_signals + crossing=traffic_signals" are completely different beasts. Only the latter gives a 3 light + 2 light symbol in JOSM. IMHO highway=traffic_signals should only be used if traffic is being blocked to allow other traffic to pass. Phodgkin (talk) 17:57, 13 November 2022 (UTC)

So is here an agreement that simple pedestrian crossings should not be mapped as a triplet of highway=traffic_lights 2x and a highway=crossing/crossing=traffic_lights? We should then remove this example from the list or at least write something aboud discouraging that solution. I just started a thread in the German Forum about it again as it broke routing. https://community.openstreetmap.org/t/fussgangerampeln-als-triplet-gemappt/107802 Flohoff (talk) 20:50, 7 January 2024 (UTC)

button operated

Please let us discuss here https://community.openstreetmap.org/t/button-operated-traffic-signals/7752 what button operated means on traffic signals. --Langläufer (talk) 10:38, 11 January 2023 (UTC)

Traffic lights for alternating oneways

Is there a tag (or a set of tags) for mapping traffic lights whose purpose is to alternate the flow of traffic on an alternating oneway road/bridge? --Bon (talk)

Advisory yellow - proceed if safe, even though opposite flow has green

Barcelona has many advisory yellow signals, whereby road users (normally cyclists) are allowed to proceed if safe, even though there is an opposing flow (e.g. cars, or a pedestrian crossing) which has green. Three examples are photographed and geolocated here:

https://www.cyclestreets.net/location/196794-6/

How should this be tagged? These are extremely useful, especially for cyclists, as they reduce often a minute's wait to merely a few seconds usually, and so are highly relevant to cycle routing.

There is nothing for UK's flashing amber ball for cars yet. traffic_signals:turn=* doesn't deal with caution proceed, give-way (US flashing yellow left turn arrow for protected-permissive signalling) or stop priority control, and other controls, only turn indications. It is opposed for the use of vertical bar | in conflict with *:lanes=* . —— Kovposch (talk) 11:34, 17 August 2023 (UTC)

Looks like there is red_turn - see: https://taginfo.openstreetmap.org/search?q=red_turn#keys (despite being badly named, arguably). I was going to invent traffic_signals:bicycle:advisory_proceed=yes but I think red_turn:bicycle=yes is probably nearest to what already exists. The lights apply to all directions in this case.--Cyclestreets (talk) 21:27, 17 May 2024 (UTC)

Traffic Signals With Temporal Inactivity

In short, some traffic lights aren't active 24/7 but instead turn inactive during the night or on certain days (or both in some cases), turning it into an uncontrolled intersection at these times, and the Wiki (I searched the page, the discussion, looked into the proposals and used the Wiki's search function but found nothing thereof) has no mention of it whatsoever but it's still a noteworthy feature to be mapped considering that we also map whether streets are just during the night, when someone is walking nearby or always lit. --ManuelB701 (talk) 18:47, 15 September 2023 (UTC)

How to map crossing signals whose audience is the intersecting highway's users, not the crossing's users?

Looking at the crossing=traffic_signals wiki it looks like the key is intended to apply to crossings where there is some sort of signal to guide the *crossing pedestrian* on use of the crossing (e.g., whether they can go or not). How should one map a crossing signal that, when activated, activates signal lights pointed at the intersecting highway's traffic? A HAWK beacon is an example. See https://en.wikipedia.org/wiki/HAWK_beacon. Another example is that sometimes there is a pedestrian marked crossing that is not at a road intersection (it is midblock) and is supported by yellow warning lights. When a pedestrian wants to cross they press a button and warning lights activate and flash at the perpendicular highway traffic, to alert that traffic that there is probably a user in the crossing. In these cases there might not be any signal that guides the pedestrian on whether to go or not.... the only lights are ones that face the oncoming traffic.

1. Hawk has a pedestrian signal. Still crossing=traffic_signals .
2. It's a warning light, but not signal control that's meant by crossing=traffic_signals . There's flashing_lights=* , although I personally think crossing:light=* should be extended to highway=crossing . Rigorously, flashIng_lights=* doesn't exactly convey what the light is for. Eg they can be located at the practically the same point, as I read about this light for the speed limit at a crosswalk. https://wehco.media.clients.ellingtoncms.com/imports/adg/photos/203125773_PXL_20221212_140035552_ORIG_t800.jpg https://www.nwaonline.com/news/2022/dec/16/gentry-council-passes-338-million-budget-oks/

—— Kovposch (talk) 05:38, 16 August 2024 (UTC)