I became aware of this practice a couple years ago as we debated the scope of destination:street=*. The original destination tagging scheme didn’t envision a table of destination details spread across multiple keys with parallel value lists. Each key was more or less independent. Some mappers did favor a more structured representation that relied on, e.g., destination:3=* and destination:ref:3=*, but this never caught on beyond a few cities.
Maybe the sign renderers can cope with this format a bit better?
Meanwhile, in America
Tabular destinations don’t work in the MUTCD system because that isn’t how the signs are supposed to be laid out. In general, American destination signs are divided into parts:
If you know the exit number, you look at the tab poking out of the top.
Sometimes you might see extra ancillary information poking out of the top, like a motorist service sign or a restriction sign.
If you know the route number, you look at the top section containing all the route shields. (This is off to the left in some states.)
If you know the street name or city name, you look at the middle section that contains all the traffic generators.
When you need to know how far or which lane to take, you look at the bottom section that contains the distance or arrows.
Unlike in Europe, there isn’t enough information to match a route number to a control city or an amenity to a route number from the sign alone. Moreover, route concurrencies are extremely common here. Collating any of this information together in visual or voice guidance would confuse the user. Here’s a typical exit sign featuring two route shields and two control cities:
At the end of Exit 61, you can turn left onto New York State Route 34 toward Waverly, or you can turn right onto Pennsylvania Route 199 toward Sayre.
Certainly, the router wants you to head toward Waverly, it’ll tell you about only State Route 34 in the following step, but for now, you just pay attention to what’s on this sign. The tagging on this ramp forms a table only by coincidence. But that’s far from guaranteed to happen:
At the end of Exit 5B, you can bear left onto southbound U.S. Route 51 = Elvis Presley Boulevard toward Graceland, or you can bear right onto East Brooks Road and continue straight for many blocks until you reach West Brooks Road. (The “Elvis Presley Boulevard” is smooshed into that top part of the sign as alt text, a footnote of sorts.)
destination:ref=US 51 South
destination:street=Elvis Presley Boulevard
destination=Graceland;West Brooks Road
At the end of Exit 222, you can turn left toward Anderson or right onto southbound State Road 9 = southbound State Road 67 = eastbound State Road 38.
destination:ref=SR 9 South;SR 67 South;SR 38 East
destination=Anderson
Exit 61 leads to Omega Road. If you turn left at the end of the ramp and go to the end of Omega Road, you can turn left again onto southbound U.S. Route 319 = southbound State Route 35 toward Moultrie. (This is also an example of a destination:ref:to=*.)
destination:ref:to=US 319 South;GA 35 South
destination=Omega Road;Moultrie
This is the entrance to southbound Interstate 95 = southbound Interstate 495. That highway goes to Andrews Air Force Base and eventually Richmond, Virginia.
At the end of Exit 22, you can turn left to continue on U.S. Route 301 or turn right to head toward Lumberton. Robeson Community College, the Highway Patrol station, and all the listed food and gas options are located less than 2,000 feet (600.6 km) from the exit, well outside the Lumberton city center.
Analyzing the destinations to this extent should be far outside the scope of any destination tagging scheme. A mapper familiar with the country’s signs should be able to look at the destination sign in street-level imagery and reliably intuit the correct tags for the link way without having to first locate each of the toponyms and amenities.
So what to do about the tables that routers mangle? Should we fork the tagging scheme, one interpretation in Europe and another in North America? Should we more explicitly structure the tabular data on separate traffic sign nodes, where we have more room to describe the sign? Does the German sign standard have a code for each of these layouts that specifies the location of each unit of information, so the traffic sign node can just list all the information in order without fussing about the layout?
I have to admit I fail to see in which of the cases you listed the current scheme fails.
There are always country specific rules for the renderer that influence how the tags are shown. There is no one-rule-fits-all, not even in neighboring countries in Europe. E.g. France has ref’s often sticking out to the top, and even uses different colors depending on context - both of these are completely unknown in e.g. Germany.
It’s up to the renderer to organize information in a country specific way.
I'm not sure how universal the signs you show are. Is there some rule that defines the order of destination, destination:to and destination:street? Then it would be just about how to set up the renderer properly for the US.
If the order is arbitrary, we can stick to the “tabular tagging”, but require that in MUTCD-land all tags have the same number of (mostly empty) entries. Using your second US example “Exit 5B”, this would be
destination:ref = US 51 South;;
destination:street = Elvis Presley Boulevard;;
destination = ;Graceland;West Brooks Road
destination:distance = ;;0.5 mi
If entries are not listed top-to-bottom but somehow arbitrarily arranged on the sign, then more information is needed for perfect rendering.
A viable option could be to keep the same tagging scheme, but add another tag that tells about the arrangement of entries, listing how each entry is placed in respect to some other entry destination:arrangement = ;right_of:1;below:2;below:3 (which would be a two-column layout, one entry on the left, three on the right).
Which “renderers” organize the information as though all the keys are dependent on each other (the tabular format)? The most prominent consumers of this data are routing engines, for the purpose of guidance instructions in the form of simple functional displays or sentences read aloud. There is little attempt to render realistic signs. And none of them accept this tabular interpretation.
Are there any sign renderers that depend on this information? Should we be optimizing for their needs at the expense of routers that have no ability to consider other tagging schemes like traffic_sign=*?
The global mapping community should’ve been consulted and data consumers should’ve been informed when redefining the keys to be tabular a few years ago. Now that both approaches are commonplace in different regions, we may need to tell data consumers to implement destination tags twice over. We would need a comprehensive list of countries that follow the tabular syntax.
In general, the rule is what I listed in the original post: the main sign consists of three parts: route information at the top, traffic generators in the middle, lane and distance information at the bottom. Exit numbers and ancillary information poking out of the top.
Perfect sign rendering is unrealistic and beside the point for this roadway-based tagging scheme. destination:*=* is about encoding the messages conveyed by the signs, not literally reproducing their layouts. That is at best a side benefit. Otherwise we would’ve gone down the deep end with presentational details or replaced these tags with sign codes.
And we really don’t want to go there. Despite the federal standard, some states treat these signs like refrigerator magnet poetry, cramming information wherever there’s room because they’re too cheap to buy more metal:
These are the cases where people most rely on OSM to encode the message, not the literal sign. Not for geeking out about signs but rather for finding the right exit when following the instructions they’re given.
The tabular format can only express the first example, and only by coincidence.
This would misinterpret the sign. Graceland is related to U.S. 51. But you don’t know that just from the sign and neither should the driver by this point. Any tagging that explicitly relates or does not relate the two units of information would be misleading. (Also, the distance is to the exit, not any of the things on the sign.)
Oh dear, how is anybody meant to make sense out of these while driving by?
There are not many yet, but there is my crude try of creating a display - thanks to the help of others it already supports a couple of European countries, e.g. here, on a 5-lane highway OSM Destination Signs
In my opinion, this is the only place (to be precise, in the users interface of these routing engines) where destination signs are actually useful.
I tend to contradict here - for me it is far more useful to have decent visual representation and less so a perfect encoding of the meaning. Why? Because most of the information can be deduced by routing engines from the map data itself. They just know that this exit leads to ABC-city or that there is a gas station straight ahead. What I think the information is useful for, is to guide the driver and to help them identifying the right exit and lane to take. In a complex intersection it might be difficult to follow “take the exit in 200m, using the third lane from the left” but much easier to compare a graphic representation of the sign from the heads-up display to those actually mounted above the road and identify the right way by these means.
Ok, corrected version:
destination:ref = US 51 South;;
destination:street = Elvis Presley Boulevard;;
destination = ;Graceland;West Brooks Road
distance = ;;0.5 mi
The ref and the street are clearly put together on the sign
As you write, they are indeed related
The tagging puts them together and allows to display them together
As you said, I wouldn’t make any assumptions about Elvis = Graceland and Graceland = US51, because that can’t be seen at all on the sign
Ok - this is something a mapper used to these signs will know and handle correctly (why the heck don’t they put it next to the “exit” sign or clearly separate it from the entries?)
It’s capable of much more than you think it is. I don’t see is any issue encoding the information from examples 1 to 5. Also the last one can be done, but as it is split into 3 individual signs it can’t be tagged on the road itself. The order of entries on number 2 might be ambiguous, but that can be solved with the “full tabular” system.
I agree with most of your reasoning but not your conclusion. To know that the exit leads to a certain city or that it has a gas station, the user doesn’t really need to see a simulation of the sign. Standard turn-by-turn navigation interfaces are designed to extract a minimal amount of information most relevant to the user’s route and present it at just the right time. In reality, when a driver passes by a guide sign at 120 kilometers an hour, they don’t have time to read the entire sign, let alone nitpick about its layout.
Some premium navigation experiences do go beyond this minimalistic approach. A “junction view” illustration depicts more than just the signs, in order to give you situational awareness as you reach the junction. Yet it still drops details from the real sign for easier comprehension, and it doesn’t necessarily replace the simpler banner at the top that gives you basic information at a glance.
Incidentally, to get to Des Moines from here, you have to travel over 200 miles (330 km), passing through another major city and leaving Interstate 35. To get to Wichita from here, you have to travel almost 180 miles (290 km), passing another city and also departing from I-35. Without destination=Des Moines and destination=Wichita, how is a router supposed to know it needs to say Des Moines and Wichita instead of Kansas City and Emporia? That’s really what destination tags are for: the messages on the destination signs.
Successful wayfinding requires both visual and spoken voice instructions. The instruction text that you see on the OSM website is more or less what turn-by-turn navigation applications use to deliver the spoken voice instructions. As you can see, these instructions indicate destinations. Lanes would be nice to have but are generally unimplemented so far.
When you give verbal directions to a friend, do you tell them:
Take the exit with the sign for A 7 motorway symbol Fiensburg/Kiel, followed by A 23 motorway symbol Husum/Heide, then airport symbol, then B 4 and B 5.
or do you tell them:
Take the exit onto A 23 toward Husum/Heide.
I recognize that the latter may require collating route numbers with destination cities, so we do need a solution that routers can handle. I don’t think that necessarily means we need to burden the tagging scheme with the goal of perfect sign rendering.
(In case you’re wondering, the equivalent MUTCD sign would probably have the A 7 and A 23 shields at the top, Fiensburg and Husum in the middle, an airport symbol poking out of the top, and no other information.)
Good thing I’m normally stuck in bumper-to-bumper traffic as I encounter that particular sign. But there are many thousands more signs like it. When the traffic engineers are constrained by money and space rather than rules and regulations, anything is possible. In fairness, it does look beautiful sometimes.
I think this is not unique to California or the U.S. Before everyone started treating it as their own scratchpad, the original proposal opened with this representative photo of an Austrian motorway junction. A driver like me who knows nothing about the Austrian StVO can still handle an instruction to take the exit for Brno or A2 or maybe even Hungary, even if the exact layout requires a longer description.
Instead, your suggestion claims that these things are not related, which is just as misleading. And that’s before getting into the problem that you’d be breaking most existing data consumers in pursuit of this ideal.
Because the bottom part of a destination sign is for distances or lane arrows. Sometimes it contains two arrows, to let you know the exit ramp is two lanes wide. The green sign isn’t visually divided by horizontal lines, because everything is about the same maneuver.
Honestly, I admire your attempts to reconstruct photorealistic destination signs from OSM tagging. My own attempt from 2018 is nothing to write home about. However, I think it’s unfortunate that you and others felt the need to commandeer an existing successful tagging scheme for this use case. If we really believe in perfect sign rendering, then we’ve only scratched the surface, yet we’ve already reached the limits of what we can realistically express using a tabular format on highway=*_link ways.
To do this well, we’d need to encode dimensions and arrangement explicitly, because the legends on the sign don’t necessarily form a neat grid. We’d need syntax for messages spread across multiple signs placed side by side, stacked vertically, or placed in sequence along the roadway. We’d need syntax for multiple exits on a single sign, like the arrow-per-lane and diagrammatic signs above. We’d need to research the full breadth of nonstandard signage out there. Most of us only really understand the destination signs in our own countries.
I’d almost venture to suggest that we upload sign diagrams to Wikimedia Commons and tag traffic sign nodes with wikimedia_commons=*. Or if sign renderers need the ability to take artistic license, then we upload JSON files to some external repository and link to them from OSM traffic_sign=* nodes. But the destination:*=* tagging scheme should not aim for this level of precision, and the wiki should not pretend it does.
I’d rephrase that from “need a solution that routers can handle” to “need routers that handle the solution”.
The tagging seems perfectly suitable to generate useful instructions, choosing the one that best matches the route you planned. It just seems that some more work needs to be put into it.
The issue with complicated instructions doesn’t seem to be caused by the tagging scheme but by the decision to blindly copy the full tag instead of making an informed choice which parts to show. A basic version of this should be easy to implement.
I once though about an API that can be called by the router to ask for turn descriptions and signs - but it seems to be a bit difficult to get back to OSM ids from the abstract routing graphs the engines use.
Sure, but sometimes a simple visual comparison between an image and a sign is even faster than reading, for example in bad weather. You just need a glimpse to identify a sign as “the one with the 3 shields on top and the two entries in yellow on the bottom”.
I agree - this is the reason for basic destination tags, which are still perfectly fine to use. Here we’re already two steps further adding more and more information besides the basic stuff.
The Austrians can do better than this, so I wouldn’t call it representative. Here’s the currently tagged sign, without using tabular tagging: OSM Destination Signs
And this would be it with tabular tagging: Destination Signs - Tagging Sandbox (Please excuse me removing the middle lane going in both directions, I still have a bug in the code handling those)
Not quite. The tabular design was made to give additional information over the plain lists. It’s not meant to tag that items are not related - that would also break backwards compatibility with the simpler lists. There’s nothing breaking - all the data is still there and can be read individually. It’s just giving the consumer flexibility to get more out of the tags. At most, they need to be able to handle empty pairs of semicolons - but this is already required given the amount of people ending values with lists in a semicolon in other tags.
I fully agree, but we still can squeeze as much as we can out of the existing tags. With minimal additional effort to generate routing advice we can get useful speech and text output.
More seriously, as you say, you don’t read everything. First as soon as you’ve found the right information (for you), you stop reading. For instance you want to use the 580 West, you just look at IS logos, and read the numbers then East or West. For reassurance you’ll read the destination.
As you point out, this isn’t a binary choice between rendering the destination=* tag verbatim versus a pattern-accurate sign. Existing OSM-powered navigation applications do extract certain pieces of information from the destination tags that they think will help the user make the right decision. For OSRM and CoMaps, this means choosing just the first destination:ref=*. For Valhalla, this means preferring the destinations that appear later on in the route. However, they don’t fashion the various destination:*=* tags into a table in order to figure out what to display.
These routers and applications did the right thing. They implemented the tagging scheme that was documented on the wiki, that was discussed at nauseam, that both volunteer and paid mappers have been applying en masse. No one said they had to make it look like a sign. It isn’t their fault that someone came along and snuck a different format and different expectations into the documentation.
Mobile applications have very different usability constraints than giant overhead signs. Fitts’s law and Hick’s law matter much more than skeuomorphism. To the extent that the display resembles a sign, it’s only a hint that the user can find this information on a sign outside the window. Otherwise, it’s just another interface element like the distance indicator.
Is this supposition, or is this really how destination signs in Europe are designed to be read? It certainly isn’t true of North American signs. A navigation application could never get away with showing a “ … ” with nothing but placeholders and expecting the user to match it to a real sign. Just about any cloverleaf interchange will feature a sequence of two exits with the same number of shields on them. And by the time they see the final destination sign, it’s probably too late to get into the right lane. They should’ve heeded an advance sign that potentially features a different layout.
As much as I love geeking out about signs (and will continue to do so below), we have to recognize that the sign renderers came late and remain largely theoretical. Decades after junction views became commercially available, most drivers have never seen them in their lifetimes and wouldn’t know what to make of them. Meanwhile we have countless cars, trucks, and bikes on the road that depend on OSM’s destination tags as they are in most of the world, whether they’re using CoMaps or driving for Lyft or for a Toronto-based OSM-powered trucking company.
Alternatives
If we could travel back to 2016 and design the perfect tagging scheme from scratch, maybe we would try to accommodate both use cases and both sign systems in a single tagging scheme. The problem is that the tabular format makes assumptions. It assumes the sign has any relationships across different information types. I’ve demonstrated that this is a not a reliable assumption.
Even if every country laid out their signs like Germany, this format still has it backwards. Why not tag destination:1=* for everything on the first row, destination:2=* for everything on the second row, and so on, using subkeys like destination:3:type=* to indicate the type of information in a particular slot on the row, as we have on some guideposts?
Or why not more keyword-based subkeys, as on some destination signs in Catalonia? This could even coexist with the original tagging scheme. Unfortunately, you’ve previously rejected this more structured approach out of concern that queries would require regular expressions. I’d agree if this were the only tagging scheme for destinations, but it wouldn’t be such a problem as a complement to the existing non-indexed destination keys.
Ergonomics and reality
So you’re saying a standard North American destination must always start and end with a series of dangling semicolons, depending on which other destination:*=* tags are present? What happens when someone proposes a raft of new destination:*=* subkeys that also need to align? More semicolons? Meanwhile, the “full” tabular format requires cross-multiplying destinations, refs, and symbols so that each value list has the same number of “columns”. I never met someone who likes semicolons even more than I do!
Just to make sure we understand each other, here are some more examples that I think illustrate the complexity that you’re ignoring while introducing other complexity:
At the end of the next exit, Exit 62, you can turn left onto westbound U.S. Route 82 = westbound State Route 520 toward Albany, or you can turn right onto eastbound U.S. Route 82 = eastbound State Route 520. In one block, it becomes eastbound U.S. Route 82 = eastbound State Route 520 = northbound U.S. Route 319 en route to Waycross.
This is currently tagged according to the original destination scheme as:
destination:ref=US 82;GA 520
destination:ref:to=US 319 North
destination=Albany;Waycross
The Mapbox Navigation SDK and MapLibre Navigation SDK (both powered by Valhalla) prioritize the U.S. Route 82 and State Route 520 shields because the following step is to turn onto U.S. 82/SR 520. The second line is only there for extra reassurance, in case multiple exits are identified by the same shields.
Organic Maps and CoMaps focus on the essentials: the exit number, the first route number, and the first destination name. Magic Earth has the same information on the closest thing to a rendered sign. It’s green and square. But otherwise it still takes plenty of liberties with the actual layout, because glanceability depends on keeping the each kind of information in a stable, predictable location on screen.[1]
If I understand correctly, you think we should adopt the tabular format but lean on the fact that none of the units of information are necessarily related:
This is a relatively tame example of the duplication that would occur. Let’s keep going, shall we?
Exit 164B leads to Lynes Parkway = westbound Interstate 516 = westbound U.S. Route 80 = northbound State Route 21 = northbound State Route 26 toward Garden City. Here’s how it’s tagged according to the original destination scheme:
destination:ref=I 516 West;US 80 West;GA 21 North;GA 26 North
destination=Lynes Parkway;Garden City
The tabular scheme would turn it into one of these monstrosities:
I could keep going, but you get the idea. Whichever way you cut it, this mini-language is extremely error-prone. Do we realistically expect mappers of all abilities to enter these tags without using a dedicated destination sign editor? Mappers already balk at the notion of maintaining parallel traffic_sign=* and traffic_sign:id=* tags, concerned that they’d easily get out of sync. How is this any better?
This is not to say that the German sign layout cannot be found elsewhere, but we’d need to have a much better idea of where. Otherwise, why would we rule out a more compatible approach, spinning out a new tagging scheme for the relationships you want to encode?
By the way, that is extremely confusing because it looks identical to the shield for a state route in some states. ↩︎
Counting any destination tag that contains a semicolon. ↩︎
Please note that destination:ref=* values are mostly not expected to match the number of destination=* values. This is because the upper shield basically says by turning right, you will drive the road with ref X, which you can assume is unrelated to any specific destination. For instance, we would tag so the right-hand road:
It seems that your SparQL test checked the respective number of values for these two tags; if so, this is no surprise that you find so much inconsistencies: they are in fact often no inconsistency, only expected tagging practice.
So this is really only about destination:symbol=* and destination:colour=*, not about the whole destination tagging scheme? How arbitrary. In any case, that’s another difference with the MUTCD: the shield on the sign doesn’t necessarily mean you turn directly onto that route.
I concede that the query missed one nuance, that the tabular format only kicks in once there’s a semicolon. So that leaves 38,650 supposedly invalid values, still almost three times the number of tabular tags in the whole database. Most of them are in Germany and Spain.
Also, supposedly the tabular format expects two destinations on the same row to be separated by a comma. But pretty much no one does that with shields on the same row. And that conflicts with another common convention in North America, the comma as part of a name:
Nobody ever claimed that. To repeat once more: It is an option that gives additional information. Tabular tagging can be perfectly used by anybody not aware of it. And vice versa, if someone assumes tabular tagging but it is not, the output may look a bit weird, but still all tagged information is there.
Nobody claims that. They can make it if the want to. Nobody is forced to extract more information than they want to use.
Btw, the corresponding proposal, which gained immediate use even without a vote, is from 2012. Most of these routers are not that old.
Which are both perfectly valid choices, independent of the tagging format. But that’s not what caused the messy output you based this thread on.
That’s basically how the human brain works anywhere in the world. Guess why companies use distinctive logos and color schemes instead of plain text.
As you said elsewhere, there is not necessarily a nice grid. And who wants to change a dozen keys if somebody adds a new line at the top?
Without any kind of documentation I’m at a complete loss understanding what is tagged there. There are 25 (!) tags for a simple sign with 4 lines, 2 refs and 3 symbols.
Nobody forces anybody to do that. Use the format or don’t. It’s up to every individual mapper. Apart from that, if signs are messy, tagging gets messy too.
Which is perfectly valid in any tagging scheme. As these signs do not match refs and destinations on single rows, a renderer for US signs knows this and shows an appropriate sign with all ref’s and ref:to’s on top.
Who said that?
No, it wouldn’t.
I have no idea how you came up with this. The sign doesn’t show any pairs of refs and destinations and keeps them completely separate. The tagging in OSM should not create something that is simply not there.
Please don’t. There is no need to change any of the tags as you propose. Software can interpret the simple tags on each of these signs without extensive tables by just knowing some basic defaults for MUTCD signs.
Why should we? Everybody is free to add simple destination tags. Same holds for e.g. relations which are a complete mystery to many mappers. We also don’t deprecate relations just due to the lack of proper support in our main editor.
If you want to force everybody to follow a full-tabular tagging then this number is maybe correct. But that’s not what anybody tries to do.
How does a convention only for symbols conflict with shields and names?
The idea is that tabular format is possibly fine for Europe and awfull for US.
the notion of maintaining parallel traffic_sign=* and traffic_sign:id=* tags, concerned that they’d easily get out of sync. How is this any better?
I didn’t know we could use “human readable” traffic sign, putting “human readable” restriction on the roads. So using traffic_sign=FR:* (instead of traffic_sign:id=FR:* then) we have no desynchronization in France.
By the way, the nav app “knows” where you wan go to, it could highlight the “column” where you probably want to go, and the destination in bold. (column = lane, exit…).
Hill Island, Ontario
1000 Islands Bridge To U.S.A.
(yes the app would need to interpret that the destination is in the US, and that “To U.S.A.” means it’s the right direction).
Basically, I would say that you got it right; wouldn’t say arbitrary, though, but rather matches the structure of OTG (European) signs.
The main point here seems that the wiki was made by and for European signs, which obviously don’t allow a correct tagging of MUTCD signs. Maybe we should simply relax the wiki pages by saying destination-related tags basically work tabular in Europe, but not in MUTCD countries, where it rather works [insert explanation here]. I increasingly think that this would better match local tagging/signage customs. At one point, tagging practices must match OTG reality.
Please don’t forget that tabular tagging allows to have one destination:symbol=* for several destinations: it means that the symbol applies to all destinations, ganz einfach!
Nope, I’m afraid you got it wrong here: this comma paragraph is for separating symbols related to a single destination, as explained on the first line of this table. AFAIK, using commas in destination=* is fine and works out-of-the-box.
Edit: something one may also easily miss is that AFAIK much wiki pages and tagging customs originally come from German contributors, which are fairly active in these areas; that may explain why the wiki and some tagging habits so Germany/Europe compatible and US-incompatible are…
Would it be possible to say briefly why it works for Europe and not MUTCD countries (or the US, or North America, if that is the distinction being made)?
There are hints in this and related threads, but I have struggled to grasp what is the key difference in this context. Which in turn leaves me unsure if “Europe” means all of Europe or a subset of countries.
Probably the distinction should be between Vienna Convention and MUTCD.
Look at the examples given: it looks less tabular in US. But maybe saying that an information may span over several column would solve the issue.
Taking @Minh_Nguyen example: destination:lanes=none|none;Lynes Parkway;Lynes Parkway;Lynes Parkway;Lynes Parkway;Garden City;Garden City;Garden City;Garden City|Lynes Parkway;Lynes Parkway;Lynes Parkway;Lynes Parkway
destination:lanes=none|none;Lynes Parkway[4];Garden City[4];|Lynes Parkway[4], where * could mean all the lanes not mentioned elsewhere.
(as @Penegal, I don’t get the number of texts, but that’s another question).
I can see that the tabular format often doesn’t worth with MUTCD signs. I am less sure if it is systematically useful in Vienna Convention countries. As far as I can find out, the Convention says little about direction signs.
E.g. in these two examples from Spain it’s not so clear to me that the tabular approach helps.
(I couldn’t find readable photos anywhere except Google - most street level photos in the south of Spain seem to be taken facing directly into blinding sunlight that turns road signs into silhouettes!).
Here, you would take the right turn leading onto the A-92 if you are heading for Málaga or Granada. You would continue on the A-92 to Granada, or turn off it at a later point onto the A-45 to Málaga. The A-45 is irrelevant to Granada, even thought it is the 2nd ref listed and Granada is the 2nd city listed. I guess this could be expressed as a table but it would require knowledge not observable at the junction itself - is that the idea? Even then, it seems like “matching” refs to destination would move further away from the physical appearance of the sign.
In this one, both directions lead immediately to the SE-40. All other references are to roads that you would reach after some time on the SE-40. I guess with the tabular format SE-40 could be considered a ref with no destination? But that seems to lose the information that it is the immediate road you are joining.
Edited to change SE-30 to SE-40 - I had confused two of Sevilla’s ring roads.
There is no matching on the sign, so the tagging shouldn’t do this as well. We can tag the A-45 as a destination:ref:to due to the distance until you reach this road.
If there are in fact two ‘ref’ on this sign, then an automatic decision whether the sign is using a “tabular” approach or not might not be easily possible.
SE-40 it is. This would be listed as destination:ref, while all others are destination:to and destination:ref:to.
If my tool had a scheme for Spain the colors would be right, but here is the full description of the sign: Destination Signs - Tagging Sandbox
As you can see, there is a minimal “table” involved for the two entries straight ahead (one additional semicolon, no repeats or “multiplications”):
I don’t wish to single out mappers based on their country. This is fundamentally a disagreement about the primary purpose of destination=* etc. The original proposed and documented destination scheme, still used in most of the world, was developed by an Austrian mapper and is perfectly fine for the U.S. as far as its stated purpose. On the other hand, it’s inadequate for fully expressing the layout of destination signs anywhere. That’s why we have a separate traffic_sign=* scheme.
The goal of destination=* was to record the destination sign’s message, so that data consumers could present it somehow as an “instruction”. “Perfect sign rendering” wasn’t the goal – a destination sign isn’t an instruction. But a relatively small group of sign enthusiasts latched onto this tagging scheme, apparently without appreciating how destination information is typically used in the real world.
I concede that the original format is also inadequate for fully expressing the message of a typical guide sign in Germany, which explicitly associates routes with destinations, or in France, which explicitly associates restrictions with destinations. The destination scheme could benefit from further tagging without turning into a full-fledged traffic sign scheme. But first we have to acknowledge that rendering signs from these tags is only a “best effort”, not a primary goal to pursue at the expense of other use cases. Otherwise, we’ll turn destination=* into a homonymous key over something that most users don’t strictly need.
The tabular format was quietly inserted into the proposal in 2023. You can’t use an edit in 2023 to criticize a software implementation from 2016 or so without at least acknowledging that backwards compatibility was broken. Of the navigation systems I’ve looked into, only CoMaps/Organic Maps had any opportunity to notice this format when they revamped their voice instructions later that year. If I knew this was a legitimate way to go about redefining a tag, I would’ve fixed crossing=uncontrolled so long ago…
In seriousness, one lesson we can draw from this experience is that, once an abandoned proposal becomes a de facto tagging scheme in the database, we should promptly archive it in favor of the articles in the main namespace to reduce confusion.
Yes and no. In general, human drivers visually recognize a sign based on shape, color, and pictograms. Recognition at a glance is the reason for the shape and color categories in all modern sign standards, the symbol-heavy hazard and restriction signs in the Vienna Convention, and the intricate system of symbolic route shields in the U.S. and other countries. However, unlike symbol signs, a predominantly textual sign such as a destination sign is complex and variable enough that a literate driver must read it. This takes precious time when traveling at speed. To compensate, drivers visually scan an unfamiliar sign for the piece of information that they know:
Both methods [to compute combined information load ratings], however, assumed that the most complex sign had the greatest impact on mental workload. That assumption may not necessarily be applicable to this study, since, in a real roadway environment, drivers would search—in an array—for the sign most relevant to their navigation needs.
If Valhalla/MapLibre tells you to “take I-91 South toward Hartford” but both signs have I-91 shields, you might look for the word “South” or the name “Hartford”, depending on what you heard in one ear as a toddler in the backseat is screaming at you in the other ear. The MUTCD destination sign format facilitates scanning by making sure you only have to scan one third of the sign for a given type of information, but even something more irregular like a British-inspired roundabout sign is still designed to be read at a glance.
If you’re calling for regional variation in the meaning of destination=* and destination:ref=*, that’s one thing. But if you mean that even in the U.S. the data consumer should check whether the value lists are the same length, then that approach would be ineffective. The route shields would be isolated from the destination names whether the lists are the same length or different lengths.
I didn’t want to ostracise Germans; I simply meant that they are a very active community, so that their functioning and customs may be presented or understood as standard customs, or simply be perceived as more widespread than they really are on OSM.
I already felt this reality distortion field before, when I read and edited wiki pages related to destination tagging: much of these pages were about German signs or examples. This may explain why, for instance, MUTCD signs are not correctly accounted for in the wiki: the contributors editing the wiki were maybe simply mostly German, or otherwise from countries where tagging and signs are way different from MUTCD signs… hence, maybe, the discussion you started here!
then East or West. For reassurance you’ll read the destination.
![[62]: [US 82] > Albany; Waycross](https://community-cdn.openstreetmap.org/uploads/default/original/3X/0/d/0d33ca48beef8b827f2b065f6823168366fe3828.jpeg)
.jpg){kind=link}