OpenStreetMap

mvexel's Diary

Complex Intersections, or Why We Should Get Rid Of exit_to

Posted by mvexel on 3 July 2014 in English. Last updated on 5 April 2017.

Here in the U.S., we have been using the convention of tagging exit information on the highway=junction node using the poorly documented exit_to tag. The rest of the world has been using destination=, and now that I start to think about this problem more, I can see why.

Let’s take this example of the junction of I-70 and the Baltimore beltway I-695.

Example situation

(Have you used Mapillary? It’s pretty awesome and unlike Google Streetview, OpenStreetMap explicitly does have permission to map from the images. It’s pretty easy and fun to contribute your own, too.)

How to tag this so that navigation and other software could make sense of it?

Currently, the only relevant tags on the junction node are ref:left=91B and ref:right=91A indicating the exit / junction numbers. There is nothing on the `_link’ ways to indicate destination.

tags

One way I have seen people map this information in the US is roughly exit_to:left=I 695 N;New York;Towson and exit_to:right=I 695 S;Baltimore;Glen Burnie. This is not great for a number of reasons:

  1. There is no way to distinguish the ref information (I 695 S etc) from the names reliably.
  2. The US seems to be the only jurisdiction where exit_to on the junction node is used, the rest of the world uses destination= on the _link ways.

If we were to adopt destination= in the US like everywhere else, most of the signpost information would be on the _link ways after the junction node. Here is the situation in OSM:

situation

The (first part of the) top way is 11830056. The bottom way is 11830053.

According to the destination documentation, the first way would get destination=New York;Towson and the second way would get destination=Baltimore;Glen Burnie.

So far so good. But there’s a few pieces of information that are not captured yet:

1) The exit (junction) numbers 91A and 91B. Oh wait - these were already on the junction node as ref:left=91B and ref:right=91A. This works, but intuitively it would make more sense to have this information on the _link ways as well. I am not sure how and the wiki does not give any guidance. (Actually it suggests using ref on the junction node for exit numbers.) 2) The road numbers the exits connect to, in this case I-695 N/S, leading to I-95 N/S. destination:ref seems to be used for that quite a bit. That would work for I-695 but I don’t know how to capture the connection to I-95. destination:ref:to?

Following the documentation as best I can, this is what I come up with for the highlighted _link ways:

first tags

second tags

I think this system makes more sense than the exit_to convention that is poorly documented, doesn’t scale well to cover complex cases, and is used nowhere else in the world. The only good reason I can think of why people use it is because it’s used much more (about 18,000 times) than destination= in the U.S. Elsewhere, from what I can see in TagInfo, destination= is more popular.

Discussion

Comment from rickmastfan67 on 4 July 2014 at 02:38

Well, the main reason I can think of that people use ‘exit_to’ more, it is because that it is built into JOSM on the ‘Motorway Junction’ preset. We would need to get that part removed and also a new preset added for properly tagging ramps themselves.

I personally have no problems with going with either format myself, just as long as we all agree on a proper format, like having or not having ‘hyphens’ in the route numbers and stuff like that. Also, I think we should spell out the cardinal direction in the ‘destination:ref*’ tags. Sure, there is only one word each of those could mean, but when you then get into routes that have spurs and such, spelling stuff out might be a better option, and then allow the router to abbreviate it on their end.

Heck, I would love it if we could have the motorway junction preset expanded to allow adding the split ramp exit numbers with ease instead of adding them manually.

Comment from rickmastfan67 on 4 July 2014 at 02:46

Oh, btw, Ontario doesn’t even use exit_to or the destination tags. They add everything to the ‘name’ tag.

https://www.openstreetmap.org/node/76478134

Comment from Baloo Uriza on 4 July 2014 at 03:39

destination=* also fits for a LOT of awkward edge cases exit_to=* doesn’t. For example: A four-way crossroads. Would be nice to come out of a side road and get a direction like, “Turn right on OK 11, then in a quarter mile, turn left on to CR XYZ, to Ramona (via county road)”. Which would be an improvement over the current usual OSM direction of “Turn right on OK 11, then in a quarter mile, turn left to CR XYZ,” or Garmin’s equivalent, “…then turn left onto Unnamed Road.”

Comment from rickmastfan67 on 4 July 2014 at 04:28

Oh, and I think we need to leave the exit numbers on the node for the splits. Mainly because we use the ‘ref’ tag on ways for when there is a route that gets off the highway and goes onto the surface route there.

If anything, I would not have any objections if we add the Exit number(s) to the ‘name’ tag on the ways like this: ‘name=Exit 77’. Otherwise, we could have to create a completely new tag for the numbers. Maybe ‘destination:ramp:ref’ or ‘destination:exit:ref’? That’s all I can think of right now.

Comment from Baloo Uriza on 4 July 2014 at 06:25

No, I’m against name=Exit 77. I’m in favor of ref=* on destination=* relations, however. Mostly because North American ramps often have multiple exit refs on the same ramp to start with. I can think of several in the Portland, Oregon; Vancouver, Washington; and Tulsa, Oklahoma areas without trying (and, in Vancouver’s case, minor edit wars, thanks to exit_to being hamfisted).

Comment from Baloo Uriza on 4 July 2014 at 06:30

I’m in favor of burying the exit_to dinosaur, simply because I know of many center-lane (OR 8 from westbound U26), left (westbound I244 to southbound U75) and ambigious (U26 to Market Street; west I244 to north U75) exits that don’t fit classical definition, yet are, exits).

Comment from EdLoach on 4 July 2014 at 07:49

OsmAnd uses the destination tag. I don’t know about exit_to.

I could never work out how putting information on a node could easily be calculated about which way(s) the information applied to, so haven’t used it. Perhaps OK on say motorways and interstates (if you haven’t had to split the interstate at that node for a change in the number of lanes, or similar) where you only have one way actually starting at that node, but not for general use.

Comment from Pieren on 4 July 2014 at 08:40

I don’t understand your questioning about the destination reference. Why not simply use the tag ‘ref’ on the link way if it’s valide after the junction node ?

Comment from JohnDoe23 on 4 July 2014 at 10:16

For JOSM there’s a very helpful MapPaint-Style available called ‘lane and road attributes’ which shows destination tags and much more: http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes

Comment from Colin Smale on 4 July 2014 at 12:31

I don’t think there’s any reason to limit the use of destination=* to *_link ways. It’s useful for all kinds of junction topologies, not just simple motorway exits. There is a difference between routing (a mathematical exercise) and navigation - which means giving useful, relevant instructions to a human. Normal practice here (NL) is that destination and destination:ref reflect the signage (irrespective of what “seems logical”). In some places the junction number is prominent and important for navigation (e.g. the UK - you might say “turn off at junction 24”) and in other places the junction number may not be so relevant. By keeping the tagging distinct you allow the navigator the freedom to present the information in different ways.

Comment from k1wi on 4 July 2014 at 14:53

Another reason for using destination: At Skobbler are planning on using destination tags.

https://twitter.com/apphil/status/473048674000306178

Comment from pnorman on 4 July 2014 at 16:26

I don’t understand your questioning about the destination reference. Why not simply use the tag ‘ref’ on the link way if it’s valide after the junction node

Frequently the link road does not itself have a reference, or at least not the same reference.

In one example locally, there is an exit signed as the exit to get to Highway 17, but Highway 17 is 4-5 km away through secondary roads and over a 1km bridge. This is a bit extreme, but a good example of how the destination refs may be quite distinct from the refs of the roads themselves.

Adding to the support for destination, both MapQuest Open and GraphHopper are consumers who support it.

Comment from mvexel on 4 July 2014 at 16:52

Thank you everyone for adding your insights and opinions to this article. It’s a day off here and a particularly nice one here in Utah, so I intend to spend the rest of it playing outside, but I will come back and respond over the weekend!

FWIW, for Scout we currently only support exit_to mainly because it has the most extensive coverage in the market it serves (the US). We are currently embarking on an effort to add more signpost information to the U.S. interstate systems, and I want to make sure that we adhere to the best possible tagging convention. If that turns out to be destination= we are quite happy to (help) make that transition, both in the app and in the data.

Comment from RussNelson on 5 July 2014 at 01:51

I don’t understand the problem that is solved by destination=. Surely that is something that can be automatically discerned by examining the network to see what roads are reachable. Should I put roads there? Should I put cities there? How big a city? How far?

exit_to, on the other hand, is a recording of what the exit sign says, in conjunction with ref= which is the exit number. This allows a navigation program to say “Take exit 37 to NY-32;Lake Placid;Keene”. Or if there is no exit number, just “Take the exit to NY-32;Lake Placid;Keene”. Or if they want to be terse, then “Take exit 37”.

Comment from It's so funny on 5 July 2014 at 09:42

Loads of info on tagging destination signs can be accessed through this landing page: http://wiki.openstreetmap.org/wiki/Lane_assist

Comment from JohnDoe23 on 5 July 2014 at 13:51

@RussNelson, in destination=* you should write the names of the cities which you see on the green destination signs above the motorways. mvexel posted an example imagery: https://dl.dropboxusercontent.com/u/187922/Screenshot%202014-07-03%2012.28.37.png plus example tagging: https://www.openstreetmap.org/way/11830053 https://www.openstreetmap.org/way/11830056 In some countries are these signs blue: http://wiki.openstreetmap.org/wiki/Lane_assist#Description

The destination is not computable, here is an example from Germany: www.openstreetmap.org/way/143755684 The destination cities are hundreds of kilometers away from this sign.

Further destination tags could be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#Tagging

For example: The key destination:ref=* should be used to specify the reference of the roads ahead as indicated on signposts, road markings or similar. The value of this key should be equal to the value of the key ref=* of these roads.

Comment from RussNelson on 6 July 2014 at 05:18

@JohnDoe23 (although I’m not enthusiastic about responding to anonymous people), it sounds like you’re saying that everything that I’ve been putting on exit_to= on the motorway_junction should be moved without modification to destination= on the motorway_link.

Comment from mvexel on 7 July 2014 at 13:58

@RussNelson - I tried to describe the problems with exit_to that are solved by destination in the post. Let me summarize and add some insights shared in previous comments. destination is a more generic solution for signpost information - as Maarssen Mapper pointed out, destination can also be used on non-link ways to indicate control cities; it allows for a clear separation of named and ref parts of the destination; it can be combined with :lanes to add lane level granularity; and finally, it is better documented and has wider support globally.

For ‘simple’ motorway exits, the transition could be as simple as copying what is now on the exit_to tag to a new destination tag on the exit _link. There may be an opportunity for a mechanical edit, but that would require additional discussion.

For more complex situations, the tagging needs to be reviewed manually, and ideally, destination tags should be added on the main motorway ways (and perhaps trunk as well) to indicate the control cities.

Comment from mvexel on 7 July 2014 at 18:42

Here’s a situation I would like some advice on:

photo

(If it is too small to see, here is the full size image.

The left two lanes are a continuation of I-80 Eastbound. The right two lanes are the start of I-215 Southbound. Neither are _links. Currently, the only relevant tag is on the junction node: ref=128 indicating the exit number.

Here’s how I would tag this with destination:

  • The way branching left would get destination=Cheyenne
  • The way branching right would get destination=Belt Route.
  • Both ways already have ref tags indicating the freeway number.

Because neither branches are _link ways, the ref on the ways, or the relationship membership, should be sufficient to infer the full signposting, right? If either or both were _links, would they require a destination:ref?

Also, destination=Belt Route is a little strange intuitively, but it is what is on the sign, so that is what would end up in the tag, correct?

(I am disregarding the more sophisticated variant of using destination:lanes as described on the Lanes page, an example can be found here).

Comment from RussNelson on 10 July 2014 at 03:27

I don’t understand this “better documented” advantage of destination= over the “poorly documented” exit_to. If there is a problem with the documentation, we can fix the documentation. If people are using exit_to inconsistently, then THAT is the problem. It might be caused by poor documentation, but THAT is the problem. It’s a much harder problem to solve, so we really need to know if it’s a problem. If it is, then an algorithmic edit is going to have to take that into account.

For the latest example, the way branching left would get destination=I-80;Cheyenne and the way branching right would get destination=I-215;Belt Route because that’s what the sign says. Using exit_to, there is no way to render the sign on the left because you’re not exiting; you’re staying on the same highway. The ref=128 node would say exit_to=I-215;Belt Route.

I’d say that the most important thing to render here is that you have a four lane highway splitting into two two-lane highways. That’s different from a three-lane highway splitting into two two-lane highways, because the middle lane gets to choose whether they exit or not.

The link anchored with “junction node” is a link to a way, not a node. I think you meant to link here: https://www.openstreetmap.org/node/352894978

Comment from imagic on 10 July 2014 at 14:26

I’m not quite sure what you need destination:ref:to for? If it should be the reference of the highway this (i.e. the first) highway is heading to, then you should be able to derive this information from the data already.

A short question regarding Mapillary: I tried it in Switzerland and more or less all signposts are pixelated like all license tags. License tags have to be pixelated, but why signposts? Or is it just a bug?

Comment from mvexel on 10 July 2014 at 15:26

imagic: In the case I highlighted in the blog post, there is a destination further down the route (I-95 North / South) that the beltway connects to. You could compare it to control cities There is no way to derive that information from the data. This is why I was looking at specifying that as destination:ref:to as a suggestion, but in general I am not in favor of many levels of colons in the tags.

Re: the blurred signs, this is an unintended side effect of the anonymization image processing, I assume. I have just raised it with them.

Russ: The documentation issue is only one of the problems with exit_to, but it shows that nobody has cared enough about this tag to properly document it so far. It likely has contributed to inconsistent usage. I don’t know. I haven’t found any inconsistent use of exit_to myself, and my issues with the tag are not that it is used inconsistently.

Comment from mvexel on 10 July 2014 at 17:17

I edited the exit_to wiki page to reflect that usage of this tag is being discussed here.

Comment from mvexel on 11 July 2014 at 16:15

I also added a comment to the Discussion section of the highway=motorway_junction page, where exit_to is still referenced in a few places. I want to move to de-emphasize exit_to in preparation for a plan to deprecate this tag altogether, if the community feels this is the right thing to do.

Comment from Skybunny on 17 July 2014 at 20:06

My biggest problem with this issue is this. It’s actually a pretty obvious one.

Look at http://wiki.openstreetmap.org/wiki/Key:destination , and look how many examples you see on that page showing ‘[typical MUTCD interchange signs(http://en.wikipedia.org/wiki/Road_signs_in_the_United_States#Interchange_signs)] translation to the [destination tag(http://wiki.openstreetmap.org/wiki/Key:destination)]’. There’s a bit of it above, but that’s not exactly easy to find.

You see it (on that page) for every sign case for the world EXCEPT the United States. If these get added in, I personally would start using Destination tomorrow, so we’re not playing ‘The U.S. does Imperial, and everyone else does Metric’, so to speak. It’s not that much work if we simply declare ‘Hell with it, Destination is our baby’; tools will set up to work with it properly.

But - again - it isn’t there, not obviously. Please add it! There’s nothing wrong with USING Destination in the U.S., if use cases are reasonably documented so we know what to do.

Comment from k1wi on 9 August 2014 at 20:11

Scout is adopting destination=*.

See http://www.openstreetmap.org/user/mvexel/diary/23369

Comment from mapsru on 17 February 2015 at 15:37

@mvexel Agreed - I am proposing we use detination:street and destination:street:to for the road name branch and toward information. Please see my updated Exit Info page: http://wiki.openstreetmap.org/wiki/Exit_Info

Comment from Baloo Uriza on 17 August 2015 at 22:24

OK, it’s been a bit of work using it for tagging, but some things I’ve noticed:

  • destination and destination:lanes is far less ungainly than a simple exit_to or relations
  • I’m not convinced Osmand uses this data yet. It certainly would be handy to validate things, since I’m currently working to implement this state wide as part of my lanes and relations completion project.

Comment from mvexel on 15 September 2015 at 22:35

k1wi wrote a follow up blog post showing there are now as many destination as exit_to tags in the US - let’s continue the discussion there.

Comment from Skybunny on 22 December 2015 at 22:54

’'’1) The exit (junction) numbers 91A and 91B. Oh wait - these were already on the junction node as ref:left=91B and ref:right=91A. This works, but intuitively it would make more sense to have this information on the _link ways as well. I am not sure how and the wiki does not give any guidance. (Actually it suggests using ref on the junction node for exit numbers.’’’

The answer to this appears to be in the junction proposal; specifically, ‘junction:ref’ applied to the way immediately following a motorway_junction.

As best I can tell, junction:ref tends only to be put on ways for which ambiguity exists (such as two exit refs from one junction, or a ‘left’ exit in a country where right-side-driving is the norm). However, an argument could be made that any exit should have on it:

(node) highway=motorway_junction ref=* (if exists) noref=yes (if it doesn’t)

(link ways) destination[:]= junction:ref=* (Identical to ref on the node in the simplest case, or, what is indicated on the sign)

Doing it this way would allow both simple renderers (e.g. Mapnik) to show the pretty blue numbers on nodes where a junction exists, but also allows navigation programs to declare an unambiguous exit number/ref when one exists.

Log in to leave a comment