Usage of the destination and destination:street tag with the street name

Minh_Nguyen · July 31, 2023, 12:45pm

Thank you for bringing this issue to the wider community. It’s been festering for several years; hopefully we can put an end to the uncertainty around this key.

Streets as destinations

Unlike in much of the world, a destination sign in the United States or Canada can name any combination of streets, places, schools, and attractions as destinations. (The technical term is “traffic generator”.) Streets are particularly common destinations in urban areas, since neighborhoods generally may not appear on these signs.

For some use cases, it might be nice to distinguish between street names and place names. In English, a router can say, “Take the exit onto Street Name toward Place Name,” instead of simply, “Take the exit toward Street Name and Place Name.” However, each language has its own requirements for natural-sounding guidance. For example, French places an article before some names and varies them by grammatical gender.

`destination:street`

Originally, streets were always included in destination just like any other kind of traffic generator. In February 2015, a Valhalla developer modified a fairly well-known wiki page to propose splitting out streets as destination:street, introduced this key into the database, and implemented it in Valhalla within the span of a few days. As far as I can tell, there was no discussion about this key until the following year:

followed by discussions in December 2016 on the obscure talk page and January 2017 on a sprawling mailing list discussion that quickly devolved into a debate about how to delimit multiple values in a tag:

Later that year, Telenav started using destination:street in their mapping and @mvexel incorporated it into the main destination proposal. Meanwhile, Mapbox’s data team found it in the wild and incorporated it into their mapping guide, while their colleagues on the OSRM team implemented it as a fallback when destination is missing – incompatible with Valhalla’s implementation.

Not all streets are equal

By then, this key had already seen some organic adoption in the U.S. However, this growth – and the proposal – was largely based on a distinct practice by some state highway departments of including a street name as “alt text” for a route shield:

Some signs even distinguish between these supplemental destinations and streets that happen to be destinations, like “Stevenson Expressway” (the name associated with Interstate 55) and “Lake Shore Drive” (a destination in its own right):

While supplemental destinations may be useful to show in some contexts, mentioning this fine print so prominently in guidance instructions, as Valhalla does, confuses the user for no good reason. Moreover, shunting street names to a different subkey erases information about the order of destinations on the sign, which doesn’t necessarily begin with the street name:

Valhalla’s developers were content with this dataloss because Valhalla only used destinations to produce guidance instructions as complete sentences, omitting all the destinations except the one that you’re headed towards. Later, after Mapbox adopted Valhalla, they introduced on-screen renderings of destination signs, similar to CheckAutopista2. This use case requires the destinations to be in the same order as on the sign, so Valhalla’s ranking approach is counterproductive. In order for this feature to work with OSM data, OSM would need to maintain a single ordered list of destinations.

For these reasons, Mapbox later retracted its suggestion to use destination:street, and OsmAnd also declined to support it. Valhalla and CheckAutopista2 are the only data consumers that attempt to combine destination:street and destination, but this leads to incorrect assumptions. For example, this exit for Chillicothe and Richland Avenue was tagged destination:Chillicothe destination:street=Richland Avenue:

In my opinion, the dataloss and potential for real-world confusion matters much more than choosing the perfect preposition in voice guidance.

For what it’s worth, this is just a draft proposal, and I’d be quite open to moving these “supplemental destinations” to some other key, as long as it isn’t destination. It’s unfortunate that the most obvious key, destination:street, conflicts with Valhalla’s any-street-name definition. Valhalla’s definition has always been, essentially, tagging for a particular router in a particular region in a particular language. But dislodging that usage would be tricky; the key has already been skunked.

If the community does prefer Valhalla’s definition, then we need another tag to indicate the relative orders of the values in destination and destination:street, to avoid (further) dataloss. We’d also need to convince most routers to add support for destination:street or risk putting mappers in a catch-22 situation.