Talk:Key:traffic sign

Original discussion

See Talk:Proposed_features/Traffic_sign for the discussion on the original proposal.

Neither is worse

I've removed this bit from the signs as separate nodes section:

As this causes major implications on algorithmic processability, it is recommended to tag traffic signs on nodes which are part of a way instead.

If one is mapping them as separate nodes at their exact position, one can and should also tag the signs' effect on the ways they concern. Most probably mappers don't enter the signs thinking routers would pick them up (without also tagging the ways), but for quality control, and - well - maps of signs. Alv (talk) 11:27, 1 September 2013 (UTC)

Yes, mappers should of course also tag the concerned way with corresponding tags (e.g. by using maxspeed=* if there's a speed limit sign). The problem however is that many signs don't have any corresponding tags which could be applied to the way. While this probably isn't an issue for routing itself, traffic signs tagged on the way could for example still be used for enhanced text-to-speech instructions for the driver (e.g. "Caution: falling rocks"). This isn't (easily) possible if the traffic sign is tagged as a separate node. --Emkey08 (talk) 15:48, 1 September 2013 (UTC)

The tag can always be made up, there's even a limited amount of signs in use. (For hazards: hazard=falling_rocks + source:hazard=traffic_sign. I've tagged several hazard=children sections, and long stretches of hazard=moose. :) It's only a problem when there are two identically tagged nodes, one on the way and one next to it; even though there's just one sign. (Signs can be above the road, too, so an accurately placed node might happen on the way, too. Probably should be unconnected, then, though, and with layer=.) Alv (talk) 16:15, 1 September 2013 (UTC)

Hm... but then we potentially need several new well documented tags, as there are hundreds of different traffic signs around the world. People would always have to map both the sign itself as well as the sign's effect on the way, which seems not ideal to me, at least for some traffic signs. It may also simply not always be possible to adequately tag the sign's effect on a way because it actually affects a node or an area instead (examples may include traffic_sign=city_limit, stop signs, give way signs, and others).

Both methods have their pros and cons, but IMO the con of harder algorithmic processability matters more than the con of an approximated vs. exact physical position, which is actually only a rendering issue. Rendering can even be more accurate if the sign is tagged on the road itself because the direction of affected travel can be specified in this case, allowing navigation software to only display traffic signs if they apply to the current direction of travel. --Emkey08 (talk) 06:40, 2 September 2013 (UTC)

The sentence is now better. Nice. Alv (talk) 12:31, 2 September 2013 (UTC)

Always as separate node + effect on the way

I'm a micromapper, so mapping signs which are next to the road, as a node which is part of a way, is not an option for me. The direction tag may seem like a good idea, but as soon as the next mapper splits the way on that node, this becomes meaningless. Maybe the editor software should start warning about this. But will iD ever become so intrusive in people's workflow? It's hard to imagine a world where the developers of iD might even consider that as an option.

Of course, I'll also map the effect the sign has on the way, although I can imagine this will involve a lot of semicolons on certain ways... Especially when parking signs come into play.--Polyglot (talk) 12:38, 30 January 2015 (UTC)

In Germany I verified a lot of traffic signs which had been tagged as a part of a way. In all cases traffic signs had corresponding tags which describes the effect on the way. In my opinion a traffic sign should only be mapped as a node, either as part of the way or as separate note. It doesn't matter that much. --Helmut (talk) 18ː52, 24 December 2019

Relevant discussion on the tagging mailing list

This tag was also discussed here: [1] --Dieterdreist (talk) 10:13, 4 November 2015 (UTC)

value of the traffic_sign in []

like for incline value or maxheigh, we can use traffic_sign=city_limit[Paris] for the entrance and trafic_sign=city_limit[-Paris-] for the exit. -Yod4z (talk) 11:59, 3 August 2016 (UTC)

Contradiction of the tag definition page

