Traffic_signs: human readable values vs. ISO and law codes

General talk Tagging general discussion
1

Well, let’s start. As you know there are values in traffic sign key that are human readable and others that are the ISO code of the country plus the code inside the traffic law of every country (from South Africa to USA). It is not a big problem…except they are using the same key.
Probably human readable values are the future of OSM, because you don’t know very specific knowledge about that. So a newby mapper can use iD Editor and put a maxspeed traffic sign, or can use hazard from a proposal from the wiki.
But in the other hand major use in traffic_sign key are the legal and specific values for each traffic sign (or a combination of that). You can use the traffic laws of each country or specific presets, plugins and styles to edit them without big difficulty, too.
What can we do? What value has to prevail in OSM: the specific or the verbose? What can we do if we want to maintain both of them?
What do you think about that? With which tags would you separate that values?

Salut i mapes
yopaseopor

2

How to register traffic signs
I would assume most taggers don’t know exactly what a traffic sign is called or what it means. Yes, even the ones with a driver’s license.

In that scenario, for most taggers to be able to register a sign correctly, it would have to be selected from a set of images based on what the sign looks like. The tag value can then be whatever is technically best suited.

Code vs. name
I read the main purpose of the proposal for traffic sign names as standardising traffic signs nomenclature across borders, not as a way of making the values human-readable. The codes (or standardised names) can easily be made (more) human-readable by the editor if there’s a need for that.

1 Like
3

It probably depends to some extent on whether the sign is symbolic or textual, and whether the text is fixed or variable. For example, France has some mandatory signs that consist of white text in a blue circle. It would certainly be nice to display it graphically alongside all the symbol signs, but unless the images are large enough to read and sorted alphabetically, the UI would also need a way to search by text.

It’s actually a lot like the challenge of designing an emoji keyboard. Despite the best efforts of UX designers, nothing quite beats :shortcodes: or a search bar in efficiency.

4

There’s a big discussion going on about this here.

2 Likes
5

Premise

  1. The 3rd solution, aside from using traffic_sign= for either of them, would be leave traffic_sign= unchanged. Both id and feature can be separated, while traffic_sign= remains for any general use, including backwards compatibility or machine parsing, in the short term or for some years until the replacement is established. (As a side note, I also suggest reserving crossing= for unspecified use, instead of deprecating it entirely)
  2. Besides, the other perhaps bigger problem you will face later is the number suffix. Other issues not examined further includes signs on each lane.
  3. The eventual ideal future of traffic_sign= could be eg a simple traffic_sign=yes , as a replacement to the failed highway=traffic_sign for the feature. This limits the number of features at the top-level, unlike the ever-growing building= or shop= with varying details.
Functional vs Physical

Apparently Tag:highway=traffic_sign - OpenStreetMap Wiki suggest to use this for the exact position, but I feel highway= should be used to be linearly referenced on the highway= road line first, to emphasize it’s functional and routable for applications. While there are exceptions eg highway=street_lamp , the likes of man_made= is better for the exact position, though issues remain in how to show it’s for roads if not using highway= …

Human-readable meaning

  1. traffic_sign:id= itself is fine. at least for the simple case of 1 (main) sign. I can’t think of any good possibilities for the meaning, except maybe traffic_sign:message= from advertising= ? It was discussed to supplement utility= in marker= too. Proposal talk:Markers subject refinement - OpenStreetMap Wiki
  2. But I disagree with having suffixes ie traffic_sign*=maxspeed:advisory= etc , as mentioned before. This leads to the 3th aspect. For standalone traffic_sign*=maxspeed + maxspeed:advisory= viz German autobahns, it could have eg traffic_sign:category=informational added anyway.
  3. For the issue, eg US has W-series “ramp” or “exit” signs without a hazard=turn warning on them, that’s debatable on how they should be classified, officially or functionally; or does that qualify as an implicit hazard=curve not mentioned yet in MUTCD/W - OpenStreetMap Wiki @Minh_Nguyen ???
  4. Another problem is overlap between traffic_sign*=hazard and perhaps traffic_sign:category=hazard . However, again it can be seen from MUTCD/W - OpenStreetMap Wiki that not all W-series are hazard= proper. Then maybe traffic_sign:category=warning is still needed? Unfortunately yet again, this runs into the aforementioned official classification difference. Eg W4-3 and W4-6 lane gains or parallel merging lanes are rectangular informational signs in UK.
  5. Anyway, the advantage of always having a traffic_sign:category= (regardless of whether there is established val) is that instead of using unspecified traffic_sign=regulatory etc for uncommoon or unestablished signs, users can be encouraged to invent a traffic_sign*= , backed up with traffic_sign:category= for completeness.

