Puzzled by traffic sign mapping

General talk
,
1

Last night I was following up a discussion on IRC and adding lane, sidewalk and, where appropriate verge, tags to some highway=trunk where they were missing (lanes is relatively poorly used in the UK).

At one roundabout junction I could see a couple of destination signs in the aerial imagery and it was useful to map them to more accurately check a change of speed limit. I don’t normally map traffic signs and a few things surprised me both in support within iD and on the wiki:

  • highway=traffic_sign is deprecated. My understanding is that originally all “street furniture” was tagged using the highway key (street_lamp, bus_stop etc.) so I presume the original intended form was highway=traffic_sign with traffic_sign=*. It looks as if this pattern didn’t survive very long and traffic_sign itself became a standalone ‘top-level’ key: something which often happens with heavily used values. So not something I’m worried about.
  • traffic_sign itself predominantly contains values which refer to a given reference for a specific sign in a given national sign directory. I would have expected it to provide a more human readable indication of the nature of the sign: precise for very common values (e.g., give_way, stop, city_limits, maxspeed, …) and more generic for signs with variable content (destination) or ones used less frequently (hazard, instructional …). It is this latter approach which is best documented on the wiki, but usage does not really reflect this (hazard: 2135, destination: 1507, stop: 31,907, but NL:G11: 57,080). iD offers about 5 of the documented textual values and not the ones most widely used.
  • There is little or no documentation about mapping actual destination signs compared with providing destination information for turn-by-turn routing. Users of the relation type=destination_sign don’t seem to generally map the sign, although there is a role sign for this relation.
  • There are often different kinds of destination signs at a junction, at least in the UK (primary destination signs, local destinations, other local amenity destinations), and tourist information destinations (e.g. hotels) in other countries. I can’t see a way of tagging this for the sign at present.

