exit_to vs destination Update (USA)

Posted by k1wi on 12 December 2015 in English (English). Last updated on 8 May 2016.

Since my last report on exit_to vs destination in the United States, destination tags have continued to grow and they have clearly surpassed exit_to tags.

Here is the evolution from January 2013 to December 2015.

Read more about this exit_to vs destination subject on this great diary entry by mvexel.

Also, some more information on the subject in the wiki.

Plus, you can also check the usage of exit_to vs destination on a freeway by freeway basis using my CheckAutopista tool. Example: Interstate 15 in California, Interstate 64 in West Virginia.


Comment from Omnific on 12 December 2015 at 17:30

I’ve been pushing the destination recently (since the previous report) in West Virginia, Virginia, and Washington state. Glad to see it’s still trending upward.

Comment from Paul Berry on 12 December 2015 at 18:26

Given the trend, would we be looking to eventually retire the exit_to tag?

Comment from Skybunny on 12 December 2015 at 18:56

Does CheckAutopista take enhancement requests?

I’m wondering if its intelligence to ‘autofind’ freeways might be nudged up a bit, on ones that are ‘partial along their length’. Let me explain…

Check out

This is Wisconsin 29. In the 1980s, it was a two lane highway along its entire length, but over the last few decades, it has gradually been being built up as a motorway in sections.

It happens in Wisconsin a lot that roads (see US 51 or 29 here) could really use the love CheckAutopista can give to add destination tags to *_links, but the only way to push the tool to check it over is to put in the relation ID by hand.

What do you think? (Something to see roads like these when motorway sections are in the bbox, and maybe eliminate sections that obviously ‘aren’t’ motorway?) I think this is totally a version 3 thing, but perhaps a cool idea.

Thanks for reading!

Comment from Baloo Uriza on 16 December 2015 at 11:20

Destination definitely has the advantage of being applicable to more situations than just freeway exits, being more specific (a real issue given about 20-30% of ramps in my region are something other than off to the right, and I’m aware of some truly convoluted ramps that barely grasp real world logic much less are something that can be readily assumed by data consumers from a single point), and already has live adoption (Osmand at the very least).

Comment from Skybunny on 18 December 2015 at 03:04

My take on this whole thing is, for as many issues as destination does have, they appear to be ones that can actually have solutions derived for them, such as:

  • junction:ref on a way when multiple refs appear at one motorway_junction point, rather than the limited ref:left and ref:right
  • destination:forward/reverse when an exit ramp is reversible
  • destination:ref and destination:ref:to for NHTSA reference identifiers, which don’t exist at all in the exit_to family
  • I’m sure I can think of more

Destination has become a more mature standard than exit_to ever was, and in pretty much every numerical sense, has now surpassed exit_to (which used to be, IMHO, its sole staying power; e.g. ‘But look how much work it will be to not use it!’)

Not to mention the fact that every navigation standard out there is now preferring destination tags and outright ignoring exit_to anyway. I suspect if the ‘deprecated’ label were put on exit_to, and/or it was added to map_roulette as an issue to move information to destination tags, it would be gone within a year or two - and that’s with no automation assistance at all. I do hope it goes that way.

Login to leave a comment