Other possibilities

  1. A 4th aspect could be for one of your controversies of advance signs, and the repeating signs etc. Inspiration from railway:signal= , again as mentioned before. This makes it clear which signs are the most important For the former, this makes them clear without having to rely on the presence of eg distance= , which as mentioned before is undecided vs length= for signs that apply to a section of road due to ambiguity with physical attribute of the sign plate itself.

Caveat

However, all these still presents an incomplete view on how signs should be organized. It can be seen this question can’t be answered exactly and properly without treating the method of handling multiple sign plates together.

6

If we’re looking for an intuitive primary feature tag, there’s already man_made=sign, which has in its short existence already been stretched well beyond its original discussed meaning, and for good reason. Or man_made=traffic_sign, by analogy with the man_made=traffic_signals that I sometimes have reason to map.

The arrowless exit or ramp warning signs are warning about the need to slow down. The reason isn’t given. Often it is due to curve geometry, but it’s up to engineering judgment.

As for the other arrowless signs in that series, the “P” at the end of a sign ID indicates that it’s a supplementary plaque. In other words, it’s a hazard sign by virtue of the sign it accompanies. This differs from the Vienna Convention, which categorizes plaques separately without regard for the sign assembly’s function.

Sure, there are lots of differences between jurisdictions (even subnationally) about what is considered a warning versus a regulation. Lately, the U.S. considers tolls to be a kind of hazard. Most countries don’t warn of this personal budgetary hazard in quite the same manner.

The U.S. also considers height restrictions to be warnings, not regulations as in the Vienna Convention. The reason is that the laws of physics override; the cops have nothing left to regulate except to levy a fine for destruction of property.

OSM isn’t in a position to decide that one country’s regulation has no regulatory effect because of another country’s norms. This is part of why I personally don’t care a great deal about harmonizing sign identifiers globally. Drawing parallels between signs from different systems is ultimately the job of a data consumer.

1 Like
7

Oh sorry, I forgot to type back the W13-2, W13-3 I was asking Figure 2C-3 Long Description - MUTCD 2009 Edition - FHWA

8

Ah, I realized that at the same time you posted. As you can see, the signs are interchangeable, but without the arrow, it can be used in more situations with different geometries or other reasons to slow down. A perfectly straight but very short off-ramp could also have one of these signs. Or it could be due to several factors that together necessitate the advisory speed, according to engineering judgment. We might not even have access to the documents that justify the sign to fill in hazard.

9

I have had to rewrite this response a couple times, because it’s hard not to reference back to the voluminous digital ink spilled on the greater conversation about your (failed) proposal about this. I had been trying very hard to parse that conversation, and I came away feeling totally overwhelmed and not understanding what the end-purpose of the proposal was.

That said, I find it hard to comment on this more specific question about “human-readable” inputs vs. “codes” without delving back into that discussion and, ultimately, asking myself what the purpose would be to prefer one or the other.

I can follow the argument that “human-readable” values like “stop” are a lot more intuitive for most users than “CA:AB:RA-1”, and that’s all well and good. Using the “human-readable” “stop” to indicate a stop sign seems pretty straightforward, and even though there are a myriad different stop sign designs around the world, they all pretty much mean the same thing.