My general thoughts are:

  • Many traffic_sign values of the form “XX:123”, where “XX” is a country code and “123” a reference to an official sign manual, might be better held in a separate key, say traffic_sign:ref=“XX:123”. traffic_sign would then have more human readable text for mappers. This would make validation in some editors easier (i.e., those without explicit support for many country-specific codes).
  • Current practice is poorly structured for mapping though incremental steps, as the primary way information if captured is via very specific sign codes or through relations.
  • Not including the actual sign in the relation also makes validation difficult: I checked relations at my local junction and it is very difficult to see which signage a given relation applies to, and I suspect at least one of them is wrong (it looks as though the mapper assumed destinations from the S would be replicated for traffic coming from the W, but they are not.
  • A vast number of relations would be required to map all signed destinations at my local junction: “Ring Road” (two directions), Mansfield, Grantham, Birmingham, Melton Mowbray, Derby, “City Centre”, “The North”, “The South”, Hospital Emergency dept, football & cricket traffic, University of Nottingham, East Midlands Conference Centre, Multiplex Cinema, several suburbs.
  • Mapping signs as street furniture is potentially important for some applications: for instance routing and/or hazard warning for people with limited vision.

In closing I’m also impressed at just how much information has been captured. Presumably this is used by various routing applications.

3 Likes
2

The human-readable values are convenient for mappers who haven’t looked up the codes. Since they aren’t namespaced by country and don’t make as many distinctions as actual sign standards, there’s less fragmentation. If you add up all the warning sign codes, they might well surpass hazard in prevalence, but it’s hard to say without some mapping from codes to categories.

Some of the values are catch-alls for when the local sign standard has no code for a kind of sign (even as it specifies various aspects of it). For example, the MUTCD establishes some general categories like “regulatory” and “warning” with prototypical shapes (white rectangles and yellow diamonds, respectively) that highway departments are free to fill with whatever they need to if a more specific sign hadn’t been codified. When I encounter these signs, I tag them with the general category and use secondary keys to clarify the message.

In most states, destination signs are specified in exquisite detail but never given a code. I suspect this is because the codes are primarily used to streamline inventory at a sign shop, but destination signs are always customized case by case. California is the only state I know of that has rigidly codified the size and layout of destination signs (ironic considering the refrigerator magnet poetry they often put up).

I agree that a “progressive disclosure” tagging scheme would’ve been more practical than what we ended up with, but there’s a very large body of existing signs that would be difficult to transition over to a new scheme.

Once we build out the wiki’s correspondence tables between sign codes and tags in each country, software developers can turn them into something machine-readable so that editors can offer the mappers a palette of signs instead of forcing them to look up the codes manually.

This relation type was envisioned as a routing hint for “Follow the signs for” guidance instructions. The idea is that a router would be able to traverse the routing graph it has already built but consider the relations at the same time. When a traffic sign is mapped as a standalone node, the router needs to figure out whether the sign would be visible to a driver on a nearby road based on its direction or traffic_sign:direction, which could be tricky. (But I do prefer to map the physical sign per se.)

Sometimes I’ve seen mappers attempt to use confusingly named destinationsign relations to disambiguate the place names, street names, and route numbers on the destination sign. This is especially helpful in countries where way refs are terribly ambiguous. But taken to its logical conclusion, New York City would be a member of a destinationsign relation with over 850 members, and the relation for Interstate 70 would hold a whopping 1,781 members.

I think this highlights a limitation of OSM’s data model, that it isn’t possible for a way to directly refer to a relation in the manner that a relation can refer to a way. As a workaround, I’ve been using destination:wikidata and destination:ref:wikidata. It’s the same strategy we’re using for associating features with their namesakes via name:etymology:wikidata. Obviously, an external database reference isn’t as convenient for routers, which would need to join to Wikidata in the same manner that some renderers do. But at least mappers won’t get into edit conflicts with other mappers over a name that happens to be repeated on signs hundreds of miles apart.

maxheight on the sidewalk and building:min_height on the sign assembly:

Kidding aside, this could be a real application of traffic sign mapping. At State of the Map U.S. this weekend, there were some discussions about even mapping sidewalks as areas, so that routers could evaluate whether a pedestrian or wheelchair could maneuver around an awkwardly placed signpost, guy-line for a utility pole, or trash can that doesn’t technically block the sidewalk.

2 Likes
3

Too much to respond too all at once, but this also relates to your comments on an earlier accessibility thread.

I think this is a good micromapping target, in part, because many of the same features are worthy of mapping for other purposes. Below is my current best example of where Ii’ve experimented with this.

I have tried to map this short section of sidewalk because it is a pinch point for cyclists and e-scooter riders who use the dropped-kerb to ride past the bus stop on the pavement (Mapillary). There are numerous other obstacles (a traffic CCTV pole, a listed building & railings, the bus stop (with shelter, waste bin), other pedestrians, people waiting for the bus and then a cycleway crossing (with signage on poles)). This means the actual usable width varying quite a bit over a few 10s of metres.

As my 91-year old father walks this way 4 times a day, and, particularly, after he had a stroke two yeas ago ,which impaired his peripheral vision, I was interested in capturing the detail. I had hoped I could configure OSMAnd to warn of obstacles, but it wasn’t easily configurable. Fortunately, the impairment reduced and he has adapted so that he can navigate safely even in unfamiliar places without bumping into things. I still think a simple audible warning of upcoming hazards could be useful in OSM-based mobile apps.

I think the constraints are too much for the local authority to do anything, but it would be nice if they did assess such issues; and of course OSM can help with that too.

2 Likes
4

The Wiki, Traffic sign IDs is clear to me, it is after Human-readable values that might obscure it a bit.

I do not see a need for human-readable values, what is needed is that things are clear to the user and precise. This is how Josm looks for me:

Screenshot_20230617_120829
Screenshot_20230617_120829795×421 218 KB

Source: Josm with an image background from beeldmateriaal,nl

Notice that it is clear that the cycleway is a NL:G11 without seeing “traffic_sign=NL:G11” ever. Also adding new traffic signs can be done without knowing the code ever.

For the JOSM menu, see JOSM Presets voor NL, traffic signs for ways are available through Josm Map Paint Styles and I have also the Road Extended JOSM (default) style (forum post) active.

iD offers about 5 of the documented textual values and not the ones most widely used.

Fix the tools instead of adding an additional traffic_sign:ref that will for sure trigger problem like traffic_sign:ref and traffic_sign not being in line with each other.

1 Like
5

I am not so sure I see the use case for mapping destination signs in OpenStreetMap, this kind of information is I think only used through traffic guiding software and with that the destination signs become less important.

If you still like to map it you better map it in a way that it can used by Software that uses this feature and there I read nothing about support for relations.

6

In some navigation software, an idealized first-person view of a motorway junction appears as you approach it, especially if the junction is complex. This feature comes standard with standalone GPS units, waned for a while in consumer applications like Google Maps, and is now making a comeback with in-car navigation systems. Mapbox has a junction view feature too, but it isn’t active when using OSM-based data.

To be clear, the junction view images are always based on a mix of actual road data and hard-coded artistic hints. If you look at a Garmin junction view very closely, you might not recognize the tree pattern or skyline in reality. But even if we focus on just the destination sign in the image, it isn’t always possible to derive a presentationally correct sign based on the more semantic destination:* tagging scheme. There is a proposal for encoding the layout of the sign more literally, but it isn’t very internationalized. Making maters worse, Valhalla helped popularize destination:street, which takes the streets out of the main list of destinations, erasing information about the order on the sign.

iD is simply listing what taginfo says are the most common values of traffic_sign on a node. You can hover over a value to get the description that taginfo scraped from the wiki article’s infobox, but otherwise iD doesn’t have any information about individual values.

There are some proposals for adding traffic signs to either id-tagging-schema or name-suggestion-index. Either approach would require some additional infrastructure to handle an influx of tens of thousands of new presets.

1 Like
7

Seeing the Human Readable being mentioned multiple times, maybe a little inventory of those which are ‘uniformly’ accepted and I mean uniformly.

OTTOMH noting that to my surprise traffic=sign=* has only been used 1.07 million time and city_limit has the largest chunk of nearly a quarter (which of course is combined with city_limit=begin/end and facing direction which too many traffic signs in general have missing (search and thou shalt find a good lot without, not sure if it is just direction=* or traffic_sign:direction which still has 47K roll outs.

So, the short list of human legible traffic_sign=…

  1. stop
  2. roundabout
  3. give_way
  4. city_limit
  5. maxspeed (I tag that as e.g. traffic_sign=maxspeed:50 if it is signed like that
  6. overtaking
  7. noexit (?) (yes we do countless on close way end nodes, but there are countless too at the start of such ways, even seen one today start of a country road that goes on and on to end in the farmland mud. Without sign and navigator you’re up mud creek and blood pressure rises :wink:

Seeing hazard listed in TI, would that then be e.g. traffic_sign=hazard:children or hazard:animal_crossing, hazard:curve or curves, hazard:bump or bumps ?

Anymore that can be legit added to that list?

If this is considered a thread hijack, admin please split to “Human readable traffic signs inventory”

Edit: Found list of all ‘human readable’ traffic sign values in wiki Key:traffic_sign - OpenStreetMap Wiki referenced earlier in the thread by SK53

1 Like