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_signis deprecated. My understanding is that originally all “street furniture” was tagged using the
bus_stopetc.) so I presume the original intended form was
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_signitself 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.,
maxspeed, …) and more generic for signs with variable content (destination) or ones used less frequently (
instructional…). It is this latter approach which is best documented on the wiki, but usage does not really reflect this (
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_signdon’t seem to generally map the sign, although there is a role
signfor 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:
traffic_signvalues 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_signwould 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.