Hello! I’m Anastasia. I’m an OSM communications specialist on the OSM mapping team at Lyft.
Due to the lack of a unified approach in OSM, we would like to bring up the topic of using the destination:street/destination tags with street names.
While working on our Destination signs project (Exit and Destination Signs project · Issue #18 · Test-DCT/OSM-LYFT-DCT · GitHub) we came across the issue of tagging street names.
Currently while mapping US cities, we are relying on Minh Nguyen’s proposal in our workflow.
According to this proposal the destination:street tag is used only if the street name is a supplemental that accompanies a route shield.
But we encountered a different point of view. It seems, an active mapper strongly prefers to add all the street names only to the destination:street and massively modify our edits by moving values to the destination:street tag.
We’ve been following the discussions in the OSM slack channels and have come to the conclusion that there is no final decision yet on the use of the tag and no rules strictly prohibiting adding street names to the destination tag.
One of the main arguments in favor of the proposal is that many destination signs have both streets, cities (and/or other POIs) and the distribution to the different tags can break their priority order in navigation systems. As a result, drivers may receive information about a less significant POI instead of the street that is listed first and where the “exit” actually leads.
Ex: Motorway link has both destination=Tulsa Zoo and destination:street tag=Sheridan Road tags.
Here is a simulation: OSRM
Guidance ignores destination:street at all, while it’s a main destination.
We would greatly appreciate your input regarding the usage of the “destination:street” tag. Our goal is to reach a consensus and avoid any potential conflicts. Your thoughts and insights are invaluable in this process.
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:
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 taggeddestination:Chillicothedestination: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.
Is the order really important? Not sure, in the US they are always in a defined order, in Germany and China that’s not always the case. As a data consumer I would feel distracted by getting all the sign read out.
I would expect top get a matching destination based on my actual route.
For voice instructions and compact visual instructions, I agree that it’s often better to mention only the destination that’s most relevant to your route, such as the destination that you’ll also take at the fork following the exit. This is the use case that the Valhalla team originally optimized for.
However, at complex junctions, users respond better to a design that lays out all the destinations in a layout reminiscent of the physical signboard. This is a real feature in GPS devices and navigation applications. In this layout, it’s important to maintain the same order as on the sign; otherwise, if the destinations are scrambled in a different order, the user has to go hunting for a matching sign, which makes this information counterproductive.
In most states, the order is consistent and even follows a set of subliminal rules. The Kentucky Transportation Cabinet specifies a typical set of rules:
When two destinations are included on a guide sign, the destination to the left at the end of the exit ramp should be placed above the destination to the right. If the destinations are in the same direction, then the closest destination should be listed first.
Other states like Ohio follow a similar practice implicitly. There’s no rule saying the street has to be named first. It just happens to come first much of the time because it comes closest to the ramp. But sometimes the signs name a major street farther away. Even if Valhalla knows that Eastgate Boulevard is more relevant than Newtown on a route that reaches neither the street nor the city, the user isn’t helped by subtly swapping the names on a green rectangle that otherwise looks like the sign.
Unfortunately for me, I also map in California, where Caltrans is notorious for inconsistent signage. Even the guide signs leading to the same exit sometimes list the destinations in reverse order. A typical example: a sign half a mile away from an exit lists the City of Santa Clara before The Alameda, a major street. However, at the exit, this becomes just The Alameda. Several years ago, when Caltrans assigned numbers to freeway exits around here, they had to remove the first destination from many older signs in order to make room for the exit number. (In this case, it’s the wrong exit number!)
There were slow-motion edit wars over these destinations until I mapped the signs. Even so, any traffic_sign node or destination_sign relation would use the same syntax involving semicolons in destination.
I don’t disagree with the idea of classifying destinations if it would help fine-tune voice guidance. However, it becomes problematic when the classification forces us to spread the names across multiple keys. A more robust alternative would be something like destination:type=street;street;city;city.
Courtesy of this discussion, used the destination:street:forward/backward a few times, direction signs pointing at road names further down, where road names and hamlet names are often same such as Via Xyz for the road and Contrada Xyz … for the locality. Learned something new without contributing \o/
As someone who uses the tags to draw European style signs, I don’t see a problem with order of entries, if we follow the same scheme as we already do with e.g. symbol and color: Use semicolon separated lists which are aligned between tags. For example a sign with first a street, then a city and then another street on pink background:
Did not see pink but then as one gets older you could/can/will turn slowly daltonic, and the drivers license office likes to test that every 5 years. I’d have overdone the tagging with
I have two main issues with this proposal the first is bleeding into the next set of instructions or the current set of instructions gets cut off and the next one starts, especially for short exit ramps within large metropolitan area (see sign for Superdome, hospitals, French quarter in New Orleans off of 10/90) or I-10/35 and US-90 in San Antonio where the exit ramp splits pretty quickly to stay on 10 to go east or 90 to go west. According to the sign, it’s 10/90, Houston/Del Rio/Lackland AFB. The first set of instructions would always get cut off, because there’s too much info before the next set of instructions take place.
The second issue I see with this, it’ll be used on surface streets where the green information signs exist for various destinations within a city. I still see you segments where there is a destination reference on a turn lane because a green sign exists for that particular destinations.
I’m also in the boat (I may be paddling this boat alone) of less info can be better for the end user. If I’m heading to the Audubon Zoo in New Orleans, I don’t need directions saying “zoo” or “Tulane University” to get me to the zoo, just “exit left on Main Street” or “exit right on exit 46 to 3rd Ave.”
Can you clarify which proposal are you referring to? Some routers, including Valhalla, do abridge the instructions to mention only one of the destinations when time is short, but this behavior isn’t dependent on any tagging proposal.
Agreed, I think it’s already been settled for years now that destination tags should omit any traffic generator that only appears on a supplemental guide sign but not on the exit direction sign. This is not to be confused with the supplemental destinations I referred to earlier, which are almost always on exit direction signs, often in fine print.
For example, for the following exit, “Bend” and “College of Siskiyous” only appear on the supplemental guide sign (“Next Exit”) but not the exit destination sign (the one with the arrow). So the highway=motorway_link’s destination should only mention South Weed Boulevard and Klamath Falls. If Bend and College of the Siskiyous make it onto any feature, it would be a traffic_sign node rather than a link way.
@A_Prokopova_lyft’s question is whether “South Weed Boulevard” should go in destination:street instead of destination, as the Valhalla developers prefer. Moving it to destination:street would enable Valhalla to say, “Take exit 747 toward onto South Weed Boulevard and toward Klamath Falls.”
That sounds pleasant if you’re actually headed to Klamath Falls to the east, but it would be inaccurate if you’re headed to the college to the west. It would also force other existing routers to say “Take exit 747 toward South Weed Boulevard and Klamath Falls,” and prevent a Valhalla-powered application from displaying something like this in the UI:
I’ve never seen the empty semicolon syntax used with destination tags in the wild. I guess that’s because color-coded destinations are so rare in the U.S., confined to surface streets and airport terminals. It does make sense that you’d want to match colors with their destinations.
Of the 310 ways that currently have empty values in destination, each of the six ways in the U.S. appears to be a mistake. This usage does appear to be more common in Europe, primarily in conjunction with destination:ref, destination:symbol, and destination:colour. Is the idea is to match route numbers with destinations on the same row, or perhaps to provide osmc:symbol-like detail about destination:symbol? Even then, it’s very inconsistent: spot-checking these ways reveals a lot of empty destination values that don’t correspond to a semicolon-delimited value in any other key.
According to this Overpass query, there’s currently only one link way in the world that uses an empty value in a semicolon-delimited destination tag in conjunction with destination:street, but it points to a value in destination:ref, so we can’t really use it to test whether this approach would be compatible with existing routers.
I don’t think this empty-value solution is satisfactory for salvaging destination:street. It would imply a one-to-one relationship between destination values and destination:* values that’s usually inaccurate in the U.S. It would also imply that guide signs pair route shields with destination names, even though the MUTCD always lists route information at the top (including supplemental destination names) and traffic generators at the bottom (including both streets and places). I’m aware of only a few exceptions to this rule in Maryland and Utah.
For example, this ramp carries eastbound Interstate 40 to Fort Smith, northbound Interstate 35 to Wichita, and eastbound U.S. 62 to Henryetta (far too small to be listed):
We can’t reasonably encode the correspondence between route numbers and destinations without essentially taking on a router’s responsibilities. Therefore I think it’s unnecessary to maintain a similar correspondence between “virtual” destinations and destination:streets – they should all just go in the same pile.
Long ago, @Skybunnyhad a great suggestion to keep the street names in destination but also duplicate them in destination:street, in the same manner that we might duplicate name in name:en. A router that needs to distinguish between streets and other traffic generators can simply look for matching values. The advantage to this approach is that we don’t need to redefine any key except for the already muddled destination:street, and the only software needing modification would be Valhalla.
A not-quite-performant Overpass query says there are almost 23,000 ways with at least one destination:* key with an empty entry around the world: overpass turbo.
The example way you linked is tagged
This is supposed to mean that there is one entry for a city and a symbol on white background as a separate entry. Without semicolons it would not be clear if it is two entries or a one-line entry pointing towards a stadium with name Oberhaun. Both options are equally common on signs in many European countries.
I’m sure there are plenty ways mistagged in one or the other way. The scheme itself is quite simple to describe, understand and evaluate - but sometimes a bit hard to get right with the first try, also because of lacking support in the editors. That’s the reason I wrote a sandbox to try out different tagging schemes without bothering the OSM database: Destination Signs - Tagging Sandbox . Please note that I didn’t add support for destination:street yet, because they are extraordinarily rare in the countries I included so far.
As someone who’s not familiar with American destination signage I’d say this would be one of the country-specific rendering rules that need not be tagged in OSM, but need to be implemented in the rendering tools (like the arrows that point downwards for through-lanes in France but upwards in Germany)
This will avoid empty values at least for the main tags, it maintains a order and you have information available rendering icons (like for university, stadium, airport, train station,…) as well as give announcements.
In the development of destination tags the common focus was how to describe actual signs to allow navigation systems to render them and to create announcements the traveler can easily match to signage to find their way. I think this approach is obvious: The plain information “this road leads to X” is not necessary, because routers can find out on their own, the important piece of information that can’t be inferred from geographic information is “this road is signed to lead to X”.
Your approach would add more semantic information to those tags - they might be useful to have semantic information about the entries on the sign, but are not helpful finding your way. If there’s just an entry on the sign, which might read “Albert-Einstein-S.” it’s not helpful to know that this points to a school if there is no corresponding symbol next to it. All you need to know when traveling is what to look out for on a sign, not the meaning of it.
I would also like to mention, we’re not developing a new tagging scheme here - the discussion point is how destination:street fits into the already existing scheme without creating too many ambiguities.
Oh that’s weird, I thought I ran exactly that query last night but with far fewer results. Thank you for correcting me. Your query even turns up a way that I had experimentally tagged with an empty value in destination:wikidata.
So a destination:symbol entry is considered a separate destination represented by a symbol, as opposed to a symbol associated with the exit overall? That seems to contradict the wiki’s definition. If you’re right, it would invalidate the vast majority of the 4,700 or sodestination:symbol:* tags in the U.S. In many cases, a link way gets a destination:symbol because of a separate sign altogether, yet this is still information that a navigation application would typically associate with the exit or cross street ( is the symbol for hospital):
If not destination:symbol, how should this information be encoded? Maybe it was a mistake to tag these as symbols in the first place? In the U.S., some of these symbols represent attractions, similar to the for Oberhaun, but most of these symbols officially represent services. For decades, in-car navigation systems worldwide have listed the services associated with an exit in interfaces that look nothing like guide signs. Also, sometimes the signs even spell them out instead of using symbols:
Of course, the visual layout should be a rendering rule. (We have both kinds of arrows on pull-through signs in the U.S., quite randomly.) However, at the data level, it would be problematic if we assume a one-to-one relationship between destination values, destination:ref values, etc. using a syntax that prevents us from encoding refs or symbols that apply to the overall way.
I agree. To this I would add: the information that Interstate 40 leads to Fort Smith, not Wichita, is properly the responsibility of the router, not the link way. This link way doesn’t need to encode the fact that a subsequent fork in the road ¾ miles (1.2 km) away forces the motorist to choose between I-40 toward Forth Smith and I-35 toward Wichita. Most routers already know how to make that association on their own.
Many European signs (and all of a dozen signs in the U.S.) may indicate this kind of tangential relationship, but I believe the order of destinations on the sign is the more salient information.
I mostly agree, but the Valhalla developers did have a valid point when proposing destination:street: for voice instructions specifically, some languages would naturally distinguish between the connecting street name and the terminus city using a different preposition. Generalizing beyond English, it’s also the case that some languages like French would use a different article before some destinations than others.
In my opinion, this information, while useful, is not so important that it needs to sort the destinations into separate keys, eliminating information about the order. Besides, there are other methods to micromap individual destinations on a sign, such as the convoluted traffic_sign syntax that includes brackets and the destinationsign[sic] relation type that would explicitly relate the traffic sign node to the mentioned roadway or place node. No relation can indicate the relative order of destinations on a sign, due to OSM’s data model.
By the way, both these things are true at the same time:
Which means that Valhalla technically doesn’t need destination:street after all. Its developers have explained that the guidance engine prioritizes one of the destination values in voice instructions by walking the routing graph. The destination that appears in subsequent steps along the route is the one that the current instruction should mention. If I understand correctly, the same heuristic could be tweaked slightly to look at the actual street names along the route, to figure out whether this ramp really leads onto Eastgate Boulevard or just toward it.
There’s no contradiction here. If there’s a simple tag without any fancy semicolon pattern, then it can be interpreted as basic tagging saying “there’s this symbol on the sign”, without any further information how it is displayed. If one chooses to use the more complicated tagging, then we can use this to infer more details about the layout of the sign. If there are two destinations and a single ref, I interpret it in a way that assigns the ref to the whole way and not an individual destination.
The scheme is definitely not perfect, but it seems to work in the vast majority of cases in Europe without being too complicated. I deem it perfectly acceptable if the tags are interpreted differently in the US due to the often very different design of destination signs.
For me this is a clear case of destination:symbol, no matter if it’s on a different sign or the same.
The wiki page for destination:symbol does currently contradict itself between the “Keys” and “Values” sections. The “Values” section apparently came from your proposal.
It definitely would need to be interpreted differently in the U.S., because it’s very normal for a sign to have multiple symbols and multiple route markers and multiple traffic generators without a clear relationship between them. The only grouping that ever occurs is by cardinal direction or lane (but we already have *:lanes for that). Data consumers that serve the U.S. (or other MUTCD-influenced countries) should not attempt to mix and match values across keys on their own. Fortunately, as far as I can tell, none of them do.
Incidentally, one of the most common kinds of freeway signs, the logo sign. These signs are intended to reduce distracting advertising along freeways, though they’d probably give some overseas mappers conniptions about overcommercialization.
So far we don’t have any established tagging for these signs, but the wiki ponders the possibility of encoding this information in brand tags on traffic_sign nodes.
Anyhow, where does this leave us regarding the original question? Do you think we should attempt to promote empty values in destination that refer to destination:street values? Or duplicate destination values in destination:street, as once proposed? Or avoid destination:street altogether?
Hard to answer. I’m pushed to say we don’t need destination:street at all - why should we distinguish streets from other destinations when we don’t do the same for attractions or amenities?
If there is a wish to use it (and this seems to be the case), I would clearly opt to include it in the list-scheme that is synchronized across tags. In the US the sensible definition should be not to merge lists between ref/symbol/plain destinations. But the lists of destination and destination:street should be merged to keep the order of entries correct.
Duplication seems to be redundant, but could be handled easily by data consumers, so this seems to be the next best option to me.
I don’t read it like this. The first sentence says that the tag indicates that a symbol is present on the sign. The Values section continues to explain how the tag can be used to define the position of the symbol on the sign.
In any case I suggest that we add a clear distinction on these Wiki pages between “European” and “US” style signs (whatever countries these categories contain, I’m definitely not an expert in world-wide road signage).
Realistically, country-specific rules about mixing and matching keys are very unlikely to be implemented by mainstream routers. After all, all these years later, mainstream renderers haven’t managed to implement regional fallback rules for localized place names either. In the absence of fallback behavior, empty values in destination would probably make some existing routers oblivious to not only destination:street but also the other values in destination. If someone starts tagging like that around here, I don’t foresee their edits sticking around, for practical reasons.
I was referring to this sentence repeated throughout the table: “Describes the destination symbol for the complete OSM way.” I suppose the emphasis on “complete” was meant to distinguish destination:symbol from destination:symbol:lanes though.
for Oberhaun, but 
