Traffic_signs: human readable values vs. ISO and law codes

[hoserab]

@Minh_Nguyen

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?

Well, as I wrote earlier, I think trying to come up with a descriptive nomenclature for the tagging of every single possible traffic sign is a fool’s errand. How many signs are as (nearly) universal as the stop sign? A lot more than the list at Key:traffic_sign - OpenStreetMap Wiki. Turn restrictions, keep right/left and speed limits are pretty straightforward, I think.

How do we draw the line at which should be tagged with just a keyword vs. just an alphanumeric code? I think we draw the line at which ones are most universally understood to mean essentially the same thing. Stop and yield signs are the obvious ones we already tag with a simple descriptive keyword, but it doesn’t take a rocket surgeon to figure out that (e.g.) , and each mean the same thing.

@Minh_Nguyen

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.

@hoserab

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?

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?

I think we’re actually on precisely the same page: a descriptive keyword can serve as a “rough draft”, or “placeholder” if you will that would serve the purposes of… probably 90% or more of use cases, and if for whatever reason somebody wants/needs the actual appearance of the sign to be specified in detail, they could overwrite with the alphanumeric code to get that desired specificity.

I can see a lot of value in having the descriptive tagging in place for many more of the world’s most popular signage. Especially in that it’ll make it much easier for the average ignoramus mapper (e.g. me ), who doesn’t know the alphanumeric codes of the MUTCDC (nor any other national/international/sub-national standard) cover to cover, to put some signs on the map in the first place.

I’d like to quote a post you made in Large scale change of traffic_sign to traffic_sign:id, because I think it makes a good point:

@Minh_Nguyen

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.

Going back to the comment about a lookup table, you wrote:

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.

I actually meant the complete opposite: I didn’t mean “requiring a lookup table to convert codes to keywords while mapping” (although frankly that is the status quo, when it comes to mappers entering the “codes” in the traffic_sign=* tag in the first place), I meant that it’s easier for mappers to enter a “keyword” and data users can reference a lookup table to spit the “code” out for them, if they need it.

I had envisioned something like a lookup table that would parse a descriptive tag, let’s say for the sake of argument a hypothetical “traffic:sign=one_way_right”, that could cross-reference the administrative boundary within which it’s found, and in the case of the US would spit out .

However, you brought up a huge limitation: what do you do when you have two different sign designs that mean the same thing and are used concurrently in the same jurisdictions? I was going there with the example of the stop signs earlier: for me it doesn’t make much difference if it’s a red octagon with white lettering saying “STOP”, “STOP / ARRÊT” and “AST’A NITŁ’A”; all of which I can find within about a fifteen minute drive of my house. I admittedly was thinking only of routing uses, wherein… who cares what the sign says? It’s a red octagon with white lettering: it’s a stop sign.