mvexel의 일기

Complex Intersections, or Why We Should Get Rid Of exit_to

mvexel님이 English로 2014년 7월 3일에 게시함. 최근 2017년 4월 5일에 업데이트됨.

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.

토론

2014년 7월 4일 02:38에 rickmastfan67님의 의견

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.

2014년 7월 4일 02:46에 rickmastfan67님의 의견

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

osm.org/node/76478134

2014년 7월 4일 03:39에 Baloo Uriza님의 의견

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.”

2014년 7월 4일 04:28에 rickmastfan67님의 의견

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.

2014년 7월 4일 06:25에 Baloo Uriza님의 의견

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).

2014년 7월 4일 06:30에 Baloo Uriza님의 의견

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).

2014년 7월 4일 07:49에 EdLoach님의 의견

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.

2014년 7월 4일 08:40에 Pieren님의 의견

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 ?

2014년 7월 4일 10:16에 JohnDoe23님의 의견

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

2014년 7월 4일 12:31에 Colin Smale님의 의견

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.

2014년 7월 4일 14:53에 k1wi님의 의견

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

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

2014년 7월 4일 16:26에 pnorman님의 의견

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.

2014년 7월 4일 16:52에 mvexel님의 의견

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.

2014년 7월 5일 01:51에 RussNelson님의 의견

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”.

2014년 7월 5일 09:42에 It's so funny님의 의견

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

2014년 7월 5일 13:51에 JohnDoe23님의 의견

@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: osm.org/way/11830053 osm.org/way/11830056 In some countries are these signs blue: osm.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: osm.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.

2014년 7월 6일 05:18에 RussNelson님의 의견

@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.

2014년 7월 7일 13:58에 mvexel님의 의견

@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.

2014년 7월 7일 18:42에 mvexel님의 의견

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

(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).

2014년 7월 10일 03:27에 RussNelson님의 의견

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: osm.org/node/352894978

2014년 7월 10일 14:26에 imagic님의 의견

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?

2014년 7월 10일 15:26에 mvexel님의 의견

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.

2014년 7월 10일 17:17에 mvexel님의 의견

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

2014년 7월 11일 16:15에 mvexel님의 의견

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.

2014년 7월 17일 20:06에 Skybunny님의 의견

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

Look at osm.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(osm.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.

2014년 8월 9일 20:11에 k1wi님의 의견

Scout is adopting destination=*.

See osm.org/user/mvexel/diary/23369

2015년 2월 17일 15:37에 mapsru님의 의견

@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: osm.wiki/Exit_Info

2015년 8월 17일 22:24에 Baloo Uriza님의 의견

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.

2015년 9월 15일 22:35에 mvexel님의 의견

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.

2015년 12월 22일 22:54에 Skybunny님의 의견

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

mvexel의 일기

Complex Intersections, or Why We Should Get Rid Of exit_to

토론

댓글을 남기려면 로그인하세요