Add a new category for traffic signs

[Dimitar5555]

Coming from openstreetmap/id-tagging-schema#11.

I think that a good idea is to have them separated in files for each country (data/traffic_signs/DE.json for example).

The suggested schema also looks ok to me. description is the string that is shown to the end user, maybe we can rename it to name or displayName. There could be additional fields for some signs (maxweight, maxspeed, maxheight` etc.).

[
     {
       "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"
     }
]

I assume that it is possible to add locationSet to each item for the dist folder during build time.

[UKChris-osm]

I’m not quite sure what this is asking for?

Are you referring to adding brand / operator tags for traffic signs, which I would suggest is unnecessary considering how many signs exist, and which would likely already be region specific by default.

Or is this about Country specific traffic icons appearing in iD when editing? If so, I think that would be out of scope for the NSI, but would work well as a new repository, and could mimic how the NSI works with Country specific presets being available.

I think the comment from @bhousel was about how country-coder would make the NSI better, and not about adding traffic signs making the NSI better. I see the former maintainer of iD @quincylvania also thought a new repository would be a good way to make traffic signs available.

If I have misunderstood this issue, my apologies.

[bhousel]

"An item for every traffic sign" is a thing that we could add here to name-suggestion-index under its own tree, but it would make sense to do ideditor/nsi-collector#2 first, so that we can collect the data from Wikidata where it already exists. (Road routes #4768 are like this too)

The chatter on that other issue was from 2019 in an issue in the iD repo - back then I was the maintainer and iD did not have country specific presets.

Since then, we added support for specific presets using the Country Coder and locationSet geofences, then I was forced off the iD project, and many of those old iD issues got moved over to the id-tagging-schema repository.

[1ec5]

As with road and bicycle route networks (#4768), the tagging for traffic signs would be based on a code system rather than Wikidata QIDs. The codes would be based on national and subnational standards but would probably have to be maintained in this repository.

As with flags (#5982) and denominations (openstreetmap/id-tagging-schema#254), the preset names need to be localizable. Many countries officially speak multiple languages that have different words for the same exact sign, regardless of the location within the country. These aren’t proper nouns, so the name of a sign in another language really wouldn’t be understandable or searchable (except maybe for “Stop”).

[LaoshuBaby]

https://github.com/arch0345/traffic-sign-index/blob/3c00347cbd629d7f2cf86c7cd2bba65742f32d5e/data/us/w8-21.json

Here is another project that aimed to collect traffic sign, but looks like only contain US data currently.

[1ec5]

Yes, looks like @arch0345 started indexing Wikidata items about MUTCD signs, of which there are very few. Regardless of the repository, I think it would be worthwhile to automate the creation of indices like this, with the manual aspect being limited to OSM tagging at most. That could include mass-adding items about these signs to Wikidata.

[bhousel]

Can the identifying tagging be based on a link tag like sign:wikidata or something ? It helps a lot if we can do this the same way we did the flags.

[1ec5]

traffic_sign is already a systematized identifier scheme, based on published standards, so I’m not certain that pairing it with a Wikidata subkey would have an advantage other than possibly convenience for an index. However, there is a need for a machine-readable representation of, for instance, the MUTCD tables on the wiki, which a repo structured like NSI or id-tagging-schema could collect. Or we could totally lean into Wikidata and create all the sign items there, tagging those items with standard sign numbers and OSM tag statements. Then any index would just be using Wikidata as a backing database store.

[bhousel]

traffic_sign is already a systematized identifier scheme, based on published standards, so I’m not certain that pairing it with a Wikidata subkey would have an advantage other than possibly convenience for an index.

Can you connect the dots for me? I'm not seeing how I'd actually accomplish this.

e.g. I go to
https://wiki.openstreetmap.org/wiki/Key:traffic_sign

I see

Ok, so GB:956 is some kind of standard value. Where do I go to get that image as an svg?

The List of IDs by country table has some resources, but also a lot seems missing.
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Lists_of_IDs_by_country

I follow the links there to other places, but neither of these pages has anything about 956 at all:
https://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom
https://en.wikipedia.org/wiki/Road_signs_in_the_United_Kingdom

Compare this to flags, where there's a very clear path from flag:wikidata=Q42537 to whatever info I need about the flag, including the image of it.

[1ec5]

First of all, I agree, there are still a lot of gaps. Ultimately, an editor needs three things to correspond to a given standard traffic sign:

• Diagram image
• Names in different languages (not just one language)
• Relevant OSM tags

One option for associating a traffic sign with a Wikimedia Commons image would be to rely on pattern matching. Unlike for brand logos, the road editors on Commons insist on consistent file naming whenever possible. So the UK’s sign 956 is located at https://commons.wikimedia.org/wiki/File:UK_traffic_sign_956.svg. The format for each country does differ, but that would be a much smaller set of strings to maintain in an index repository.

Unfortunately, all Commons can provide is the image. For the name of each sign, we can build out Wikidata’s coverage of sign items and use their labels, as I alluded to above and as OSM Americana has successfully done with road networks. Or we can maintain our own tables of sign names in this repository and solicit translations through a TMS such as Translatewiki.net or Transifex. Either way, I don’t think we need to add any Wikidata QIDs directly to OSM, because the lookup table between official sign codes (which are tagged) and Wikidata QIDs would be a straightforward SPARQL query; the index could simply cache the results.

For the other OSM tags that indicate the sign’s parameters, such as maxspeed=*, there’s really nothing out there at the moment. I’m not particularly inlined to write a scraper of OSM wiki pages to generate the tag presets, and there are other considerations, such as tags that don’t go on the sign node itself. openstreetmap/id-tagging-schema#11 didn’t sound like such a bad idea to me in theory, but I don’t think that repository as currently structured would scale to the sheer number of presets we’d need. Just for California alone there would be 700 presets. The UK has almost as many.

[UKChris-osm]

If traffic signs become part of the NSI, would this make the dataset a lot larger than it is now?

[bhousel]

If traffic signs become part of the NSI, would this make the dataset a lot larger than it is now?

Yes, but I'm not too worried about that. nsi.min.json is currently 1.3MB and I get it from the CDN in 331 ms.

The raw file is actually 8.0MB, but servers (like the CDN) will gzip it when sending it over the wire to your browser, and JSON gzips really efficiently, so it actually goes faster than a lot of the other things that Rapid downloads at startup (like OSM data).

We could also do other things to make the files smaller or break them up it it becomes a bigger problem.

[bhousel]

Oh for context on those other numbers - NSI currently has around 25k items in it:

[1ec5]

To be clear, I’m not concerned about the package size – and there will probably be few if any new geometries to add, so it wouldn’t really exacerbate the current memory issue either. Rather, it would be more of a logistical challenge to manage an influx of manually maintained traffic sign presets, and traffic sign presets would need to behave quite differently than the other kinds of presets in this index.

We need a way for an NSI entry to result in a preset that adds multiple blank fields for the mapper to populate. Some signs are straightforward, like or – you just tag it as traffic_sign=US:W14-2 or traffic_sign=VN:I405c and move on. But others like require additional tagging to make any sense. There are two competing styles for encoding the sign’s parameters: traffic_sign=US:R2-1[50] or the combination of traffic_sign=US:R2-1 maxspeed=50 mph. I strongly believe the latter style is superior and more internationalizable, but either way, we aren’t going to create a separate preset for every possible combination of values that can go in a sign. The wiki has only documented the expected tags for a minority of common signs, and many of the suggested tagging combinations need review.

On top of that, the name of each preset needs to be translated into every language, or at least the locally relevant languages. If the mapper selects the generic Traffic Sign preset, the Traffic Sign field’s dropdown needs to list the available signs by name and icon. The preset needs to work with traffic_sign=* instead of *:wikidata=*. A lot of this functionality is normally provided by id-tagging-schema for its preset definitions, so at least there would be a model to follow if we want to take that on in NSI.

[bhousel]

Yeah, sorry to say this just sounds too hard. The schema for traffic sign tagging is too chaotic, we'd need to change a bunch of things about how NSI works in order to support it. You've talked me out of it 😁