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. ↩

[k-yle]

Creating a separate preset for every sign is going to be a huge task, so as a first step, it would be nice to show a preview image for the existing traffic_sign field. This only requires minimal changes to iD and I've made a demo that works for certain countries where the wikipedia page is easy to parse.

I'd be keen to assist with creating an index but as far as I can tell from this issue and osmlab/name-suggestion-index#8225, there is no work underway at the moment (?)

[tordans]

FYI I started working on this a few month ago (but did not finish it, yet). There is this nice tool http://osmtools.de/traffic_signs/ which is not maintained anymore. I used many ideas and the base data from that tool to create https://trafficsigns.osm-verkehrswende.org/ (https://github.com/osmberlin/osm-traffic-sign-tool).

I see those use cases, that a tool like this would ideally cover:

• handle combinations of traffic signs
• handle traffic signs with values like maxspeed=90 or conditions (only…/for…/from-to…)
• name the traffic_sign value for a traffic_sign=* node
• name the recommended values for the lane
• help with special cases like traffic_sign:forward, bicycle:traffic_sign (not yet supported)

It would also allow for reverse lookup to show the signs visually but also commend on the current tagging ("usually this sign also has a segregated=yes tag").

I did not look into how to possibly integrate it into NSI but the data can probably be migrated (once it is collected and validated).

[1ec5]

I agree that we should at least make the existing field more visual. At least mappers who are unfamiliar with the sign codes would be able to verify existing tags, even if they’d be unable to map any from scratch without consulting an external reference. We should track a custom field implementation separately in the openstreetmap/iD repository rather than here in this preset-specific ticket.

This only requires minimal changes to iD and I've made a demo that works for certain countries where the wikipedia page is easy to parse.

Let’s not rely on scraping Wikipedia articles. Wikipedians will feel absolutely no obligation to avoid breaking scrapers, and may even be tempted to do so! Instead, rely on the fact that Wikimedia Commons is trying to maintain a predictable file naming scheme. For example, in Australia, the patterns (after splitting traffic_sign=* by commas and semicolons) would be:

• National: AU:([-\w]+) → File:Australia_road_sign_$1.svg
• State-specific: AU:(\w\w\w):([-\w]+) → File:AU-$1_road_sign_$2.svg

There would need to be a JSON of these mappings, but it wouldn’t be very large.

Instead of embedding the Special:FilePath image directly, implement a service for Wikimedia Commons that accepts a file name, maximum width, and maximum height and outputs a thumbnail from the MediaWiki API. This will better accommodate some countries for which the signs have only been uploaded as PNGs or (gasp) JPEGs so far.

I used many ideas and the base data from that tool to create https://trafficsigns.osm-verkehrswende.org/ (https://github.com/osmberlin/osm-traffic-sign-tool).

So you’re the one behind this tool! I’d like to see a similar tool for the MUTCD at some point, regardless of how iD ends up integrating traffic signs. Something for the big old to-do list…

/ref osmlab/name-suggestion-index#8225 (comment)

[tordans]

A few quick notes

• For the MVP for iD: I think the images would be great. But also adding a "title" and a link to the OSM Wiki per sign would also be very helpful to quickly learn more about the sign. I split the traffic_sign-value for my too to create separate wiki links.
• On signs with text: One annoying thing is, that at least for Germany not all traffic signs are tagged as an explicit ID but rather with additional info. So a on-to-one matching from string to image is not possible. One has to modify the SVGs in order to show the final image. (Which is also the part that does not work good enough in my tool.)
• On preset images: Just a reminder that it is possible to also change the preset image to an external source which can be an SVG traffic sign from wikidata. I tried this for Add presets for German bicycle DE:240 #345. That opens up new talks about how the privacy dialogue should handle those URLs, though…
• On Parsing: When I build the tool I tried parsing some content to get the traffic sign images but that did not always work when the convention was not used. Also, it is not like all traffic signs are used equally in OSM. I think if we started a lean process to create a shared JSON to collect the base data that could work very well and would make the whole system more stable and easier to understand.
• On MUTCD: My tool already has some pieces to support multi country data and multiple translations.

[k-yle]

Let’s not rely on scraping Wikipedia articles. Wikipedians will feel absolutely no obligation to avoid breaking scrapers, and may even be tempted to do so! Instead, rely on the fact that Wikimedia Commons is trying to maintain a predictable file naming scheme. For example, in Australia, the patterns (after splitting traffic_sign=* by commas and semicolons) would be:

• National: AU:([-\w]+) → File:Australia_road_sign_$1.svg
• -specific: AU:(\w\w\w):([-\w]+) → File:AU-$1_road_sign_$2.svg

There would need to be a JSON of these mappings, but it wouldn’t be very large.

In the case of Australia, unfortunately the file names in Wikimedia Commons have a number of inconsistencies such as:

File:Australia R5-71.svg
File:Australia road sign R6-1.svg

File:Queensland R5-Q05.svg
File:AU-NSW road sign R5-406.svg

File:Australia_road_sign_R4-1_(20).svg
File:Australia_road_sign_R4-1_(25).svg

So I imagine we will still need to create a mapping between each traffic_sign ID and the associated image(s), at least for some countries. @1ec5 I believe you previously suggested using a wikidata item for each traffic sign¹, I've read Wikidata:Notability but it's not clear to me if it would be acceptable to create 1000+ wikidata items per country (?)

Q97332032 seems like a good example, although it is only connected to one (blank) image instead of all the possible variants²

Footnotes

1. https://github.com/osmlab/name-suggestion-index/issues/8225#issuecomment-1575713163 ↩

2. Of course, there are many cases where there is no image for every possible value. ↩

[1ec5]

In the case of Australia, unfortunately the file names in Wikimedia Commons have a number of inconsistencies

I guess the Australian roadgeeks are a little behind the American ones. 😉 You could request a batch renaming at the Village Pump, but if you’re willing to create Wikidata items, then that would be far more robust anyways.

it's not clear to me if it would be acceptable to create 1000+ wikidata items per country (?)

Yes, it would be. To keep any of the items from getting deleted, you can add a reference to the actual standard and/or add structured metadata to each image to say that the image depicts the item.

One annoying thing is, that at least for Germany not all traffic signs are tagged as an explicit ID but rather with additional info. So a on-to-one matching from string to image is not possible. One has to modify the SVGs in order to show the final image. (Which is also the part that does not work good enough in my tool.)

The advantage of a preset is that no one would expect the preset icon to faithfully encode all these details. I think it would still be possible to get away with a simple sign blank if we stuff a small icon inside the text field, similar to the color swatch in a color field.

If we do decide to inject text into the SVG, the placeholder text element ID (P9410) property would tell us where in the file to inject it. But getting this right would be difficult: every country uses a different set of typefaces on its signs; some, like the German DIN 1451, are proprietary. Using the right typeface would matter because the kerning and sizing would be bizarre and unreadable otherwise.