Suppress redundant road names which restate the route reference/number

[adamfranco]

🚀 feature request

Description

What's working well...

OsmAnd announces both the route numbers (I'm assuming from OSM route-relations) and road names (from OSM ways) when announcing turns. In general this is an important feature because signage at any given intersection may show either route signs or road name signs. For roads where the name=* is something different than the route number, this is especially helpful a turn direction like the following will be valid if only a route sign is present or only a street-name blade sign:

At this location...

Turn left on VT 30, VT 125 South Main Street

The problem...

In North America there is a common tagging convention in OSM to tag roads known by their route number with a name=* that matches addresses along the road and highway blade signs. The names often take the form of something like name=State Highway 25 or name=Vermont Route 15 West (where this "West" in this case is referenced from the village center rather than being a travel direction).

When driving on roads tagged this way, OsmAnd announces the route numbers first, followed by the street name, which is actually another restating of the route number. For example:

At this location...

Turn left on VT 15, VT 100 Vermont Route 15 West

This announcement is much longer than desired and the extra restating of the route number adds to the cognitive load and makes the turn direction much harder to interpret. This becomes even more of a problem when there are many route concurrencies splitting at an intersection.

Describe the solution you'd like

Instead of always including the road name, directions would be more understandable if the road name was only included in the turn directions if it isn't a repetition of the route numbers. The first example above wouldn't change:

Turn left on VT 30, VT 125 South Main Street

But the second one would have the street name dropped as it is redundant to one of the route relations:

Turn left on VT 15, VT 100

I've discussed this problem in the OSM-US Slack channel as I initially thought that this was likely a tagging issue that would require new data to be mapped in OSM. In the long thread that followed it became clear that while there may be some edge cases that would require additional manual tagging to support data-consumers, the vast majority of cases should be able to be safely handled by a simple matching algorithm.

Suggested "name is redundant" algorithm

To test potential algorithms I wrote a script that pulls out route=road relations and their member ways from Geofabric's regional OSM exports, applies a simple redundancy algorithm to them, and then dumps out the results in tabular form.

Algorithm: For ways that are members of route=road relations… Does the way name contain any parent route’s ref=* “stand-alone”?

• Detail: Does the name exactly equal the route ref, begin with the ref followed by a non-word character, has the ref with a non-word character on either side, or has a non-word character followed by the ref at the end? If so, then the way name is redundant of the route refs.
• I accidentally did a case-sensitive match and it missed only a few names -- case sensitive is probably fine.
• There are route refs like ref=A, so delimiters are needed to avoid catching normal words.

This algorithm can be implemented as a dynamically generated regular expression matching the way name tag once for each parent route relation where ref is the escaped route reference value from the route relation: ^ref$|^ref\W.*$|^.*\Wref\W.*$|^.*\Wref$

Example:
For our second example, name=Vermont Route 15 West would be matched twice to determine redundancy, once against 100 and once against 15, the refs of its two parent route relations:

1. "Vermont Route 15 West" matches ^100$|^100\W.*$|^.*\W100\W.*$|^.*\W100$ ? False
2. "Vermont Route 15 West" matches ^15$|^15\W.*$|^.*\W15\W.*$|^.*\W15$ ? True
3. The name is redundant -- do not include in turn announcement.

Algorithm testing results
The results of this test script (Google sheet, grouped by relation) show the effectiveness of this algorithm at pulling out names that are largely redundant while successfully ignoring non-route names of many formats. It turns out that there is wide regional variability on the inclusion of route numbers in names. Great Britain has almost none, while New York, Ohio, and Vermont have “redundant” names on about half of their routes.

Describe alternatives you've considered

The other alternative I've looked at is adding additional tagging to OSM ways to flag that the name is redundant to the ref. Something like name_is_ref=yes that data-consumers like OsmAnd could use to suppress redundant names. Given the demonstrated efficacy of the algorithm described above, this large amount of mapping effort is likely not worth it.

Related issues

• Voice navigation could be smarter about what names/numbers to use for street #7289 - Similar issue of overly wordy turn directions, but focused on filtering which routes are announced (rather than suppressing the street name).

[vshcherb]

Wow, you did quite a big task of investigation. Usually we do transformation here https://github.com/osmandapp/OsmAnd-resources/blob/master/obf_creation/rendering_types.xml but the algorithm you propose might not be declarable in this file.