First, please fix the citations, that’s not what I wrote.
Now, I still haven’t seen any convincing argument why mixing codes and human readable values as appropriate for some sign is a bad thing. You’re repeating this over and over, but I just don’t see any reason apart from shortcomings in current editors.
Sure, there are problems with long texts and non-standardized signs, but none of this is fixed in any way by your proposed new tags. The proposal currently shows only the most simple cases of single signs that are covered perfectly well by the two currently existing tagging possibilities. Complicated example where a new scheme really makes a difference are needed.
Please tell me what citation is wrong and the literate text. I want to fix it. It is not my intention to missunderstand or not copy correctly the words I cite.
I repeat it because is true. Two weeks ago a person deleted the info about some traffic signs because “he did not understand that codes” and as a maxspeed node the editor was suggesting this edition. Then I have realized it was a big problem because the codes I love are disappearing (I don’t have the control about all I map ever). I have search statistics with human versus codes and see how human are growing fastly (and I understand it and I respect it). But I want to map the id’s without having conflict with the rest of the mapper who use editors and assistants (I have made some presets and completers about that). Solution: what is easier: change a newbie who don’t know really what is doing or change myself adding two letters to the code I write it? For me it is not an “easier idea”: If this is possible then I will have to change more than 40 presets and styles, more than 5 styles with more than 10000 traffic signs (and its codes). But if this does not go on then, in a future we will not be able to map by international code probably because if we map it then other newbie mapper will modify it. I prefer to be able to map it.
You know my way and your way to map them it is not the same and I have an opinion about that. But this is more important than decide multivalues or osm existing tags. For this reason , the proposal is voluntary (not mandatory), the proposal does not touch the way of mapping anything more than two letters if you want to use it. And It does not deprecate anything. It is totally neutral although I’m the person who writes it. And it is open. For this reason I put only basic examples without conflict into the variety of models to map.
This is a subkey and a new possibility of map the international codes inside a traffic sign, diverting the info into different tags. I don’t think this is a new scheme of mapping. It is a little tweak , if you prefer.
Maybe @mueschel can you post an example with image and code where you don’t know how to apply the proposal’s approach? @yopaseopor please then tell us how you would tag it.
Yes, I can do that with existing traffic signs. Also with other existing examples everyone can write here. Remember this proposal is about the separation between human readable values and international codes. This proposal will not fix other gaps of the schemes of mapping traffic signs. You can propose an example and I will do the traffic_sign:id=* version.
Thanks for your position and your attitude.
No, you keep saying that traffic_sign=* should continue to allow international codes alongside descriptive names, and that traffic_sign:id=* should only allow codes. And some of us think that this is not a good idea. Introducing a new tag, co-existing next to the old one, because some new mappers are continually deleting or ruining the data you’ve added to traffic_sign=*, is, in my opinion, the wrong way to address this specific issue. At best, we might be trading missing data for inconsistent data.
The Vienna Convention does require additional panels to be mounted under the signs they modify, so this is no problem for Europe (until we consider destination signs).
Not exactly. I’m saying that traffic_sign=*may continue to allow international codes alongside descriptive names (or however would be your way of mapping the traffic signs, because this proposal is voluntary -not mandatory-, you can continue with the old way), and that traffic_sign:id=* should only allow codes (because if you follow the proposal you will separate the international codes to the subkey traffic_sign:id and leave traffic_sign for the existing human readable values, or also if you consider it use a generic tagging like traffic_sign=yes, an idea apported there)
I don’t agree (I would not present a proposal about that if I think it is a bad idea to separate into subkeys two kinds of information as we have separate in power or other schemes) with that but I respect it, of course.
I’m here to hear your solution and if there is something useful for this proposal I would adopt it without any doubt. Fixing editors with complex syntaxis or make learning to the newbie mappers to do in a specific way…it’s not under my control (and it would be fantastic if it is under yours, please act now.)
Yes, but OSM could be inconsistent “by nature” (Can you assure the existence of this feature as is it mapped ever?). The deleted and mixed data is a “new problem” we can afford now before it would be too late.
Because I don’t know anyone who would or did delete correct data in traffic_sign=*, I’ve never talked to them, and asked them what was the reason – things being too complicated to understand, codes looking gibberish, editors doing things they weren’t planning, so this happened without them even knowing. Can rule out the latter? Maybe someone was using a plugin to map traffic signs, and it didn’t load the already mapped ones into the editor?
I rather meant that traffic_sign:id contradicts traffic_sign, not that OSM contradicts the reality. That’s a whole different problem, totally unrelated to this.
On 1 February 14:09 On Spanish Community Telegram, about the icon he watchs on iD editor. He says me he sees a mandatory traffic sign on the editor (it was a ES:R301 for maxspeed).
Probably this newbie mapper had understood traffic_sign=maxspeed but not ES:R301.
It is the same problem , as you told us before
So, in inconsistent data who can work better? A newbie mapper without advanced knowledge or a interested mapper in this question (they would use other tag not in conflict with , know tools to check it, etc.) And for this reason you had told us
probably there will be few conflicts for this reason.
As I have demonstrated problems are starting. If we don’t do anything, problems will be bigger.
Do you have any better solution? Make a proposal to avoid this. Put it here to get comments and when it will be ready we’ll vote it to approve it (probably).
No, I don’t. But in order to criticize your solution, I don’t have to come up with a better one. I’m just pointing out possible problems of your suggestion, and why I see them as major, and not just minor. Nothing more, nothing less. I don’t hold a grudge against your suggestion, or you personally, and I’ve said all there is to say from my end.
So, you found one case of one mapper who misunderstood one tag and changed it. This could have been prevented by a better presentation in the editor, e.g. showing the human readable text in brackets, similar to how JOSM does it for language codes.
That’s nothing that requires a new tagging scheme.
There are some options that start mix human readable values and international codes, also there are starting to be other tags related to traffic signs tags that also have mixing kind of values. Now it is time to avoid that before “my” example will be repeated by thousands of newbie mappers in front of the “less number” of experimented mappers interested in traffic signs we have to fix it.
And I think that’s a problem. Having two equally-acceptable ways of mapping traffic signs means that any mapper who wants their contributions to be compatible with all applications would have to enter both tags, and that any application which wants to be compatible with all OSM data would likewise have to support both tagging schemes.
To me, this outcome seems worse than deciding on either of the two options could be.
It is not the first time that we have two schemes or more going on in OSM. Think about Public Transport V1 and V2 or the deprecation but not translation of parking:lane vs parking=lane scheme. Now we have some traffic signs with human readable values and others with international codes in the same place. Also there is an accepted proposal with human readable values but specialized mappers wish international codes.
Also there are more than a way of mapping traffic signs.
And we don’t map for the render/the editor…but if the render or the editor is important for us we can change the things without big problems
My proposal is voluntary because the other was finally a nightmare for me.
I remember the (from my point of view) “bad” language I had, the modifications of the wiki “in the process of voting”, or the “no reason” to say no in voting process, things that I had the sensation it only happened with that proposal (I have never read something similar in proposals in OSM, probably you know more cases than this).
The problem is as it is, we can close our eyes and say there’s no problem, we can “edit” the editors, have no better solution but not this or apply ten other subkeys but not this proposal.
For mapping traffic signs, one thing I like to contribute since I am in OSM, this will be a big problem. And I try to solution it with tools I have in my hand. Start separating this kind of information by interested mappers without being hostile to other ways of mapping is a good start to make this possible.
Please tell me other ways of make this proposal or others proposals successful about this topic. I will appreciate your comments.
After 13 days of discussion is any concern more? Anybody see it as positive explicitily? How many people from here would vote positive for this proposal?
