First of all, thank you for all the community who finally has decided to vote to approve or opposite and comment all the proposal and all the possible errors. Perhaps all the rounds of comments were not productive or positive (specially last week of RFC) but from my point of view the job was done (every message there had be answered, and some parts of the proposal were changed). It is sad to have to arrive to this moment but I try to see in a positive way and the part of “why not” is working. So thank you very much to the ideas for remaking the proposal. Tonight I will stop the vote for this proposal, due to it is complicated to be approved in that way , with that numbers. So, next days I will redo the proposal and start the RFC part. I will be clear: I want a consensus proposal to make possible the mapping of traffic signs with the major information in the easiest and massive way.
But before I close all the vote part and redo this proposal let’s talk about all the “no” reasons or comments. I will answer it 1 by 1.
1-“Doesn’t add anything what can’t be tagged already with ease in fact only complicates.” >
Well, more tags give to the map more information. Consider a specific place without relation (let’s talk about that later),knowing only the traffic_sign itself, the position avoiding multivalues, (let’s talk about that later also), the direction and the side (taken from the same way of the node), to unite meanings of what are you mapping. And the possibility to map human readable values and international codes both.
Also I think it is not the most large tag system for one item inside OSM. Think about anything with names in other languages. Nobody said “only complicates”.
2-"Currently the proposal is lacking any concise documentation of what it actually changes (not to mention examples of changed tagging) making it impossible to determine what is being voted on. It might make sense, it might not, but there is no way to determine that. >
In the Aim of this proposal you can read "The aim of this new scheme for traffic_signs is to unite the different approaches for mapping traffic sign as it is. It uses the most complete parts of the existing schemes. It uses the “categories” you can find in traffic signs law from Europe or US, like hazard with a node per traffic sign and with a human readable value,using existing OSM tags to this when possible and marking the position with a numbered subtag :2 or :3…This avoid misinterpretation errors from the tags and also the multi-value problems. Also allows the correspondence between some tags each other. And to be more specific you can use the tag traffic_sign:id=* to specify the code of this traffic sign per country if you know the value. It uses the traffic ID national code you can find in the traffic sign law of each country to mark which traffic sign is and also gives the entire importance as states do in their laws (we know it because when you ask a government e.g. Spanish government, for the database of traffic signs in their roads each traffic sign has a unique ID with its position and code.) There are so convenience to not fit more than three traffic signs at the same pole to make easier the readability for human eye at the reality. This proposal does not deprecate any method but establishes a scheme how you can map a traffic sign in a more specific mapping method.
This proposal establishes:
- traffic_sign:id for the specific picture with the national id of the traffic_sign
- traffic_sign for categories
- categories for human-readable values , with a scalable scheme (not which categories and which human-readable values)
- direction
- side
- position
-Other existing things will not change (the tagging of highway=stop and highway=give_way is so massive and so controversial than it does not fit in this proposal). "
Think about it, have the other systems some tag to map both the international code and the human readable value in the same node ?
Is it any category to map the other traffic signs rather than hazard?
Is not clear the reluctance to avoid multivalues in tagging?
Is traffic:id existing officially, with proposal ?
Things that don’t change: “This proposal does not deprecate any method but establishes a scheme how you can map a traffic sign in a more specific mapping method”
Is it not clear enough?
3-On the idea, I’m fine with traffic_sign:id=* , but not traffic_sign:#=* number suffix. On the execution, you have butch of “(new)” in Proposal:Extended_traffic_signs_tagging#Examples_of_possible_traffic_signs_human_readable_values that’s confusing on whether you are proposing them, and there’s a lack of actual examples showing why number suffix is needed. You didn’t explain your consideration of alternatives, and justification of using number suffix in the proposal. >
About the bunch of (new) values they are in the Example part (you are not voting nothing about that). You can read “If this proposal is accepted, then there will be other specific proposals about the specific human-readable values and its categories (following national traffic laws and most OSM used values) so does not affect this proposal.” I don’t know where is the confusion. These were here due to a petition in the thread discussion . Large scale change of traffic_sign to traffic_sign:id - #74 by osmuser63783 Is it bad to answer other people?
About the numbered suffix question. A fast answer would send you to Finland/Traffic signs - OpenStreetMap Wiki and ask to the Finnish community (I did not write this wiki article). A more extended answer can explain you the fact that every traffic sign should be mapped. In OSM there are some main ideas. One of them is “One feature, one OSM element - OpenStreetMap Wiki”. When there are two traffic signs you should map the two of them as a unique elements, not a list of it. Tag is traffic_sign=* , not traffic_signs=* . Well, if the position on the node is the same then you will indicate that with a suffix, like Finnish community does. I don’t know a traffic sign with two codes or with two meanings. You can map together, in the same node, but you cannot apply different values in the same tag (if you want to respect One feature,One OSM element) so suffix would be a good solution.
4- The whole proposal is huge and doesn’t describe well what needs to be changed. Most reasons given are assumptions that have been challenged in the discussions. >
The whole proposal is huge because traffic signs are a huge thing. Instead in OSM there are little number of them , in the reality you have…millions so mapping have to be open, and complete. Nowadays there are three methods and only one has a scheme accepted (without voting, from 2009) and other is being rejected…now. This proposal had many changes from the start to take care about the topics in discussion (and the proposer has answered all the questions done in talk and the thread. The structure of the proposal would summarize all the proposal:
Rationale-1.1 Present:Different approaches -1.1.1 By key-1.1.1.1 Highway.The classics-1.1.1.2 Human-readable values-1.1.1.3 Traffic signs by national ID-1.1.1.3.1 Examples-
1.1.2 By way of mapping them-1.1.2.1 On a way or area-1.1.2.2 Separated node-1.1.2.3 Node in a way-1.2 Conclusion: node in a way-
2 Aim of this proposal-3 How it works. How to map-3.1 Position-3.2 Direction-3.3 Side-3.4 Final example-
5-the proposal is not clear, IMHO it is far too long (answered in 3rd). I also don’t think indexing keys (1,2,3) is a good solution to tagging several signs together (answered in 3rd). An excellent proposal is concise. Having a dedicated key for sign ids vs verbose values would be ok, although I don’t think it is actually needed.
Well, some topics are answered in 3rd and 4th. But how about the need of human readable values? So…why the hazard proposal, with almost 30 values was approved? How about all the other main 20 “verbose values” we have inside OSM? Should any newbie mapper know all the international codes for traffic signs?
6-The proposal points to issues in traffic sign mapping, namely better documentation and perhaps more need for standardization. However, it is difficult for me to see any contribution in the proposal to provide more clarity here. Instead, it promotes one of three variants as an “ideal”, although in my opinion all three variants are appropriate, depending on mapping context, and do not exclude each other.
The proposal has (apparently intentionally) many open ends, which means that it does not answer any questions, but only leaves new ones. The human-readable categories for traffic signs remain completely vague and imho aren’t evaluable at all in this form. The number-suffix notation (traffic_sign:2 etc.) is unnecessary and has already proven to be useless in other contexts (street parking conditions). The proposal floods me with information that does not seem essential for understanding it, while the actual aim remains unclear. In the end, the presented tagging suggestion seems more complicated to me than the current way(s) of mapping - for example, it seems much easier to me to read a country code from an image table than to think my way into the chaos of human readable values. (Yes, there are regions where these codes do not exist or aren’t usable, but then the aim should be to provide a category system that is as clear as possible).
All in all, it seems to me that the proposal would like to enforce a specific mapping style that most other mappers don’t understand. I have tried again and again to understand the proposal process, but I have never succeeded. The main reason for this was the way the discussion was conducted and, in my perception, a lack of willingness to compromise by the proposal author. I’m really sorry for all the work and discussion you put into this proposal, but I can’t agree with it in it’s current form. Although I can see that things have moved in a better direction between the beginning and the end of the proposal. So a failed proposal should not be the end of the discussion, even if I think the discussion needs to be conducted in a different way. >
Well, it is not the best proposal ever. But it has minimum requirements of a proposal (https://wiki.openstreetmap.org/wiki/Proposal_process) Let’s start to answer it.
Citting proposal process article in wiki. 2 Before creating a proposal
2.1 Does it already exist? Some people say in thread of the community I have to do a proposal to map in this way, so I assume that does not exists. > Large scale change of traffic_sign to traffic_sign:id
2.2 Significance > There is no approved method yet to map with all the possible information a traffic sign.
Compatibility with established practices > The tagging system would be able to be adopted for other ways of mapping if someone makes a proposal and vote it.
Verifiability: You can see if traffic sign exists or not in the ground.
One feature, one OSM element > Each traffic sign has its own code so has to be mapped individually with one tag, also you can map other with the same node with a suffix, to assure the correspondence with other information mapped in the node.
Syntactic conventions for new tags > This proposal uses some values are in use in OSM, so there are not new.
Due diligence: Research: about ten years , 40 presets, 5 styles working and some messages in tagging list ([Tagging] Traffic sign direction tagging..) I have done enough research to assure a proposal that can work.
Private comments: I have done about 10 private messages asking about all of that.
British English : although my bad English some people help me to fix the writting errors I had in the proposal.
Similar tagging schemes: I have talk about the other options of mapping traffic signs in Rationale Section.
Explanation: The proposal is clear and it is ordered in a good way to be readable.
Potential benefits: I have talking about the mapping for newbie people and experienced people in the proposal. Also I express the errors have the other mapping system that this proposal fixes.
3 Creating a proposal > I have done all these timings until the votation.
4.2 Solicit responses > Four messages in three languages 4.3 Respond. After a talking page with more than 20 sections and a thread in the community with more than 130 messages I consider I have accomplished this part. Also I will answer all the opposite votes, you are reading these answers.
7-The proposal has (apparently intentionally) many open ends, which means that it does not answer any questions, but only leaves new ones. > As you can read in the talk section ,votes and in the thread some people is inviting me to make smaller the proposal and part it. This is what I have done. All open ends are parts of future proposals community has to do in the future. But if the first step is not approved how can do this other proposals? It makes nonsense.
The human-readable categories for traffic signs remain completely vague and imho aren’t evaluable at all in this form > they are all out of this proposal. They are in the part of examples.
The number-suffix notation (traffic_sign:2 etc.) is unnecessary and has already proven to be useless in other contexts > well, it was an option that it is not mine, but it is used and it works (see taginfo). I know it is not the only option but tell me how to follow one feature, one OSM element without saying relative position of two items.
the actual aim remains unclear (answered in 4th)
it seems much easier to me to read a country code from an image table than to think my way into the chaos of human readable values > You can do this, but in other tag. Should a newbie, in the middle of a street know what value (or searching it by a major searcher) is in Germany for maxspeed traffic sign, and in Spain?, and in Portugal? and in China?
The aim should be to provide a category system that is as clear as possible > well, in other proposal, first we have to know how to map the item itself then the other information of that item.
specific mapping style that most other mappers don’t understand (answered in 6th)
The main reason for this was the way the discussion was conducted and, in my perception, a lack of willingness to compromise by the proposal author > Well, these are personal perceptions and you are free of voting whatever you want. I have changed many times the proposals to fit ideas of other people from the threads, I have accepted the corrections done for other community people, and I haven’t left any message to be answered about this proposal, even negative votes. I have not get any comment for last week RFC in any three languages I have threads. And I have to read something like Voting zu traffic_sign:id läuft and accept it. Probably I have to retire this votation. But this will not be last time you will hear about this proposal or in relation to this proposal.
8-I have issues with understanding what this proposal actually proposes versus what is a description of current tagging .
I am missing information on the actual reason for (apparently) the key points this approval wants to change. E.g.: Why tag traffic signs as vertices on roads, what’s the advantage? (Because this requirement(?) comes with a cost as it seems to make lots of extra complexity necessary, such as specifying of traffic sign direction, side, and this :: namespace). Also, what use is e.g. traffic_sign=mandatory? mandatory-what? It seems to be just half-a-sign >
In the thread you can read some people talk about a draft proposal. The object of all this process is to be an accepted proposal due the other system has a defacto proposal from 2009, with some issues this new proposal would fix.
With a vertice on road you will unite the traffic sign to the way it affects (there is no traffic sign that has no effect at some point) , making relative position possible with two tags.
If you put the traffic sign in the real position you would need a relation to point the way where affects or a compass to say the cardinal direction it is faced (or located?)
If you put the traffic sign as a property of the way you are mapping the effects of the traffic sign…but not the traffic sign itself…and what can you do to mark the end if there is no traffic sign about that?
About the position, if you want to be clever with One feature, One OSM element how to do this without semicolon values? You can map two nodes one up to the other or map with two different tags, with suffix, for example, the proposition of Finnish community made 10 years before.
What would be mandatory category?
About the “half” category topic…we have approved in OSM traffic_sign=hazard hazard=* and I think nobody said it is just a half-a-sign.
9- This proposal in insufficiently developed and does not clearly communicate the problem, solution, and rationale (answered in 4th)
10- I do not see the much value for human readable traffic signals, if you have the id of the traffic_sign it could be automatically generated from that > but…if not? Do you know all the codes about all the countries? Should a newbie mapper now at all? Why did we approve hazard proposal if then we don’t accept the human readable values? What can we do with the other 20 values we have with use in OSM?
11-The currently existing tagging with (concatenated) IDs is ultimately much easier to use than what is proposed here > but it is wrong because this style of tagging does not use one feature, one OSM element.
12- "But this page fails to convincingly argue that large scale deprecation makes sense here. And yes there is “This proposal does not deprecate any method” fig leaf but we went through it before. Proposal claims something like this and people, sometimes author(s) of proposal immediately go into deprecating other “not approved” versions. > I don’t want to be rude but I don’t know how to tell this. So…should I have to swear by the God I believe that I will not change any traffic sign mapped before? Does Proposal system go in that way? In map we trust?
Also, traffic_sign=restriction makes no sense. That is a class of traffic signs, not a specific traffic sign. Maybe splitting proposal into parts is feasible? > This proposal is NOT about categories, you can read it in the proposal. This was already splitted out of the proposal.
How that puts preference onto node embedded in a way? In such case it is also needed anyway. “But others alone would need a relation” no, they would not need > It is true ,it is not necessary but…how can you make a relation between traffic sign and the point where acts it? Why in other items like enforcement do we need a relation? And how to map without a compass?
It is anyway only addition to restriction/implications mapped on routable way so it is enough so it is human-processed and machine-readable matching to road is not needed > I’m not a big expert about that but I don’t understand why a traffic sign does not affect “itself” the object. Also I don’t know what software can do that and when, because some approved tags are not considered by main software. Is it a official parameter for “not to map” some kind of objects?
13- I see no advantage in adding traffic_sign:2. The proposal is not clearly worked out. (answered in 3rd )
14-:2 should be avoided at all costs (answered) The proposal itself is quite hard to read though, I couldn’t really figure out what is changing and what stays the same (answered in 3rd and 4th)
15- I see no need to replace traffic_sign ( > 1 mio usage count) with traffic_sign:id > Please how to map the exact picture of a Spanish traffic sign of maxspeed or hazard.
16- In Europe, this would mostly result in a mass rename from traffic_sign=* to traffic_sign:id=*, which seems like a huge change and mostly unnecessary > The proposal says specifically “This proposal does not deprecate any method” so there’s no need to change anything already mapped.
But the no-go is the numbered suffixes. Traffic signs often relate to each other (for example hgv forbidden, with a sign below that, that excepts locals) and spreading stuff that needs to be interpreted together over several keys seems very stupid > With a sign below there are two traffic signs so it is important to have the two traffic signs well mapped and yes , you can have it in the same object perhaps but you will need several tags, that can be readed independent but in coordination.
17-On top of that, I prefer comma-separated values over numbered subtags like some previous commentors noted even if it kills readability for humans a bit (this is particularly for backwards compatibility reasons) > (answered in 8th)
18- A justification for a rejection is not mandatory. See https://wiki.openstreetmap.org/wiki/Proposal_process#Voting > If you have reasons to reject the proposal why you can write it?
Tagging with :2 or similar is the worst thing you can do to the OSM dataset. Furthermore, it is not clear whether existing tagging will be replaced or not > I don’t know if is the worst thing you can do it to OSM , probably don’t tag correctly and avoid the One feature, One OSM element , one of the pillars of OSM would be more bad, isn’t it?
19- this is far too unclear a presentation, and does not seem to be going in the right direction > Excuse, please write how can it be to be clearer, smarter and going…forward or backward (it’s a joke, it’s about direction, not side 
20- I did not understand the proposal after reading it once. You should keep things simpler and reduce it to the essential > (answered in 4th)
21-Too much stuff with no concise explanation > (answered in 4th)
Opposing mostly converting traffic_sign=* into traffic_sign:id=* - why is this necessary? > Why is necessary to tell the species of a tree? Why is necessary to map the signs of the railways? Why is necessary the international codes that makes a traffic sign a unique design?
But everything like hazard=* or maxweight=* are not for traffic signs, but a parallel tagging appropriate for specific elements like roads > Sorry but in the case of hazard the proposal talked about traffic signs. And yes, of course, traffic signs are a specific element of a road so it needs to be mapped in a unique way.
Real-world hardly has consistent signage to assume you can deduce stuff from signs alone > Traffic signs are from real world and are invented to sign this real world (by law also, not everybody can invent a traffic sign and can put it there) in a topic, traffic.
22-This would be significantly more cluttered for my country of interest (Norway) > Sorry, but I don’t understand why. Your country follows Vienna convention and does not use any complicated color. The nomenclature from your traffic law is clear so in traffic_sign: you would not have any problem to use it. And for the human readable values there are not any difficulties to follow too. Please, tell me the complication. We can fix it.
23-Also please don’t confuse the physical highway=traffic_signals with a traffic sign that announces/warns for traffic signals > I don’t know what can be the error between highway=traffic_signals and traffic_sign=hazard hazard=traffic_signals. They don’t use the same key…
24-Please make your comments, it is difficult to make it better if I don’t know where have to start. You can talk about any talked aspect if you want.
25- I don’t really know what this vote is about? The whole page or a very specific part of the tags? Not enough information > (answered in 4th)
26-Needs more clarity and concensus before such a massive change is approved and other methods are considered deprecated > (answered in 3rd and 4th)
27-Not a clear proposal. E.g. direction is not clear and may be ambiguous (direction is defined as the direction an object is facing to). The concept of side seems to be the second best solution as it requires the evaluation of the way’s details/direction first instead of having all attributes clear on the object. > direction has to be the same as the way it goes. Correct, side refers to the side of the way, it dependes on the direction of the way. Because traffic signs are in a way. Better would be to put in the real place but direction would be the cardinal point to refers, so imagine: you will need a compass to map traffic signs in a road with curves. Better have the info inside OSM itself. And although is a answer here telling that I don’t think so it can be so easy to put nodes next to a road and the road itself together without a relation in OSM, depending of a third software.
28-however adding stuff like traffic_sign=implicit - which make little sense except if you mean that’s the default. But default for what? Speed? Then current mapping is more… explicit traffic_sign=maxspeed + maxspeed=implicit - and the usual convention would to have a notraffic_signal=yes as we have noname=yes > Remember categories are not in this proposal.
29-Clarity needed > (answered in 4th)