The page states that the tag is to be used for mapping a traffic sign. Then in the "how to map" section it states the tag could be applied to a node, way or area. Who in heaven's name maps traffic signs as areas? My interpretation is there are 2 kind of applications for this tag (unfortunately): it is used to map traffic signs (generally on a node), and some people use traffic sign codes to map restrictions or prescriptions or other traffic sign contents on a way or area where they think that they apply to according to their interpretation. IMHO the latter is bogus (we either already have globally applicable osm tags for those, or we should invent them where missing), while the former is useful for QA (quality assurance) and verifiability. --Dieterdreist (talk) 11:45, 21 March 2017 (UTC)

Yes, there are two different uses for this tag: Mapping traffic signs themselves, and mapping which traffic signs legally apply to a given way or area. The introduction fails to mention the second one, although it's mentioned further down the page.

I don't think there's anything wrong with the latter usage. Unfortunately, the commonly used tags are still not clearly defined, and there are recurring discussions about what certain tag combinations mean (e.g. whether "cycleway" implies foot=yes or foot=no, whether blue signs should be mapped as "designated" or "official", and so on). This makes it useful to tag the traffic sign ids in addition to those tags after a survey, to make sure the information you surveyed is expressed unambiguously and isn't lost in the noise of incompatible tag interpretations. --Tordanik 19:15, 3 April 2017 (UTC)

There is a precise definition of cycleway (GB:955) as discussed on wiki page Tag:highway=cycleway and country specific default access permissions. In countries where foot access is not allowed by default, add foot=designated or foot=yes tag in case foot access is allowed. This rules also applies to other blue traffic signs like GB:953 or GB:953V1. All those blue road signs describing access permissions (only to be used by) can be clearly assigned to available access tags. Because of this I'm finally not able follow Tordaniks argumentation.

The key traffic_sign should only be used to describe the traffic sign itself and it's position. With exception of road markings (such as GB:1004) traffic signs are only applicable to nodes, not to ways. --Helmut 20:12, 20 June 2020 (UTC)

Add examplea for use of direction tag

I'd like to add two examples for the use of the direction tag on a single note. That seems to have caused some confusion in the Dutch community.

The examples I'd like to add are:

• If you encounter a traffic sign when traveling north, then the sign is facing south. So you can add direction=180 or direction=S
• Likewise, when traveling west, signs are facing east, so you tag them with direction=90 or direction=E

Phicoh (talk) 10:30, 19 May 2018 (UTC)

Usually traffic signs are directed towards the traffic for which they are intended. If you put the traffic signs right of the road and not as part of the highway, you have solved 99.8% of all cases (guess), but it doesn’t work for road markings (unless the road is mapped as a area). —Dieterdreist (talk) 13:42, 19 May 2018 (UTC)

Agree with Dietersreist. In the US, the direction tag on traffic sign nodes is used to denote the direction of the traffic to which the sign applies, e.g. direction=N means the sign applies to north-bound traffic, even if the face of the sign faces south. --Carciofo (talk) 08:41, 20 May 2018 (UTC)

So in the US the traffic signs are placed the wrong way (unlikely) or you are not tagging according to the rules ("to describe the facing orientation of the sign"). Do you want the start a proposal to change the rules? Phicoh (talk) 15:11, 20 May 2018 (UTC)

I agree with your suggestion to give additional examples to combat misunderstandings (such as the ones demonstrated in this very thread). Adding illustrations might help convey the concept, are you planning to do that? Something like image from the direction=* proposal, for example. --Tordanik 16:23, 23 May 2018 (UTC)

I'm not that good at drawing. I just now added my example text to the traffic sign page. I guess I should also add some text to the direction page. Phicoh (talk) 09:46, 24 May 2018 (UTC)

Why traffic_sign:direction is required

It may happen that a single node contains multiple attributes which require individual direction tags. Probably there is a single, separated node containing a directed street light and at same time a traffic sign because they are mounted on same pole. The tags will be highway=street_lamp + light:direction=to_street and traffic_sign=* + traffic_sign:direction=180. I assume there will be more in future. --Vanagaudi (talk) 20:40, 10 January 2020 (UTC)

