-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add country / state specific traffic sign presets #11
Comments
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. |
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. |
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. |
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. |
Started sketching out how this might look in https://github.com/CloCkWeRX/signage-suggestions-index Example: 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) |
Oh, just found https://github.com/yopaseopor/traffic_signs_preset_JOSM , investigating! |
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 |
I just did openstreetmap/iD#6124 which allows presets to specify countries via a 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. |
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 |
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. ImagesEvery 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 Tagging combinationsThe 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 assembliesThere are two competing tagging styles for parameterized traffic signs or sign assemblies. Some mappers stuff details about every sign on a post in a 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:
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 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 featuresMost 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 Footnotes |
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 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 (?) |
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:
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 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). |
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.
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
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.
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… |
A few quick notes
|
In the case of Australia, unfortunately the file names in Wikimedia Commons have a number of inconsistencies such as:
So I imagine we will still need to create a mapping between each
Footnotes
|
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.
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.
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. |
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:
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
Out of scope:
The text was updated successfully, but these errors were encountered: