Suppress temporary name changes along a designated route

[1ec5]

Going from Dallas to Missouri along U.S. 71/69, I encountered many name changes as I passed through small towns. The name would change to things like "Mays St." or "Main St." within the town limits before reverting to "State Hwy. 69" (which would be tagged in OSM as simply ref=US 69). Because the ref remains constant throughout the stretch of highway, more sophisticated routers avoid any mention of the name changes; instead, the UI and voice treat the entire road as one road named "US 69". This gives the user of a turn-by-turn navigation application a more accurate idea of the total length of highway they need to traverse, rather than the length of each individual town and the distances between them.

OSRM should similarly suppress any name change that reverts after (say) a mile, where the ref stays constant, and the road is a straightaway.

/cc @danpat @MoKob

[daniel-j-h]

Route with instructions on the demo server:

http://map.project-osrm.org/?z=7&center=36.337253%2C-95.581055&loc=32.776272%2C-96.796856&loc=38.760481%2C-92.561787&hl=en&alt=0

http --body 'https://router.project-osrm.org/route/v1/driving/-96.796856,32.776272;-92.561787,38.760481?steps=true'

39 NewName instructions, 25 of those have "US 69" in their name (ref).

I think we need https://github.com/Project-OSRM/osrm-backend/issues/2704 first to have a separate name and ref in the RouteStep. Then we could do this simply in post-processing.

[1ec5]

This would also mitigate name changes due to bridge names in OSM.

[MoKob]

The problem here is that the situation is not uniformly valid. In Germany, at least, there are a lot of roads that keep the same reference but have different names. The name might be the only displayed information, though, and the reference is only used on major directions signs. Suppressing the name change completely is difficult.

To me, this is just another case of not announcing name changes in voice but simply displaying them.

[1ec5]

In OSM, at least in the U.S., it's customary to tag non-signposted references with a tag like unsigned_ref or ref:unsigned. Unfortunately, there isn't an established way to indicate that a reference is only sporadically or inconspicuously signposted, for example only at major junctions or only when you squint at the sign. That occurs often in the U.S. as well, for example on county roads.

This isn't just a case of not announcing a name change. For example, Apple Maps says "stay on this road for 115 miles" upon entering US 69, even though temporary name changes occur roughly every 10 miles. There are no traces of the temporary names in the UI, other than street labels on the map. I'd be surprised if the temporary names were ever transmitted over their directions API.

It may be possible for the client to handle this particular case of coalescing, but there's a larger point to be made here. Route concurrencies are very common in North America and some European countries. Consider this hypothetical route:

1. Head south on Park Expy. (A 1)
2. Continue straight on High Pky. (B 10;A 1) – B 10 joins from the right
3. Continue straight on High Pky. (A 1) – B 10 splits off to the right at a ramp

Instead of three instructions, it should be possible to give one instruction to follow A 1 all the way. Naturally, if there is ever a maneuver other than continue straight, such as a fork or turn maneuver, then there would be no sense in coalescing steps like that.

This is a lot of processing for the client to perform. It isn't so much a performance issue as a maintenance issue.

[MoKob]

Requires: https://github.com/Project-OSRM/osrm-backend/issues/2704

An idea for a compromise here would be to consider road categories and potentially further parameters to distinguish between relevant and irrelevant name changes (e.g. only reference, name when coming back to the reference...).

If we find a good way to distinguish which ones might be relevant and which ones might not be, we could reduce the name changes along long routes while keeping relevant information.

[daniel-j-h]

Our prefix / suffix handling will get a boost once the name / ref split lands (https://github.com/Project-OSRM/osrm-backend/issues/2704), in addition:

If we find a good way to distinguish which ones might be relevant and which ones might not be, we could reduce the name changes along long routes while keeping relevant information.

from voice: the heuristics for announcing relevant changes will probably consider properties such as: road class, road width (potentially derived from number of lanes), turn angles, oneways, ...

[daniel-j-h]

Update: with my branch over at https://github.com/Project-OSRM/osrm-backend/pull/2900 for the original request:

http --body 'https://localhost:5000/route/v1/driving/-96.796856,32.776272;-92.561787,38.760481?steps=true'

we're now down to 8 NewName instructions. Which is now starting to look a lot more reasonable.

There are still a few in there we could suppress I guess..

[MoKob]

@daniel-j-h can you do a summary of the remaining 8 name-changes you get? from -> to name / ref strings?

Especially can you have a look at why the bride isn't collapsed as two consecutive name changes in post-processing?

[daniel-j-h]

Sure, here is the response:

https://gist.githubusercontent.com/daniel-j-h/5f6f5d0dc6042034e882322b8433c09d/raw/4b1ff9367f3896bf0adb000cab593f268e3f95e9/NewName.json

Here are adjacent RouteSteps and their names, where to is a NewName:

from name	from ref	to name	to ref
Young Street		Canton Street
North Central Expressway		Central Expressway	US 75
Central Expressway	US 75	South Jefferson Street	US 69;US 75
South Jefferson Avenue	5;32;64	East 7th Street	MO 5
	87	Prospect Street	MO O
Prospect Street	MO O	North Boonvolle Road	MO O
North Boonvolle Road	MO O	State Highway O	MO O
North D	MO D	State Highway D	MO D

Re. bridge: looks like the bridge is tagged "North Central Expressway" (you just can't see it in the image) and the Continue is for "North Central Expressway" -> "Central Expressway".

Looking into the route a bit more, what looks weird is the detour here:

but this seems okay given the main road is tagged with a maxspeed of 35kph and the roads around it with a maxspeed of 45kph.

[1ec5]

The Pryor Creek detour is probably an upstream data issue.

[daniel-j-h]

We managed to merge https://github.com/Project-OSRM/osrm-backend/pull/2900 already into the 5.4 release :tada: .

I'll sample NewName instructions emitted for routes and in case I can see potential for improvements (e.g. using suffix table, or completely removing NewName instructions) will open a new issue.