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.
Would very great. Who can do that? I donât know how to that outside JOSM. Who can help us?
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?
Well, we can start to re-edit the proposal to start to add the new text and the new codes.
Here it is. Guide me, and discuss it, please.
https://wiki.openstreetmap.org/wiki/Proposal:Extended_traffic_signs_tagging
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.
Thank you.
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.
My planning is to be able to map a sign as is, and that every mapper, driver or not can do that, as other people can do that with other elements like street lamps, trees or containers. Before it was an item not important for OSM (no proposals, inconsistent tagging, ignored topic⌠you think I can be rude but you can read tagging list and see the history of it in OSM.) so anyone can map the basics.
Now it is not as that. Now in OSM now we have big companies, and some users that want to map it .Some communities tried first. But there we are in 2023 without a way to map these common items, with a wiki saying thereâs three ways of do it, and with some âde factoâ approved or proposed accepted that does not fit the item itself as we can see at the discussion with hazard.
My experience says (could be wrong or not) that not all the proposals are threatened in the same way (again you can see the history of tagging list or import list (I remember some painful -yes- episodes). Stop and give way are one of the oldest, with different tagging, how to change that. Ok. Letâs do in the best way, with all the examples you need to understand what is the aim. Why I have to be condemned to map between brackets? Why I have to use multivalues that has no sense (for me a complementary signâŚis a sign too, for others it is residual, letâs take the meaning only). For this reason I would make whatever list I have to demonstrate that I donât have seven years old and others can arrive here, change one tag or the way to map milion of items that they want to and go on. - it is not the first time and from other mappers - (letâs see first comment of this thread as an example.)
Ok, would be interesting.
I like the idea the of breaking the proposal into smaller chunks. Starting with more straight forwad foundational concepts. Perhaps including more defacto tags because they are already in use.
I think this is a fair question that deserves a straightforward response. Otherwise, weâre wasting our time (myself particularly) trying to massage the proposal into something that the global community could get on board with. Given your stated desire for consistency, the focus would naturally shift from your proposal back to the question of what to do with your widespread edits, which are in the minority.
With +1 million and one of the traffic sign most mapped would you change for now something about that rather than add national id, position, direction and side?
Ok, except MUTCD you can find some kind of information, regulatory, complementary and warning (hazard in OSM, to use the proposal accepted) .It is true that there are some more specific categories than others but this is to avoid the major three step classification.
I think itâs better:
traffic_sign=maxspeed (exist)
maxspeed=x (exist)
Than
traffic_sign=regulatory (new)
regulatory=maxspeed (new)
maxspeed=x (exists)
but this is one thing we can talk about, only three big categories with three steps of twenty one categories with two steps?
YesâŚbut at first there are the top values of traffic signs. At first I cannot ignore them.
Well, letâs start to build the path to do this. It is difficult to get an approbation of near 250 new key/values (probably only 100 exists now). First approve what exists now and then we can add new content.
If you give both possibilities then you will have double possibilities of success in mapping these traffic signs. Trees accept species and species in languages, why canât do some similar? (possibility,not obligation, of be more technic or more âstreet levelâ.)
The idea, mid-term is to have a complete system for mapping traffic signs, with all the software adapted to that, with proposals to center all the traffic signs in traffic sign tag and to have a complete list/system/picture table of traffic_sign:id. But step by step. I hope more people would be attracted to this âroadtripâ.
Sorry for my bad English
No, your opinion and your suggestions are so valuable, and I respect that instead I could not be agree in all. I think both weâre interested in a way to map traffic signs, and to do the easiest way with the most consistency possible.
Well , it is the opportunity to use a third level of concretion. One more value-to-key. animal_crossing | Keys | OpenStreetMap Taginfo
Yes, for this reason we need second position. In Europe these plaques are complementary traffic signs, so this would map the second traffic sign with the position system using national id and the human_readable value when decide this.
No, it makes easier to see why we need these second or third position. I have identified more than 200 in Deutschlandâs traffic law. Probably would not be 200 human readable values but then you have 200 national idâs without problem.
Well. That now exists, some countries prefer prohibitory traffic signs to avoid turn left and some others prefer mandatory to turn right or go through. Different national codes, different human readable valuesâŚbut same action.
It is clear destination probably will be another proposal in the future. There are a big variety of colors,positions of the text, orders, functionsâŚIt is a complex item. Letâs start by the easier and existing if possible.
In some countries there will be combinations, in some countries there are two traffic signs, why canât exists a descriptive way of mapping to make available these two different?
My concern is arrived to a point some mappers would decide which kind of mapping is superfluous and delete my work for example, translating all the national codes (40 different pics) of 40 countries to one readable and unique human readable value. Letâs coexist together. There is no obligation to map whatever you donât know or you donât want to, but let the others do.
It is not a requirement, it is an option. All of these started because I want to maintain both tagging and I have used widely a few used tag, found in taginfo. These will occur more times in the future when people maps traffic sign as a real item with its importance. There will be tendencies so it is important to establish a way of do it.
