Proposal talk:Traffic sign:id

this incompatible proposal would obsolete hundred thousands of usages

I like the idea of seperating human-readible values and country specific traffic sign ids. But this proposal in its current form (as of 2025-02-09) would obsolete 300 thousand traffic_sign=* values of the top ten uses of this key. (See https://taginfo.openstreetmap.org/keys/traffic_sign#values)

A big incompatible change like this would cause trouble in the OSM community. For all kind of involved people this would create a challenge when I think about documentation, tool development, informing users, transitition existing values. I therefore would need to vote against this proposal, even when i like the separation.

Better we develop a backwards-compatible proposal. One simple option would be, to still allow the current use of traffic_sign=*, but additionally add traffic_sign:id=* if traffic_sign=* contains a human readible value like "hazard". Agent redd (talk) 13:03, 9 February 2025 (UTC)

The scope of this proposal is not make changes in past mapped items , it is making possible to map both kind of values without the risk of information in the future. Probably the redaction could be better (sorry for my bad English) . I have written other point with your suggestion. It is a good idea. --Yopaseopor (talk) 14:38, 9 February 2025 (UTC)

This is not resolved. You marked my comment as resolved without my consent. I therefore need to assume that you are not interested in an open discussion. I don't have time to spent to an ignorant person. If you want to succeed with your proposal I highly recommend to cooperate with the community and value feedback Agent redd (talk) 14:57, 9 February 2025 (UTC)

Sorry I did not how works this of the wiki (first time I see that was in parking proposal) and I have thought I have to mark it if I have made something to solution this. I'm interested in a open discussion as you can see in the community forum. Please forgive me. But don't insult me please. What do you need more ? --Yopaseopor (talk) 17:10, 9 February 2025 (UTC)

Thanks for reverting that resolve button! There are still some statements in the proposal that sound like being backwards-incompatible:

• "The goal of this proposal is to move the country-specific sign code to the traffic_sign:id=* tag
• "With time and the help of software (Maproulette) and mappers old traffic signs with international codes can be "translated" to new tag"
• in "Proposal tagging" there is no example for backwards-compatible tagging

Maybe I can try to contribute to your proposal, but only if you are really interested in making a fully backwards-compatible proposal. --Agent redd (talk) 00:09, 10 February 2025 (UTC)

I'm very interested in your opinion. Can you afford some examples about this backward compatibility you write are missing? --Yopaseopor (talk) 12:46, 22 February 2025 (UTC)

Please keep the etiquette guidelines in mind - I feel that this was unnecessarily insulting. Lumikeiju (talk) 01:57, 17 February 2025 (UTC)

What is the problem we are fixing?

Typically i like the idea of not mixing machine readable and human readable information into seperate tags. This is not this proposal as we just have a different presentation in a different tag. So we still have a "fixed" list of strings which should be in the tags like "hazard/curve". So we do not have human and machine readable tagging seperated, but we have human friendly tag values, and non human friendly tag values. Both need to be machine parsable.

As the non human friendly tag values follow a strict syntax "$ISOCOUNTRY$:$number$" i dont see the necessity to split it out to a different tag. Its just a matter of parsers allowing additional, human friendly values.

And redefining a tag to something different is a no go - So instead of traffic_sign:id it should be traffic_sign:description= Then i see a huge validation issue coming up where the human and the machine readable values mismatch. I'd rather like to see Editors beeing smarted in offering traffic_sign "point and click" possibilites. We do have stuff like this http://osmtools.de/traffic_signs/ which should probably be integrated into editors. Flohoff (talk) 21:40, 9 February 2025 (UTC)

As I have written here primary schemes are working with human readable values. Of course you can read a bunch of numbers and other characters like wikidata but try to do the exercise of determine that without using any assistant and connection to wikimedia's database. The same works with the international code of every traffic sign. Try to determine the code of some international traffic signs without reading their respective traffic laws. But you can map a traffic sign without problem with human readable values although you are a newbie mapper (for example). So Why not delete the numbers I don't understand and point the keys and values editors suggest me and are approved in the wiki? This had happened in Spain last week. More to come when there were other proposals in the same way.

It is not the first time we have in OSM this. Plants are tagged with their common names and their species with translations without big problems.

Traffic_sign:description is an interesting approach that I encourage you to afford and if you do some day I would vote yes if there is no possibility of separate traffic signs with international code.

JOSM/Vespucci has presets and styles to map every traffic sign in 40 countries graphically but never can avoid a newbie mapper starts to apply suggestions that he/she/it can understand better than a bunch of codes. I'm agree to integrate assistants and presets to other editors to make easier mapping with international codes, but also we have accepted proposals that in some case will occupy the same place and probably this specific information would be lost.--Yopaseopor (talk) 06:41, 10 February 2025 (UTC)

Same comment from my side. There's nothing to fix because there is no problem:

• in simple cases the user enters a human readable string. The editor shows the string and the data consumer infers the correct sign ID from the tag and the location.
• if required, the user can enter a human readable string, and the editor converts it to a sign ID.
• in complex cases, the user has to add a complex tag. The editor supports them by providing a list of signs to choose from. The editor displays thumbnails of the sign when selecting/hovering over an ID. In this case there is also no possibility to add any human readable value (apart from having values like "hazard_slippery_road_in_100m_for_2km").

The only thing remaining from the status quo is to add better support in our editors. There's just no need to have two, possibly contradicting tags for the same thing. Note that also requires a lot of code for QA to check if the two tags match. --Mueschel (talk) 20:35, 11 February 2025 (UTC)

* As I said in the above answer if there is a human readable string probably an advanced mapper will delete this and push the international code inside.

* Then newbie mapper detects that "his/her/its" node has changed deleting the info and modifying with codes he/she does not understand. He/She reverts the situation rewriting the tag to the human readable value = information lost. This is what we lived last week in Spanish Community. A real problem that encouraged me to do this mininum proposal, respecting the existing info without radical changes.

* It is true that there is no an approved list (by the way with negative votes of mappers) of all the human readable values or categories you can find in a "standard country traffic law" (Vienna/MUTCD). But we have an accepted proposal with 20+ values and more than 10 read values that can works like with a category. It is matter of time we have these problems continuously.

* You know that probably, there would be able to be other standard formulations, very short that worked with that but it is not the scope of this proposal.

* Making better support in the editors is good but It is not a problem made by this proposal also when this proposal maintain the status quo totally. This proposal only gives the possibility to put these codes in other tag if your way of micromapping match with this interest. And I believe so in this community that probably experienced mappers who finds traffic signs with human readable values will not delete that and simply use the new tag to match with the specific picture following the scheme they want to map these traffic signs to enrich this info with their way of mapping instead of crushing correct but not advanced information of other mappers (then the newbie mapper can check it and revert it manually with the risk of losing the information).--Yopaseopor (talk) 06:35, 12 February 2025 (UTC)

That is all not a problem with tags, but just about proper editor support - essentially it is the same as adding translations for tags like building=house plus edificio=casa - which we don't do for very obvious reasons. --Mueschel (talk) 09:57, 12 February 2025 (UTC)

The problem is the editor...and the place the mappers edit. And yes, you have reason: it is like a "translation" of picture between countries. We do translations like name= and name:es= and name:ca . We have species, species:en, species:es... So yes, it is similar.--Yopaseopor (talk) 20:36, 12 February 2025 (UTC)

@Mueschel, @Yopaseopor (and others): Only a note – if the editor support is the problem (and/or the map icon display!): I have realized a preset solution for German traffic signs (with the complete range, all IDs and its variations!) for Vespucci, with which you can not only map single signs (1 ID), but also signs with multiple IDs – which even distinguishes between the separators ";" and "," and contains some plausibility checks for nonsensical ID combinations. And a lot more (e.g. human readable values, too – but only for 1 ID signs, because I would prefer the IDs for multiple signs). I have not seen such a solution anywhere else so far. I haven't published it yet, but I've been using it for a while and it's fully functional. You can see 2 screenshots here (at the end of the post). I plan to publish it at some point. It makes heavy use of Javascript for combining and checking the IDs, which is possible in presets in Vespucci (and unfortunately not in JOSM!). This makes the mapping of signs with IDs really fun! You don't need to know a single ID ... I also have a data styling for JOSM almost ready that is able to display signs with multiple IDs (mapped as a multiple value tag with the separators ";" and ",") as multiple icons one below the other (up to 6, but it could easily be extended), including icon size adjustment, etc. This in turn makes heavy use of REGEX to tolerate as many possible spellings of the tag value as possible (e.g. ID follow-up text in square brackets). I actually want to publish that as soon as I have finished the final details (and such data styling is unfortunately not yet possible in Vespucci, but maybe it will come – MapCSS-based like in JOSM!). Something like that would probably have to be done for every country, including its particularities (see basic sign differences USA/EU, etc.)... But once it is implemented and works well (for ONE editor), it can perhaps be ported/adapted for other countries and other editors (at least for those countries with symbol-based signs – but at least for that!). Countries like the USA, with their (sometimes quite chaotic) text-heavy signs, have to find their own solutions. I'm not sure whether there can or should be ONE universal solution that can cover all cases in the simplest, most precise and most user-friendly way possible. Perhaps we should first show that it could be implemented quite well with IDs and symbol-based signs (with some effort, that's clear... but there are many enthusiasts at OSM!). I could perhaps contribute something to this. Once you have seen what is possible, you may see things from a different perspective. Maybe even countries like the USA would change their sign systems (*irony off*)! --Goodidea (talk) 04:54, 13 February 2025 (UTC)

