Proposal talk:Traffic sign

Questions

How does one tell to which highway a sign belongs and to which direction it belongs, and to which direction it's pointing (some signs are repeated on the left side of the road, or are placed above a certain lane).
What about difficult parameters of a sign? Sometimes you'd have to completely describe how certain lines, arrows, icons and texts are put on a certain sign. Like [1], [2] (where each arrow can contain any other traffic sign (or even more than one), [3] or signs like [4], [5], [6] if you really want to have some fun... which also shows the problem of having signs within signs.

--Eimai 11:55, 7 April 2009 (UTC)

Maybe this wasn't clear enough: This is not to tag the position of the sign. You just tag it to the way or area it applies to. As for the more complex signs: This proposal just provides a tagging scheme to tag more (and in a consistent fashion), not necessarily everything you may come across. --Driver2 20:45, 8 April 2009 (UTC)

How do you know to which direction a sign applies then if you put it on the way? --Eimai 15:55, 14 April 2009 (UTC)

The same as access-Tags: traffic_sign:forward=*, traffic_sign:backward=*. And many apply to both directions anyway. --Driver2 16:36, 14 April 2009 (UTC)

I am also using traffic_sign=* and put this on a node beside the way (in countries with traffic on the right I put them right of the road). I am mapping traffic signs with this (e.g. traffic_sign=maxspeed, traffic_sign=maxheight, traffic_sign=maxweight, traffic_sign=city_limit, ...). If you want to tag the implications of a traffic sign rather then the sign itself you should use a different tag. --Dieterdreist 10:45, 14 March 2012 (UTC)

What is the point of this proposal? Why would anyone want to add signs to the OSM DB that are intended are warnings for a driver? If this is intended to be used in some sort of navigation system then forget it. It would only be reliable if *every* sign was added, and that will never happen. Chillly 21:58, 14 March 2012 (UTC)

If one person per 100 houses decides to help in a particular town, it will not take long to get many useful signs (at least of various types). I anticipate finding people to do this for where I live. It would be a shame for osm not to accept such data. If signs are broken up into groups (as is already the case, eg, bus_stop), then this can certainly be managed. Navigation systems of many sorts are more than possible and I think desirable, usable even offline since few changes take place per day and an open provider can maintain a simple mechanism for auto updating from an ordinary website query. Since people are going to do this, we should probably continue to seek out standardization. Jose X 20:05, 22 April 2012 (BST)

The country code is pointless, unless a sign for one country occurs in another country. What is the point of tagging a sign physically located in Germany as DE:? We know that the sign is in Germany. Chillly 21:58, 14 March 2012 (UTC)

Why have you chosen an abstract numbering scheme to describe the sign? The numbering system is not workable. You are missing the most important rule of tagging: make it workable for mappers. Mappers will need to look up every sign they tag - no one will bother so the scheme will not get used. Chillly 21:58, 14 March 2012 (UTC)

How to parse

For parsing it would be useful to not use [*] and to prefix every sign-value with the country code. The last example from the proposal page would look like this traffic_sign=DE:260;DE:1020-31;DE:265:3.8;DE:264:2. See DE:Road signs in Germany! --Phobie 13:52, 31 May 2009 (UTC)

This however won't work if the values contain any of the separator characters. Key:opening_hours for example can contain both ';' (semicolon) and ':' (colon). Of course we could define another syntax to specify hours for traffic signs, but opening_hours is already in use and pretty versatile. I'm all for easy parsing, but it should also be relatively stable. --Driver2 23:53, 31 May 2009 (UTC)

Yes, you are right. But I think we should use extra-tags for complex signs and do not include everything in the main tag! traffic_sign=DE:xxx:yyy or traffic_sign=DE:xxx:+ + traffic_sign:DE:xxx=yyy --Phobie 00:31, 18 July 2009 (UTC)

You mean like: traffic_sign=DE:260;1020-31;1040-30 traffic_sign:DE:1040-30=Mo-Fr 8:30-13:00;Sa 9:30-19:00 ? Keep the 'simple' things in the main tag (making it easy to parse the individual signs), but putting the more complex values in an extra tag? --Driver2 02:40, 18 July 2009 (UTC)

