Traffic_signs: human readable values vs. ISO and law codes

[Minh_Nguyen (Minh Nguyễn)]

@dieterdreist

Many restriction traffic signs are very easy to understand, e.g. traffic_sign=maxheight, or maxspeed, or hazard signs.

This is only true for someone fluent in OSMian English or at least British English. For everyone else, these keywords only seem human-readable but are actually a jumble of unpredictable rules. Oh, the sign that says “No Passing Zone” is overtaking, not passing? What is an hgv or a queue? What’s the right tag for a “Begin Freeway” sign?

Of course, we cope with this reality for many tagging schemes out of necessity. For example, we’ve developed a custom set of keywords for cuisines, some of which have unintuitive definitions (e.g., chicken specifically for fried chicken). But if there were already standard cuisine classification schemes used by restaurants the world over, as there are with signs, maybe we would try to align with those schemes instead.

@dieterdreist

I’d prefer someone to add a maxspeed traffic sign with a typo in the tag than them not adding anything at all because it is too complicated to look up the sign code.

So would I. But this is already the status quo, quite different than expecting features to be tagged with overtaking:hgv even when the code is known or provided by the editor. That’s the implication if we reserve one key for codes and another key for keywords, because then there’s nothing preventing both from being dual-tagged on the same feature.

@hoserab

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 .

Ah, then indeed we are on the same page. iD is already capable of suggesting the right ALDI brand when you search for “aldi”, depending on the country you’re mapping in. It will find “PFK” (brand:wikidata=Q524757) if you search for “kentucky fried chicken” in French-speaking Québec. And of course it’ll find the amenity=fast_food cuisine=chicken preset if you search for “poulet” while using the French localization.

I think in these discussions, we tend to forget that not everyone maps in English, so a British English–based tagging scheme might as well be in alphanumeric gibberish. But as long as an editor can accommodate the mapper’s language, it can certainly accommodate differences in terminology within that language. We already have this functionality today with most tagging schemes, even brands to some extent, but not for traffic signs due to unresolved questions like the one posed by this thread.

@hoserab

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.

To the extent that the applicable sign standard considers them to be different signs, an editor can turn up multiple presets when you search for the word “stop”. But if all are considered the same sign, just with different legends, then inscription=STOP / ARRÊT would get the point across, or perhaps language:en=yes language:fr=yes to be more structured.

As to who cares: maybe not a navigation system, but Tsuutʼina language advocates may appreciate representation of that language via language:srs=yes tags on traffic signs and other features.

@dieterdreist

Most of the signs are almost useless when mapped as signs even for other mappers, and those that are helpful are so for other mappers and QA, but not for actual user applications like routing.

This is indeed my usual reason for micromapping traffic signs – to affirm some name that I applied to a roadway, or the starting point of some maxspeed, or the maxweight of a bridge (because those signs are usually posted far away from the bridge). If you were to query for traffic signs I’ve mapped, you’d get a sneak preview of zingers in my future forum posts, but little else. On the other hand, I recognize that more comprehensively mapping traffic signs would facilitate more interesting use cases, such as realistic street furniture in 3D renderers and the sort of ADAS features that proprietary vendors consider their “secret sauce”.

I’ve driven cars equipped with camera-based traffic sign recognition displays. This feature is useful for letting you “replay” the signs along the road that you may have missed. Unfortunately, I’ve found the sign repertoire to be quite limited. The car can detect the most common kind of speed limit sign, but so could an OSM-based GPS navigation application without the fancy sensors. Yet the car can’t reliably detect speed limit signs in school zones, an admittedly rarer sign that’s less machine-readable. If the system can’t detect that school zone sign, then I can’t trust that the normal signs it detects are still relevant by the time I glance down to see them. This undermines the feature’s core safety benefit. If we can increase coverage of traffic signs in OSM to some degree, vendors of TSR systems might notice and use OSM data to calibrate their output.