Talk:Tag:highway=traffic signals/Archive 1

Numbers

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)

Resolved: included in article Mateusz Konieczny (talk) 07:26, 7 November 2021 (UTC)

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)

Resolved: Mateusz Konieczny (talk) 07:26, 7 November 2021 (UTC)

oneway

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)

Resolved: Mateusz Konieczny (talk) 07:27, 7 November 2021 (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)

See https://wiki.openstreetmap.org/wiki/Key:traffic_signals in general. Mateusz Konieczny (talk) 07:28, 7 November 2021 (UTC)

Resolved: seems to not require further edits Mateusz Konieczny (talk) 07:28, 7 November 2021 (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)

Resolved: seems to not require further edits Mateusz Konieczny (talk) 07:28, 7 November 2021 (UTC)

Separately mapped traffic light and highway=crossing + crossing=traffic_signals

Lets say that there are highway=crossing mapped.

Is it OK to map

• traffic light object separate from crossing
• remove crossing=traffic_signals from highway=crossing node

Is it OK to map

• traffic light object separate from crossing
• add crossing=traffic_signals to highway=crossing node

?

This was triggered by https://github.com/streetcomplete/StreetComplete/discussions/3490

Note "Nearby can also be a traffic light (highway=traffic_signals) on another node." in another article and "If the traffic signal is not separately mapped, the node that is the actual crossing between the road and highway=footway/pedestrian should be tagged with highway=crossing + crossing=traffic_signals. " here.

Note, also here "If the entire crossing is represented by a single node (not recommended as the attributes mostly differ from the traffic signals used for cars) add highway=traffic_signals to that node. "

If there is a clear preference for one version we should recommend it, if both are accepted we likely should not describe one as preferred.

Mateusz Konieczny (talk) 07:33, 7 November 2021 (UTC)

Removing is not good. crossing=* is only an attribute, not a feature. traffic_signals:direction=* doesn't really work if 2 lines are connected either. ---- Kovposch (talk) 08:28, 7 November 2021 (UTC)

In my opinion crossing=traffic_signals is entirely fine on highway=crossing node - also when traffic signals are mapped separately. Mateusz Konieczny (talk) 13:39, 7 November 2021 (UTC)

I agree with the two previous speakers. crossing=traffic_signals should be tagged in both cases to specify the type of crossing. --Chris2map (talk) 13:59, 7 November 2021 (UTC)

The StreetComplete discussion was initiated by me under my github account. My suggestion was not about whether things like crossing=traffic_signals and traffic_signals:button_operated=* should be tagged, but rather where these tags should go. I had in mind cases like this one (screenshot below) where the traffic lights are already mapped separately at the ends of the cycleway=crossing path (or path=crossing or footway=crossing equivalently). In my opinion, tags that describe details of the traffic lights (like, traffic_signals:button_operated=*) should go to the traffic light nodes, not to the node(s) where the pedestrian crossing and the motor traffic road intersect. Likewise, kerb=* should go to the kerb node if an intersection is mapped in this detail (which is in many cases identical with the highway=traffic_signals node). Information about the entire extent of the pedestrian crossing (e. g. crossing=traffic_signals) should go on the path, and not to the intersecting node in my opinion. I can't substantiate this with documentation or widespread usage. But it seems logical to me. Martianfreeloader (talk) 17:15, 7 November 2021 (UTC)

In my opinion in such case all crossing properties should (or at least can) be recorded at highway=crossing node, mostly for consistency. Otherwise assigning info to the crossing would require elaborate matching of various nearby objects. What worse, in some cases closest crossing to traffic light is not its crossing, and in some cases traffic light closest to its crossing is not its. In general I really prefer when more complex tagging is done in addition to simpler tagging. For example, road area area:highway=* mapped in addition to highway=* lines, not instead it, waterway=riverbank areas in addition to waterway=river not instead, if someone adds brand:wikidata=* it does not mean that they can remove brand=* and so on. If someone want to map exact position of traffic lights it seems fine, but please do not remove or request to avoid adding crossing properties. Mateusz Konieczny (talk) 18:25, 7 November 2021 (UTC)

Having done a lot of reading on mapping pedestrian infrastructure, my first thought went exactly the same way, as Mateusz'. StreetComplete adding the information on the node of the crossing, that this crossing is protected by traffic-signals is in a way similar to adding a pedestrian way inside of a pedestrian area. The only damage from it may be, that a router calculates superficial delay, or warns twice, where there are extra traffic_lights mapped. This case is for a router very easy to handle, because it operates on a sorted itinerary, while it would put undue burden on an app like StreetComplete and likely other consumers of the data that had to roam the surroundings to learn simple facts about stuff they are interested in, imagine e.g. somebody wanting to know, how many of those exist in their city, perhaps in an effort, to control with official numbers… Can overpass even do that then?

Regarding logic: Remember, when you map "traffic_lights", you actually map the place, where people are supposed to stop for a red light - yet, unlike for cars, for pedestrians the light itself is on the far side of the street, ie. opposite to the stop-line. If you can live with that, I think you should be able live with the other too ;) --Hungerburg (talk) 21:21, 7 November 2021 (UTC)