The traffic sign and the street light are separate objects and, in my opinion, should be mapped as two nodes. --Tordanik 10:53, 11 January 2020 (UTC)

I would also map it as two nodes. IMO it's better to separate the two DIFFERENT features. (Otherwise you also had to add a waste basket, a guidepost or other things which are fixed at the street_lamp pole to the same node ... it will soon overload the node and it can make further editing quite complicated or confusing). Unfortunatly, such cases (specially concerning nodes with more than 1 "feature") is not explicitly described on the page Good practice nor on One feature, one OSM element (at least there is room for interpretations) – it would be nice IMO, if this would be mentioned/described there how a "good pratice" would be in general (if you can say that at all). At the end, it always seems to be an interpretation of what a "feature" really is and where another "feature" begins. And that although it is described on the page Features as "a physical element in the landscape that can be mapped". But: is the street lamp the one and only physical element or the main element in this case? Or are waste baskets or a traffic signs fixed on a street lamp not "stand alone" physical elements as well (with quite another function as the street lamp, so it's not a sub-feature of the steet lamp ...) – althought they are fixed on the street lamp? (Side note: a separate mapped waste basket could have support=street_lamp – even the traffic_sign, if you like that). And if the fact that something is fixed to another thing should be a criterion (should it???), it could become tricky or even undecidable – what's the "main" thing, what's the "sub" thing? E.g.: a pole with a traffic sign and a guidepost. On the other hand, there can be 3 or 4 or more nodes at one place if you separate everything (e.g. a street lamp, a traffic sign, a waste basket, a guidepost, a surveillance camera ...). But I see no other way (only a relation perhaps grouping together everything – also some kind of an overload in this case). To follow the basic rule "keep it simple", I would always place serveral nodes quite near together at such a place (perhaps not exactly one on top of the other, but that should also be possible). The editors and the renders would perhaps have to be improved for such cases ... (e.g. automatically showing a group of nodes/POIs – perhaps depending on the zoom level! – which could be expanded if selected to see the different nodes/POIs in a clear way – if they have the same or very near coordinates). --Goodidea (talk) 14:02, 30 December 2021 (UTC)

Variable Message signs

Added description for Variable Message Signs / Dynamic Message Signs following discussion on the tagging mailing list: [2] -- Fizzie41 (talk) 00:43, 1 November 2019 (UTC)

Message signs combined with electronic road signs (or single electronic road signs)

@ User:Fizzie41 (and others of course): OK ... apart from the fact that a display which shows digital text messages (for the traffic on the road) is not a traffic sign in a legal sense (as far as I know, but I don't know the situation in every country – and the term "traffic sign" could perhaps be used in a different way for OpenStreetMap – but on the other hand this is perhaps not the best idea ...): should this tag also be used for single electronic road signs? Or how should something like that be tagged (a gantry with electronic road signs – AND a display for variable messages):

Other example on Mapillary: https://www.mapillary.com/app/?pKey=1282800138841973 – Or see this category on Wikimedia Commons for various kinds of electronic road signs: https://commons.wikimedia.org/wiki/Category:Electronic_road_signs

Should this (the complete signs + the display) also be covered by a single tag traffic_sign=variable_message – because it doesn't only show a message, but also variable traffic signs (you could say: a sign is also a message ...)? Or do we need a new value for such digital/electronic traffic signs like traffic_sign=variable_sign/traffic_sign=electronic_sign or something else? I saw some nodes (of a motorway) where a gantry like this exists tagged only with traffic_sign=signals, which seems to be an undocumented value (and only 12 uses) – and the word "signal" is not the best for such a sign IMO (it's very unspecific, a signal can be analog/digital/acoustic/...). I would prefer another value. And second question: HOW should it be tagged? I also ask because of the sentence "Usually combined with man_made=gantry." in the table of human-readable values – how should/could it be combined? There are several possibilities (and problems):