However, yopaseopor, you ask:

What can we do? What value has to prevail in OSM: the specific or the verbose?

I’ll answer a question with a question: why must one prevail over the other?

You ask,

What can we do if we want to maintain both of them?

… Nothing? What do we need to do that isn’t being done?

Or rather, the overarching question that I think needs answering is: what is wrong with the way it is? What’s broken? Do you envision a “human-readable” way of inputting all the possible traffic signs in the world? I can almost guarantee that’s a fool’s errand.

As a point of reference, I added a few stop signs to an area of my city I’ve been mapping in more detail in the past few weeks: Changeset: 150056944 | OpenStreetMap

Here’s a marked-up example (this is 18th Street & 31st Avenue SW):

humanreadable
humanreadable1460×1006 92.6 KB

Roadways in white, sidewalks in dashed red, crossings (unmarked) in dashed brown with intersecting crossing nodes on the roadways, and there are highway=stop (stop=minor) nodes (with appropriate directions) on the roadways, plus traffic_sign=stop nodes at the actual locations of the signs. I think is a perfectly good way of doing this because:

  1. The highway=stop nodes let the road traffic that they are expected to stop, and where to stop; in this case just before the (unmarked!) crosswalks,
  2. The traffic_sign=stop nodes denote where the signs actually are.

I think this is the best compromise and it’s useful to know the sign position because in this case these signs are technically not an “MUTCDC ‘Ra-1’ sign”: they have itty-bitty little print at the bottom reminding drivers, “NO PARKING WITHIN 5 m”.

Note that the “stop position” on the roadways does not coincide with the location of the stop sign; the sign merely indicates to a driver that they must stop at the intersection. The rules of the road dictate they must do so without impeding pedestrian traffic at the crossings.

Now, is it perfectly understandable what I mean by traffic_sign=stop, as opposed to something more esoteric like “CA:Ra-1” or “CA:AB:RA-1”? I think so. Is it important that every single possible sign and sign combination needs to be able to be expressed in words? Probably not, because there are too many variations of signs to make this feasible. E.g.

FYI that traffic signal has, from the bottom up: solid green, solid amber, red right-turn arrow, and solid red lights. The sign is indicating that a driver is not permitted to turn right when the red right-turn arrow is lit, but that they are permitted to otherwise make a right turn against the solid red light (after they’ve stopped and yielded the right-of-way to pedestrians and any other cross-traffic). The sequence went solid red → red right arrow → green → amber → solid red; the red right arrow lit when the “bike signal” light turned green, allowing cyclists preferential advancing across the intersection.

I can guarantee that no-right-on-red sign has no associated MUTCDC or any other signage standard ‘code’, but I don’t think you can boil this down to an easily ‘human-readable’ description either.

10

To be pedantic – in keeping with the zeitgeist, it seems – that sign might have a standard code in Alberta. There’s R-117-R next door in British Columbia; maybe the Albertan equivalent is flexible enough to cover unusual signal configurations. Provincial transportation ministries have an incentive to develop these codes to cut procurement costs on construction projects. Some jurisdictions place more importance on these codes than others.

I hope we can get to the point where mappers can easily enter such specific codes based on what they can observe, if they choose to. In the meantime, OSM is built on rough drafts along the lines of the keywords that generically describe signs. The codes are interesting because of the more exotic or complex signs; the common signs only get tagged with codes for consistency.

A few years ago, I made the same argument about flags on flagpoles. At the time, the community was satisfied with identifying flags by ISO 3166 codes in country, but I was more interested in the flags that this scheme left out. It’s a classic OSM impulse. I set out to map flags that broke the mold, using Wikidata for extensibility, and others followed suit. Without an eye towards extensibility, we’re stuck with the obvious data points, whether we spell them in British English or alphanumeric soup.

11

