Proposal talk:Set of Traffic Signals

Relation instead

Wouldn't a relation that would hold all component parts of the junction be better than an area?

then to the relation add something like

junction=traffic_signals

to denote a junction controlled by traffic signals. Some junctions are also named, so you could have a relation like:

type=junction junction=traffic_signals name=Henley's Corner

Members:

a list of nodes within the overall junction where the turn is traffic signal controlled.

Using relations makes it easier for anything that will attempt to automatically interpret than areas

see also Relations/Proposed/Junctions

Welshie 15:23, 27 June 2008 (UTC)

I agree with welshie. A relationship for junctions seems more reasonable than enclosing the junction area; and IMHO it's quite simpler for software to make sense of relations than things enclosed inside an area.

Having complex junctions in my country (roundabouts with traffic lights, oh yes), the proposal makes sense - just apply the idea to any junction. Ivansanchez 18:17, 27 June 2008 (UTC)

Yes, of course, its possible to use relations for this purpose. But it's much easier to handle if you simply assume a physical representation and edit this relation as an area. I say: it really has a physical representation. Why not edit as one and refrain from using the type relation in this case? --Gypakk 22:05, 29 June 2008 (UTC)

I think there should not be an area, because an area draws lines in the editor, and more lines around a crossing will be confusing. I propose a relation! --Lulu-Ann 08:13, 30 June 2008 (UTC)

It has been my intention to make these relations visible! I do not want having to click on node after node only to get this nearly encrypted information, which element has been linked to which other element(s) by a relation tag. What if we found a way to make this area (resp. this relation) visible and invisible by choice in the editor? Same as "G" key does with GPS tracks in Potlatch.
It has never been easy to integrate a third dimension in a two dimension oriented user interface. Relations are such a third dimension. The simpliest way to do this is to map the new third dimension downto the existing two. And that's what I'm trying to do... --Gypakk 09:45, 30 June 2008 (UTC)

One more problem with your area is that I've seen numerous junctions with extra traffic signals in the middle of the junction in addition to those at the end of each road. There's no way to make areas out of that, you could link them with a closed way of course, but then you need to have a way that goes criss-cross over the junction. --Eimai 11:01, 30 June 2008 (UTC)

I would also use relations for this. On simple junctions with only a handfull of trafic lights it should be no problem to find out if a trafic light is in an relationship or not. On more complex junctions, it might be more difficult to see which nodes are part of the relationship, but that has nothing to do with the relationship, only with the tools you use. If you can change the tools to hide your area when pressing "G", you could also change the tool to highlight all nodes part of the selected relationship when pressing "N". Also with the area solution, you might have nodes inside the area that are not part of the relationship. With the area you would force everybody to make sure that a traffic signal isn't inside an area that it shouldn't be in and if it happens to be inside such an area you would need to create a new tag saying this traffic signal is not in the area xyz despite the fact that it really is??? One more problem is when moving the junctions 20 meters to the left for example. Using a relationship -> no problems. Using an area -> it might get messy if the area is not moved with the relationship... --Ckruetze 14:40, 6 September 2008 (UTC)

I agree, relations makes more sense for the reasons already stated. Vid the Kid 16:33, 24 December 2008 (UTC)

Relations sound good to me. Example: What shall I do with the present propesed technique if there are only two traffic signals (e.g. a junction of a big road with two lanes and a small road)? A connection between these nodes would be a simple line and not an area. It doesn't make sense to map a traffic light system with an area. --Erde12 20:56, 24 February 2009 (UTC)

Yes. Please convert this draft proposal into relation type. --Gypakk 20:42, 27 February 2009 (UTC)

I don't think relation would be great. If you think about real-time mapping, relation is another object to analyse, and some relations are huge in size, so it's better to avoid using them. Area for the traffic light set seems to me the best choise because it's pointing directly to the places where to put trafic signal on the map and also shows it's relation. This object also could be used in the cases where it is only one or two traffic signals - it doesn't show area, but it's still pointing to the places where to put traffic lights. Also i'm thinking about a tag, which shows if the area in the middle of ways of intersection is covered with concrete or not. It's handy for rendering to show how this intersection is really look like. And it's possible to combine this tag with traffic signal set. --Lesnik 23:03, 23 April 2009 (UTC)

