There are a few assumptions in here that I’d like to unpack. I’m not sure how rigorously you mean “the same”. Pedantically, there are only a few types of traffic signs that come close to being universal. Stop and yield come to mind, but even they aren’t fully universal. But if you mean that two countries can use visually different signs that share the same function, that much is true. How then, should we handle two visually different signs in the same country that share the same function, such as versus ? Mapillary makes this distinction because the detection model necessarily differs, but a router couldn’t care less.
Plenty of traffic signs can’t reasonably be tagged as nodes on a roadway. Earlier, you correctly pointed out that some countries assign traffic sign codes to road markings. The U.S. isn’t one of those countries, but regardless, I think the existing road_marking=* key, flawed as it is, would work better for those traffic signs, especially since they can occur longitudinally across a roadway:
On the other hand, the U.S. national standard does number signs along sidewalks, hiking trails, and bike trails, while some states number anything that a highway department might need to manufacture a sign for, whether or not it belongs on a roadway:
Personally I don’t think these discrepancies are a problem at all. Use the country-prefixed sign ID and call it a day. But if you want to promote a universal ontology for traffic signs, these are edge cases you’ll need to deal with.
I’m very much in favor of establishing generic catch-all values of traffic_sign=* that can be used whenever there’s no sign ID. One of the most commonly tagged signs in the U.S. is the neighborhood watch sign, which the sign standards intentionally omit as being irrelevant to traffic safety. But this sign matters a lot in national discourse about social issues.
Somewhat less common are warning and regulatory, corresponding to official MUTCD sign categories. Our regulatory category includes what the Vienna Convention would call mandatory or prohibitory, as well as some information and complementary signs.
But one of the core questions surrounding your proposed scheme is whether we need to tag these categories even when the sign ID is known – as it would be when using Mapillary’s sign detections in an editor. I’m still not sure if you’ve explained why mappers would need to do all this extra work. Is it so that someone can easily write an Overpass query for all the “keep right” signs anywhere in the world, from memory, without consulting a reference page on the wiki?
If you mean that we should reuse highway=*, as in highway=stop for the location of a stop sign, then this is a deal-breaker for me and some others who have commented in this thread. One of the reasons is that a supplementary plaque (complementary sign) can modify the location at which a sign takes effect in all sorts of interesting ways. It is far too late to the change the meaning of tags like highway=give_way so that data consumers need to consider secondary tags to determine where it takes effect.
A traffic sign has the same utility here and in China. Sorry for my bad English. Probably you will assume we are so different…but with different codes, with different compositions there are more or less the same. If you compare all Vienna and MUTCD you will see lots of similarities. So the conclusion is you need to map traffic signs, and if you want to do that for a newbie user these have to be human readable, if you want to do exactly by an expert you need national id , so in OSM we need both as possible.
Should two trees of a similar specie be mapped or only once? Every traffic sign has its code. If you want to make an inventory you have to map exactly the traffic sign you have instead meaning would be the same. I’m not working only for routers but for all the projects will use osm data.
Well, we can have traffic_sign=road_marking or we can jump to a road_marking=* . If it is the case then we would map also road_marking:id=* because most of them have its own code so we have to respect that (wherever has national code, of course).
Traffic is traffic. MUTCD (Manual on Uniform Traffic Control Devices) is about traffic signs. Vienna’s derived laws are about traffic signs. Risk of forest fire is a traffic sign here. For other interesting advertisements we have other tags we will not discuss here. Also we will not discuss about railway signs here, for example. If it has code, if your government assign it a national/regional/local code , etc. it is a traffic_sign with its traffic_sign:id. Otherwise you can’t invent traffic signs that they are not in any place without any code. They are interesting things but not traffic signs. Signs? a lot, of course but they are not traffic_signs.
Let’s talk about that: is the 19th in United States. First is maxspeed with +39000. I don’t think they are from the same scale (+200). traffic_sign=neighborhood_watch | Tags | OpenStreetMap Taginfo
Also is the unique in the list with human readable value or not…because that is not a traffic sign. Has code? Did it makes reference to the traffic? It is a fantastic plaque, a sign, but not a traffic_sign. Traffic sign id has to be official, from whatever administration but official.
One thing is that you can’t map the code because you don’t know it, and it’s normal and not obligatory. And other thing is you can invent a traffic sign id. This will not work for big companies as TomTom.
I will not see the statistics and the user who maps it, and I will not search to, instead these was done to me. No wiki. No project on taginfo, No preset, No style…
Well, warning would be interesting but the aim is use existing OSM tags so we can convert it in Hazard without any problems. Your regulatory category is our reglamentation traffic signs here in Spain (yes, included mandatory and prohibitory). Indication or information is not a great difficulty once we accept we have to categorize traffic signs. Why we have to? Because Hazard exists. So to make coherence between hazard and the rest of future human readable values approved now or in future’s proposals we have to use the same structure.
One mapper could not drive, but here it is studied in school with basic knowledge. Here shape (triangle, inverted triangle, octogon, cercle, rectangle, square) and color (blue, red, yellow, basically) of traffic signs gives their meaning (and MUTCD, to my surprise too, Warning are yellow, Regulatory are white, speed limits are rectangular… is it correct?)
So any mapper would infere what kind of traffic_sign it has in front of him/her without knowing any national id. But the possibility to add it too has to exist. I studied a little bit that and I have a proposal. But I don’t think I can’t invent all the rest of +100 missing human readable values in two weeks. 20 categories (some of them are in use now) can be possible.
Correct. With these two traffic signs is easy. There are +1000000 of each. There are the oldest traffic signs in nodes as a part of a way. Unless there were a big automatic DWG controlled operation nobody can change these two to traffic_sign tag.
Only we can add information (direction,side,national id) but we can’t denaturalize 2 millions of nodes. If some of these node are bad tagged is not a fault of this proposal or proposer but for the original mapper.
So I insist. Proposal has to have:
-Type of traffic_sign. As hazard style. We can define some types to cover all traffic signs. Using existent OSM tags (maxspeed,access…) preferible and previously approved. +20 I have calculated in total.
-No more than two tags in scheme (when possible) to reach the meaning (traffic_sign=hazard / hazard=* ) . Use of human readable values (to define in other processes.)
-Possibility of mapping national id. Use traffic_sign:id=*
-direction relative to the way: direction=forward, direction=backward, direction=90 direction=270 instead it is in the way or independent . In OSM all the ways have direction, apply it.
-Side of the way the sign is located relative to the way. Again, in OSM all the ways have direction, apply it.
-Position.
No need to apologize – I really appreciate your willingness to engage on this topic, despite the unpleasantness. It’s a big topic that didn’t get enough attention until now.
I came to a different conclusion after considering your point about the importance of presets. With presets, the user sees a palette of signs that they can select from visually, or they can search for a sign by the name in their language – maybe even if the sign standard is written in one language, like Spanish, but the user speaks another language, like Catalan. When selecting an existing feature, they can visually confirm that the preset icon matches the sign in street-level imagery.
This is what you’ve implemented, more or less. Would you have had to do more work to implement these presets without the human-readable tags? I’d contend that it might take an expert to develop these presets but not to use them.
You’re right that some signs don’t function very much like the traffic signs you’re focused on, even if they’re manufactured like traffic signs. I think you should clarify the scope of your proposal, in terms of the subset of traffic signs you consider to be traffic signs. As it is, you’ve listed tags such as traffic_sign=city_limit that don’t necessarily play a role in road traffic safety either.
Here’s a city limit sign along a bike trail in my hometown. It looks identical to the city limit signs they post along roads, but slightly smaller. These days, most cities design their own city limit signs. They’re no longer uniform like in Europe, but the same US:OH:I-H2a value would apply.
Sometimes the same exact traffic sign is used for roads and non-roads alike. Parking regulatory signs can be posted either streetside or at individual parking spaces in a parking lot:
Earlier, I mentioned this rattlesnake warning sign, which the highway department posts at trailheads and around the rest areas it maintains. This is a traffic sign in the sense that it appears in a traffic sign standard. Maybe also in the sense that it’s a standard part of a rest area, and rest areas promote safer driving.
My city has a program that lets residents post yard signs out front encouraging drivers to slow down. These British-inspired “Twenty Is Plenty” signs function like the official advisory speed limit signs but don’t require a traffic study beforehand. Eventually, the city will use them as justification for lowering the speed limit.
If your proposal considers these signs to be out of scope, then there should be an alternative tagging scheme for it, just like we discussed with road_marking=* earlier. Could an alternative tagging scheme be based on the newly documented man_made=sign tag? If so, why not apply this tag to any traffic sign or quasi traffic sign that’s being mapped as a standalone node, whether or not you personally consider it to function as a traffic sign? We can still combine traffic_sign=* with this tag (or traffic_sign:id=*, if you insist) to indicate the ID in the national traffic sign standard, but it no longer serves as a primary feature tag.
Similarly, if a country’s traffic sign standard numbers road markings, we can add traffic_sign=* to the road_marking=* node/way/area. That element isn’t connected to the roadway, so there’s no risk of a router misinterpreting it.
I think this would be an improvement over the status quo, in which the location of a physical sign and the location it pertains to are tagged identically – even if both are mapped for the same sign. There are some precedents for this approach: for example, we combine kerb=* with barrier=kerb when tagging the location of a physical curb cut, but we omit barrier=kerb when tagging the kind of kerb associated with some other feature, such as a highway=crossing. Would you be open to this approach?
Please don’t read too much into the absolute usage numbers in the U.S. The community here didn’t really start mapping traffic signs until 2020 when I started documenting the MUTCD on the wiki. Of course, it’s true that we have many more speed limit signs than neighborhood watch signs in reality, but how many nuclear decontamination centers are there by comparison?
I suspect that the neighborhood watch signs were mapped as part of a concerted effort by one mapper in one city. On the face of it, they’re simply surveillance warning signs, but depending on your point of view, they also serve to warn about a unwelcoming neighborhood, even about vigilantes with guns. The federal government doesn’t deem them to be relevant to traffic safety, so in their view these signs would be invalid, and posting them along the street would be illegal. But local governments and organizations post them anyways under the authority of a local ordinance.
Conversely, California has annulled quite a few national signs, so that they technically cannot be posted here as traffic signs. And then a city ends up posting the national sign anyways, which is how my city wound up with two different shapes of one-way signs at the same intersection. oneway=disputed?
At the end of the day, what counts as a traffic sign will naturally vary a little bit from one jurisdiction to another, both in terms of the law and in terms of what ordinary residents expect. If we can relegate the sign IDs to a secondary key called traffic_sign=*, then the exact scope and format of that key doesn’t matter as much.
Correct, I meant that there are slight differences in what each country (and indeed each state) considers to be regulatory versus something else. (We call them reglamentación also.) It’s not a huge issue, but I didn’t want you to waste effort on duplicative tags, only to discover they’re the same thing.
Emphasis on more or less. There are in fact a lot of subtle differences between countries. In the Netherlands even the exact same traffic signs have various different meanings in overseas territories. Any newbie can map with national ids, but you need to be an expert to map the exact meaning of the sign correctly.
highway=traffic_sign is in use to specify standalone traffic sign nodes. I highly recommend this, since man_made=sign seem to focus on a different kind of signs.
road_marking=traffic_sign is a good equivalent for traffic signs marked on the road surface.
That sounds reasonable, but this documentation claims that highway=traffic_sign must be omitted if we know more details about the traffic sign. One more thing for this proposal to clean up, perhaps.
That would still leave the signs that are physically and legally traffic signs in reality but that @yopaseopor wants to distinguish from traffic signs because they’re used differently than some better-known traffic signs. man_made=sign was documented in the context of a discussion about more substantial political signs, but I thought the idea was to be more generic than that.
That would certainly be the case for a route shield pavement marking. I was thinking of how some countries like the UK number ordinary road markings like centerlines and the lines that indicate parking restrictions. Globally, these markings are commonly tagged with keyword-like tags such as road_marking=solid_road_divider, but in fact it appears that traffic_sign-like values such as GB:1003A are already commonplace.
With only 1300 items around the world and a wiki page written in 2023 are you sure highway=traffic_sign is in use?
Traffic_sign=yes has +16000.
Well, in this I’m agree with you. Signs like neighborhood watch, for example.
A road marking is always a traffic sign, so we can save the step road_marking=traffic_sign to road_marking=human_readable_value of traffic sign, I’m think. Here in Spain we have horizontal (road markings) and vertical (traffic signs itself). In some countries it has also its own code so we would need also road_marking:id=* to the same as traffic_sign:id. What about road_marking=solid_road_divider and road_marking:id=GB:1003A ?
More or less you can map a tree. Then you have the species tag, the species in xx language, the kind of leave…
Maxspeed is maxspeed, city_limit is city_limit, stop is stop. Which percentage of traffic signs do not have the same meaning? If not probably drive license would not be compatible between countries, here in the EU or in US. I don’t want to be rude, I know there are some specifities but in general…has to be the same because if not there will be different traffic signs to avoid the confusion.
So even if there are different human readable values then you have the possibility of mapping more or less. Then other mapper, probably from the place could adjust better the mapping.
Any newbie who knows the specific traffic law of that country and who knows the code. Any newbie has to have the possibility of mapping with human readable values too. If one does not one other mapper can do that job, as in OSM always there will come after someone who maps better than you. Also it depends the tools or the assistants the mapper would use.
Please don’t. The road_marking scheme is a total mess already and needs a total rework. road_marking=human_readable_value for every kind of traffic sign meanings makes that even worse IMHO. road_marking values should be a set of categories like arrow, divider, barred/prohibited area, stop line, traffic_sign… What kind of divider, arrow, stop line, traffic sign etc. is present should be specified in subtags.
Every newbie knows how to tag a McDonald’s restaurant, even if they don’t know that, under the hood, it would be tagged brand:wikidata=Q38076 thanks to the Name Suggestion Index.
I think this is the kind of experience we want to eventually achieve for traffic signs in most editors. Someone who chooses a bare-metal editor will see bare-metal tags, but that’s their choice.
There’s some truth to this of course. People do get international driver’s licenses, and I hear they often end their trips in one piece. But the sad reality is that international traffic sign comprehension is very uneven, even for basic warning and regulatory signs. This is a practical concern for us, given that mapping is a different activity than driving. A lot of navigation mapping (most of it?) is performed by armchair mappers half a world away who are very unfamiliar with local driving laws. One of the reasons I translated the MUTCD signs to OSM tags was so that we wouldn’t have to keep correcting each wave of paid mappers who come in with scant prior training.
The Vienna Convention countries have an advantage because of decades of pursuing international harmonization as a priority. By contrast, the U.S. abandoned that effort in the 1950s, after UN field tests of international signs were such a failure that the experiments had to be called off prematurely. The MUTCD has been developed independently ever since then. The U.S. also abandoned the dream of metricating road signs in the 1990s (although Liberia later adopted some of the metric signs). But it isn’t just the troublesome Americans – large swaths of the world have their own systems that differ in surprising ways.
A good starting point would be to read through these two issues that have ended in a kind of stalemate between the name-suggestion-index and id-tagging-schema projects. It seems like we need to combine the strengths of both projects without bringing along the baggage. You can also get a sense for who else is interesting in helping out with a solution.
Yes, but after statistics and watching evolution like iD editor, etc. human readable values have to be able to coexist with technical national id’s that like to people like me. Because if not some information can be lost, or not mapped o similar. With the two approaches we give answer to the two audience (specialized and not specialized). OSM is for all.
We have to do in a coherent way. If hazard exist all the other categories have to exist too, and if they not exist…we should create them.
Probably I’m not the best to do that and I hope someone can do this better, or can help, or can collaborate but I will adapt all I can do to the agreement all we will have.
Here in Spain city limit is traffic_sign:id=ES:S500 and traffic_sign:id=ES:S510. Of course is a traffic sign.
Is it legal? Is it the same? Is it in the MUTCD of that zone? If it is…it is.
I would ask the same before: Is it legal? Is it the same? Is it in the MUTCD of that zone? If it is…it is.
I would ask the same before again.
Do you think a personal and customized yard sign without any registry of any administration can called traffic sign?
Here in Spain we have some people in some town that painted in the walls “Please go slowly” but I don’t think this could be a traffic sign. Would be a positive message, good for your city but I don’t think this could be a traffic sign. Would the police put a fine relative to this yard sign, or to the law in general?
For me, probably.
Because I’m no God. I don’t decide which is a traffic sign or not. Traffic laws decide this. I can’t invent a traffic sign. I can’t put a traffic sign in the street myself. Traffic signs are in laws with its codes. My proposal want to maintain the national code and the human readable value that it has. As traffic signs are similar all over the world we can establish some tagging for them.
traffic_sign=* exists before my proposal so this would not change. And it is so interesting the discussion about was better highway=stop or traffic_sign=stop or highway:id=ES:R2 or traffic_sign:id=ES:R2. But we are far away. We passed that. We have to decide if human readable values should coexist with national codes. hazard=* exist as a traffic_sign human readable values, so only we have to decide if we want to be coherent with other traffic_signs, if we want to establish the step before (traffic_sign=hazard), if we want to develop now other parts of the traffic laws like traffic_sign=mandatory (or similar) and prohibited and if we want to maintain national id’s. Then we have to decide how to map it and with which tags.
My proposal covers all of that.
Good discussion. I think is better to solution one, and then another. I have some ideas for the discussion about that but let’s focus to be able to finish anything.
The problem of this would be the misinterpretation depending of the country. Eg: The majority of crossings of Spain has traffic_sign:id=ES:S13 before, but the mere existence of a crossing does not put the traffic_sign:id=ES:13 before a crossing. Because you can find other traffic signs so it is not possible to infere 99% secure always which traffic_sign you will have next to/before/after a item. Think about crossing=unmarked in United Kingdom. For a Spaniard is very shocking this idea as here we have the majority as marked.
Probably Mapillary copied the MUTCD as is. Don’t care much about that.
No, depending my point of view if there are not inside MUTCD and are approved by the administration they are other thing that traffic signs. I will not enter about the information you have inside the sign.
Good for the local authority. Which is the target of this traffic sign for the traffic? Which is the objective of this traffic sign for the traffic? Would the police fine you if you don’t do what this traffic sign say to you to do? If not, I don’t think would be a traffic sign, would be a sign, a plaque, but not a traffic_sign.
Ok, we can study which code applies, MUTCD or state authority or local authority with its code in traffic_sign:id=*
traffic_sign:id=* would be for codes, traffic_sign=* and its subcategories for human readable values. Probably major part of mappers who does not know about traffic law would not use traffic_sign:id=* But I think there will be mappers like me that then we will be able to do it without losing the information when have to select human_readable value or national id because there is one only tag to map it.
Yes, yes, and yes. Even this sign that every city wants to install in its neighborhoods, to the consternation of state and federal agencies that would never consider codifying it:
If you look closely, it has the logos of the city and the state Office of Traffic Safety. The government hands these signs out to residents who want to install it themselves. It functions like a traffic sign in the same manner that a construction warning sign might, and I tagged maxspeed:advisory=20 mph based on it, but its composition is no different than that of a political campaign sign, and no one would call it a traffic sign. It’s a yard sign.
But you’re right, these complexities existed before your proposal and will exist after your proposal too. Regardless of what your proposal says, ordinary non-experts will map miscellaneous traffic signs they come across, even if they don’t know how it fits into a regulatory standard.
Probably after the proposal would get approved (or an agreement about traffic_signs and its mapping) we can start to develope and help to other projects that need some structure. I have read that nowadays tagging could be a problem to make some correspondence table because the composition between codes and texts inside the value. We can “fix” that.
Sorry, but in the wikipedia article you mention it is explicited that some administrations are arguing that is not a traffic sign. But ok, what code is it? How can I map with traffic_sign:id ? What is the equivalent in other places?
Here, in Europe probably the privates would end with a big fine. (in Spanish)
No, I’m not agree with you ,any driver can pass about this sign. As advertisement would be good, but is it a traffic sign or not? Not like a, is it or not? If not , there’s no tagging about that. You can map the law that order in that street, the message of the sign but not the technicality of that ad. Would you map in the same way Smoke kills ad?
Correct, it is a yard sign and I think it would be mapped as is, not like would be. Would your local administration can use OSM as inventory if we start to map yard ads as a traffic signs?
The impasse between these two projects has little to do with tagging. I don’t think anyone involved in those discussions favors the complicated syntax with the brackets either. Rather, the difficulty seems to be around logistical issues, because traffic signs don’t neatly fit the kinds of tagging that either project is used to. id-tagging-schema is better set up for localization (important in multilingual countries like Belgium and Switzerland) and can specify which empty fields to present the user along with each sign (for example, the Speed Limit maxspeed field for a speed limit sign). On the other hand, name-suggestion-index would be more capable of handling an influx of thousands of new entries, and it can fetch icons dynamically.
OK, I didn’t want to go into this rabbit hole, but since you asked: the U.S. is big and complicated. Traffic signs are standardized at the federal, state, and local level. The state regulations are supposed to conform “substantially” to the federal standard, and local ordinances are supposed to follow the state regulations. State laws generally prohibit non-MUTCD-compliant signs from being posted by anyone, but often the state and local governments are the ones who post non-compliant signs. Some states like California and Oklahoma are notorious for nonstandard, even childish signs:
The federal government’s role is mainly to coordinate the state regulations, sort of like how the OSMF “supports but does not control” OSM. To the extent that state and local funds are used to maintain a highway, the Federal Highway Administration is responsible for enforcing conformance, by threatening to withhold that funding. Otherwise, on a local street maintained with local dollars, the federal government only has the right to send sternly worded letters of disapproval. This is how a town in Indiana gets away with posting its street name signs in German, and in colors that the MUTCD explicitly prohibits:
But even a more conventional traffic sign can lack a standard MUTCD number. For example, here’s a regulatory sign at the Louisiana state border that has no equivalent in the national MUTCD. Louisiana hasn’t adopted a state supplement to the MUTCD, so there’s no state sign number either. This sign still has the force of law, because it follows the general design rules for a regulatory sign. This is exactly the kind of situation that I think would benefit from a set of tags like traffic_sign=regulatory.
As for the “Slow Children at Play” sign, the federal and state governments don’t claim that this isn’t a traffic sign, and they certainly don’t prohibit us from calling it one. (That would be a violation of freedom of speech.) Rather, they say that there’s no valid location along a roadway to post such a sign. Yet cities routinely post these signs (and the neighborhood watch signs) on city streets, intending for them to serve as traffic signs. A police officer may issue you a ticket for violating the sign, but you might be able to argue your way out of the fine. If you get into an accident because of the sign, you might have grounds to sue the city. But not because it isn’t a traffic sign.
OSM maps the world as it is, not as it should be. This means we should have some way to map an uncodified or nonstandard traffic sign. Every now and then, someone in OSMUS Slack asks how to tag a miscellaneous sign. My informal advice is to tag the sign category, such as traffic_sign=regulatory, and provide more details in other keys such as maxweight=* or even maxwheels=*. Then, for good measure, also tag the text on the sign as name=* or inscription=*. People have been following this advice.
I think this approach mostly aligns with your proposal. The aspect we disagree on is whether all the usual signs should also have structured, human-readable tagging. Honestly, I’m still not sure why we’re going through all this trouble to create a new ontology just to accommodate power mappers who don’t want to use presets. Maybe you’ve explained this already, but I didn’t understand?
We agree on this point. What I meant is that some navigation-related tags such as maxspeed:advisory=* can sometimes be tagged based on things other than traffic signs. Granted, yard signs are an unusual example of this, but just think of all the non-government-provided signs that prohibit access to private property:
I really think you should start new forum discussions with each national community you hope to bring on board with this proposal. Of the very limited set of entries you included in your revamped proposal, I made a couple dozen changes, some of them very significant. The existing signs looked like guesses; you would’ve avoided a lot of confusion by consulting the MUTCD correspondence tables that I keep mentioning. If you got these signs from pages in the Key: or Tag: namespace, then I’m sorry that other non-Americans keep making poor guesses at what our signs mean.
I blanked out some of the table cells in the MUTCD column, because there’s no national sign, only some state specific signs; in other cells, I added as many as 14 more sign numbers that involve the same tag. Some of them are used in different contexts, but I assume you don’t expect U.S. mappers to ignore the sometimes significant differences between these signs just because the corresponding Spanish signs are more uniform or less precise.
Maybe you consider this initial set of signs to be a logical first step, but from my American perspective, it’s a very haphazard set of signs. I don’t know how you’d hope to get this proposal into shape without systematically going line by line through the relevant sign standards or the documentation that mappers in various countries have helpfully put together for you. Again, we could end this difficulty just by tagging the sign ID whenever it’s available.
I don’t know why I can map any tree of the World and I can’t map a traffic sign (an artificial thing, registred, countered, based on law) of the world.
Yes, tell me what can add. As you can see there are several categories:
traffic_sign=hazard
highway=Stop and give_way
traffic_sign=max* ,min or advisory
traffic_sign=implicit
traffic_sign=access
traffic_signs=restriction
traffic_signs=mandatory
traffic_signs=information
traffic_signs=lanes
traffic_signs=services
traffic_signs=complimentary
traffic_signs=ref_id
traffic_signs=boundary
traffic_signs=regulatory
What more?
Probably I had not explained me well on this.
This proposal is about the way of mapping a traffic sign nor specific examples (the idea is to give examples to show the people how to do that, but as a massive thing the documentation will grow a lot, each community specifying which values uses and what codes have.
As exists hazards and other human readable values , in a future you will have all it around, because each value or category can be the target of a proposal of this kind of values.
At first in OSM there is human readable values attached to traffic signs (city_limit, maxspeed). This proposal only wants to complete the scheme. If you want a top category you will have traffic_sign=* and its category. Then , from the category, as hazard or maxspeed you can derivate all the scheme you will need for your mapping. US is variate, but also Europe too, you can have 300 official signs but with variations approved and installed in our rouds, you can have near 700 (Spain’s case). Codes derived this kind of traffic signs, is for this that are important here in Europe, if you want to be as accurate as you want to be. Some people will not map it, some people will map only stop and give=way, some people will map only OSM well-known values, and some others will use the national code, accompanied of a human readable value as a completed micromapped item.
Totally, no discussion about that. But them we will accept controversy cases when informal traffic sign says the opposite to official…but then these will be the problem of the mapper.
It has no sense to discuss about all the bunch of human readable values if I cannot map the signs with direction,position, side, human readable values and national id if I want to. When we have that, then we can discuss with each community how to make this mapping. And also we can front what human readables values are missing in OSM, now hazard exist. I’m not from US, probably you will know better what US roads need. I read a lot of traffic laws, etc, but my presets are about national codes you will find in laws and a way of mapping that because I don’t have the local knowledge that it has the local community. Probably from each country , the community knows better what traffic sign do they need in a preset. I can help, I can adapt, but I’m only be able to do an analytic proposal.
I accept your changes but be conscient they were only few examples how to tag it. There was a general example, the categories, and then what human readables values looks like, and how to map national id’s together. I can do a complete list of that…but it has no sense if I cannot map the basics of any item in this case: direction, position, side, national code and human readable value.
Yes, but when you have human readable value and national code too, what do you map? How to map it together without removing any information? This is the aim of traffic_sign:id=, to let traffic_sign= the human readable value, as the first traffic signs stop and give way does. And this is the topic of this proposal. Also we have to discuss how to tag the position or the direction. Better layer of subkey? Better 0 or forward? In the past I’m only used what others used before. Now I’m asking if that is not sufficient what more do we need, and to established via a proposal, to avoid any missunderstanding with mechanical , automatic or manual mapping because I can use these keys.
Also all this discussion focus in the need of collaboration of biggest “structures” of OSM. iD Editor (via nsi or tagging preset o scheme or whatever) is an “OSM national-structure”.
If we not approve this proposal, then in the future we will have some others that can do. Traffic sign is a big topic inside OSM (more than 2 million worldwide) and some day we will need to think about it. Let’s do now and save time and efforts. Focus the discussion for the structure (because it is clear in OSM quasi-all is mappable, and anything can stop that), how to do that, and then we will talk about the rest.
So you are planning to take this proposal forward?
I read your proposal and thought you were trying to formalise a whole bunch of human-readable values.
If your proposal is just about the basics, e.g. how to tag position, direction and id, then you can reduce the proposal in length by about 80%…
It would be good if you could make it clear what you are actually proposing: which new tags you are introducing, which existing “in use”/“de facto” tags you are formalising, and which tags, if any, you are deprecating.
This list consists of very general values like regulatory and information mixed together with very specific values like lanes and give_way that only pertain to a limited number of signs. In my opinion, this set of values doesn’t seem to be any more consistent or rational than the current mix of sign codes and keywords. For reference, I put together a list of general sign categories in some major sign systems. Feel free to add more standards to it. Obviously it isn’t possible to align 100% to each of the standards, but you can see some common themes among them – much more commonality than at the level of individual signs.
I see, thanks for explaining your expectations in more detail. I’m not in favor of the existing ad hoc values like traffic_sign=maxspeed. These values are only popular because the documentation and editors historically haven’t done enough to support mappers entering more specific values, based on the more specific signs they can see with their own eyes.
If so far no one has put together presets or a wiki page about your country’s traffic signs, but a mapper wants to tag a speed limit sign, traffic_sign=maxspeed is better than nothing. It’s the same story if they encounter a sign that hasn’t been standardized yet – any tag you like. By contrast, if they’ve already chosen a specific sign code visually using a preset, then they shouldn’t need to additionally provide the sign’s category.
Assuming that a given sign code belongs to a single category every time it occurs, traffic_sign=* can be either a specific sign code or a general sign category, following the approach we approved in 2020. These keywords more or less already exist today, but we can come up with a shortlist for consistency if you prefer. Aside from that, there’s nothing really to fix here, other than to build out the tools for mappers to migrate from the ad hoc values to more specific values. If the indexed :2 syntax would unblock these tools, I suggest making the proposal about that change and setting aside the extended keywords.
(By the way, you probably mean complementary; complimentary would be for a “Thank you!” sign. The text of the Vienna Convention calls them “additional panels”, while British English calls them “supplementary plates”.)
OK, if I misunderstood the purpose of including sign images and codes in this proposal, then please feel free to revert my changes.
In fairness to you, many key and tag description pages present an oversimplified gallery of signs by country. To me, this practice is rather backwards: it’s not as though anyone window-shops for traffic signs based on a tag they’ve chosen upfront. Often, when you see a gallery of signs in an “Examples” section of a tag description page, it means “This sign proves the need for a tag,” not “If you see this sign, use this tag.” This is especially true of any tag that went through the formal proposal process, such as hazard=children (which confused signs about playgrounds with signs about children playing in the street). Over time, as mappers in more countries put together country-specific tagging pages, we might be able to deemphasize these galleries.
Going through the table you set up, I saw a few reasons why it would be complicated to cleanly map a single human-readable keyword to sign codes across countries:
Many tagging schemes rely on more than one tag in combination. For example, most countries have signs that we’d tag as hazard=animal_crossing. But animals come in all shapes and sizes, so usually there’s a whole series of signs with cute and cuddly animal pictograms, requiring an additional hazard:animal=* or hazard:species=* tag. The only kind of sign that literally just means hazard=animal_crossing is something like , but most countries don’t have a general sign like that.
The meaning of a sign can change significantly due to a complementary plate beneath it. For example, means “bicycle crossing” by default. It only means “bicycles riding in the street” (hazard=cyclist) with an additional plaque. But the main sign’s number is the same in both cases. Similarly, Vienna Convention countries use signs for many different situations that we’d tag as hazard=*. By the way, this issue probably complicates your desire for :2 and :3.
Two signs can have exactly the same function but look very different to a mapper or computer vision algorithm. There is no functional difference whatsoever between Puerto Rico’s and signs. But not every country has two different signs for oneway=yes.
A single sign can contain multiple pieces of information. Destination signs are some of the most extreme combinations, but combinations like are very common too.
These considerations don’t matter very much when mapping the effect of a traffic sign, for example, hazard=* or highway=stop. I think most mappers would agree that mapping the effect is more important than mapping the traffic sign itself, but mapping the traffic sign isn’t completely useless either. My concern is that requiring every traffic sign node to be dual-tagged with its effect will cause mappers to view one or the other as redundant or superfluous. If you want to dual-tag a single node with an effect and the sign that indicates it in the same location, OK, but don’t make that a requirement.
I think this a good start this is a lot signs to work on at once. Can take a type or two a work out common themes first? Leading to a consistent way to describe a sign. That way we will have a basic framework that can be applied to other categories.
versus 
? Mapillary makes this distinction because the detection model necessarily differs, but a router couldn’t care less.
The text of the Vienna Convention calls them “additional panels”, while British English calls them “supplementary plates”.)