I want to state explicitly that there is already a neat distinction between the “human-readable” and the “code” values for traffic_sign. Namely, the presence of the country prefix (and the colon). As long as we exclude colons from being allowed in the “human-readable” values, it is trivial to distinguish them from the “code” values (which require a colon).

So, there’s no need for a separate key – the values are already divided.

5 Likes
12

To be pedantic – in keeping with the zeitgeist, it seems – that sign might have a standard code in Alberta.

Haha, sorry, not that one:

thisone

THIS one:

thatone

Believe me: it’s non-standard. :laughing: Canadian standard, Albertan standard, MUTCD, Vienna Convention, etc.; I would be shocked if that sign isn’t unique to that one installation at 17th Ave & Richmond Road.

And that streetview capture is actually a little out of date: the signal has been updated to solid red → solid red & red right arrow → green → amber → solid red, and the sign pictogram thus now shows the arrow and the solid red.

1 Like
13

First of all, I want to say sorry if with previous discussion anybody felt offended. It was not my intention. Also my intention is not to get insulted because of the discussion.

The intention of write maxspeed:advisory it was to use existing tags and combinations in OSM. Using a new category seemed more difficult to be understood.

But as you say certainly the category informational would be a good solution because in Vienna convention informational traffic_signs are square or rectangle in blue.

The idea behind traffic_sign:category can be the equalization of the categories you can find on the traffic laws of each country. Of course there will be differences of namings but you will see some common words, could be possibilities.

Spain > https://www.interior.gob.es/opencms/pdf/servicios-al-ciudadano/participacion-ciudadana/Participacion-publica-en-proyectos-normativos/Audiencia-e-informacion-publica/16_2022_Borrador_Tomo_I_Definicion_senales.pdf
(translated with Google translate)
Danger warning signs, priority, entry prohibition, passage restriction, prohibition and restriction, obligation, end of prohibition, restriction or obligation, general indications, lanes, service, pre-signaling, direction, road identification, location, confirmation, use specific in town, complementary panels, others

France > https://www.auto-ecoleducentre.com/userfiles/files/TOUS%20LES%20PANNEAUX.pdf
(translated with Google translate)
danger, prohibition, indication, obligation, direction and location signs.

USA > MUTCD 11th Edition - FHWA MUTCD
Regulatory Signs, Barricades, and Gates,Warning Signs and Object Markers,Guide Signs ,Toll Road Signs,Preferential and Managed Lane Signs,General Information Signs, General Service Signs, Specific Service Signs, Tourist-Oriented Directional Signs, Changeable Message Signs, Recreational and Cultural Interest Area Signs, and Emergency Management Signs,Markings

UK > https://assets.publishing.service.gov.uk/media/656ef4271104cf0013fa74ef/know-your-traffic-signs-dft.pdf
Warning signs,Regulatory,Speed limit,Low bridge,Level crossing,Tram signs, signals and road markings,Bus and cycle signs and road markings,Pedestrian zone signs,On-street parking control signs and road markings,Road markings 74,Traffic calming,Motorway signs, signals and road markings,Direction signs,Direction signs for cyclists and pedestrians,Information signs

Vienna > https://unece.org/DAM/trans/conventn/Conv_road_signs_2006v_EN.pdf
Danger warning signs,Regulatory(Priority,Prohibitory or restrictive,Mandatory signs,Special regulation signs),Informative signs (Information, facilities or service signs, Direction, position or indication signs),Advance direction,Direction,Road identification,Place identification,Confirmatory,Indication signs,Additional panels

I know we have already a “category” (my option would be to translate traffic_sign=hazard into traffic_sign:category) approved . Probably hazard could not be the word you would search in a traffic law but we can assume is the equivalent to danger/warning.
The option for regulatory could not be too explicative so I would choose the subdivision (priority, mandatory, prohibitory).
I think informational or informative (informatory exists? ) is a good possibility if we talking about traffic signs for information but I’ll do the same about regulatory taking the subdivision… I don’t know if the Vienna nomenclature can be compatible with MUTCD nomenclature.

