Am I missing some discussion about this topic? What is your opinion about these changes. IMHO this should be reverted until a detailed discussion has taken place. In the current state these traffic signs are not accessible for any tool using the traffic_sign tag as documented in the Wiki. https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Traffic_sign_IDs
However, your example shows that the usage was already “broken” before: The user used traffic_sign=ES:R1 + traffic_sign:2=ES:S800, the common tagging is simply traffic_sign=ES:R1,ES:S800. “traffic_sign:2” isn’t in use anymore since 8 years.
It would make sense to confront the user with this and possibly invite them here. In any case, the mass edit does not seem legitimate to me.
1- My proposal was finished but not voted, many years ago. What is the problem? Is it the only draft in the wiki? Is it the draft less complete of the wiki?
2-It is not totally true. You have forgot to say the change for traffic_sign was for the tag highway=give_way (firstly used and massive accepted if you read taginfo). Traffic signs were modified to maintain the Spain’s picture and also to fix direction tag. We have discussed in the Spanish group of Telegram about human readable values.And then I start to search it. As the tag for human readable values would be the same tag as national id’s it would disappear the specific pictures and national ids for traffic signs.
Are you saying we have to retag 120000 Deustchland traffic signs with national id to loose the pics and the national codes or should not use human readable tags in these more than 120000 traffic signs?
3-I have searched a solution. As the wiki did not say anything about that I have found in taginfo the answer, with a few results for traffic_sign:id. Then I have modified the proposal because it could be possible to find the information.
4-Tell us what is your option about that? How you will combine traffic sign with human readable values or national ids? There are more than 400000 traffic_sign with national id’s. There are more than 2500000 traffic signs with human readable tags. What can we do? How we combine them?
Tell us your opinion and your knowledge. We want to hear you not only about 25000 Spaniards traffic signs, tell about your country’s traffic signs, tell about your tool OSMLaneVisualizer, for example. Did you remember who helped you to make it the nodes readable as traffic signs?
5-I’m very surprised how this question is so “exquisite” but iD editor would invented traffic_sign:direction without any problem, without any voting process and without any discussion of that (no, writing 10 messages, with people clearly against , without anyone accepting that but no voting and going to other questions is not a serious discussion, probably not also for a seven years-old child). It was no problem for existing key direction, it was no problem to repeat the same method as crossing=marked and so on.
Tell us. How can you tag human readable values with national id’s too. Thanks.
It is not true. See traffic_sign:2=FI:372 | Tags | OpenStreetMap Taginfo . Either of these items are not mine. traffic_sign:2 was made for Finnish Community. Also second position for traffic sign was in used within :backward and :forward subkeys , from German community (they revert me the conversion to direction simple tag, for example).
Documented?
Accepted?
You can see at the wiki “De facto” description. There is no official acceptation or voting about that.
About the comma values, in 2022 someone specify something more in the wiki about that. Can you show me the consensus messages about that ? Where is the official transformation of that?
Finnish community had a good way to manage second position traffic signs and avoid multivalues. Are they wrong? How to show a second only position traffic sign with first value empty?
Is there any situation where having both national sign codes and human readable values with the same key causeses any ambiguity. AFAIK, sign codes always have a country code and a colon, so at least I don’t think there’d be any opportunity for confusion. (Of course whether having them separate may have other advantages, but so far I haven’t seen any advantage to having them as separate tags)
This is the first time I’ve come across your proposal. My first impression is that, if only we had adopted it in the first place, years ago, then traffic_sign wouldn’t be the inflexible mess that it is today: two competing, mutually incompatible syntaxes, neither one able to express all that needs to be expressed about a given country’s signage system. I’ve griped about these syntaxes in the past:
But now that it’s almost 2024, we do have to think a little bit about backwards compatibility. The last thing we need is yet another competing standard. I’d suggest scaling back the proposal’s ambitions a bit. I realize that the Finnish community came up with the indexed :1 notation first and used it in a massive import, but incorporating it into a proposal means you take responsibility for defending that practice.
I’ve always thought of indexed subkeys as an elegant solution to the lack of an array type in OSM’s data model. (It’s probably going to come in handy for sources in OpenHistoricalMap.) However, a user-friendly editor such as iD would basically need to have its UI redesigned in order to accommodate this kind of nesting, with the attendant usability challenges, and some data consumers would face similar obstacles. I don’t think robust software support is very realistic at this point, and that will hamper adoption of traffic_signs in general in the long run.
Instead, I would suggest formalizing the practice of mapping each sign in a sign assembly as a separate node, distinguished by layers. This practice is also in use and compatible with both the documented syntaxes. Mapping separate nodes takes advantage of existing software support and also accommodates more micromapping – essential for the extremely common multidirectional street sign assembly I highlighted in the thread above.
Other than that, I appreciate the idea of splitting the sign code from something human-readable. However, I don’t think the human-readable tags need be as precise as the sign codes. General categories like warning and prohibitory should be enough; editor presets and data consumers should be responsible for shielding users from the complexities of raw sign codes. Otherwise, I don’t think we’re prepared to devise an international ontology for everything a highway department anywhere has codified. For a sense of scale, the MUTCD and its local variants are used only in one country, but there are about 12,000 sign codes among these standards and plenty more standardized signs without codes. We’ve barely started cataloguing them – the wiki translates only 2,900 of these signs to OSM tags so far.
@yopaseopor For that object specifically, I would disagree with using highway=give_way (absolutely) + distance=150 (strongly) for “give-way in 150m” . highway==give_way and =stop should not be used at advance signs to show a junction control ahead. distance= used in =route and =milestone now has different meaning, and both of these two usages are unclear. What about a sign applying to a length of road? No overtaking or u-turn prohibition, and falling rocks or other warnings for some metres to miles . length= on the traffic_sign= , will it mean the “length” dimension of the sign plate??? Conceivably, some form of height= could be used for the “height” of the sign, with more potential issue for vertical dimension of the plate vs elevation above ground.
For traffic_sign:id= alone, I don’t find it a thorough solution to separate and simplify. Country suffix traffic_sign:ES= can be used to not repeat ES: in every val.
For multiple signs, first of all, I would like to remind that numbering is already used in seamark:light:1:*= , for better or worse. I don’t find it ideal or needed yet. For road traffic, as an initial step, I suggest following railway:signal:main:*= to have traffic_sign:ES= / traffic_sign:regulatory:ES= ( traffic_sign:main:ES= may show it is the “main” sign, but is not meaningful compared to “main” rail signal) =R1 + traffic_sign:supplementary:ES=S800 . While using traffic_sign:ES= frees up traffic_sign= for human-readable vals, using traffic_sign:regulatory=give_way would preserve traffic_sign= in the transition period.
Fundamentally, I’m not a huge fan of creating a group of points arbitrarily for signs at the same pos. It’s better to get Proposal:Node - OpenStreetMap Wiki used (I would rename it to type=point to represent the point concept, and avoid confusing with node object), if traffic_sign:regulatory= is not enough.
It is true that there are a few results, but I remember there was a plugin/preset/style for JOSM helping to do that as you can read on Finland/Traffic signs - OpenStreetMap Wiki. Even it was started as an import you have forgot the aim of it. In the wiki you can read the possibility of contributing to it with surveys. When you do an import your intention is not make a closed system that never ever would be updated, your intention is add information massively to the map in a way it can be managed and updated in a natural way forever. Then you’ll be able to do interpreters, renders, statistics and similars about that for consuming nationaly o
When you do a proposal or you want to edit some “new” in OSM first you have to do is see if others are doing the same as you better, first you search the wiki and learn how it does other people than you and take the better option. If you think your way is better then you can write a proposal with your documentation and your uses you’re proposing. Also if you don’t find anything in the wiki you can search in taginfo, the complete statistics for each tag. And use it. It is better to use a few items tagging system than a totally new system, is it?
What? It is the first time I heard about layers to avoid multivalues. Another use for them never used in this way instead of using an existing subkey?
I don’t agree with that. OSM is wide so all the traffic signs should fit in it. Or are you saying some species of trees are not necessary for mapping? What about other uses of poles? As you can see with hazard (Key:hazard - OpenStreetMap Wiki), it is necessary to be precise, because if not mapping would be inconsistent. Hazard is now accepted so we can do the same. Traffic laws from many countries have the same parts that you can find in the proposal. Also they are the same parts Mapillary traffic sign recognition system had.
I have talk with Jan Erik Solem and others a few years ago about that.
What?? OSM , the system you can map anything with a simple node,way or relations can’t handle items contemplated in laws?? If we can do with hazards why we can’t do with other topics?
In a highway governments can only put official traffic signs. And also there are advertisings we can map…or can’t we? https://taginfo.openstreetmap.org/keys/advertising#values
So are you telling me we can’t map anything but these 2900 traffic signs? There are more than 14000 different species of trees mapped in OSM, are you sure we can’t? I don’t think we can’t find in the wiki these 14000 species.
I have made 40 presets and 5 styles that can handle that. Other people done its countries. What is the problem?
If anything, what’s arbitrary is that we claim to be mapping “a traffic sign” that represents multiple physical objects at different (vertical) positions. In my view, the corollary to “One feature, one element” is “three features, three elements”. The best part of this proposal is that it favors secondary keys instead of stuffing all the details inside a single inscrutable traffic_sign=* tag. But syntactic gymnastics is inevitable if we continue to stuff the details about multiple signs in the same element.
It is not true. It was not an automated edit. I was done manually with JOSM, as fast as I can but never automatically or in a import style. I have searched the traffic signs with lacks of some tags and I have added manually. Also I have a Maproulette quest for people who does not like JOSM. I know every edition I do. And any of my last edition are bigger than +350 per ten minutes (normally). I can download all the data I need and I work at my speed. When I have a part done, I upload to OSM again.
I realize you might be feeling a bit defensive due to how this conversation started, but I honestly meant my remark as a compliment. Your proposal would’ve been better than what we ended up with.
It’s not so unheard-of. 3D and indoor building mapping also make use of layers to avoid glomming multiple related or unrelated features’ details onto the same element. Otherwise the result would often be incomprehensible. Fortunately, sign assemblies tend to be spatially simpler than building layouts.
The primary advantage of my suggestion is that it’s fully backwards-compatible, whereas your proposal requires some retrofitting. In fact, the layer-separated traffic sign nodes slot into existing tagging practices well enough that I’m not sure how I would word a tagging proposal about it.
Just so you don’t think I made up this layer-based idea myself, nearly a quarter million traffic sign nodes have layer tags on them. This practice has been “in use” for longer than the Helsinki syntax. It just went unmentioned on the traffic_sign page because everything can be tagged like this to indicate a vertical position.
I’m not sure what you’re asking. In case I wasn’t clear, I was trying to point out that the proposal includes very long tables of possible values for keys such as complementary=* and information=*, as though these are comprehensive. If they’re intended to be merely suggestive rather than comprehensive, then I’m glad you provided these examples, so we can get an idea of the expected pattern. But regardless, mappers in some countries will have to do a lot of extra work to agree on a set of consistent values for each sign in their national standard, and perhaps the mappers of each country will need to ensure some international consistency too. (Do the values have to be British English?)
Imagine if, instead of merely tagging the scientific name of each species of tree, we had to also tag the common name of that species, in British English. I just mapped a bunch of Christmas trees, including some species that have half a dozen common names in English. Even scientific names can be inconsistent, but whoever decided that species should be in Latin at least recognized that OSM is primarily a mapping project. With traffic signs, presets can help, but someone has to create the presets, after someone catalogues the tags on the wiki. We’ve got so much work ahead of us just to get to a functional state, and you’re asking us to do so much more.
When I do something I dedicate lot of time to do it best as I can. In the middle somebody (tell me exacly where is that consensus) change the decision, the wiki and last the uses. I have worked in this topic since 2012-2013, I read the wiki, saw taginfo and start to do some little apps (I have done preset for Road Sign plugin, preset for JOSM -Spain was the first-, a complete and complex preset, months of work…And then consesus changed. Change everything and also change the wiki.
When I started to do that one option was to use existing tags rather than invent others. Was it a bad option?
To avoid problems I’m only changed my proposal. But it is not a problem. We can change all the human readable values as hazard for example.
I don’t think create any country subkey would fix it. If it was a big problem use forward and backward as a subkey imagine more than 40 different subkeys. Also I don’t know why is better solution is subkey with country=value rather than subkey for id=country:value .
Generally, this policy covers all edits where changes are made to objects in the database without review individually by the person controlling the edits. This includes:
[…]
use of find-and-replace functionality using a standard editor such as JOSM or finding using services such as Overpass API and changing without reviewing each object individually;
manually changing tags without adequate review;
Sounds like “finding using services such as Overpass API”.
350 edits per 10 minutes is less than 2 seconds per edit. That sounds like “without adequate review”/“without reviewing each object individually”.
I know that the border between manual edit and automated/mechanical edit is not sharp. I am sometimes not sure about that too. It is sometimes hard to tell what edits are ok to do without discussion and which should be discussed. But the more experience I gain the more I tend towards discussing them.
As I am not an traffic sign expert nor an expert for tagging them, I realy can’t tell if the edit damaged or improved anything. But as this was an undiscussed mass edit I suggest that it gets reverted. After the revert the proposal can get refined, discussed and voted on. If the proposal gets approved a mass edit can get discussed. If there is consensus in that discussion, the mass edit can be done.
I have no doubt that you @yopaseopor had the best intentions in improving the map quality. It is just that communication is crutial in a community driven project like OSM.
I agree. traffic_sign:[country]=* or traffic_sign:id:[country]=* would allow us to indicate that two countries dispute the sign code for a particular physical sign, but that seems very unlikely. At least here in the U.S., I’ve never heard of such a dispute between states, but I have frequently seen one state use another state’s standard signs, and I’ve even seen an occasional Mexican sign on private property in California, even though the U.S. doesn’t adhere to the Vienna Convention. traffic_sign=[country]:* or traffic_sign:id=[country]:* allows me to map these imported signs without adding too much flexibility.
Sorry for my bad English. I wan’t to be rude. I’m a teacher in a primary school. I can teach seven years-old children. I don’t remember in tagging list and in this forum these kind of adjectives going to a ten years OSM active mapper.
My intention it was show you my proposal is not an one-day 2023 invention. For me it is a very important topic and I want to be inside OSM in its properly way.
If you adjust and use only nodes and remove all layer=1 as unic option from these results you have this. overpass turbo . Less than 1700
Remember:
Yes, mapping traffic signs around the world will be one of the long-term uses of OSM, with users like TomTom you can be sure. I have used English because OSM uses English. Also the same values were the same used by Mapillary recognition traffic sign system (remember the game?). But we can change that if we agree doing it that and select these correct values. In OSM everyone map as everyone can and want, so if someone wants national id I will not stop them and If someone wants human readable values, as hazard I will not stop them.
But tell me , Does anyone forbid you of do that?
Yes, There more than 40 presets for different countries in JOSM/Vespucci, 5 styles that covers all over the world. And if it is interest of somebody I can teach him how to do that .All the code is in github, and some of them I have updated some times.
You can see them inside the proposal Proposal:Extended traffic signs tagging/Tools - OpenStreetMap Wiki
I have fond memories of that game. Many tail lights incorrectly detected as stop signs. And then I got trapped in the Sign Post Forest.
Over the years, I’ve heard very much about Mapillary’s sign icons, these JOSM preset packs, and also Mapbox’s sign detections, but I feel underwhelmed by the software support overall. Maybe it’s just that the signage systems in the U.S., Canada, Australia, etc. are so much more complex than in Vienna Convention countries. Your Kenzi3D plugin comes closer than most, but it’s a moving target. Just last week, a new national standard was issued, which means about 40 regional standards will also be revised soon (some of them even longer than the national standard). I’ve been busy updating the wiki documentation and will need to think about mass-retagging soon, due to scores of sign codes that got redefined overnight. We still have lots of placeholders in the MUTCD conversion tables for things that no one knows how to tag in OSM.
I look forward to either id-tagging-schema or name-suggestion-index adding traffic signs so that iD can make sign mapping accessible to less tech-savvy mappers via a WYSIWYG interface. All these tools will have to grapple with the sheer number of signs and the complex layouts within those signs.
I guess not, but whenever I spot someone adding common names, I do make an effort to figure out the scientific names because the common names are so unreliable. A few years ago, a high school geography teacher set a whole class loose in an area I watch, instructing them to map plants for foraging. I was very puzzled at all the natural=treespecies=banana, wondering if it might be the one variety that can actually grow in this relatively cold climate. Eventually, I realized that the kids had cheated: they spotted tiny weeds known as “plantains” and tagged them like plantain banana trees. Yuck!
My main motivation is only to cut down on the repetitive prefix. The meaning is traffic_sign:regulatory=give_way is codified as traffic_sign:regulatory:ES=R1 in this country.
Yes. Who don’t use it? You can use it from JOSM it self. If I’m interested only in give_way traffic signs Why I have to download all the road? Then like I have few data I can include big extension of data. Then I can work with it and upload at my rhythm. Can ask yours? What kind of items? At what speed? How many per changeset? With which frequency?
I’m only improving data as MapComplete or Streetcomplete does. Is it bad? What is the fault? Use of JOSM? Mapcomplete, Streetcomplete, Maproulette are better?
You can revert that if you want and what will do you: erase some correct direction tags? Delete some thousands of give ways and substitute by its national id? Ok, do it, if you want.
Always I have answered to all messages I have received about that, in changesets, via messages, via issues. In years I have done proposals, messages to tag list, heard some insults to me or other community pals, and interest for some people in that topic, inside and outside OSM. Now I’m writting in this forum too.
Traffic sign ID and traffic sign meaning (human readable value) are different. It is not a repetitive prefix.
Is repetitive name:xx in a city with the same value?
OK, we can use the key id: alone, or the key symbol: … but these refers to traffic signs, should be clear, what is the problem with traffic_sign:id ?
placeholders in the MUTCD conversion tables for things that no one knows how to tag in OSM.