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)

Just noticed this question now .. a while back I had used information=guidepost to sort out naming of a series of named forest roads (most with no landmarks). Signs had 1-3 names at intersections. It had taken us quite a while to name all of them correctly. 99 tabazan (talk) 15:12, 29 October 2026 (UTC)

Adding further differentiation to multiple signs sharing the same National designation value?

While Mapping a simple sign in Japan, Left Turn Only ( JA:311-B ), I discovered signs 311-A (straight + 1 turn only) and 311-B (turn only) are undifferentiated as to what the turn direction is! left or right, they use the same code, but they note in the description that the different signs are left or right ( 左 or 右 ). Two different signs - one identifying code! What to do?

the sign: https://www.openstreetmap.org/node/14330057228/

What would be a good method to add the left or right value? appending :left ? [left] ? Currently, I am adding [left] to the sign as if I am adding a data value, but this feels wrong. I think there should be some kind of appended cardinal direction and motion direction standard suffix ( -N -S -E -W -F -B -L -R ) to further differentiate sign types when a single value is used for multiple different signs like this. I'm sure this issue affects other signs in other countries, so having these simple values ready to differentiate ambiguous sign values might be useful in the future. To me, this is to choose the correct sign image code, not to define the data value the sign reflects (speed, name, destination, length). If the "left" or "right" state of these ambiguous ISO values is considered a data value to be appended with [ X ] or similar manner, then this needs to be documented for this tag - but perhaps there is a better way to go about this I am unfamiliar with - or the offending signs need to have the OSM values changed or something. Until it is decided, I will be adding the direction as a value, [left] and [right] with the sign code. Javbw (talk) 01:57, 29 October 2026 (UTC)

No, this is already mentioned as traffic_sign=JA:311-A[left] Key:traffic_sign#Traffic_sign_IDs Kovposch (talk) 07:08, 29 October 2026 (UTC)

Nowhere in that section does it say [left] that I can see . In tagging examples, none illustrate (that I saw, maybe I missed it) any sign with a restriction or turn value that has [left] or [right] in the [value].

Does the [value] affect the choice of the sign ID? I thought only the only tagging data that would affect the sign choice is the “JA:311-B” - and the [value] information be for data INSIDE the chosen sign, not a determining factor on *which* sign to use. Skimming, there is no mention of how to resolve this ambiguity, besides preferring the national sign IDs over generic sign IDs. I know people who are smarter than me wrote this sign handling system, but the documentation is missing any mention of relative directions. Some signs I have seen have had extra arrows taped on - is there also [slight left] and [sharp left] ?

is there any *actual* example on the wiki to document using [left] and [right] as values? Maybe I skimmed it too fast, but I do not see anything documenting this besides your reply to me just now (referencing a section that doesn’t contain any specific documentation for [left] and [right])

Does this happen with other countries, where multiple sign variants use the same ID number for several directional signs, and then depend on the [value] to determine the proper one? Even if this is just an edge case, the values of adding [left] and [right] to signs as an option for data values OR as an option resolve sign ID ambiguity should documented in the wiki somewhere. Currently, I don’t think it is (unless I am stupid, which I might be). Javbw (talk) 09:09, 29 October 2026 (UTC)

"Where the traffic sign requires a numeric or textual value, you can supply it after the ID using brackets" and the example traffic_sign=NL:H01d[Merum][Maerem][Roermond];A0150

Please search https://taginfo.openstreetmap.org/keys/traffic_sign#values Kovposch (talk) 11:27, 29 October 2026 (UTC)

Taginfo clearly illustrates this problem, if you look at the data.

I am not trying to append any numerical or text values to my signs, I am trying to differentiate between two different versions of the sign that confusingly share the same ID in Japan - a problem that doesn't seem to exist in other countries, but seems to exist in Japan. And Japan has basically zero road signs mapped (40 total in the country using JA:*), so maybe this issue hasn't come up before.

Why do I say it is a problem that doesn't seem to exist elsewhere? Because [left] is almost completely unused tag value - and most of the tags that use it for a value for are mismapped!

There are close to a million uses for values for traffic_sign in Taginfo.

in Tag info, "Left" has only 241 uses in it's highest value: FL:413[left] , second highest is FL:551[left], third highest has 66 uses and dribbles off to single digits.

The two signs that make up the bulk of the [left] tags shouldn't be mapped that way, if I am reading the wiki properly because the sign codes are now obsolete (discontinued in 2020), and the turn direction options are now part of their designation ID.

NL:413[left] should be tagged as NL:D1.5 (left turn only)

NL:551[left] should be tagged as NL:D1.2 (one-way arrow pointing left,) (again I think I am reading the wiki and the tags correctly).

To me, almost all the other countries correctly differentiate between the different types and directions of signs.

https://commons.wikimedia.org/wiki/Road_signs_in_Finland

They have three different codes for three different variants of left turn signs.

Japan seems to conflate the single left and right turn only options because of poor documentation standards (If I understand this correctly).

That is the issue I am trying to address.

Lets say I'm totally wrong, and I'm not following the spirit of this tag nor reading the documentation correctly.

Let's say appending [left] and [right] is the correct solution to this problem, as you suggested.

- Then the documentation needs to be updated to actually document the [left] and [right] tags as data values.Again, there is NO MENTION of left or right in this tag's documentation. I assume because it is barely used by anyone.