Good option would be other discussion about this part perhaps.

Well , If I’m not wrong there was a change some years ago in that sense so probably community will have to decide its meaning finally and its uses to avoid the ambiguity you have mentioned. Other discussion and proposal.

Well, my vision or my opinion of that could not be the unique if a proposal for that is need to go on, so interesting discussion about the map of each traffic sign in separate nodes or at the same node should working next months, from using multivalues to avoid them.

I hope that it should have been a constructive answer this time.

14

But one possibility could use the categories and the descriptions of every traffic law. In Vienna if you see a triangle is warning (it is not important if it is about maxheight or some curves), but if you see a circle with the red border the same information would be a prohibitory traffic sign about the maxheight. This is so visual , shapes and symbols (or meanings) . For this reason a newbie mapper could map that with a human readable value (or summary of a word redacted in a law). Official traffic signs are finite and defined by law.

example_esp26
example_esp261920×1440 308 KB

My final intention was this. Final result= fail.

You have totally reason. Why one and not the other? Why not both?

Sorry, but as you can see in the example, nowadays I cannot have a traffic_sign=hazard and a traffic_sign=ES:P26 in the same node. This was the purpose of the :id part. We have the same situation with other values like traffic_sign=maxspeed.
What can I do if I want to maintain both tags?

Sorry, but I’m not agree with you in this. All the drivers who have studied for getting de driver license must know the explanation of every traffic sign you will find on the road. I believe is factible to summarize to one or two words every traffic sign (like Falling rocks example).

…Why not… “no-right-on-red” (or similar) ? Anyway, there are so many complex situations that can assume inside the same panel two or three traffic signs together. Also there is the option to add a description key or something similar the community would think that could work. Major part of traffic signs match with the same you can find on traffic signs law probably. So there will have a code and official description it can be converted to a human readable value.

But when you want to have both information (the specific picture and the meaning) you cannot use the same key, as you can see in the example.

1 Like
15

Thank you for clarifying about wanting to have both the code and the human-readable value applied to the same sign. I agree, that’s not possible with just one key.

However, I don’t think that having both a code an a human readable value for a single sign is a good idea. With that, they can get out of sync, which would make it impossible to interpret. And the code value can be displayed in a way that makes it human readable (including translations, and images), so you can have the advantage of readability without having the chance of inconsistent claims about the same sign.

1 Like
16

Okay, the marked-up photo helps immensely; thank you for that!

Now I get it. Or at least I think I do: you want to have the ability to add both the “human-readable”—or maybe let’s call it a descriptive tag—and the official government traffic sign code at the same time. But the problem is they use the same key, so you can’t do both: just one or the other.

I understand your point that people ought to know the meaning of all the traffic signs they encounter, thus one should be able to describe them, but I still don’t think you’re going to capture every possible sign with a descriptive tagging scheme. At the same time I personally don’t think it’s very important to tag sign nodes with the national or sub-national “code” either if they’re easily described: the prime examples being signs like “stop” and “yield” (or “give way”, whatever one happens to call it).

Those signs mostly look the same or similar around the world, and they mostly mean the same thing too. Aesthetically the only stop sign that looks quite different that I happen to know of off the top of my head is the triangular Japanese sign; mostly the world uses red octagons that stay “STOP” or something equivalent in a local language. I know there are many variations of those local language words—in fact here in Canada, depending on where you are, you may see signs that read one or both of “STOP” and “ARRÊT” (and this can get very political where preference is shown for one over the other…), or one of those and an aboriginal language, or an aboriginal language alone (e.g. near where I live a few read “AST’A NITŁ’A”). Aside from the sign’s national “code” being included as a piece of trivia, a curio: does it add any value to its comprehension? I would strongly argue ‘no’.

