This thread got a bit distracted and divided into three different topics. Let me try to summarize what we got so far (please feel free to intervene if I got it wrong!)
“Update tagging scheme for traffic signs”
From the discussion it seems clear that there are contradictory tagging schemes in use and some more still present although not actively used since many years. In addition there are several ideas about how the tagging scheme can be updated. These ideas seem to be conflicting with each other so it seems that we need a larger discussion among mappers world-wide and possible users of this data. I suggest that we start a page in the Wiki and everybody can add a few real-world examples of their preferred tagging scheme, with photos and possibly arguments why this particular is the most suitable one.
Once we have these descriptions, it might be a good idea to have a poll here in the forums to attract the most opinions possible on this topic.
In my personal view, I’m perfectly fine with the current scheme and I’m not very keen on exchanging it with another one.
“Mechanical Edits”
The precise definition of “manual” edits vs. “mechanical” edits is a complicated thing which, I think, we can never define exactly. Editing routines of different people just differ too much from each other to have a clean yes/no classification. In this particular case it seems that the size of the edit is such that it should classify as “mechanical” more easily than, e.g., a fully automated local change of a few hundred tags. But - in the end it doesn’t matter how we classify it, what matters is the common opinion about how to deal with it. Calling it an “unambiguous mechanical edit” would just mean that there is no need for discussion and a direct revert is backed by OSM rules. I think that’s not what we are after in view of this extended discussion so far.
“These particular edits”
There were only few responses to the central question of this thread - what should be done with this particular set of edits. Those comments mainly expressed the opinion to revert these changes for now.
The main issue seems to be that there weren’t new tags added (which would be perfectly fine), but existing tags that were done in accordance with the Wiki were replaced by new ones.
If we revert this now, it doesn’t mean that all the work is lost - if we have a consensus in the near future it should be possible to re-apply these edits with a lot less work, just checking for objects that have been edited in the meantime.
Let’s start and extract something positive of all about that. My intention is not to approve “my” proposal. My intention is the possibility of add and edit all the existing traffic signs in the world. If the proposal has to be written four hands for me it is not a problem, if the proposal has to be discussed with all over the world let’s do it. If the proposal has to be unnamed (no author) , no problem. For my point of view…
We need:
-international codes
-human readable values
-categories for traffic signs
-subkeys for the content of the traffic sign
-different position and orientation of the item by syntax (traffic_sign:xx=* or layer=* whatever.)
-easily adopted by renders, coders, editors and programmers
-simple to be edited by anyone with any editor.
Preferable
-no multivalues
-use of existing tagging schemes for OSM (keys,values,etc.)
-adaptability (some communities need on the road, some communities need at real place). If we can live with PTV1 and PTV2 we can live with two logic and physic situation.
Ok, probably my way of edit saving time is not the most orthodox way of doing it in OSM. But is it wrong? If my edition would not contemplate a few used key should be any problem to do that? What is the maxspeed an editor can edit? (I’m a particular, imagine a company with lots of workers). As I explain here, for years I have discovered I’m faster drawing and creating than importing it (map is not blank and conflation is a pain).
Also, what is the limit of kilometers around its house one mapper can do? It is very common in Spanish community to take actions together in all Spain, from Mediterranean to Atlantic when we are interested, like #1calle1nombre (name all the streets of Spain) which started in my home city. Is it not correct too?
I’m not agree with it, what do you fix with it? Do the 25000 Spaniards traffic signs have to lose their national codes? Do the 25000 Spaniards traffic signs have to lose their human readable values? What is better?
Not exactly, when existed only national code I have applied the human readable value, and the inverse, when existed only human readable value I have applied national code. It is not important for me if it is traffic_sign:id or traffic_sign:ISO or traffic_sign:whatever , I have found it on Taginfo and I would have adopted whatever similar solution.
Tell me ,what is the tag to maintain national codes and the tag to maintain human readable values ?
Thanks.
As this post got 4 upvotes and no downvotes there seems to be some kind of consens that this plan is at least not totally bad. @yopaseopor how much time do you think you will need to refine your proposal? Maybe 2 weeks? After that at least 2 weeks of RFC (request for comments) and also at least 2 weeks of voting are needed (see here for details). That would add up to 6 weeks. If I add a little bit of additional buffer I sugest that the proposal exactly matching your mass edits should eighter be approved by the end of February or the edit gets reverted. @yopaseopor do you think that is possible? If not, how much time do you think you will need?
Do you think that, alone, I can fix in 6 weeks with little changes, something it was on the wiki for almost 6 years without any consideration or interest discussing it (you can see tagging list to counter times I have tried it), that started now with messages about the quality of the proposal itself, and which now needs so people to find the big consensus that It does not have in the last years and that it is not demanded for other no-proposals?
For me ,as I have said in last message reverting is not the solution. You can do it but you will not fix anything doing it. And now it is clear that we need some big discussion and some big proposal to deal with one of the probably most massive items you will find in OSM next years. I would be able to help but I will not do it alone (because it has nosense to fail because it is “my” idea) .My intention is to map with human readable values and with national codes Worldwide all the traffic signs here, in OSM, and if is not today some day in some way we will find the way to do it. Someone have any different idea than “leave it as it is” or “kill the proposer”?
It’s exactly the opposite. Take the node I linked in the first post: Node History: 6355477497 | OpenStreetMap . The readable information in “traffic_sign” got deleted and replaced by a new tag that is invisible to anybody who reads traffic sign information as documented in the Wiki. As others pointed out, the added highway tag is not a valid replacement for a traffic sign tag that doesn’t even apply at this position of the road.
A revert would restore the state we had before: Usable data in a documented format in the OSM database. There is nothing wrong with having a national id in the traffic_sign tag.
Yes, the plan is good, but I don’t think the time scale fits. Right now the proposal is very hard to read, contains huge tables without much information, no examples and so on. We need to plan at least several weeks to bring this to a state that can be discussed about.
I would prefer to not keep the data in OSM in a questionable state for so long.
If you do not belive that your proposal is in good shape and will get appoved without problems I realy do not understand why you already edited according to your proposal.
Ok, what time scale do you @yopaseopor and @mueschel suggest? I would realy like to set a fixed date. Without a fixed date this discussion will go on forever and in the end we will have neighter an approved proposal nor a revert.
What do others think about the timescale?
As you can see there is no doubt about the purpose of these two map features: a “x” sign.
You are talking about node that it was made for me many years ago. There is no human readable value until my last edition in which I have saved the national id to the tag and add the highway=give_way tag to better understand the traffic sign by non-Spaniards . That’s is what you would revert.
It’s not my fault if some users forget about the original purposes of one tag. Is it a give way sign or is not? It is. With “x” distance and it is complementary traffic_sign_id. In Spain.Yield ahead , in Spain, does not exists. There are two traffic signs for these. Probably nowadays all the stops and give_ways should be translated to traffic_sign key. But this is another battle.
Contains huge tables with all values you need made it with the collaboration of Mapillary people and all their recognition traffic sign system. The proposal has eight examples in two pages. First there is the explanation how to use the tags and then there is one specific example per different section. How many examples do you need to consider it complete?
What is your proposal? Revert totally? Would this make clearer the information? Would this make better the information? Would this make more understandable and stable the information? Would you fix this problem? Probably not.
I see some possible tension between these goals. Earlier you made the case (which I agree with) that the traffic signs should be accessible to every mapper via presets. If so, does it really matter whether there’s a comprehensive set of human-readable values that’s as precise as the sign IDs? With the human-readable values, someone who isn’t using presets will still need to rummage through a very long list of hyper-specific values for all but the most common signs. This is the status quo of course, but I just wonder if it’s worth agonizing over this use case if we can rely on presets.
The other aspect of these human-readable values is that there are no country namespaces, so you’re expecting us to harmonize every country’s signs according to an international system. This places an extra burden on countries that don’t adhere to the Vienna Convention and so have never needed to align their signs to those of other countries. For example, what does regulatory=building_direction mean? Do we have a sign like that in the U.S.? Maybe under a very different name?
If you’ve already attempted to classify signs from multiple countries according to this system, I’d suggest presenting a correspondence table to each country’s forum category so they can spot any incorrect translations. After all, you need to be very familiar with the driving laws in a country in order to interpret its sign standard correctly. At a glance, I find regulatory=toll_pass_only somewhat amusing. It’s clearly a reference to the following sign in the MUTCD, which was renumbered from M4-20 to R3-31 a couple weeks ago:
There’s actually no such thing as “TollPass”. This is the federal government’s fictional brand representing any electronic toll collection system’s logo. (Real examples include EZPass, FasTrak, and PikePass, all documented on the payment wiki page.) I wonder what other misunderstandings have arisen because you haven’t reached out more directly and proactively to each local community for input.
In those six years, I guess either the clunky mailing list stood in the way of sign nerds like us noticing your proposal, or we didn’t take it seriously enough. Now that you’ve brought it to a head by implementing your proposal regionally, we’re faced with a choice to keep the changes or refine them – especially since the tagging scheme you’ve designed seems to focus on international harmonization. If you wanted feedback without the rush, I suppose you could’ve conducted a smaller-scale edit and proactively asked for feedback on this forum. But here we are.
Two weeks sounds like a pretty short turnaround time for a proposal that frankly hasn’t gotten the attention it deserves until now. Most successful proposals of this magnitude take several weeks longer to get into shape, especially if multiple people are involved.
No. I believe in my proposal, I believe in its content (it was not easy to do that, you can see how many changes had it since 6 years, and I believe in negotiation, adaptation, conflation and evolution. I recognize I don’t believe in things like this proposal is done by someone “seven year old” for the first message.
It is sad but it’s true with some messages from here I have to recognize it will be difficult for other non-technical reasons outside me. Sometimes I remember why I did unsubscribed from tagging list. But I think it is important for OSM and with collaborations all abroad this question will be “defined” and “semi-finished” at least for a big part of OSM interested in that topic.
Noone forces you to use specifically Maproulette, especially in way you describe there.
There are few other ways for doing this, like editing by area in JOSM that would result in not doing it as massive Bing Bang editing and uploading it with a very short time.
Well, I think even there are presets with the perfect picture and the national iD like nsi suggestion (it is so interesting even is out of my possibilities) would be interesting to be able to write these traffic signs, as you can do with values like hazard. As I have explained I take Mapillary as one font that previously try to do this effort, talk with them and check their traffico (their font to make traffic signs) and their API controlling that “game”.
You can find them in
and the resultant traffic signs icon invented by them (there are very similar to mine but it was no so realistic for me so I didn’t use it) in
I expect to have some human readable values, like hazard, existing from 2020 as a key , not a proposal (during 13 years - my proposal is “only” six years-old) https://wiki.openstreetmap.org/w/index.php?title=Proposal:Hazard&oldid=2059923
Probably not all national ids values should have an exact translation to human readable values but most of them should like hazard or all limitations (max* / min*)
Yes, It’s “yours” : US:EM3-1c
That people of Mapillary got good spot with Traficco.
Page 531
Good idea, it is one good change to do to the proposal.
I have the 40s traffic signs laws on my pc from 2017 to 2023, when I had to do the preset for each country. Because for me if not it is impossible to know what is the code for that traffic sign.
Although in Europe we have similar systems and it is not a bad analogy, as the building_direction this is from Mapillary people.
All the misunderstandings that can have any proposal that want to give answers to all over the world. It’s complicated…but it is necessary.
If regulatory=building_direction is supposed to be the sign that points the way to a decontamination center in case of a chemical attack or nuclear meltdown (as opposed to another emergency facility), then I don’t think this is a great example of the benefits of human-readability.
I’ve never been particularly impressed with the Mapillary icons or nomenclature. This part of Mapillary’s interface is very difficult to use because so many of the names are unintuitive or misleading, or the options are too granular for some signs but not granular enough for other signs.
I’m not the only one who feels this way. It’s a systemic issue; we’re only scratching the surface. But unfortunately, this is abandonware, so if you intend to use it as the basis for the tagging scheme, your proposal will float or sink depending on how well it improves upon Mapillary’s work.
I will not defend Mapillary ,now as a Facebook company but in 2017 these was the nearest we had from a some “universal code” rather than national id’s, with connections to OSM and software developers and users reviewing it (talking about traffic signs).
It can be done a new revision with texts from MUTCD and Europe traffic sign law text and denominations.
A universal classification system for traffic signs is a very ambitious goal. I don’t consider Mapillary to have achieved that goal even slightly. Their repertoire was probably based on whatever they were able to develop classification algorithms for, based on the training data from the sign recognition game and other sources. As such, it’s a fairly arbitrary subset of the relevant standards. It omits many signs that are important for traffic safety.
I think you’re right that we’d have to start over, from the source texts. That’s why I think two weeks would be quite a short deadline. I spent a whole holiday week doing little besides updating the MUTCD documentation to reflect the changes that occurred last month, which affect about a quarter of the signs. Fortunately, the wiki’s per-country traffic sign documentation is fairly robust, so you might be able to leverage this work, to the extent that it’s up-to-date.
Still, I’m not sure that a universal tagging scheme would even be necessary for the use cases that we know of. After all, any correspondence tables that appear in your proposal could just as well be implemented by some data consumer as a lookup table. It’s not like a traffic_sign=US:R1-1 sometimes means stop and sometimes means go. And each data consumer that implements its own lookup table can focus on a subset of the sign codes that is most relevant to its needs, based on the detection algorithms it has.
Ok. As Mapillary’s based table are not the best start…Let’s start again.
Traffic signs are the same worldwide, they have the same target, they have the same form (majority attached to a pole but relative to a way, without a way traffic signs would not exist.), so the system to tag it would be the same (nor it’s meaning.)
First we have to define its structure:
by way of map them:
-Separated node
-Node in a way
How to map:
The mapping method is as a node using the values explaining its direction relative to the way.
-Type of traffic_sign. As hazard style. We can define some types to cover all traffic signs. Using existent OSM tags (maxspeed,access…) preferable. At first there’s no changes with traffic_signs using key highway.
-No more than two tags in scheme (traffic_sign=hazard / hazard=* ). Use of human readable values (to define in other processes.)
-Possibility of mapping national id. Use traffic_sign:id=*
-direction relative to the way: direction=forward, direction=backward, direction=90 direction=270 instead it is in the way or independent .
-Side of the way the sign is located.
-Position
When there is a second traffic sign you use the subtag 2: to traffic_sign tag and so on (e.g. traffic_sign:2=maxspeed and/or traffic_sign:2:id=ES:R301).
When we have an agreement about these basis, we can start to develop all the human readable values missing and their equivalences.
There are a few assumptions in here that I’d like to unpack. I’m not sure how rigorously you mean “the same”. Pedantically, there are only a few types of traffic signs that come close to being universal. Stop and yield come to mind, but even they aren’t fully universal. But if you mean that two countries can use visually different signs that share the same function, that much is true. How then, should we handle two visually different signs in the same country that share the same function, such as versus ? Mapillary makes this distinction because the detection model necessarily differs, but a router couldn’t care less.
Plenty of traffic signs can’t reasonably be tagged as nodes on a roadway. Earlier, you correctly pointed out that some countries assign traffic sign codes to road markings. The U.S. isn’t one of those countries, but regardless, I think the existing road_marking=* key, flawed as it is, would work better for those traffic signs, especially since they can occur longitudinally across a roadway:
On the other hand, the U.S. national standard does number signs along sidewalks, hiking trails, and bike trails, while some states number anything that a highway department might need to manufacture a sign for, whether or not it belongs on a roadway:
Personally I don’t think these discrepancies are a problem at all. Use the country-prefixed sign ID and call it a day. But if you want to promote a universal ontology for traffic signs, these are edge cases you’ll need to deal with.
I’m very much in favor of establishing generic catch-all values of traffic_sign=* that can be used whenever there’s no sign ID. One of the most commonly tagged signs in the U.S. is the neighborhood watch sign, which the sign standards intentionally omit as being irrelevant to traffic safety. But this sign matters a lot in national discourse about social issues.
Somewhat less common are warning and regulatory, corresponding to official MUTCD sign categories. Our regulatory category includes what the Vienna Convention would call mandatory or prohibitory, as well as some information and complementary signs.
But one of the core questions surrounding your proposed scheme is whether we need to tag these categories even when the sign ID is known – as it would be when using Mapillary’s sign detections in an editor. I’m still not sure if you’ve explained why mappers would need to do all this extra work. Is it so that someone can easily write an Overpass query for all the “keep right” signs anywhere in the world, from memory, without consulting a reference page on the wiki?
If you mean that we should reuse highway=*, as in highway=stop for the location of a stop sign, then this is a deal-breaker for me and some others who have commented in this thread. One of the reasons is that a supplementary plaque (complementary sign) can modify the location at which a sign takes effect in all sorts of interesting ways. It is far too late to the change the meaning of tags like highway=give_way so that data consumers need to consider secondary tags to determine where it takes effect.
A traffic sign has the same utility here and in China. Sorry for my bad English. Probably you will assume we are so different…but with different codes, with different compositions there are more or less the same. If you compare all Vienna and MUTCD you will see lots of similarities. So the conclusion is you need to map traffic signs, and if you want to do that for a newbie user these have to be human readable, if you want to do exactly by an expert you need national id , so in OSM we need both as possible.
Should two trees of a similar specie be mapped or only once? Every traffic sign has its code. If you want to make an inventory you have to map exactly the traffic sign you have instead meaning would be the same. I’m not working only for routers but for all the projects will use osm data.
Well, we can have traffic_sign=road_marking or we can jump to a road_marking=* . If it is the case then we would map also road_marking:id=* because most of them have its own code so we have to respect that (wherever has national code, of course).
Traffic is traffic. MUTCD (Manual on Uniform Traffic Control Devices) is about traffic signs. Vienna’s derived laws are about traffic signs. Risk of forest fire is a traffic sign here. For other interesting advertisements we have other tags we will not discuss here. Also we will not discuss about railway signs here, for example. If it has code, if your government assign it a national/regional/local code , etc. it is a traffic_sign with its traffic_sign:id. Otherwise you can’t invent traffic signs that they are not in any place without any code. They are interesting things but not traffic signs. Signs? a lot, of course but they are not traffic_signs.
Let’s talk about that: is the 19th in United States. First is maxspeed with +39000. I don’t think they are from the same scale (+200). traffic_sign=neighborhood_watch | Tags | OpenStreetMap Taginfo
Also is the unique in the list with human readable value or not…because that is not a traffic sign. Has code? Did it makes reference to the traffic? It is a fantastic plaque, a sign, but not a traffic_sign. Traffic sign id has to be official, from whatever administration but official.
One thing is that you can’t map the code because you don’t know it, and it’s normal and not obligatory. And other thing is you can invent a traffic sign id. This will not work for big companies as TomTom.
I will not see the statistics and the user who maps it, and I will not search to, instead these was done to me. No wiki. No project on taginfo, No preset, No style…
Well, warning would be interesting but the aim is use existing OSM tags so we can convert it in Hazard without any problems. Your regulatory category is our reglamentation traffic signs here in Spain (yes, included mandatory and prohibitory). Indication or information is not a great difficulty once we accept we have to categorize traffic signs. Why we have to? Because Hazard exists. So to make coherence between hazard and the rest of future human readable values approved now or in future’s proposals we have to use the same structure.
One mapper could not drive, but here it is studied in school with basic knowledge. Here shape (triangle, inverted triangle, octogon, cercle, rectangle, square) and color (blue, red, yellow, basically) of traffic signs gives their meaning (and MUTCD, to my surprise too, Warning are yellow, Regulatory are white, speed limits are rectangular… is it correct?)
So any mapper would infere what kind of traffic_sign it has in front of him/her without knowing any national id. But the possibility to add it too has to exist. I studied a little bit that and I have a proposal. But I don’t think I can’t invent all the rest of +100 missing human readable values in two weeks. 20 categories (some of them are in use now) can be possible.
Correct. With these two traffic signs is easy. There are +1000000 of each. There are the oldest traffic signs in nodes as a part of a way. Unless there were a big automatic DWG controlled operation nobody can change these two to traffic_sign tag.
Only we can add information (direction,side,national id) but we can’t denaturalize 2 millions of nodes. If some of these node are bad tagged is not a fault of this proposal or proposer but for the original mapper.
So I insist. Proposal has to have:
-Type of traffic_sign. As hazard style. We can define some types to cover all traffic signs. Using existent OSM tags (maxspeed,access…) preferible and previously approved. +20 I have calculated in total.
-No more than two tags in scheme (when possible) to reach the meaning (traffic_sign=hazard / hazard=* ) . Use of human readable values (to define in other processes.)
-Possibility of mapping national id. Use traffic_sign:id=*
-direction relative to the way: direction=forward, direction=backward, direction=90 direction=270 instead it is in the way or independent . In OSM all the ways have direction, apply it.
-Side of the way the sign is located relative to the way. Again, in OSM all the ways have direction, apply it.
-Position.
No need to apologize – I really appreciate your willingness to engage on this topic, despite the unpleasantness. It’s a big topic that didn’t get enough attention until now.
I came to a different conclusion after considering your point about the importance of presets. With presets, the user sees a palette of signs that they can select from visually, or they can search for a sign by the name in their language – maybe even if the sign standard is written in one language, like Spanish, but the user speaks another language, like Catalan. When selecting an existing feature, they can visually confirm that the preset icon matches the sign in street-level imagery.
This is what you’ve implemented, more or less. Would you have had to do more work to implement these presets without the human-readable tags? I’d contend that it might take an expert to develop these presets but not to use them.
You’re right that some signs don’t function very much like the traffic signs you’re focused on, even if they’re manufactured like traffic signs. I think you should clarify the scope of your proposal, in terms of the subset of traffic signs you consider to be traffic signs. As it is, you’ve listed tags such as traffic_sign=city_limit that don’t necessarily play a role in road traffic safety either.
Here’s a city limit sign along a bike trail in my hometown. It looks identical to the city limit signs they post along roads, but slightly smaller. These days, most cities design their own city limit signs. They’re no longer uniform like in Europe, but the same US:OH:I-H2a value would apply.
Sometimes the same exact traffic sign is used for roads and non-roads alike. Parking regulatory signs can be posted either streetside or at individual parking spaces in a parking lot:
Earlier, I mentioned this rattlesnake warning sign, which the highway department posts at trailheads and around the rest areas it maintains. This is a traffic sign in the sense that it appears in a traffic sign standard. Maybe also in the sense that it’s a standard part of a rest area, and rest areas promote safer driving.
My city has a program that lets residents post yard signs out front encouraging drivers to slow down. These British-inspired “Twenty Is Plenty” signs function like the official advisory speed limit signs but don’t require a traffic study beforehand. Eventually, the city will use them as justification for lowering the speed limit.
If your proposal considers these signs to be out of scope, then there should be an alternative tagging scheme for it, just like we discussed with road_marking=* earlier. Could an alternative tagging scheme be based on the newly documented man_made=sign tag? If so, why not apply this tag to any traffic sign or quasi traffic sign that’s being mapped as a standalone node, whether or not you personally consider it to function as a traffic sign? We can still combine traffic_sign=* with this tag (or traffic_sign:id=*, if you insist) to indicate the ID in the national traffic sign standard, but it no longer serves as a primary feature tag.
Similarly, if a country’s traffic sign standard numbers road markings, we can add traffic_sign=* to the road_marking=* node/way/area. That element isn’t connected to the roadway, so there’s no risk of a router misinterpreting it.
I think this would be an improvement over the status quo, in which the location of a physical sign and the location it pertains to are tagged identically – even if both are mapped for the same sign. There are some precedents for this approach: for example, we combine kerb=* with barrier=kerb when tagging the location of a physical curb cut, but we omit barrier=kerb when tagging the kind of kerb associated with some other feature, such as a highway=crossing. Would you be open to this approach?
Please don’t read too much into the absolute usage numbers in the U.S. The community here didn’t really start mapping traffic signs until 2020 when I started documenting the MUTCD on the wiki. Of course, it’s true that we have many more speed limit signs than neighborhood watch signs in reality, but how many nuclear decontamination centers are there by comparison?
I suspect that the neighborhood watch signs were mapped as part of a concerted effort by one mapper in one city. On the face of it, they’re simply surveillance warning signs, but depending on your point of view, they also serve to warn about a unwelcoming neighborhood, even about vigilantes with guns. The federal government doesn’t deem them to be relevant to traffic safety, so in their view these signs would be invalid, and posting them along the street would be illegal. But local governments and organizations post them anyways under the authority of a local ordinance.
Conversely, California has annulled quite a few national signs, so that they technically cannot be posted here as traffic signs. And then a city ends up posting the national sign anyways, which is how my city wound up with two different shapes of one-way signs at the same intersection. oneway=disputed?
At the end of the day, what counts as a traffic sign will naturally vary a little bit from one jurisdiction to another, both in terms of the law and in terms of what ordinary residents expect. If we can relegate the sign IDs to a secondary key called traffic_sign=*, then the exact scope and format of that key doesn’t matter as much.
Correct, I meant that there are slight differences in what each country (and indeed each state) considers to be regulatory versus something else. (We call them reglamentación also.) It’s not a huge issue, but I didn’t want you to waste effort on duplicative tags, only to discover they’re the same thing.
Emphasis on more or less. There are in fact a lot of subtle differences between countries. In the Netherlands even the exact same traffic signs have various different meanings in overseas territories. Any newbie can map with national ids, but you need to be an expert to map the exact meaning of the sign correctly.
