Closed 1ec5 closed 8 years ago
Route with instructions on the demo server:
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.
This would also mitigate name changes due to bridge names in OSM.
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.
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:
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.
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.
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, ...
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..
@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?
Sure, here is the response:
Here are adjacent RouteStep
s 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.
The Pryor Creek detour is probably an upstream data issue.
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.
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