If the crux of your argument is that descriptive tagging is considerably easier than cross-referencing an alphanumeric identification code, I think I agree in principle. Rather than have both the code and the description, what about just starting with ameliorating the descriptive tagging we already have at the wiki page? What about creating… essentially a lookup table, where a data user could cross-reference with where the sign is located to extrapolate the “code” of the sign in question, if said data user really needs it?

17

You are assuming two things

  1. Everyone here has a driver’s license
  2. Having a driver’s license teaches you about all signs, even if they don’t apply to you.

At least in Germany, a growing number of people don’t even get a driver’s license, because it’s not necessary if public transport is good and you have a bicycle. Plus, there are several signs that apply only to trucks, or tanks, and their meaning isn’t clear to everyone, not is it taught.
It’s always a good idea to map the exact signs and their IDs, so in a second iteration, people can add information, especially should the meaning of a sign change over time.

18

How many kinds of signs are as (nearly) universal as the stop sign? Some of the most common kinds of signs don’t have one-for-one correspondences in each country, as the withdrawn proposal unintentionally illustrated.

How do we draw the line between a sign that should be tagged only as a keyword and one that should be tagged only as an alphanumeric code? Based on the traffic_sign page’s existing table of arbitrarily chosen keyword values? The most common signs from a European or American perspective? The signs that are easiest to detect via computer vision?

Some commercial datasets and navigation systems do maintain a transnational ontology of traffic sign keywords, but these systems focus on a far more limited selection of signs than what we’re already mapping in OSM. Our decades-long ordeals with highway classification, place classification, protected area classification, vehicle access classification, and crossing classification should serve as a stark warning against developing another ad hoc classification scheme for something we already know to be subject to incompatible regional schemes in the real world.

A lookup table is inevitable somewhere in the pipeline, but I disagree with requiring a lookup table to convert codes to keywords while mapping. You might figure that mappers would be more familiar with keywords than codes, but I’d contend that mappers would be more familiar with the visuals and human-readable names than either keywords or codes.

We wouldn’t be forcing only data consumers to rely on this lookup table. Any editor would need to use the same cross-reference in order to present the user with a more usable visual sign palette. So would Mapillary’s object detections, which are coded by sign to begin with. Thus the pipeline could potentially look like:

  1. Computer vision algorithm identifies a sign by code and converts it into a suggested keyword.
  2. Editor converts it back into a code in order to choose an image to display as a suggestion.
  3. Mapper chooses the image and underlying keyword.
  4. QA tool converts it back into a code in order to choose an image to display, so that any error would stick out visually.
  5. Renderer converts it back into a code in order to choose an image to display.

By contrast, if we traffic in traffic sign codes to begin with, the editor can give the sign’s code-based preset any number of aliases, and no more conversions would be required from then on out. The withdrawn proposal’s motivation might have been that an ADAS could, for example, associate stop with the specific action of applying the brakes, rather than having to look up the local sign codes. But any ADAS would already have to be tailored to the peculiarities of local traffic laws anyways.

To be clear, I’m not arguing for the abolition of the keyword values. But I agree with others who suggest that any keywords can continue to coexist with the codes as “rough drafts” of a traffic sign node. Why complicate things further than that?

3 Likes
19

Please, take your time to figure out and clearly explain why you see a necessity to keep both tags. “ES:P26” is a sign for a hazard. Mapping this to the human readable “falling rocks”, the more generic “hazard” category or a graphic of the sign is a trivial task for any software. Having two tags simply duplicates this information.

I have no idea what all these colorful arrows and icons are supposed to represent. But there is clearly no way to reconstruct this information from the tags you give.
traffic_sign=ES:P26,ES:S800[1500] plus a side=right and direction=NE tag contains all the information you need in less than half the number of tags.

2 Likes
20

so you can have the advantage of readability without having the chance of inconsistent claims about the same sign

it also means that you won’t find a wrong code as easily, because no inconsistency hints at it, is wrong but looks right