I think you can probably update the task at http://maproulette.org/view/499 (where it says ‘See here for more info’) to point ‘here’ to https://wiki.openstreetmap.org/wiki/Exit_Info . It’s getting fairly good at explaining how to do these fixes these days - and if it needs clarification, I’d say ‘feel free to dive in and make it even better’. It also nails down junction:ref as ‘the’ way tag that compliments highway=motorway_junction ‘ref’ node tags.

Also, is there a task like this for the United States that works the same way?

’'’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.

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.

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 http://k1wiosm.github.io/checkautopista2/?id=116321&lat=44.6992&lon=-92.3997&z=7

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!

It’s been a few months now since this graph was rendered…is this trend continuing in the U.S.? (Leading to, has destination surpassed exit_to at this point?)

Updated http://wiki.openstreetmap.org/wiki/Key:exit_to#Coverage_in_the_United_States with current numbers, since this hadn’t been done in 13 months.

destination=* on ways has now nearly exceeded the number of exit_to=* instances on nodes.

That said, the number of exit_to nodes has not increased in a statistically meaningful way since June 2014.

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.