• Draw a way over the road with man_made=gantry + layer=1 + traffic_sign=variable_message for the message panel or something like traffic_sign=variable_sign;variable_message/ to mention/cover the different kinds of displays? And no tag on a node ...
• Put the tags on a node on the road with something like traffic_sign=variable_sign;variable_message and (optional) man_made=gantry on the node, too (problem: at the moment the quite unspecified tag man_made=gantry should only be used on ways according to its wiki page – perhaps a usage on a node should also be OK?)
• Put traffic_sign=variable_message (or something like traffic_sign=variable_sign;variable_message) on a node on the way and (optional) draw a way for the gantry with man_made=gantry + layer=1 (with no traffic_sign tag or optionally repeating the traffic_sign tag)?

--Goodidea (talk) 22:27, 2 December 2021 (UTC)

X HOTEL turn right

BLAPBSBURG HOTEL 500 m =>

• Say if such signs need to be mapped differently if made by a private company vs. a public goventment.
• Say if they are Key:traffic sign or Tag:tourism=information or some kind of advertisement.

Jidanni (talk) 13:52, 21 April 2020 (UTC)

OK, it must be a giant Tag:information=guidepost. Jidanni (talk) 13:57, 21 April 2020 (UTC)

But perhaps a Tag:advertising=billboard... Jidanni (talk) 14:08, 21 April 2020 (UTC)

Multiple features for multiple signs

This article recommends mapping a sign assembly (multiple signs on a single post or gantry) as a single node with multiple values in traffic_sign=*. In my opinion, this recommendation violates the "One feature, one OSM element" principle. I think the article should at least allow for traffic signs to be mapped individually as separate nodes.

One practical problem with the single-node approach is that it requires mappers to stuff any details about the signs ("values") in square brackets, because otherwise, secondary tags like maxweight:conditional=* could be difficult to associate with the right sign in the list of values. But the square bracket syntax is inadequate for a great many of the signs in the United States, because the MUTCD tends to specify more verbose layouts than the Vienna Convention. If multiple parts of a given sign can vary, what separates the values? Perhaps a comma, but what if a value itself contains a comma? What order should the values appear in, especially if the most prominent value on the sign sits below some fine print? I'm not convinced that this syntax is any more convenient for data consumers than secondary tags.

• 

  A standard distance sign in California with a route shield embedded in the second row.

• 

  A standard street sign in Ohio. Street-level imagery may be too grainy to discern the text at the top, even if the text below is apparent.
  traffic_sign=US:OH:D3-H6b[Franklin County,Patterson Road]?

• 

  A standard weight restriction sign in Ohio. Every number and the number of rows can vary.
  traffic_sign=US:OH:R12-H5[2,10,3,14,…]?

• 

  A typical logo sign. Should the values be human-readable (corresponding to brand=*) or machine-readable (brand:wikidata=*)?
  traffic_sign=US:OH:E9-H1[Food,44,Blimpie,IHOP,KFC,McDonald's,Subway,Romano's Macaroni Grill]?

• 

  Many municipalities use nonstandard parking signs. Without a standard code, an unlabeled value would be useless for either display or interpretation.
  traffic_sign=parking:condition[2,8,9,Monday,Saturday,C]?

These traffic_sign=* values can get pretty long, so a combination of just a few of these signs in a single assembly can potentially run over the 255-character limit imposed by the OSM API. I also find it problematic that two signs arranged vertically would be mapped as a single node, while two identical signs arranged horizontally would be mapped as two nodes with simpler traffic_sign=* values.

In part because of these problems, I've been mapping sign assemblies as separate but coincident nodes, using layer=* to distinguish their vertical positions. (Anyone who needs to edit these coincident nodes can lasso-select them in iD and select the node from a list.) This enables me to use secondary tags to express the values of complex signs semantically.

A typical stop sign and street sign assembly in the U.S.

