At the proposal you have examples for traffic_sign=hazard and traffic_sign=max* or min* . I think it is a good start to use them (they exist) and start to thinking the other categories with the other human readable values (because traffic_sign:id would be approved in first proposal). I think is so clear:
First you say the type of the traffic sign: Warning (Hazard in OSM),Regulatory (new)(all the maxspeed,maxwidth,maxheight,maxweight,maxaxleload,overtaking…),Information (new) (includes city_limit traffic_signs) ,Complementary **(new)**or Others. Stop and give_way uses highway (existing) key until community decide to unify all the traffic signs with one key.
Then you apply the subkey for this type (like hazard).
Do you know the id of the traffic sign in its country? Use traffic_sign:id=* (new)
I have said I’ll do, but I’m conscious I can fail. But no worries, If I do not get it, other in the future will get to. This is first time I see in tagging list/forum so big interest for traffic signs in general (81 messages talking about traffic signs), from the way of we are mapping it to the content we are mapping it.
I don’t think so. Probably if I fail with this you will start other with all the information also you have searched to help me.
My edits are not important (of course I don’t want to my job of three months would be deleted - because It was not incorrect-). But It is more important establishing a consistent way of mapping, to do 3D mapping, to can map all the traffic laws existing,to have more and more people mapping traffic signs (not only the effects - for me is like we are mapping the shadow of the tree or only the light of the street lamp), and the possibility of developing software to do that and to use that, as other topics we have in OSM, more than We have today.
In my view, even if the proposal were to deprecate traffic_sign=give_way with about 1,300 occurrences, it could avoid disruption by saying that the replacement for traffic_sign=give_way is to set traffic_sign=* to the relevant traffic sign code, with the usual admonition against bulk edits. No new tag would need to be proposed for yield signs. This would effectively reinforce the existing practice of gradually refining the keyword values into more specific sign codes as we identify the signs in street-level imagery or via a field survey.
That said, I’m not even suggesting to deprecate traffic_sign=give_way. I’m just saying you should ignore these values for now, in favor of one of the other ideas you’ve expressed in this proposal. You’re insisting that all these changes need to happen together, but I don’t see how they’re inextricably linked.
traffic_sign=regulatory more or less already exists for miscellaneous regulatory signs that can’t be described by other values. But I still am not convinced that traffic_sign=ES:R-301 or traffic_sign=US:R2-1 really needs to be shunted over to a new key. Doing so would be more disruptive in my opinion. We’re talking about the 29% of all traffic_sign=* nodes globally that is most readily consumed by data consumers.
We’ve already discussed this previously. The only thing I’d add is that the scientific name in species=* is analogous to the sign codes that you want to relegate to traffic_sign:id=*, whereas the entirely optional common names in species:*=* are analogous to the human-readable keywords you want to rely on as the primary tag.
Here’s an example of the kind of complication I foresee when a single sign’s meaning depends on another sign:
This is a lot of extra tagging that can make it very easy to miss the differences between each configuration. It isn’t possible to create a single preset to represent the very recognizable , because the tags can vary so much. Instead, some presets would have to represent sign assemblies and coexist with other signs on the same post. Yet I don’t see how these additional tags allow data consumers to more easily present, say, hazard warnings that visually match the real-life signs.
If so, then what information does the current tagging fail to express that your proposal would express? hazard=*, highway=stop, etc. are already well-established tags that are being used every day. The same mappers who map traffic signs also map these things – but they don’t consider them to be the same feature, even if they happen to dual-tag them. It is your proposal that would conflate the two kinds of features, eliminating the “option” to map the sign without the effect at the location where the effect does not apply yet. (By the way, some hazard=* values like animal_crossing and pedestrians apply to a whole section of the roadway, not just a point along it.)
If that was a European sign, the tag would be traffic_sign=US:W11-2,US:W11-15P,US:W16-2P[500']
Signs with a variable part are added in brackets - all the information is available from one single key which makes reading and interpreting it very simple.
I fully agree. The existing tagging is simple - just a list of signs one can select from a drop-down menu. And it contains all relevant information.
Simple is in the eye of the beholder. For editor developers, this is as simple as making the opening hours syntax user-friendly. On this point, I agree with @yopaseopor that the mini-language with brackets is too limiting. It’s how mappers end up making up their own key-value syntax just to stuff everything into one tag value. It only happens to work for most Vienna Convention signs by coincidence (other than destination signs). I would have had little to say except a big thumbs up if the proposal had been limited to more or less the the idea of favoring the secondary keys over the mini-language.
I love these text signs. It’s clear that the current syntax has problems with American style signs. For all the countries following the Vienna convention the current syntax is very well suited. There are almost no exceptions where it doesn’t work or the character limit for values kicks in.
I see that there is a need to cover complicated cases, but I think it must not rely on complicating the simple scheme that works in large parts of the world very well. We need to define an extension to the current scheme without invalidating it and without forcing people to use a (in their region) needlessly complicated scheme.
Well, this should be covered by a simple scheme that says “for traffic_sign=destination” the text is given using the destination:* namespace" and a proper decision on how to map the direction of signs.
“Mine” yield has not the same picture as yours. Tell me how to map these two different pictures. With give_way is not a big problem to maintain the id in traffic sign…because uses highway. But tell me the others.
The only I want to happen together is the existence of traffic_sign:id (because traffic_sign=human_readable_value exists. This proposal establishes how to map physically and logically (the possibility of human-readable-values and the possibility of national code, whatever you do both or one.)
Matching reference to 108 values ,do you say a tag with +140000 does not exist? My proposal gives the opportunity to have both information. Tell me , how I can map that is traffic_sign=maxspeed and the picture of this both at the same object?
It is not obligatory, if you want don’t change anything, but let the others that can map in this way.
1-Tell to a non-US how to map that based on street level imagery on the left.
2-that is not correct but I recognize probably the proposal have some lacks. That is why this discussion is very important. Should be
traffic_sign=hazard hazard=crossing traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=US:W11-15P complementary:2=trail_crossing (or assimilable to crossing=trail_crossing, Why not, let’s discuss in a separate proposal) traffic_sign:3=complementary traffic_sign:3:id=US:W16-2P
distance=500’`(as you don’t have any value that occupied that key why do you have to use one supplementary? Talk about it. )
They can use the first part of the tags or the second. They have human readable values and they have all the codes and the positions they need to represent it.
This kind of things you can do it with US preset in JOSM for almost 5 years…I think (not human readable values). And you have represent it to level 2 with the style. More data, with your part of layers, preset and style would represent this now. Not with the first multivalue solution.
When you have a human readable value, if you want to put the national code you have to change the tag with traffic_sign. Tell me how to do it without change the tag or using traffic_sign:id
When I want to use national code in a sign with the tag traffic_sign=human_readable_value
Well, they can consider whatever they want. If you see map features from 2006 or 2010 it is clear that highway=stop and highway=give_way are signs, traffic signs. Hazard is different but I can think that if you tag traffic_sign=hazard… it is a traffic sign.
In Spanish you can say “hacerse trampas al solitario” (you are just kidding yourself). What is the target of tagging in OSM: Tagging in one-only tag or tagging the best way and more exhaustive can do?
And with Vienna convention also if you want to put all the information you can find in the combination of two traffic signs.
So I don’t know why exists PTV2 if PTV1 works very well in large parts of the world.
You accept that your favourite system can exist instead of other proposals but you don’t accept that exists other system that can has the same rights of yours. OSM is not a competition, but If you are so sure that the system is simple and much people would use yours, etc. why don’t you let the other system exists and then comprove what is better?
Other proposal but tell how can you infere the information you will not find in the simple traffic sign scheme if you want a realistic approximation to these traffic signs. Spanish destination traffic signs are not yellow although your software gets good aproximations
It works well for some things perhaps, but if it worked well for a WYSIWYG editor, iD would’ve at least made some progress toward supporting it long ago, alongside the opening_hours syntax. At least the opening_hours syntax packs in enough complexity that a more structured representation would be unwieldy in a different way. Oh, but opening hours inside a traffic sign!
It’s easy to dismiss non-Vienna signs or destination signs as mere edge cases, but we’re talking about a significant chunk of the world (not just the U.S.). If OSM had already gotten 100% behind the mini-language by now, I wouldn’t be arguing for a wholesale replacement. But as it is, it’s just one of at least two approaches, and the alternative based on iterative refinement is not unheard of in Europe either. @yopaseopor certainly isn’t alone in preferring iterative refinement.
Likewise, if we were mapping signposts rather than traffic_signs, I wouldn’t be able to critique the mini-language on the basis of the “One feature, one element” principle. After all, I helped to popularize tagging man_made=flagpoles with multiple flags on them. But as it is, we’re mapping the traffic signs themselves, so we should ask ourselves why we need to stuff all the information about multiple traffic signs into a single tag, when we have room for multiple secondary tags and even multiple features.
Plus an exception for each of the codes that a country might assign to a particular layout of a destination sign, such as FR:D31e:
If we can make exceptions like that, then I guess we can also exempt the countries that have adopted complex sign layouts as a matter of course. But that kind of fragmentation is unfortunate when we can help it.
This issue isn’t limited to text or destination signs. What could be more American than a traffic_sign=US:OH:E9-H1[Q4926479,Q1185675,Q524757,Q38076,Q244457,Q7362714]? Or is it a traffic_sign=US:OH:E9-H1[Q4926479,Q38076,Q1185675,Q244457,Q524757,Q7362714]?
More seriously, some of our hazardous materials signs use the UN chemical symbols that match the placards on the rear of the truck:
Anyhow, like I said, I’m not really advocating to deprecate the mini-language. The iterative refinement style is better supported by editor presets, but OSM2World only supports the mini-language in Germany and Poland. All I’d like to see is more acceptance of the iterative refinement approach so we can improve editor support beyond what it is today.
Today, the yield line – the point at which the driver or cyclist must yield – can be tagged highway=give_way. Additionally, a Spanish give way sign can be tagged traffic_sign=ES:R-1, and an American yield sign can be tagged traffic_sign=US:R1-2. You can choose to dual-tag the sign at the yield line, or you can choose to map the sign separately at its physical location. This is similar to how we map a POI when it occupies the whole building. Some mappers prefer to place a node within the building, while others prefer to dual-tag the building with the POI’s details.
The visual difference between and is relevant to the traffic_sign=* feature but irrelevant to the highway=give_way feature, even if both features happen to be the same node.
traffic_sign=ES:R-301 means a speed limit sign that has a particular appearance and has the force of law in a particular region. If you only map traffic_sign=ES:R-301maxspeed=10, then you have only mapped a sign. Do you agree that maxspeed=10 should also be tagged on the highway=* way that it applies to? If there can be two different features in this case, then there can also be two different features any time there is a sign.
Then you have no proposal, because that is already allowed. But I think your proposal is currently about more than that, because you also insist on introducing traffic_sign:id=* or traffic_sign:2=*.
I think we’re getting to the cruxt of the issue: yes, today, traffic_sign=maxspeed gets replaced by traffic_sign=ES:R-301. Iterative refinement doesn’t always require an additional key: highway=residential is more specific than highway=road; building=apartments is more specific than building=residential; junction=roundabout is more specific than junction=circular; and so on. I concede that two syntaxes ideally shouldn’t occupy the same key, but at least these two syntaxes never conflict with each other.
As far as I know, this manner of iterative refinement isn’t a practical problem. A router that needs to know about a change in speed limit will see the maxspeed=* tag on the roadway, even if no one has mapped the traffic sign at all. A renderer such as OSM2World already knows what DE:274 looks like. Otherwise, it cannot reliably show a even if the node is tagged as a maxspeed sign.
This is false. In 2006 or 2010 or 2024, if you map a highway=stop node at the location of a stop sign, that is an error: you have either neglected to attach the node to a roadway, or you have shifted the roadway all the way to the curb. At best, the highway=stop represents a stop line that is marked by a traffic sign.
Besides, even in South Korea, which numbers road markings in its traffic sign standard, there is still a distinction between road markings and traffic signs. I’m pretty sure you don’t “drive over a stop sign” and stop on top of it in that country either.
Sorry but in Spanish traffic law is the opposite. And I think here in Europe is the opposite (always there is a traffic sign, not always there is a road mark), and traffic signs are more important than road marks (in Spanish we use the word prevalecer - prevail) . Probably in OSM we use orthoimage better than street imagery but we can’t change the reality.
Yes, when you have in traffic_sign=human_readable_value in which tag I can put the national code without changing existing traffic sign? Now we can not map any national code in any traffic_sign of warning/hazard due to this (in the hazard proposal exists traffic_sign=hazard), also we can not map any national code in any traffic sign of maxspeed (and probably in the other limitations with human readable values we have in OSM). Are we losing national codes? In which tag I can map them when existing traffic_sign=human_readable_value ?
Sorry but it is not mine, traffic_sign:x it is from Finnish community and I think is here more before than the rest of the proposals we have talked about here.
The proposal only wants to follow the way traffic_sign=hazard has opened but without losing any national code. Because if we had main categories inside OSM then, whoever wants to, can present a proposal about that categories that covers all the possibilities in traffic signs (instead there is a readable value or not). Making presets I see more than 40 traffic laws different countries and more or less are the same (we can change the name, we can adapt the scope but we need in a written place how to do it.)
direction=* is also not mine
and side=* is also not mine
I’m only establish the possibility of do that with codes and human readable values if they exist (or if there is a proposal to exist), written all and make a proposal. If someone wants to map simply, they can following do this. But if someone wants to spend his/her time explaining all the content of a traffic sign they can be able to do that. Now you can’t if some value is human readable value.
Sorry, this word is ambiguous in English; I should’ve been clearer. What I mean is that highway=stop represents a stop line that is indicated by a traffic sign (or road marking). And it doesn’t have to be an actual line. Most of the stop lines I map are unmarked, which I tag as marked=no, though I haven’t gotten around to proposing that.
I see 60 traffic signs but in the last revision of the preset I have +750, seen in traffic signs German law. Probably would not be the most complete tool to use it for mapping.
Are you saying is better have other tool outside the editor rather than use the editor itself?
I mean that somebody wrote a tool, but nobody feels the pressing urge to put effort into re-implementing it several times into various editors.
Maintenance for stand-alone tools is much simpler and there are many more people who are able to contribute by providing such a simple tool compared to coding inside a huge framework.
For the casual mapper an all-in-one tool is better, but unless you pay for that it’s hard to realize in OSM.
For reference here’s the seemingly complete list of defined signs: Bildtafel der Verkehrszeichen in der Bundesrepublik Deutschland seit 2017 – Wikipedia
750 signs in a tool is way too much. You don’t need to implement every single sign from the tables. E.g. there are 50 signs for inclines and declines. These will be represented by 2 signs plus an input for the value.
And the vast majority just requires a tag with the correct sign id - there is nothing to be tagged apart from this. E.g. none of the DE:600 - DE:650 signs need any tagging, they’re just markers.
It is reality now. +40 presets in JOSM, +10 styles in JOSM, and +10 projects on taginfo.
I have subtracted these (there are 800). Also you can forget the +20 DE:600-DE:650. You have +700 traffic signs.
I don’t know why hazard=curve (DE:103-20) is more important than DE:209 to don’t have its human readable value and only can be mapped by whoever knows the code. And tell us why hazard=curve cannot have its national code in Germany.
There are certainly factors standing in the way of well-integrated traffic sign mapping functionality that laypeople can easily use, but money isn’t one of them.
To be sure, some signs are a lot more common than others. For example, of the approximately 1 million traffic signs in New York City, the top 20 signs make up 78% of all work orders for replacement signs. There’s more variation along highways outside of urban areas. The top 20 signs account for only 44% of the 312,000 signs along state highways in Maryland, and the top 50 account for only 66% of the signs. This is far less than 750, but I suspect there would still be hundreds of signs just from the fact that each city and each state/province tends to use a different set of signs. Nevertheless, this is well within the scale that name-suggestion-index can handle.
This quote is hilariously wrong when applied to the land of the MUTCD. Highway authorities in the US are free to invent word-message traffic signs on an ad-hoc, “as needed” basis, and do so quite regularly, although such signs are still subject to MUTCD rules on shape, color, and permissible abbreviations. Quoting MUTCD section 2A.04, paragraphs 11 and 15:
In situations where word messages are necessary other than those provided in this Manual (see Paragraph 15 of this Section), the signs shall be of the same shape and color as standard signs of the same functional type.
State and local highway agencies and owners of site roadways open to public travel may develop special word legend signs in situations where engineering judgment determines roadway conditions make it necessary to provide road users with additional regulatory, warning, or guidance information, such as when road users need to be notified of special regulations or warned about a situation that might not be readily apparent. Unlike colors that have not been assigned or symbols that have not been approved for signs, new word legend signs may be used without the need for experimentation.
Here is the same. Under hazard=undefined (ES:P50), with a complementary traffic sign (ES:S860) you can put in the plaque whatever you want. But this doesn’t mean inventing a traffic sign, nor a code also.
So this is not an invention, you can change the text but not the shape (have meaning), the color (have meaning) and permissible abbreviations (to make it compatible with all the other complementary signs)
, because the tags can vary so much. Instead, some presets would have to represent sign assemblies and coexist with other signs on the same post. Yet I don’t see how these additional tags allow data consumers to more easily present, say, hazard warnings that visually match the real-life signs.