Hungerburg, the traffic lights are mapped the way you're explaining (see screenshot of the same intersection in iD). But thanks for the reminder to avoid mapping mistakes! Martianfreeloader (talk) 09:49, 8 November 2021 (UTC)

Well, the lights aimed at pedestrians in the screenshot below shine exactly the opposite direction, as the lights on the ground do. Except maybe, there are, what the Bits call "puffin crossing". But yeah, otherwise would make a pain for mechanical processing them, e.g. for routing. One has to live with that inconsistency, when mapping like that. --Hungerburg (talk) 08:54, 9 November 2021 (UTC)

Isn't that how you're supposed to map them? My understanding is that traffic lights should be mapped where people are supposed to stop, not where the traffic light is physically located, in which case they are mapped correctly. This seems to be common practice, e. g. here and here. Please correct me if I'm wrong. Martianfreeloader (talk) 17:14, 9 November 2021 (UTC)

"The only damage from it may be, that a router calculates superficial delay, or warns twice, where there are extra traffic_lights mapped." This is exactly my main concern (apart from aesthetic considerations). Martianfreeloader (talk) 10:18, 8 November 2021 (UTC)

"This case is for a router very easy to handle, because it operates on a sorted itinerary". If this is very easy for the routing app why should the same thing be impossible for StreetComplete? Before creating a quest at node C, StreetComplete could check whether there are already relevant tags on the way F-A-C-D-B or on one of its nodes. For example, if it finds that traffic lights are already tagged on A and B, it can trust that someone has already mapped all traffic lights on this intersection. (I believe in the very vast majority of cases it's safe to assume that the traffic light (node E) for cars has been mapped, too, even if SC can't easily see that. Of course there may be some exotic cases, where someone has mapped the pedestrian intersection in crazy detail but forgot the traffic light for cars. But I don't think detecting these exceptional mapping mistakes should be the purpose of StreetComplete. After all, there are limits to automated mapping). Martianfreeloader (talk) 10:18, 8 November 2021 (UTC)

I'm sorry but I still haven't got it why there should not be tagged the crossing node (or nodes) with the property crossing=traffic_signals basically and routers for cars simply use that. All the other details can be mapped additional at will. --Chris2map (talk) 21:16, 8 November 2021 (UTC)

Most important in my opinion is that this creates unnecessary extra challenges for routers. Perhaps most of these challenges can be handled by smart programming of the routing engine in (hopefully) most situations. But if this kind of smart programming is possible, then it should equally be possible to avoid StreetComplete's wrong tagging by equipping StreetComplete with that smartness. I don't understand why it should be considered the best solution to first tag things in unnecessary and confusingly redundant ways (confusing for the routing engine) and then leave it to the data consumers to figure out what might the truth instead of making an effort to get things tagged correctly in the first place. I find it unlikely that a human mapper would do what StreetComplete does on above shown the example intersection. Martianfreeloader (talk) 21:53, 8 November 2021 (UTC)

You severely understate the problem that SC would face, in fact you want it to include a router. All in an effort, to spare routers to do, what they are supposed to do anyway. Regarding correctness: I too do not see anything incorrect in tagging the nodes C,D crossing=traffic_signals, this just records an important fact. --Hungerburg (talk) 09:12, 9 November 2021 (UTC)

As for your first point: Correct, I'm not a great programmer. :-) But even I can think of a 10-line algorithm to solve the problem on SC's side, no routing required. Martianfreeloader (talk) 18:51, 9 November 2021 (UTC)

For your second point: This important fact is already recorded on node B. Would you find it good practice to add 100 more nodes between A and B and tag them all with crossing=traffic_signals? Or, to use more realistic examples, to add a sidewalk=both tag on a road where sidewalks are already mapped separately? Or to add turn restrictions disallowing entry into the exit of a road that is already tagged as oneway? Martianfreeloader (talk) 18:51, 9 November 2021 (UTC)

In an attempt to summarize the discussion so far, there are 2 main areas of disagreement:

• (1) What is the best practice to tag pedestrian crossings if they are mapped in high detail?
• (2) Is it possible to teach StreetComplete to distinguish certain styles of mapping in details (low detail, high detail)?

Opinions:

• (1) Mateusz Konieczny, Hungerburg and Chris2map believe that the quality of the map is improved (or at least not impaired) by adding as many tags as possible to points A, B, C and D, even if they are redundant. Martianfreeloader's opinion is that one thing should only be tagged once in order to make life easy for data consumers, but also in order to keep the map understandable and maintainable.
• (2) While this question is probably off-topic for this wiki-page, Mateusz Konieczny and Hungerburg believe this is near-impossible while the bad programmer Martianfreeloader believes he can devise a few lines of code which do the job.

I still fail to see any good reasons for redundant tagging, but after counting, I have to conclude that I'm clearly in the minority with both my opinions. Martianfreeloader (talk) 19:11, 9 November 2021 (UTC)

Resolved: It is always fine to specify the type of crossing on the node of the crossing (4 voices pro, 1 against) --Hungerburg (talk) 23:49, 9 November 2021 (UTC)