Besides, some sign assemblies can only be mapped as separate nodes because the signs face in different directions. The vast majority of street name signs and one-way signs in the U.S. are mounted on the same pole as a stop sign, with exactly the same center as the stop sign but pointing in a different direction. Incidentally, this is also a situation where the signs must be mapped at the location of the sign rather than as a node on the affected ways, because each sign affects a different way at the intersection. (Street name signs are the main reason I map traffic signs; I use these nodes to clarify an unexpected or inconsistent road name.)

 – Minh Nguyễn ^💬 09:14, 11 July 2021 (UTC)

In my mind, the sign meanings could be directly tagged as eg traffic_sign:*=*. This can either supplement, or simplify traffic_sign=* to only be the sign codes. So for your 2nd example, traffic_sign:name=Patterson Road (don't really know how to tag "Franklin County"). This allows you to do multi-value traffic_sign:brand=Blimpie;IHOP;KFC,McDonald's;Subway;Romano's Macaroni Grill (also avoids choosing between brand=* and brand:wikidata=*), and complicated combinations of messages or conditions in your other examples. ---- Kovposch (talk) 06:08, 13 July 2021 (UTC)

Viz for your 3rd example (since I can copy it): traffic_sign:maxweight=10 st + traffic_sign:maxweight:hgv:conditional=10 st @ (axles=2); 14 st @ (axles=3); 18 st @ (axles=4); 22 st @ (axles=5); 24 st @ (axles>=6) + traffic_sign:maxweight:hgv_articulated=40 st. ---- Kovposch (talk) 06:18, 13 July 2021 (UTC)

@Kovposch: This article already allows the details to be tagged in secondary keys, without the traffic_sign=* namespace, e.g., traffic_sign=US:OH:D3-H6b name=Patterson Road operator=Franklin County. JOSM plugins support this style, and I don't see a problem with it. But this article only presents secondary keys as one option, with the other option being the square bracket notation in traffic_sign=* itself. Here, I'm simultaneously arguing against the square bracket notation and the comma/semicolon-delimited syntax that presupposes it. – Minh Nguyễn ^💬 19:08, 13 July 2021 (UTC)

I'm using the non-prefixed format now. For completeness, I have some doubts over non-namepsaced tags. Like if you put brand=* on a traffic_sign=* (direction signs also interfaces with destination:*=*), or access=* tags on a man_made=gantry + traffic_sign=* (if that's how it should be done), the semantics don't entirely make sense. I disagree the semicolon-delimited multi-value is a violation of One Feature One Object, or entirely flawed. This is about iterative refinement. Combineing them together can also be less fragmented than splitting them. Sure, individual objects allow their vertical arrangement to be shown with layer=*, and the horizontal orientation with direction=* as you raised here. This is a amazing detail added. But I'm interested to know how do you relate signs about conditions and modes together when they are separated. Do you leave this to the spatial coordinates, or the roads affected? The grouping of those signs may be more arbitrary in that case. ---- Kovposch (talk) 06:17, 14 July 2021 (UTC)

man_made=gantry and traffic_sign=* should be mutually exclusive: the traffic sign node would be a vertex on the gantry way. I'm not too concerned about the lack of namespacing, as long as the keys used for iterative refinement are always used that way and not sometimes as primary keys. It seems that's the general feeling in software that supports traffic signs so far. But a namespace would be very important if mapping traffic signs as nodes along the roadway, which is why I never do that anymore. (For example, if you encounter a near an intersection and map that as a traffic_sign=R5-6,M6-1R bicycle=no as a node on the adjacent roadway, OSRM will avoid sending bikes down the adjacent roadway, not the cross street that the sign actually points toward.)

