I still don’t think you’re going to capture every possible sign with a descriptive tagging scheme.
why shouldn’t it? Seems like a big task, but completely doable, and with not so many values the major part of signs can possibly be covered, while the rest can be added iteratively later on.
Our decades-long ordeals with highway classification, place classification, protected area classification, vehicle access classification, and crossing classification should serve as a stark warning against developing another ad hoc classification scheme for something we already know to be subject to incompatible regional schemes in the real world.
I don’t see issues with these topics that would be unsurmountable, if there are distinctions you would like to make in these fields that cannot be captured with the currently established tags, the scheme should be extended or regional conventions agreed upon. If the scheme can perfectly capture all nuances in some regions but not in others, it means it should be worked on in these latter regions.
Regarding place classification, I believe there is some confusion between administrative classification (which also is done with boundary mapping) and places as geographic names and entities.
traffic_sign=ES:P26,ES:S800[1500]plus aside=rightanddirection=NEtag contains all the information you need in less than half the number of tags.
I don’t think “side=right” is a good tag for a node, even less if it is at the end of at least two different ways, as would typically be the case for signs, given that they often indicate a changing road property. Just map the node at the sign position and you don’t need a tag for the position.
Nothing is insurmountable, but do we really want to kick off years of endless debate about what counts as a traffic_sign=access? Historically, OSM’s ad hoc classification schemes haven’t aged well and have tended to sprout multiple competing schemes (e.g., crossings). 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?
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?