Visual Indicators / Signs

[MoKob]

To further improve upon our guidance, we want to handle sign information and visual indicators. These indicators can be a list of symbols (e.g. airport), or destination signs / highway names. Wherever these signs are located, they can help to disambiguate guidance. Think follow the signs towards San Francisco over turn right and take the ramp.

Modelled Data

• destination=* Seems to be the method of choice. It can be found at nodes, ways, and relations.
• Relation:destination_sign, rarely used right now. 99 occurrences according to taginfo. Can probably be ignored.

  Tasks

• [x] inspect data / find out how to parse data correctly
  • [ ] nodes
  • [x] ways
  • [ ] relations

Based on the results of the inspection, we have to find the best way to store the information. Right now all information for turns is stored with the edge-based edges. Most of them however, will not have destination signs assigned to them.

A possible way could be to store a lookup-table based on the edge-based edge-ids to additional turn-information. Only if such a sign is present, the data can be added to the turn in the postprocessing.

Storing the data directly with the edges is not reasonable, unless we manage to do some variable length encoding. The reasoning behind my assumption here is that the vast majority of turns (e.g. residential areas) does not contain destination signs.

• [x] store turn data, either as look-up table or
• [x] implement variable length encoding of edge data

Finally, the data has to be exposed to the API. This is a simple look-up in the final stages of the API when we generate the response. Both for having a dedicated look-up table or for variable length-encoding.

• [x] expose sign data

[emiltin]

can this be combined with #1342?

[willwhite]

Think follow the signs towards San Francisco over turn right and take the ramp.

Would this include incorporating exit numbers into instructions as well? E.g. take exit 18 and follow the signs towards San Francisco

[MoKob]

@willwhite essentially any part of data that we can get should be included in the response.

so exit nr, visual indicators, and destination names would be on my list right now. How the API expresses the available data into strings is something to discuss on the frontend-side of things.

[pratikyadav]

destination=* Seems to be the method of choice. It can be found at nodes, ways, and relations.

There is one more tagging system for mapping destinations in OSM using exit_to (https://taginfo.openstreetmap.org/keys/exit_to#overview).

Although destination tag on ways seems to be more relevant for mapping guidance signs, there is still large no of nodes with exit_to tags for representing such feature.

http://www.openstreetmap.org/user/mvexel/diary/35855

[daniel-j-h]

Context

• https://en.wikipedia.org/wiki/Exit_number
• https://en.wikipedia.org/wiki/Exit_numbers_in_the_United_States
• US Traffic Signs http://mutcd.fhwa.dot.gov/services/publications/fhwaop02084/

OSM

• DE Signs http://wiki.openstreetmap.org/wiki/DE:Verkehrszeichen_in_Deutschland
• US Signs http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_States

exit_to

• http://wiki.openstreetmap.org/wiki/Exit_Info
• http://wiki.openstreetmap.org/wiki/Key:exit_to
• http://taginfo.openstreetmap.org/keys/exit_to

destination

• http://wiki.openstreetmap.org/wiki/Exit_Info
• http://wiki.openstreetmap.org/wiki/Key:destination
• http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details
• http://taginfo.openstreetmap.org/search?q=destination
• http://taginfo.openstreetmap.org/keys/destination
• http://taginfo.openstreetmap.org/keys/destination%3Aref

[daniel-j-h]

For the record: yesterday's night project: https://github.com/daniel-j-h/exit-signs Started out for gathering some statistics in order to make data-driven decisions here.

Here are some statistics on ref= and destination=* tag distribution on highways:

Extract	no ref, destination (*)	ref, destination	ref, no destination
Berlin	940	164	21521
SF	1201	43	9374

The second column () shows that we can add roughly 5% (for Berlin) and 10% (for SF) additional ref tags by simply rewriting `destination=toref=*` without loss of any information. Next action for me is to implement this in a Lua profile library function.

[daniel-j-h]

This will completely land with https://github.com/Project-OSRM/osrm-backend/pull/2482.

[danpat]

https://github.com/Project-OSRM/osrm-backend/pull/2482 has landed, marking this as done!