You have reason but…
In OSM there is one approved proposal with category and human readable values and around other 20 human readable values more (maxspeed,city_limit most used). What can we do with them?
For text editors, for completers across countries, for newbies… human readable (or writable text) would be easier to attach to OSM information. Then, one experienced mapper could translate this data to codes.
With traffic signs is the same. You can have a mapper that recognize a stop…from his elemental education traffic lesson or a mapper who has upload to wikimedia commons all the MUTCD traffic signs in SVG format.
There are two “worlds”. This differents target for mappers should exist in OSM, the newbie (basic) or the experienced advanced (expert). Each tag goes for them. And when one exists probably is not need to delete the second. If something is obsolete mapper who change one can change the other.
Imagine a tree in a street, the tree (mapped in OSM, of course 
) is ill and finally death. City council substitute the tree with other species tree younger and better, adapted to climate changing. Should not map trees in cities because city councils can change them and the information in the map could be obsolete?
Lookup table would be good to OSM wiki, we can evolution the existing tables. But not all mappers in the street would use additional equipment like lookup tables or compass or the stars at night to map, probably.
To the extent that these tags are applied and interpreted differently from region to region, what is the advantage over codes that explicitly differ from region to region?
I am not opposing codes, but they shouldn’t be the only way. They are either for nerds or for programmers or programming nerds. If you use presets, they are likely abstracted away from you, but if you write your tags, speaking values are much easier (unless you are a sign nerd and know all the codes for the signs you intend tagging). Many restriction traffic signs are very easy to understand, e.g. traffic_sign=maxheight, or maxspeed, or hazard signs. I’d prefer someone to add a maxspeed traffic sign with a typo in the tag than them not adding anything at all because it is too complicated to look up the sign code.
You would surprised of what information can afford a little Spaniard…
It’s a joke…or not…
or
or
You can find all of that here > DGT - Educación Vial para la infancia
In Spain there’s about 27.7 million with driver license (2022). In Germany there’s 57 millions (2019) . I think it is not minor percentage to know something about traffic signs.
More stats at https://www.reddit.com/r/AskEurope/comments/ndu340/what_percentage_of_your_country_poplation_has_a/?sort=old
We need the possibility of map both of them, because we don’t know who would map this traffic sign and from: Camera driver from Mapillary? Somebody consulting a data set of Official Opendata? From a motard? From a student of the zone that likes PokémonGo and try to make better the road next to the dam?
[quote=“mueschel, post:19, topic:111821”]
“ES:P26” is a sign for a hazard.
Correct, and because you have interest in that topic you know it, probably. By the way , how many German mappers knows that? Better: How many mappers knows that?
I don’t agree with that. OSM mainly is done by people, not by software, so people have to have the possibility to do OSM on its way with their limited knowledge (we can’t be specialist in all, I don’t know anything specific about trees, probably I can map only the node where I see a tree, and with Mapcomplete, complete some words and better in my language, please.)
Each color would be a different tag but now that you mention it…
Kendzi3D from JOSM reconstructs it very well I think…
Well, as I wrote earlier, I think trying to come up with a descriptive nomenclature for the tagging of every single possible traffic sign is a fool’s errand. How many signs are as (nearly) universal as the stop sign? A lot more than the list at Key:traffic_sign - OpenStreetMap Wiki. Turn restrictions, keep right/left and speed limits are pretty straightforward, I think.
How do we draw the line at which should be tagged with just a keyword vs. just an alphanumeric code? I think we draw the line at which ones are most universally understood to mean essentially the same thing. Stop and yield signs are the obvious ones we already tag with a simple descriptive keyword, but it doesn’t take a rocket surgeon to figure out that (e.g.) 
, 
and 
each mean the same thing.
I think we’re actually on precisely the same page: a descriptive keyword can serve as a “rough draft”, or “placeholder” if you will that would serve the purposes of… probably 90% or more of use cases, and if for whatever reason somebody wants/needs the actual appearance of the sign to be specified in detail, they could overwrite with the alphanumeric code to get that desired specificity.
I can see a lot of value in having the descriptive tagging in place for many more of the world’s most popular signage. Especially in that it’ll make it much easier for the average ignoramus mapper (e.g. me ), who doesn’t know the alphanumeric codes of the MUTCDC (nor any other national/international/sub-national standard) cover to cover, to put some signs on the map in the first place.
I’d like to quote a post you made in Large scale change of traffic_sign to traffic_sign:id, because I think it makes a good point:
Going back to the comment about a lookup table, you wrote:
I actually meant the complete opposite: I didn’t mean “requiring a lookup table to convert codes to keywords while mapping” (although frankly that is the status quo, when it comes to mappers entering the “codes” in the traffic_sign=* tag in the first place), I meant that it’s easier for mappers to enter a “keyword” and data users can reference a lookup table to spit the “code” out for them, if they need it.
I had envisioned something like a lookup table that would parse a descriptive tag, let’s say for the sake of argument a hypothetical “traffic:sign=one_way_right”, that could cross-reference the administrative boundary within which it’s found, and in the case of the US would spit out 
.
However, you brought up a huge limitation: what do you do when you have two different sign designs that mean the same thing and are used concurrently in the same jurisdictions? I was going there with the example of the stop signs earlier: for me it doesn’t make much difference if it’s a red octagon with white lettering saying “STOP”, “STOP / ARRÊT” and “AST’A NITŁ’A”; all of which I can find within about a fifteen minute drive of my house. I admittedly was thinking only of routing uses, wherein… who cares what the sign says? It’s a red octagon with white lettering: it’s a stop sign.
The only way to correct/confirm a sign is by looking at it (either in person, or via street view data we are allowed to use).
The problem with making the “human readable” values have the same official status as the codes (by putting them in a different key) is that they are fundamentally more ambiguous – so a data user (not a mapper) trying to interpret a node with both has a big problem.
I don’t have a problem (although I don’t think it’s all that useful) with making up and documenting on the wiki additional “human readable” values for the traffic_sign key. I think they are perfectly fine as “rough draft” values that mappers can use if they don’t know the correct sign code. But such values should be seen as TODOs, that a mapper who does know the sign code should go thru, one at a time, confirming them (either in person or via acceptable street view imagery), and updating them to the actual sign codes.
For adding signs where there isn’t a sign code (or you aren’t sure of a good “human readable” value to put), I recommend (and I think it would be good to add to the wiki page if it isn’t already there) this set of tags:
traffic_sign=yes
inscription=[the text on the sign]
note=[a description of the graphical elements of the sign, as needed]
That should provide plenty of detail for a later mapper to track down a sign code (if it exists), and/or confirm that the described sign is still present, and justifies the other tags on the highway way that describe the effects of the sign (if any).
How do we draw the line at which should be tagged with just a keyword vs. just an alphanumeric code?
IMHO there is no line to be drawn, mappers will use any of the alternatives to describe the signs and data users should evaluate all alternative methods.
That is because it is a very basic example that just fits to the default “one sign on one post on the right side of a single road” and defaults work quite well. Imagine there being a second highway nearby, additional signs on the same post… and it will need to make assumptions that are not backed up by the tagging.
This is your very own assumption. Please show me any prove what the advantage might be to have both tags on the same object.
I also never said that codes are the only way to map traffic signs. I’m perfectly fine with using simple names in simple cases - but there is no need to use both at the same time.
Nobody asks any mapper to remember and type this specific code. That’s up to the editor software to provide a user friendly interface.
I fully agree. It’s not a very helpful tag and I would rather omit it.
It might be helpful in some cases, such as this great placement of a maxspeed sign just on the right side of a road… Mapillary… which might be properly ignored if it had a side=left tag.
In my opinion separate both concepts in tags would be easier. The existence of both tags would not to be mandatory per se but the possibility of tagging one or/and another yes (so in a proposal would exist both tags I think).
I think it is a good solution. Also would be easy detect which we have in a place with a simple overpass query.
OSM is for people also. And it is probably people who vote parties and situations that create the Stop/Arrêt want to map this traffic sign as is. Codes can help us in these situations.
If the node has the code there’s no possibility of error, code is one, so I don’t think you can be mistaken by the existence of human readable values if also exists the code.
I’m agree with the formula traffic_sign=yes to map unspecifically the traffic sign and some way to get the other information to finish the mapping of this unspecified traffic sign.
Sorry but it is not one traffic sign. There are two: ES:P26 and ES:S800 , and I assure you it works in other direction and in other side. If you put other highway next to this…it also works.
He can map
You can map
But then next lines…
So, is it useful or not? Maybe in other discussion.
Tagging both seems inherently very susceptible to contradictory results.
But the possibility (not the obligation) should exists, and separate the two concepts make easier this operation before we have more approved proposals with categories or more people that gets into the fantastic world of international codes. Leave half of the mappers outside scheme with or without advance knowledge is not better option.
By the way let’s see other common elements in a street:
Tag:natural=tree - OpenStreetMap Wiki.
Can you assure all the trees we have in the map are the mapped?
Tag:highway=street_lamp - OpenStreetMap Wiki
Can you assure all the streets lamps we have in the map are the mapped?
or other schemes of something similar
Tag:railway=signal - OpenStreetMap Wiki (with different schemes for each country).
Someone applied the possibility of contradictory results or obsolete results in all these mappings?
I don’t know what else we should tell you. There is a current scheme that allows for both ways of tagging. Any mapper can decide if they want to use a simple name or a traffic sign code. Insisting on that we “Leave half of the mappers outside scheme” is just not true.
Sorry but this it is what I think. Yes, this a discussion and I express my opinions without any intention of offend anybody thinking in the opposite way. And my opinion (because it is what I’m seeing and feeling) is that. Due to reason of sharing key there are difficulties to implement both (because one probably will “win” the other and more mappers will not map this because they will not find easily how to do it). By the way, I can understand the World does not feel like me, it is not an offense for me.
The discussion about give way and stop will be more funny. We’ll see.
Well, let’s go in the other way:
Is anybody in disposition to make bigger Verkehrszeichen Tool - OpenStreetMap ? We need it for all the traffic signs in Germany , and…for other countries in the World . Thanks. I demand it for Spain.
Also we can do the same with OSM Lane Visualizer . Then there’s no problem with the verbose values. My offer still holds. And we can develop other countries code.
Possibility of identify nodes instead of ways · Issue #6 · mueschel/OsmLaneVisualizer · GitHub
Would be a good option also to make bigger iD and apply all the tags existing to traffic signs nowadays.
In this case I don’t know how to make it bigger but someone here would do it.
For Streetcomplete would be good option to make a mission with the codes to translate verbose values or to show traffic signs, as there are one of the massive elements in a streets only behind of trees or street lamps.
But the traffic signs itself.
And I have to congratulate German community for this
https://wiki.openstreetmap.org/wiki/DE:Verkehrszeichen_in_Deutschland
All other countries should take in consideration to do this themselves as someone suggest here with lookup table.
In JOSM I have done many years ago presets, styles, and models for kendzi3D for this question. Would be interesting to help me to adjust or evolution to assure the possibility of mapping traffic signs accordingly.
Also josm-plugins/roadsigns at master · JOSM/josm-plugins · GitHub should be developed more.
For 3D Kendzi3D works well but know it is Kendzi3D who has problems with java I understand.
Other 3D would be Streets.gl so we have to develop this part
I talk seriously, not ironically.
Probably new mappers, with these tools or similar will not have any problem to map traffic signs. In other post I have calculate for about 30000 different values. And extrapolating operations there’s about 300 verbose values more or less.
I talk seriously, not ironically.
Probably new mappers, with these tools or similar will not have any problem to map traffic signs. In other post I have calculate for about 30000 different values. And extrapolating operations there’s about 300 verbose values more or less.
Although I have been advocating mapping maxspeed traffic signs for a decade or so (because they are helpful for mapping maxspeed precisely), I don’t think there is much use in mapping most of the traffic signs, and I have a feeling that most of our fellow mappers feel the same, this is why we have mapped so few traffic signs in the past 20 years (for example we have mapped more peaks than traffic signs, and 4 times more wetlands, 30 times more trees).
Most of the signs are almost useless when mapped as signs even for other mappers, and those that are helpful are so for other mappers and QA, but not for actual user applications like routing. Every oneway street implies at least 2 signs, but typically much more because of turn restrictions and intermediate signs, we have mapped 22 million times oneway=yes and only 860.000 traffic signs in total (on nodes, all kinds of signs).
If you like the exercise of creating a template for 30.000 different traffic signs, just do it, but IMHO it would not be a very significant step for our endeavor to make the best map.
This is only true for someone fluent in OSMian English or at least British English. For everyone else, these keywords only seem human-readable but are actually a jumble of unpredictable rules. Oh, the sign that says “No Passing Zone” is overtaking, not passing? What is an hgv or a queue? What’s the right tag for a “Begin Freeway” sign?
Of course, we cope with this reality for many tagging schemes out of necessity. For example, we’ve developed a custom set of keywords for cuisines, some of which have unintuitive definitions (e.g., chicken specifically for fried chicken). But if there were already standard cuisine classification schemes used by restaurants the world over, as there are with signs, maybe we would try to align with those schemes instead.
So would I. But this is already the status quo, quite different than expecting features to be tagged with overtaking:hgv even when the code is known or provided by the editor. That’s the implication if we reserve one key for codes and another key for keywords, because then there’s nothing preventing both from being dual-tagged on the same feature.
Ah, then indeed we are on the same page. iD is already capable of suggesting the right ALDI brand when you search for “aldi”, depending on the country you’re mapping in. It will find “PFK” (brand:wikidata=Q524757) if you search for “kentucky fried chicken” in French-speaking Québec. And of course it’ll find the amenity=fast_food cuisine=chicken preset if you search for “poulet” while using the French localization.
I think in these discussions, we tend to forget that not everyone maps in English, so a British English–based tagging scheme might as well be in alphanumeric gibberish. But as long as an editor can accommodate the mapper’s language, it can certainly accommodate differences in terminology within that language. We already have this functionality today with most tagging schemes, even brands to some extent, but not for traffic signs due to unresolved questions like the one posed by this thread.
To the extent that the applicable sign standard considers them to be different signs, an editor can turn up multiple presets when you search for the word “stop”. But if all are considered the same sign, just with different legends, then inscription=STOP / ARRÊT would get the point across, or perhaps language:en=yes language:fr=yes to be more structured.
As to who cares: maybe not a navigation system, but Tsuutʼina language advocates may appreciate representation of that language via language:srs=yes tags on traffic signs and other features.
This is indeed my usual reason for micromapping traffic signs – to affirm some name that I applied to a roadway, or the starting point of some maxspeed, or the maxweight of a bridge (because those signs are usually posted far away from the bridge). If you were to query for traffic signs I’ve mapped, you’d get a sneak preview of zingers in my future forum posts, but little else. On the other hand, I recognize that more comprehensively mapping traffic signs would facilitate more interesting use cases, such as realistic street furniture in 3D renderers and the sort of ADAS features that proprietary vendors consider their “secret sauce”.
I’ve driven cars equipped with camera-based traffic sign recognition displays. This feature is useful for letting you “replay” the signs along the road that you may have missed. Unfortunately, I’ve found the sign repertoire to be quite limited. The car can detect the most common kind of speed limit sign, but so could an OSM-based GPS navigation application without the fancy sensors. Yet the car can’t reliably detect speed limit signs in school zones, an admittedly rarer sign that’s less machine-readable. If the system can’t detect that school zone sign, then I can’t trust that the normal signs it detects are still relevant by the time I glance down to see them. This undermines the feature’s core safety benefit. If we can increase coverage of traffic signs in OSM to some degree, vendors of TSR systems might notice and use OSM data to calibrate their output.