Hey! What a good news!! I encourage you to work it and go on! You can see and use all the information you can find in https://github.com/yopaseopor/beta_preset_josm and in https://github.com/yopaseopor/beta_style_josm to do your tool (more than 40 countries, more than 10000 traffic signs) . I recognize you these presets and styles are about a way of mapping the traffic signs (from all that you can find in the wiki) to map traffic signs. It is interesting than other ways have their tools too.

For about this proposal you don't need to worry. As a "neutral as maximum can be" (I'm who I am and I have mapped what I have mapped, I cannot delete that) multivalues or the other systems are working as ever. If they have international codes inside they can would be in this subkey I propose with the generic traffic_sign=yes or the human readable value that exists in this node. This subkey is not mandatory, is voluntary. It is the possiblity to exist. And we try to find better structure as someone posted there https://community.openstreetmap.org/t/new-proposal-about-traffic-sign-international-code-mapping/125438. Good luck with your software!! And give us ideas if you wish--Yopaseopor (talk) 06:46, 14 February 2025 (UTC)

Alternative approach

• traffic_sign=* indicates code, or generic value, such as traffic_sign=maxspeed
• meaning=* indicates meaning, for example meaning=crossroads
• inscription=* indicates text, if present Something B (talk) 14:35, 22 February 2025 (UTC)