I'm strongly for a relation. A way or an area have another meaning. Members of the relation should be nodes. I propose two roles for the nodes: 1) Role=traffic_light for every node which represents a spot where one of the traffic lights is actually placed. 2) For roads which are part of the junction but do not have their own traffic light (e.g. right turn lanes which bypass the actual junction) an adequately placed node on this road should have something like Role=related_to_traffic_light or something. This should give a router the information it needs to output commands like "turn right at the traffic lights" even if the route uses a separately mapped lane which has no traffic light.

Relations may appear to be complicated, but this is IMHO due to a certain lack of usability on the side of the editors, which are programmed with the data structure in mind, not the User. Just imagine the following function: You mark several nodes, chose "traffic lights" in the menu, you get a simple dialog to confirm some settings, and that's it. The actual structure of a relation (type, keywords for roles etc.) should not be visible to the non-expert user.

A renderer should simply find the center of all nodes to place the icon. Alternatively one could include an optional node in the relation with role=proposed_icon_spot or somehting like this. --1248 15:53, 5 October 2009 (UTC)

I agree that relations are the proper way to handle this. sybren 08:17, 3 November 2009 (UTC)

I concur, relations are the best approach Nfgusedautoparts 21:30, 1 April 2010 (UTC)

I also agree to to use relations here. It is not the purpose of ways and areas to map things like this, but it is 100% the intention behind relations. --NobodysNightmare 12:38, 26 March 2010 (UTC)

I also agree to use relations for the before mentioned reasons. Computerfreaked 13:12, 22 September 2010 (UTC)

Welshie's idea sounds pretty good. -Computerfreaked

i second that. since it is a logical grouping of physical elements, the only conclusion is to use a relation. ways should be used for things that are actually physically present. btw, is this proposal dead since the last comment is from 2010? --Flaimo 01:09, 23 March 2011 (UTC)

I'm for a relation too. Do we have relation type already? May be Proposed_features/traffic_signals_set_2 is a good alternative. --Plamen (talk) 16:19, 13 April 2021 (UTC)

Use of the amenity namespace - other possibilities

Please do not put this in the amenity namespace. People will vote against it for just that reason. If an area is to be used rather than a relation, what about tagging as highway=traffic_signals instead? Yes, in theory that makes it a highway - but I'm against making it a closed Way too.

Other possibilities include:

• zone=traffic_signals
• group=traffic_signals

But I'm meh about these too. Seems like it really is better done as a relation to me. --achadwick 20:16, 10 August 2008 (UTC)

Hi achadwick, feel free to move the list entry to highway! And feel free to change this suggestion. Some weeks ago I did not want to use relations for this. But today, I must admit, it would be better to link the physical traffic lights to one logical unit by using a relation. Could someone who has more experience with relations please change this suggestion accordingly? --Gypakk 19:11, 11 August 2008 (UTC)

A set of traffic signals can also include a railway tracks, trams or lightrails. Should it be in highway namespace then? --Lulu-Ann 16:07, 12 August 2008 (UTC)

Actually, if we chose to do this as a relation, the highway-vs-railway-vs-cycleway-vs-... problem is solved too, due just to the form relations take. Just type=traffic_signals would do :) --achadwick 12:17, 13 August 2008 (UTC)

But I'm wondering too if this shouldn't be rolled into Relations/Proposed/Junctions rather than something separate. After all, all sets of traffic signals must occur at a junction, right? Consider this: for each existing highway=traffic_signals node, just add it to the junction as a member - possibly with a role of traffic_signals/signals within the relation. Light rail systems and tramways have signals of their own, and I'm not sure if a tag exists for their signals. Even so, using a relation would sufficiently extensible to accommodate all comers. Should we do this? --achadwick 12:17, 13 August 2008 (UTC)

I seriously hope no-one's proposing mapping timed traffic-light sequences along major ways, spanning multiple junctions :) --achadwick 12:17, 13 August 2008 (UTC)

Well, I'm thinking about it for some time, that's what brought me here today. :) But that would need some more information stored for every traffic signal, like which direction it looks, which direction lets the traffic pass. After that should be the timing information added to every pair of consecutive traffic signals. Sadly I do not yet have the required knowledge to make a proper proposal but I will look into it.

On the amenity issue, I think that a traffic sign should not belong to amenities. --Tylla 10:40, 22 December 2009 (UTC)

Camera surveillance at traffic signals

Makes me worry (German:) :

• :http://www.dradio.de/dlf/sendungen/computer/880034/ Über Kameraüberwachung an Ampeln

--Lulu-Ann 08:13, 26 May 2009 (UTC)