Name and ref suppressed in favor of destination on non-motorway

[1ec5]

In OpenStreetMap, the destination tag can be used on any highway 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:

This example involves several branches, highlighted in this map.

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:

destination:ref=SR 32
destination=Newtown;Eastgate Boulevard;Batavia
destination:ref:lanes=SR 32 West|SR 32 East
destination:lanes=Newtown Eastgate Boulevard|Batavia
junction:ref=63
junction:ref:lanes=63A;63B

Expected instructions:

Take exit 63 on the right towards SR 32: Newtown

Actual instructions: ✅

Then it splits into two ramps, exit 63A on the left and exit 63B on the right:

destination:ref=SR 32 West destination=Eastgate Boulevard;Newtown junction:ref=63A

destination:ref=SR 32 East destination=Batavia junction:ref=63B

Despite the exit 63A signage, the ramp to the left goes both westbound toward Newtown and eastbound toward the Eastgate Boulevard exit:

The little green sign on the right side of this photo is for the ramp on the left side of the photo.

name=James A. Rhodes Appalachian Highway ref=SR 32 [role=west] destination=Newtown	name=James A. Rhodes Appalachian Highway ref=SR 32 [role=east] destination=Eastgate Boulevard
Expected instructions: > * Keep left at the fork towards SR 32 West: Eastgate Boulevard > * Turn left onto James A. Rhodes Appalachian Highway (SR 32 $west)	Expected instructions: > * Keep left at the fork towards SR 32 West: Eastgate Boulevard > * Turn right onto James A. Rhodes Appalachian Highway (SR 32 $east)
[Actual instructions](http://map.project-osrm.org/?z=16¢er=39.099518%2C-84.285994&loc=39.094889%2C-84.288061&loc=39.103397%2C-84.289187&hl=en&alt=0): > * Keep left at the fork towards SR 32 West: Eastgate Boulevard ✅ > * Turn left towards Newtown ❌	[Actual instructions](http://map.project-osrm.org/?z=16¢er=39.098569%2C-84.280500&loc=39.094889%2C-84.288061&loc=39.097631%2C-84.275339&hl=en&alt=0): > * Keep left at the fork towards SR 32 West: Eastgate Boulevard ✅ > * Turn right towards Eastgate Boulevard ❌

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 its name and ref (contained in the wayName 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 choose destination; otherwise, it should choose wayName.

/cc @lyzidiamond @allierowan

[yuryleb]

Why not to have new texts including name, ref and destination?

[1ec5]

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.)

[Penegal]

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.