Yes, but it seems that DE:1040-30 does not need opening_hours because it is always "16-18 h". And I think traffic_sign=DE:260;DE:1020-31;DE:1040-30 is better! --Phobie 02:48, 19 July 2009 (UTC)

Why do you think every sign should get a country code? --Driver2 18:10, 30 July 2009 (UTC)

Every country-specific sign-code should get a country code prefixed, because that would make parsing much easier. If we only want to say the sign is in Germany, we could also use is_in:country=Germany, but traffic_sign=260 has no global meaning and we need to call it DE:260 to make it unambiguous. So every ";"-separated value is selfcontained and we could use tags like traffic_sign=DE:260;city_limit;DE:1020-31;stop;DE:1040-30. --Phobie 14:25, 1 August 2009 (UTC)

How to define

How should we define the signs? And how should we make available the icons for rendering and routing software? I know that most countries have defined names/references for each (non-text) sign, but these definitions (or the sign icons) are not always in the public domain. Besides, a sign database available for everybody must be made available together with such a proposal, or it will turn into a series of cryptic codes. --Skippern 10:04, 19 July 2009 (UTC)

I think this is not the job of the OSM-project. The only thing we could do are aliases like "DE:274 ==> INT:maxspeed" to help application developers. --Phobie 21:11, 20 July 2009 (UTC)

I find the idea of tagging traffic signs useful but would propose generic values for common traffic signs (e.g. traffic_sign=danger or traffic_sign=maxspeed) rather than national codes. That way a parser can make something useful out of it MUCH more easily, and it's also way easier to map (poll: how many mappers can tell the sign number for the stop sign in their national road code off the top of their head? how many can tell me what sign 126 in their national road code stands for?)

Since there is a fair amount of traffic signs which are similar in a lot of countries, with minimal visual differences (or different appearances but with the same meaning), it shouldn't be too hard to come up with a set of codes. If someone really needs national codes, we might add an extra tag for that, e.g. traffic_sign:nat_code=*. If the set of international codes is defined well, that and the country in which the sign is located are sufficient to write a preprocessor which automatically generates the national codes. --Stanton 18:41, 12 March 2011 (UTC)

Here's the Vienna Convention on which many of the signs are based: http://www.unece.org/fileadmin/DAM/trans/conventn/Conv_road_signs_2006v_EN.pdf. And here is the source for UK signs: http://www.legislation.gov.uk/uksi/2002/3113/contents/made. Perhaps the international signs should be referenced to the Vienna Convention rather than national standards? Sdoerr 23:30, 14 March 2012 (UTC)

Direction

Need to show what is direction of sign. In other words, routing and other software need advice to determine which side of sign is located in city.

I offer to use addition tag direction=*. For example, direction=forward and direction=backward. Default value will be direction=forward.

And other question. Can traffic_sign=city_limit be located on junction node? I think not, otherwise is hard to determine on which way it is applicable. -- Aleksejs 16:31, 16 July 2009 (UTC)

There is some proposal traffic_sign:forward=*, traffic_sign:backward=* at Talk:Proposed_features/Traffic_sign. Seems enough good for me. -- Aleksejs 22:33, 16 July 2009 (UTC)

But be careful: traffic_sign:forward/backward=* was proposed in the context of tagging it on ways, not nodes. Using direction-dependent tags on nodes can be a lot more tricky: You can only use nodes, that belong to exactly one way. While junctions can be easily spotted, you also have to avoid nodes between two ways (where they have been split, but are connected by a node) or of ways that lay on top of eachother (like area borders on a street). The latter could be resolved by only considering the way with a highway=* tag as the one to take the direction from, but the other cases would still be ambiguous. These could of couse be circumvented by some editor support (e.g. output a warning when adding a direction-dependent tag to a node that belongs to several ways). --Driver2 13:04, 8 August 2009 (UTC)