Good dichotomy, traffic_sign for human_readable_values or for id codes. Which of these gets into other tag? . In the https://community.openstreetmap.org/t/new-proposal-about-traffic-sign-international-code-mapping/125438/131 I have post some statistics. I think move id_codes would be easier and lower than human readable values, probably. Meaning would be good but Are you seeing better this than a category system with its values? (not the scope of this proposal). Also I like the approximation of inscription (it is a better solution than Free form text). For a big part of traffic signs from MUTCD (big part of it based on text) would be a solution but for others Would not be better using OSM existing tags like name for the city or maxspeed for the maxspeed? (again not the scope of this proposal, probably). What do you think about that? Thank you for your opinion and your interesting alternative approach.--Yopaseopor (talk) 14:47, 22 February 2025 (UTC)

"Maxspeed", "give way/yield", "stop" and some traffic signs are very common, meaning is practically identical regardless of jurisdiction, so generic value may be simpler for mapper. For other signs, mapper can indicate their types by codes. Text may be indicated in inscription=* as is. Mapper can add sign=*, but it also might be added by bot, because traffic_sign=* indicates type. Or mapper can add traffic_sign=yes and sign=*, and other mapper can replace yes with code. Something B (talk) 15:08, 22 February 2025 (UTC)

The intention is to be able to map both of them (not necessary or mandatory to do so). Your proposal for the tag sign give us a possible successful exit but with other discussion: a tag (sign) for all the values or is it better to reuse the value of traffic sign when is human readable?--Yopaseopor (talk) 22:19, 22 February 2025 (UTC)

Maybe it better to use traffic_sign=* for codes and sign=* for generic, human readable values (second also may be used for other signs, e.g beach signs, without traffic_sign=*). Something B (talk) 23:07, 22 February 2025 (UTC)

sign=* is a feature, top-level. It would be eg sign=traffic first.
—— Kovposch (talk) 04:53, 23 February 2025 (UTC)

So Will it be better to use three tags (traffic_sign=XX:yyy , sign=traffic and its subcategory , eg. traffic=maxspeed) than the use of traffic_sign=maxspeed (this exists now) and also the possibility to use traffic_sign:id=XX:yyy to save the code?--Yopaseopor (talk) 20:02, 23 February 2025 (UTC)

Yes. It allows use both of generic, country agnostic and human readable values and exact official codes. message=* may be used instead of traffic=*. See also sign=notice for off-road signs. Something B (talk) 13:59, 25 February 2025 (UTC)

Also, sign with additional plate may have different meaning. "Give way" with additional plate, which indicates distance to the "give way" sign actually means "give way ahead", with plate with "STOP" and distance means "stop ahead", but MUTCD contains concrete warning signs for it. Something B (talk) 16:06, 22 February 2025 (UTC)

For this reason second plaques (or complementary) are very important, because they can change the meaning (your proposed tag sign I understand). In Vienna convention we have these other codes about these complementary plaques so it is important to map both of them. But in this proposal this is out of scope (the proposal says there is no change on the way of mapping it, only the key if there are codes). A affordable way of mapping each traffic sign and each value by individual probably would have to be made (not in this proposal).--Yopaseopor (talk) 22:19, 22 February 2025 (UTC)

Sign with additional plate may be considered as single sign for human readable tag and as two distinct signs for tag with codes, for example sign=stop_ahead + traffic_sign=CC:R1;CC:P2. Something B (talk) 23:14, 22 February 2025 (UTC)

The use of "ahead" as a value would be interesting in Vienna situation. I think we have to make difference between Vienna , with complementary plaques (in this situation) and MUTCD that have specific plaques with this meaning stop_ahead.--Yopaseopor (talk) 20:02, 23 February 2025 (UTC)

This is the same, just different approaches. It is similar to "ice" (warning sign) vs "slippery road" (warning sign) + "ice" (complementary plate). Something B (talk) 13:59, 25 February 2025 (UTC)