Hi community!
I have start a proposal to make possible “draw” the specific picture of every traffic sign of every country without losing the information of the traffic sign itself. New tag would be traffic_sign:id and I am open to comments and suggestions before presenting officially this proposal.
You can find the draft here. Proposal:Traffic sign:id - OpenStreetMap Wiki
Thank you for your time.
2 Likes
[EDIT:] Upon reading the proposal thrice (and seeing @Nielkrokodil’s post below), I finally got the idea. Sorry! Not a bad idea at all to add the :id qualifier to the country-specific codes! I hadn’t realized that the traffic_sign= key could also hold values other that the code.
The other possibility might be to change those values under a different qualifier. Presumably they are in the minority, and the traffic_sign= key has mostly the indecipherable codes as its values. Whichever is more prevalent in the database could be left as is?
I don’t perhaps fully understand what the proposal would actually change in tagging the traffic_sign= key.
In the proposal text, you have under “Actual Tagging” (I guess meaning Current Tagging), e.g. traffic_sign=ES:P13a, and you propose to change this to traffic_sign:id=ES:P13a. So, only adding the :id-qualifier. Have I understood this correctly? Could you explain in just a few sentences or examples, how that would benefit the tagging of traffic signs compared to the current situation?
On a more positive note, in your proposal you write:
To use this tag correctly, it helps to have visual feedback and contextual tagging assistance available in JOSM (traffic signs presets and styles would be adapted to that), also presets for iD to the style of NSI can be created.
Which I think is a great idea! That is, having the editor display a visual icon of the exact traffic sign alongside the near-indecipherable country-specific code.
I, for one, can remember only a few of the Finnish traffic sign codes by heart. Indeed, e.g. traffic_sign=ES:P13a probably says very little to anybody (even the Spanish mappers), but an added icon of that traffic sign besides it in the editors would be a great benefit.
That, however, could be done with the current way of tagging the traffic signs. The =ES:P13a value already uniquely identifies the country-specific look of the sign.
But perhaps I misunderstood your proposal. Please feel free to explain where and in what way!
I had to read it twice to understand your point. I think the proposal would benefit a lot, if you put the same traffic signs as examples of both human readable values and IDs. This would make it crystal clear that there are two “correct” tagging approaches for one sign.
1 Like
Do you have some statistics of actual dual use of human readable vs. IDs? I suspect, when looked at each sign individually, there is either the hunan readable value or the ID dominant.
Examples of my assumption:
traffic_sign=stop appears way more often than some id of a stop sign.
traffic_sign= ES:P13a appears more often than traffic_sign=hazard hazard=curve
If my assumption would be true, it would be possible (I don’t say this would be good or not) to define a complete set of traffic signs which get human readable values, and the whole rest gets the IDs. There would not be a need for traffic_sign:id then. It would be harder for editors (check the country and look up the ID) to implement an image of the sign, but not impossible.
Is it really desirable to map both the standardized national ID and an OSM-specific homebrew ID for the same traffic sign? After all, the former already unambiguously identifies the traffic sign, so the latter adds no useful information.
Given that the national IDs are in use beyond OSM (and therefore improve interoperability of OSM with the rest of the mapping world), and are much more complete than the set of tags we’ve invented so far, I would not necessarily consider inventing OSM-internal values for additional traffic signs an improvement.
8 Likes
Do you mean this?
https://wiki.openstreetmap.org/wiki/Proposal:Traffic_sign:id#Tagging
Or do you need some other examples? I can try to make the example you suggest.
Sure. Visual editing can help newbie mappers in this topic.
You can have this with traffic signs presets and styles for JOSM. You can install it from preferences menu.
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Presets,_styles,_libraries,_statistics_and_maps_with_traffic_signs_with_IDs_per_country
Something I glossed over and overlooked for long, the Italian traffic sign wiki has 2 code columns, the signs as per Italian design (JOSM supports those, including some like give_way: stop, traffic_signals showing the facing direction…)
And the Wiki layout
Intl codes we have, those undersigning Vienna, not a big leap to make this standard.
(Be warned, not 2 years ago some (Vienna?) codes were changed like the no entry sign, now C1a, so there could be fun to be had, ivanbranco spending lots of time checking the many hundreds I and others mapped. So happens most I didand do I leave the description on, so those were easy-peasy to fix,.)
My fav editor does not support a render of simple tags like stop, give_way, no_entry, but since a small week now have the Quicklabel plugin resulting in the TS labels to show in the edit view allow an ‘at a glance’
In simple words would be great though, always the same, anywhere. A very very very long haul to get that in… needs re-surveying
I mean this, but in the intro section of the proposal.
After having a look at taginfo, it looks like there is about 1/3 human readable vs 2/3 ID values for traffic_sign.
More than half of the human readable signs are city_limit, followed by maxspeed and then just very few others (stop, hazard, give_way, …).
With the IDs there (as expected) is no dominant value but lots of different ones.
1 Like
Probably I’m wrong but , for example, in traffic laws from Spain we don’t have written any table conversion between Spanish codes and the Vienna convention codes.There’s no “MUTCD” Vienna’s Spanish adapted edition. I think it will be a mess to define other international code rather than national because we don’t have an specific key to introduce codes in OSM (if we accept human readable values).
If you are talking about JOSM you have presets and styles to show traffic signs in 40 countries (well, If those presets and styles have missed the traffic sign you need we can update it). If you find some interesting country for you is missing I can do it.
Excuse me but I think you have missing the controversial tagging for highway=stop and highway=give_way.
When OSM started it was the way to tag it.
In wiki you can read a Stop sign or a Give way sign.
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
Then numbers change a lot.
Hazard is the first category of traffic signs accepted by proposal.
Now Human readable values can have big audience (specially with newbie mappers, completers, and so on).
I think it is a good moment (early enough) to establish the codes of every picture in other tag and make possible both standards living together (this will not mean to replace one for another, it is only giving the possibility to exist). Otherwise in the future there will not be space to tag these codes.
Well, those highway= tags don’t interfere with traffic_sign= so your proposed traffic_sign:id is not necessary for those two signs as they could be put into the traffic_sign= tag without deleting something human readable.
But probably in future we will have problems with hazard, maxspeed and so on. There is an accepted proposal with hazard. Probably more to come. The use of highway for a traffic sign is an anacronic but exists.
Each country have more than 200 different traffic signs (more or less).
In other cases there is no discussion about the existence of specific codes like trees.
Would be a good idea to tag into the same key the species, the genus and the species in our languages (not latin) for tagging the trees?
A renumbering of national license plates has already taken place several times in Germany. The same numbers were reused for completely different signs. For this reason, I do not trust the national numbering of traffic_signs and would prefer to tag the general meaning of the symbols.
2 Likes
I think it is interesting to see there are two ways of mapping a traffic sign that seems irreconcilable but when you read all the proposal you see there is a way to make it compatible both.
There are 37.000 different values for traffic:sign. Of those, 33.000 contain a : so I guess those are IDs. This means ~10% of the tags are human readable.
When looking only at tags with 5 or more osm elements, we have:
~5.600 tags with : and ~500 without : (again, ~10% human readable)
As I understand it, your proposal would deprecate all those 33.000 tags. I cannot imagine the effort to administrate this. I guess hundreds of wiki pages and templates would need to be changed.
Have you thought of reversing your approach and retag not the IDs, but the human readable values, which clearly are the minority, instead?
This has happened at least once in Finland as well. Last, on the first of June 2020. Slightly offtopic: I’ve been thinking of making a proposal to do an automatic edit on these obsolete codes for Finland for some time (in Finland it would be an ideal case for an automatic mass edit because none of the values were reused. I haven’t done an automatic mass edit yet, so It’d be a chance for me to learn something new too).
Back to the topic at hand, I agree with @Tordanik in that while the human readable values and the exact codes convey the same information, the codes are more precise and explicit. Therefore I don’t really see a problem in always overwriting the human readable values with the more exact codes. Moreover, the meaning and implications of many (or most) traffic signs are already coded in many other keys (like oneway=, segregated=, maxspeed=, etc.).
There is an approved proposal from the tagging system with human readable values (and the same tag traffic_sign) . It is only about one topic. Should we change all the human readable values to a new tag?
Imagine changing maxspeed, city_limits, maxheight, maxweight, hazard, stop (millions and the difficulty of separate real traffic signs of the spot you stop your vehicle) , give_way (same situation), stop_ahead, yield_ahead, variable_message,overtaking,… It is also a big effort. I encourage you to do it. I can help you to do it and I will vote for your way.
Nowadays I don’t see deprecate anything.
With time and the help of software (Maproulette) and mappers old traffic signs with international codes can be “translated” to new tag.
My intention is make available and compatible both systems. Then people will be able to decide if they want to use an universal description tag system for all the traffic signs (probably newbies) or they want the specific picture for every traffic sign (probably technically interested in traffic signs). In other century we can decide which way of mapping the traffic signs is the winner (if there’s any).
I have a question about that. If the meaning and characteristics of all the plants are coded in species why we accept species in other languages other than latin itself ?