Is there some consensus on this yet? There still seems to be no well established solution for tagging the direction of traffic signs, at least if mapped as nodes. For traffic signals, we have traffic_signals:direction=*. For traffic signs, both traffic_sign:forward=* and traffic_sign:backward=* as well as direction=forward and direction=backward seem to be used, and documentation about them on the Wiki is virtually non-existent (I've tried to add documentation to the Key:traffic_sign and Key:direction pages). Can anyone clarify on this? --Emkey08 (talk) 06:48, 28 August 2013 (UTC)

Grouping and Ordering

Should signs (on the same post) that belong together be grouped or just be ordered the same way they are in reality?

For example:

Grouping: traffic_sign=DE:260,DE:1020-31;DE:265[3.8] / traffic_sign=sign1,sign2;sign3 (notice the comma instead of semicolon)

You know that DE:260 and DE:1020-31 belong together, because they are in the same group.

Sorting: traffic_sign=DE:260;DE:1020-31;DE:265[3.8] traffic_sign=sign1;sign2;sign3

You know that DE:260 and DE:1020-31 belong together, because DE:1020-31 comes directly after DE:260.

Grouping would explicitly say: Those belong together. Sorting would require you to check which signs can or have to belong to others. On the other hand, Grouping requires mappers to know which signs belong together, while Sorting is more natural, since it's a just a representation of the real traffic signs (they are also ordered in a certain way). --Driver2 12:48, 8 August 2009 (UTC)

Warning traffic signs

I want to use some designations for ~~preventing~~ warning traffic signs. Please, look at my proposals, support them or propose another. If you know analogous traffic signs in another countries, you can add it to galleries. Dinamik 22:09, 13 March 2012 (UTC)

I think the usual English term is "warning signs" rather than "preventing signs". HillWithSmallFields 11:30, 14 March 2012 (UTC)

Thank you! I changed the title. Dinamik 11:32, 14 March 2012 (UTC)
It makes a lot of sense to me to use descriptive names for each of this types of sign as you propose. PeterIto 14:19, 18 June 2012 (BST)

dangerous turn and dangerous turns

Germany: dangerous turn right
Poland: dangerous turn right
Russia: dangerous turn right
Sweden: dangerous turn right

Germany: dangerous turn left
Poland: dangerous turn left
Russia: dangerous turn left
Sweden: dangerous turn left

Germany: dangerous turns right
Poland: dangerous turns right
Russia: dangerous turns right
Sweden: dangerous turns right

Germany: dangerous turns left
Poland: dangerous turns left
Russia: dangerous turns left
Sweden: dangerous turns left

traffic_sign=dangerous_turn_right, traffic_sign=dangerous_turn_left, traffic_sign=dangerous_turns_right and traffic_sign=dangerous_turns_left Dinamik 22:17, 13 March 2012 (UTC)

slippery road

Germany: slippery road
Russia: slippery road

traffic_sign=slippery_road Dinamik 23:20, 13 March 2012 (UTC)

rough road

rough road
rough road

traffic_sign=rough_road Dinamik 23:20, 13 March 2012 (UTC)

emission of gravel

Germany: emission of gravel
Russia: emission of gravel

traffic_sign=emission_of_gravel Dinamik 23:20, 13 March 2012 (UTC)

dangerous kerb

Italy: dangerous kerb
Russia: dangerous kerb

traffic_sign=dangerous_kerb Dinamik 23:20, 13 March 2012 (UTC)

falling rocks

Poland: falling rocks (there is one traffic sign for danger from both sides)
Russia: falling rocks (there is one traffic sign for danger from both sides)

Germany: falling rocks (from the right side)
Italy: falling rocks (from the right side)

Germany: falling rocks (from the left side)
Italy: falling rocks (from the left side)

traffic_sign=falling_rocks, traffic_sign=falling_rocks_right, traffic_sign=falling_rocks_left Dinamik 19:03, 14 March 2012 (UTC)

crosswind

Germany: crosswind
Russia: crosswind

traffic_sign=crosswind Dinamik 23:20, 13 March 2012 (UTC)

low-flying airplanes

Germany: low-flying airplanes
Italy: low-flying airplanes
Poland: low-flying airplanes
Russia: low-flying airplanes

traffic_sign=low-flying_airplanes Dinamik 23:20, 13 March 2012 (UTC)

children

Austria: children
Belgium: children
Brazil: children
Chech Republic: children
Republic of China: children
Finland: children
Germany: children
Italy: children
Poland: children
Russia: children
Sweden: children

traffic_sign=children Dinamik 22:24, 13 March 2012 (UTC)

driving of cattle

Germany: driving of cattle
Russia: driving of cattle

traffic_sign=driving_of_cattle Dinamik 22:28, 13 March 2012 (UTC)

wild animals

Germany: wild animals
Russia: wild animals

traffic_sign=wild_animals Dinamik 22:29, 13 March 2012 (UTC)

traffic jam

Germany: traffic jam
Russia: traffic jam

traffic_sign=traffic_jam Dinamik 22:37, 13 March 2012 (UTC)

danger

Germany: danger
Russia: danger

traffic_sign=danger Dinamik 22:38, 13 March 2012 (UTC)

traffic_sign:extent

Germany: extent
Russia: extent

I would like to propose additional tag traffic_sign:extent=* for sign, which shows extent of action of some another sign. Marking of measurement unit is obligatory. For example, - traffic_sign=rough_road + traffic_sign:extent=100 m. Dinamik 11:06, 14 March 2012 (UTC)

Approval of proposal?

Can I suggest that we now treat this proposal as agreed and move the above table of traffic signs into the main tag page. I say that because this discussion has been rumbling on since 2009 and there are already 100,000 usages of the tag so far and no one seems to have objected to the approach. Thoughts? PeterIto 14:00, 18 June 2012 (BST)

Also... It was my understanding that the traffic sign tag was mainly used as a node at the point where there is a sign planted in the ground. This proposal as written seems to imply that it is applied to all the ways affected, and some of the discussion above that it is used on a node within the way. Can people clarify on the traffic-sign tag page how it should be used. Personally I was expecting that it would be attached to the location of the actual sign to allow 3d rendering and games rendering etc etc to produce realistic representations of what can be seen and where as one travels down a road. PeterIto 14:48, 18 June 2012 (BST)

There are two different styles of using the traffic_sign key:

One group of mappers uses human-readable values. The most prominent by far is city_limit, and these are predominantly used on nodes.
Another group of mappers uses country-specific traffic sign ids. These are mostly used for access or maxspeed restrictions, allow listing multi-sign combinations, and are predominantly used on the ways affected by the sign.

This proposal describes the second variant, and Taginfo confirms that the two groups are surprisingly distinct. I don't think there is necessarily a conflict, though - if a traffic_sign value is used on an isolated node, then it's probably the position; if it's used on a highway=*, then it's probably the list of signs affecting this road segment. --Tordanik 16:01, 18 June 2012 (BST)

OK, thanks. So would it be reasonable to clarify that difference on the tag page given that there is certainly considerable use already of both methods? PeterIto 17:29, 18 June 2012 (BST)

Maybe, though I'm not sure whether that difference actually makes much sense. I'm just observing that it exists. --Tordanik 16:26, 19 June 2012 (BST)

Anyway, I've tried to make the distinction a bit clearer and have also added some information from the proposal that was missing on the key page (such as the distinction between comma and semicolon separators, and brackets for values) --Tordanik 12:47, 21 June 2012 (BST)

Thanks. I am now beginning to understand how the tag is used myself, which is always a good start :) Are we agreed that we are going to document how this tag is currently used and are not going to try to get people to change how the are using it by proposing a new tag for one of the uses? PeterIto 15:07, 21 June 2012 (BT)

I have no intention to set up a proposal related to the traffic sign issue anytime soon, so yes, I'm just trying to document existing usage of traffic_sign. (One caveat is that I would like this proposal to be documented on the key page either as a whole or not at all, but not partially. It is internally consistent, so just cherry-picking the most frequently aspects of it wouldn't be a good idea imo.) --Tordanik 16:33, 21 June 2012 (BST)

Agreed. The key page should either be a redirect or be a page describing the recommended use of the tag with a 'See also' link at the bottom to this original proposal. Given that there was already a page on the key page I suggest we add all of the current usage to it treat the proposal as 'approved'. PeterIto 17:15, 21 June 2012 (BST)