Add country / state specific traffic sign presets

[CloCkWeRX]

openstreetmap/iD#5333 is fantastic, as is mapillary sign detection being present in ID.

Unfortunately, most of the time I spend editing to add sign information I am referencing https://en.wikipedia.org/wiki/Road_signs_in_Australia

Current UX adding country specific signs - a sign is easily detected, with a broad (sometimes incorrect) category suggested; however determining that is a "AU:W6-1" is difficult.

Obviously, adding a preset for every locality in the world is unreasonable, so I'd suggest:

• A directory(?) or other container for a given ISO country code (ISO 3166-1 alpha-2); or country-subdivision code (ISO_3166-2)
• An easy localisation file containing a list of sign identifier, local name, aliases for a
• A sample implementation of the top 5 or 10 values without presets - https://taginfo.openstreetmap.org/keys/traffic_sign#values (anything with > 20,000 uses?) - the community could provide PR's for more detail/their countries

I'm unclear from reading through the preset schema if these kind of country-specific-presets are possible.

Psuedocode examples -
traffic_signs/nl/presets.json

[
     {
       "key": "traffic_sign",
       "value": "NL:G12a",
       "description": "Cyclepath Sign / 
Fietspad Teken (NL G12a)",
       "object_types": ["node"],
       "icon_url": "https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_G12a.svg"
     }
]

Out of scope:

• Conditional signs are complex and would require significant detail; I'd exclude them from this feature request

[bhousel]

Ah yeah country-specific presets are a thing that iD does not have yet. We'll also need this to make name-suggestion-index presets even better.

[Mannshoch]

To get a database with street signs maybe you could us this feature request from streetcomplete/StreetComplete#633 to request country specific questions and complete the database.

[rivermont]

I've been wanting to create a database of signs for a while now. It seems like this should be something outside of iD so that different editors can access the data, like the name-suggestion-index and editor-layer-index.

[CloCkWeRX]

Somewhat related: https://www.mapillary.com/developer/api-documentation/#traffic-signs - not aligned to the country codes as per the wiki; but they do highlight the common, real world multiple country signage.
Potentially available somewhere under an open license and in a structured format

[CloCkWeRX]

Started sketching out how this might look in https://github.com/CloCkWeRX/signage-suggestions-index

Example:
https://github.com/CloCkWeRX/signage-suggestions-index/blob/master/data/au/presets.json

Will have to decide around country specific signs vs openstreetmap preferred tagging (ie; stop signs, give way, it makes more sense to use OSM defaults for editing, but as a reusable database, more sensible identifiers)

[CloCkWeRX]

Oh, just found https://github.com/yopaseopor/traffic_signs_preset_JOSM , investigating!

[rivermont]

That looks like a great starting point. Looking at just the US collection, it is missing many signs and looks like it was extracted from an abbreviated MUTCD or similar. It also has many duplicates, for example W1-1 and W1-1L. It definitely isn't comprehensive but is the most organised and broad dataset I've seen.

[quincylvania]

I just did openstreetmap/iD#6124 which allows presets to specify countries via a countryCodes property. We now use this to filter the name-suggestion-index presets, which include country codes.

Given the recent success of the name-suggestion-index project, I'd say now would be a great time to create a similar sign index! Especially if we can link the sign types to Wikidata.

[bhousel]

This is something that really would belong in NSI, (but depends on our collection script being able to collect the list of signs) so I'm closing here so we can track it better on osmlab/name-suggestion-index#8225

[1ec5]

Upon further investigation, osmlab/name-suggestion-index#8225 was closed because it would require substantial changes to NSI. I guess this issue should be reopened so we have some place to track an eventual solution, though I’m not sure it can be confined to id-tagging-schema. Adding traffic signs to id-tagging-schema wouldn’t be a walk in the park either, but at least some of the technical difficulties mentioned in osmlab/name-suggestion-index#8225 (comment), like localization, are nonissues for id-tagging-schema.

Images

Every one of these presets needs a unique image, which would be a pretty large undertaking. One of NSI’s advantages is its mechanisms for discovering images without having to manually specify an image for each preset. It looks like schema-builder already allows a preset to specify an imageURL, which would most likely point to an SVG image on Wikimedia Commons. But it couldn’t hurt for schema-builder to add another icon repository for Commons. If id-tagging-schema could automatically derive these URLs from the sign codes, there would be significantly less maintenance overhead.

Tagging combinations

The main challenge for id-tagging-schema would be an influx of new preset files requiring tagging review. Maybe it would make sense to start with the generic values, as in #928. Then, in regions that have more specific sign codes, we can mark those generic presets as unsearchable and add presets that inherit from the generic ones. (Does this work?) At some point, though, mappers in a region will want a full complement of signs applicable to their region, even if there’s no corresponding generic value.

Parameters and assemblies

There are two competing tagging styles for parameterized traffic signs or sign assemblies. Some mappers stuff details about every sign on a post in a traffic_sign tag on a single node (“inline style”), while other mappers put details on secondary keys like maxspeed and map each sign as a separate, coincident node (“structured style”).

The inline style predominates globally. However, the structured style is popular in the United States, despite the wiki’s clear preference for the inline style, possibly due to real-world differences in signage standards. For example, the most common sign assembly in the United States (by probably a few orders of magnitude) is unmappable using the inline style:

View from the south	Inline style	Structured style
	traffic_sign=US:D3-1[E Main St];D3-1[S Center St];R1-1,R1-41 direction=?2	traffic_sign=US:D3-1 name=East Main Street layer=4 direction=90;270 colour=green traffic_sign=US:D3-1 name=South Center Street layer=3 direction=0;180 colour=green traffic_sign=US:R1-1 layer=2 direction=180 traffic_sign=US:R1-43 layer=1 direction=180

I firmly believe that the structured style is the only one that editors could reasonably implement presets for. The inline style is more like the opening_hours syntax in its complexity, and we all know how that’s going a decade on: openstreetmap/iD#974. Yet unlike the opening_hours syntax, it lacks clear answers for common situations like a sign that takes multiple parameters, or an assembly of double-faced signs facing in different directions. There are probably also cases where the inline style would overflow the 255-character limit for a tag value.

On the other hand, the structured style requires mappers to meticulously place nodes atop each other. I’m confident that editors could tweak some behaviors to make that more ergonomic for traffic sign nodes, but it does preclude mapping traffic signs as vertices on roadways (a positive thing, in my opinion).

Related features

Most of the tagging documentation on pages like “MUTCD” and “Road signs in the Philippines” is actually about how to map the thing that the sign talks about, such as a nearby turn restriction or link road. Handling those “external” tags would go beyond the scope of a preset per se, but I think id-tagging-schema would be pretty useful for powering a “suggested nearby presets” feature, like in the iD v3 branch: openstreetmap/iD#4139 openstreetmap/iD#6583. I’m not sure how “suggested nearby fields” would work though. Maybe a validator warning that, say, the maxspeed on this traffic sign doesn’t correspond to any nearby roadway’s maxspeed?

Footnotes

1. D3-1 can vary by both a name and a color, but which comes first in the parameter list? ↩

2. Impossible to tag direction, even with semicolons, because a street sign faces two directions simultaneously. ↩

3. Assumed to “cascade”, that is, modify a sign on a higher layer per the relevant sign standard. ↩