Open adamfranco opened 2 years ago
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.
š 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...
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 likename=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...
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:
But the second one would have the street name dropped as it is redundant to one of the route relations:
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āsref=*
āstand-aloneā?name
exactly equal the routeref
, begin with theref
followed by a non-word character, has theref
with a non-word character on either side, or has a non-word character followed by theref
at the end? If so, then the wayname
is redundant of the routeref
s.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 whereref
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 against100
and once against15
, the refs of its two parent route relations:^100$|^100\W.*$|^.*\W100\W.*$|^.*\W100$
? False^15$|^15\W.*$|^.*\W15\W.*$|^.*\W15$
? TrueAlgorithm 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
7289 - Similar issue of overly wordy turn directions, but focused on filtering which routes are announced (rather than suppressing the street name).