There seems to be a distinction between commas and semicolons, so that commas can denote very closely related signs, such as the state route shield embedded in the guide sign above. That doesn't seem quite as problematic to me as completely unrelated signs. My expectation is that a data consumer would have to do some linear referencing anyways in order to consume traffic sign nodes mapped independently of the affected roadways. So if that's feasible, grouping signs based on coincident nodes shouldn't be much more of a challenge. But I recognize it's all more difficult than a node on the affected roadway for some use cases. The public transport v2 schema solved this problem with public_transport=stop_position nodes joined to highway=bus_stop nodes via public_transport=stop_area relations, but insisting on a similar solution for traffic signs (outside of exceptional cases perhaps) would probably dampen excitement over traffic sign mapping...

 – Minh Nguyễn ^💬 18:51, 14 July 2021 (UTC)

Is it invalid to map traffic_sign=* as a for the sign itself? That's why I want to ask whether man_made=gantry + traffic_sign=* could be nice enough for single signs mounted on a gantry. This is already done on advertising=* in some numbers. ---- Kovposch (talk) 04:23, 15 July 2021 (UTC)

I don't know that that combination is invalid, given that nothing has been formalized through a vote. But existing usage of the man_made=gantry traffic_sign=* combination is minuscule compared to overall man_made=gantry or traffic_sign=* usage. Some of it is better expressed as gantry:type=*. This article does currently suggest the combination for traffic_sign=variable_message specifically, but for sign types that don't usually extend across the entire roadway, it's pretty crude compared to separate features. If there are multiple signs on the gantry, or traffic signals plus signs, this dual tagging style omits information about two different dimensions. – Minh Nguyễn ^💬 21:23, 17 July 2021 (UTC)

A standard street name sign (traffic_sign=D3-1) can be in any of four colors, and the color of the sign may carry some meaning (such as the type of road or its location in a historic district). The color isn't a "value" per se, and traffic_sign=D3-1[Main Street];R1-1 colour=brown;red seems needlessly complex compared to separate nodes. – Minh Nguyễn ^💬 20:56, 12 July 2021 (UTC)

At least one mapper has attempted to reconcile the single-node style with the need to indicate different directions on the same pole. The result is reinventing the concept of a node... inside a node. I would assert that traffic_sign=US:D3-1("WESTPORT", direction=190);US:D3-1("TERRACE", direction=100);US:R6-1(right, direction=100) is no improvement over mapping three different nodes. – Minh Nguyễn ^💬 11:24, 15 November 2023 (UTC)

street name signs

Give instructions if for some reason one would like to map a street name sign's location.. Jidanni (talk) 19:43, 26 May 2023 (UTC)

It tends towards being out-of-scope. traffic_sign=* is for legal traffic signs. Often street name sign is controlled by postal or land authority, so it may not even be a standard informatory sign.
At most at the hundreds. Others at tens.

traffic_sign=street_name_sign

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

More details at taginfo

More details at taginfo

traffic_sign=street_name

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

More details at taginfo

More details at taginfo

traffic_sign=street_names

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

More details at taginfo

More details at taginfo

traffic_sign=name

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

More details at taginfo

More details at taginfo

traffic_sign=highway_name

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

More details at taginfo

More details at taginfo

traffic_sign=memorial_road_name

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

More details at taginfo

More details at taginfo

traffic_sign=road_name

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

More details at taginfo

More details at taginfo

--- Kovposch (talk) 09:40, 27 May 2023 (UTC)

@Kovposch: Street name signs may not be traffic signs everywhere, but they are standard destination signs in some countries. Virtually all street name signs in the U.S. (apart from a few historical signs in places like the French Quarter of New Orleans) would be traffic_sign=US:D3-1, US:D3-1a, or a similar state-specific code. – Minh Nguyễn ^💬 10:37, 15 November 2023 (UTC)

Anyway, sure, most street name signs are no big deal, and not worth mapping. But then there are those

• In the middle of nowhere, with no cross street even: very valuable as a landmark.
• Ones that are very special in certain ways, and may even be featured in photographs... commons:Category:Street signs. Jidanni (talk) 20:50, 30 August 2023 (UTC)