Open 1ec5 opened 6 years ago
Why not to have new texts including name
, ref
and destination
?
Brevity, primarily. For example, turning left, this is already wordy enough:
Turn left onto James A. Rhodes Appalachian Highway (SR 32 West)
I don’t think there’s enough ambiguity in this instruction to justify an additional clause:
Turn left onto James A. Rhodes Appalachian Highway (SR 32 West) towards Newtown
In this case, destination
is tagged on the surface streets to improve guidance at preceding maneuvers. If the driver takes exit 63B instead of 63A, they’d have no opportunity to access Eastgate Boulevard, because the exit 63B ramp joins SR 32 well after the Eastgate Boulevard exit. A router would ideally say “Eastgate Boulevard” instead of “Newtown” at the A-B split if the route leads to Eastgate Boulevard. So the destination=Eastgate Boulevard
tag tells the router to prioritize “Eastgate Boulevard” over “Newtown” throughout the sequence of steps. The Mapbox Directions API takes care of this prioritization independently of OSRM Text Instructions. (Valhalla has similar logic, for what it’s worth.)
The names are not always more relevant than destinations. For instance, here in France, most ways outside of towns have no name, but all of them have a ref and most of them have destination signs at junctions. Even when, for instance, motorways are named, it is only a nickname, nothing official nor displayed on signs.
Besides, when the way is named, it is not very readable compared to destination signs. For instance:
Here, the destination of the way, Saint-Dié, is very readable, whereas its name, Quai Jules Ferry on the bottom right brown plate, is far less readable. When way names are displayed on site, they are virtually always less readable than destination signs; according to the example US pictures given above, I would say it is the case in other countries. If fact, it seems logical: a driver using signs only has to know where he wants to go, so this data is emphasized on signs, unlike way names, which are of little interest for passage.
That is to say: to help one to find the right way at junctions, giving the destination of the way seems far more useful, and fitting in more IRL cases, than giving its name, as it is quicker and easier to find for a driver, and far more likely to be displayed than the name.
In OpenStreetMap, the
destination
tag can be used on anyhighway
way, not just ramps, to encode what’s posted on guide signage. While usage on non-ramps such as surface streets is relatively rare in the U.S., it is important in some cases involving collector-distributor ramps. Unfortunately, OSRM Text Instructions gives undue preference to the destination tag on surface streets, ignoring the name and ref that are more likely to be useful to a driver.Example
The interchange between I-275 and SR 32 east of Cincinnati features multiple weaving collector-distributor ramps:
I-275 is a freeway. SR 32 is an expressway that has freeway-style exits interspersed with at-grade intersections, so it’s tagged
highway=trunk
and treated as a non-motorway by OSRM.The problematic route starts with this highway exit:
Expected instructions:
Actual instructions: ✅
Then it splits into two ramps, exit 63A on the left and exit 63B on the right:
Despite the exit 63A signage, the ramp to the left goes both westbound toward Newtown and eastbound toward the Eastgate Boulevard exit:
The
destination
on these two segments of SR 32 tag cause OSRM Text Instructions to omit the name and ref from text and voice instructions in favor of the destination, which is the least important information at the at-grade intersection with SR 32.Diagnosis
The root cause is this code that unconditionally prioritizes a step’s
destination
over itsname
andref
(contained in thewayName
variable):https://github.com/Project-OSRM/osrm-text-instructions/blob/42e39ed92682e05a8b7b52cc5850e22c1275e25c/index.js#L178-L183
This code needs to consider the passed-in road classes: for
motorway
, it should choosedestination
; otherwise, it should choosewayName
./cc @lyzidiamond @allierowan