- in what cases is it appropriate, because for most taggers tagging a "left turn only" in the rest of the world, appending [left] is unnecessary because the signs they are tagging in their country are properly documented.

Please document the uses of [left] and [right] (and what about [slight left] and [sharp left]? those are also common sign values as well) it and give examples of where it is and ISN'T needed! Javbw (talk) 22:24, 30 October 2026 (UTC)

Currently, there doesn't seem to be a defined approach for cases where the difference is not a string or number. You could suggest and document an extension to the syntax. 99 tabazan (talk) 09:04, 31 October 2026 (UTC)

I don't see the problem or need to have this distinction, and the necessity to mention every possibility in the square bracket. If you want, do it yourself. This is a wiki. Kovposch (talk) 17:00, 31 October 2026 (UTC)

"do it yourself, this is a wiki" is not the purpose of the OSM wiki.

If this was "just a wiki", I would just do it myself. But all of these tag syntax and parsing issues are above my pay grade. I know enough to know there is a parsing/data problem brewing here, so I am bringing it to the attention of the community - and you responded to my post about it, so I assumed you had some involvement in the creation or implementation of this tag. Apparently not.

Perhaps my use of "document" is wrong - I assume the people that understand how this data is parsed need to come to consensus and then document that consensus on how to deal with this odd data ambiguity. It seems you and I are not part of this. I know I am not. That is why I am here in the discussion page raising the issue to these people!

I have sunk months into making and crafting tags to extend OSM only to get voted down ( Proposal:Civic admin ) - I would just "do it myself" and invent whatever values I want and and modify tags to my whims but the wiki is meant to document the existing tags and approved values, not to have someone come in and invent syntax and values for the tags and insert them into the wiki without consensus - Which is why I am in here in the discussion page to raise this data issue I spotted, and wonder what a possible solution is to the people who know what to do.

So "do it yourself. This is a Wiki" is not only dismissive, but factually wrong, and against the purpose of the wiki itself as I understand it.

If you aren't one of the people who are involved in the tag implementation nor interested in finding and correcting problems in tags, why respond to me to begin with? Javbw (talk) 03:03, 2 November 2026 (UTC)

tldr: Any tags you like might help ? 99 tabazan (talk) 13:05, 2 November 2026 (UTC)

I do invent tag values, such as surface=landscaping_paper to tag the weed-blocking and rain-blocking paper common to use on roadside embankments and medians here in in Japan. I'd never seen it before I moved here, its a laminated plastic or tarpaper-like sheeting stapled to the ground that lasts for a decade or two, and is not temporary, but there was no value for it, so I made one and use it.

But when tags start having detailed syntax, like business hours, or fee, or relations metadata, I usually don't mess with altering those schema because I do not know how the data implementation people are reading or parsing this metadata. And I don't feel comfortable making up tags and putting them directly into the wiki as a proper solution.

Since I see an abmiguity the Japanese data ID set, I wonder what should be done, since it hasn't been encountered yet, I think - this kind of specific, detailed, and external data dependent scheme doesn't seem like something where I should just make up data rules - so here I am in the discussion page, pointing it out.

Thanks for the suggestion page, though. Javbw (talk) 13:37, 2 November 2026 (UTC)

What's "people who are involved in the tag implementation nor interested in finding and correcting problems in tags" that you are looking for? There's no such job. Everyone can do it. And why does one need "some involvement in the creation or implementation of this tag"? Anyone can reply to you, which wasn't useless as you have only more detailedly explained the problems you find after my comment. Why does not seeing this as a problem mean I'm not "one of the people" "interested"? You seemed to be only looking for people agreeing with you, therefore those disagreeing shouldn't comment. I find you being "dismissive" by claiming the wiki's "be bold" motto as "factually wrong, and against the purpose".

Again, what's "some involvement"? I have use some road_marking=*[left] and road_marking=*[right] in my country. Does that qualify? When does not having an id become a problem? I don't understand your criteria, and distinction you see compared with other signs.

What's "existing tags"? The wiki is not limited to "approved" ones. The Netherlands ones exists in the database, and were correct before they are assigned an individual number. The wiki can document existing uses and potential problems, including debated or outdated ones (as of now). It's not limited to consensus only, as commonly all sides of a controversy is documented.

You are confusing documentation with proposals. Your proposals' success or not are unrelated to wiki editing. Kovposch (talk) 16:18, 2 November 2026 (UTC)

Thanks for asking! I'm fine with syntaxes like traffic_sign=JA:311-A-left, traffic_sign=JA:311-A_left, traffic_sign=JA:311-A:left, traffic_sign=JA:311-A-l, traffic_sign=JA:311-A_l, etc., but would avoid square brackets "[" and "]" like traffic_sign=JA:311-A[left] for two reasons: a) As you pointed out, square brackets are intended for additional information displayed on the sign, so using them for graphical variants mixes sign content with visual characteristics. b) Square brackets cause OSM Wiki documentation issues: Any tags you like recommends avoiding them, and MediaWiki does not allow them in page titles, see: [3] and see the invalid page title traffic_sign=JA:311-B[left]. --MalgiK (talk) 21:35, 2 November 2026 (UTC)

Problems with square brackets (Map and Taginfo)

There was some discussion about the problems with square brackets in general, see Talk:Wiki#Key:traffic_sign values with "[" and ""] . 99 tabazan (talk) 09:05, 31 October 2026 (UTC)