Talk:Tag:highway=motorway junction

From OpenStreetMap Wiki
Jump to: navigation, search

Similar tag for trunk road junctions?

Could we add a tag "highway=trunk_junction" for trunk roads or are these not common? In germany, the exits of trunk-roads mostly have a name (usually the name of the town/city to where the exit leads via primaries or such) but have no numbers. How is the situation in other countries? --Jannis 17:24, 22 January 2008 (UTC)

It's the same thing in France. And these exits can have numbers. Wagner51 10:56, 8 February 2008 (UTC)
Other than the name, is there any particular reason why this tag is not appropriate for these exits? Chriscf 10:40, 18 September 2008 (UTC)
The only one that I can see is that it's then hard to tell what category of road the junction is for - should it be a blue number, green number etc. Gravitystorm 10:12, 23 September 2008 (UTC)
Perhaps, but we can deal with that when it becomes a real problem. As things stand, you can establish what type of road it's for by the road it's attached to. That is, once we've got rid of the sited-for-the-renderer nodes. Chriscf 10:53, 23 September 2008 (UTC)

Names and destinations

Some mappers seem to be adding the exit destinations as the name. I don't think this is the right thing to do, as IMO, the name tag should be the name of the junction itself (e.g. "Lofthouse Interchange", or "Spaghetti Junction" - though the latter is a common name for "Gravelly Hill Interchange, but that's a different kettle of worms). Do we need an exit_to tag?--Tms13 12:12, 3 June 2009 (UTC)

Don't know if it's used, but there's Relations/Proposed/Destination_Signs. Alv 12:34, 3 June 2009 (UTC)

I agree. In fact I've just swapped a 'name' to an 'exit_to' key on this junction node Having 'Gatwick Airport' in a name tag was causing incorrect matches on this geocoding query. Now CloudMade could adjust their algorithms to filter this out (and may have to for reliability), but it is bad tagging in my opinion. There's plenty of scope for systems (anything automatically examining name tags) to get confused if we start putting signed destination names in name=*. So I agree we should not do that. -- Harry Wood 14:31, 11 June 2009 (UTC)

How about junction=exit instead?

Why is this a highway=*? Wouldn't it be cleaner with junction=*? And whats with the motorway bias? 'exit' would work (and not be confusing) in any highway level. --Gorm 19:31, 3 July 2010 (UTC)

I think it's highway=motorway_junction because motorway junctions are grade-separated… and highway=grade-separated_junction just looks stupid. Kevin Steinhardt 00:08, 9 August 2010 (BST)
So you are saying that only motorways are grade separated? I think not: --Gorm 01:23, 17 August 2010 (BST)
I personally wouldn't be against doing it this way, but I think highway=exit would be better if it was changed. --Rickmastfan67 05:20, 17 August 2010 (BST)

Street name

Should a street name on an exit sign be included as name, exit_to, or not at all? If the exit sign just has a street name, does that count as the name of the junction itself? The thing is that the road where the exit ramp ends does not always match the road on the sign. Evil saltine 05:14, 11 March 2011 (UTC)

The text on the sign would be exit_to. The street it leads directly to is already in the database as the way that intersects the chain of motorway_links that begins at the motorway_junction node. A junction name is a separate thing that often doesn't exist. --NE2 06:44, 11 March 2011 (UTC)
Thanks. Evil saltine 14:23, 23 March 2011 (UTC)

Multiple exits - Collector roads

In Virginia there are approximately 47 "exits" which lead to collector roads which then have the actual exists. In some areas these have been tagged by separating the actual exit numbers with semicolons, e.g. ref=123A;123B;123C. However you then have additional nodes on the collector road which are the actual exits, ref=123A, etc. How is this to be handled? For the Virginia Department of Transportation (VDOT) database, they indicate this initial "exit" with the X suffix, e.g. 123X. I doubt this is the way to go, at least not without sufficient warning to the routing developers out there, not to mention there might actually be an X suffix used somewhere in the world. -- Joshdoe 02:28, 2 April 2011 (BST)

There's a 2X in Kansas City: and a 15X in New Jersey. What I've done is find a sign that lists all the exits together and use whatever it uses. That might be 123, 123A-B-C, 123ABC, or 123A-C. If there's no such sign, I guess you'd use whatever is normally used in that area of the state. --NE2 17:28, 2 April 2011 (BST)
I agree with matching the sign - I've seen it two ways that I can find: 123 or 123A-C MikeN 00:54, 3 April 2011 (BST)
Ha, thanks for that picture, good to know! So we'd all agree to create multiple exits then, and to use whatever is on the sign or whatever is common convention in that area? Then later if necessary we could add a tag like motorway_junction=collector_road or something to indicate that it's not an actual exit from the interstate (assuming you consider the collector road to be part of the interstate). -- Joshdoe 02:08, 3 April 2011 (BST)

Where to split the junction

The text states that the splitting point should be located at the place where junction "spplits" from mailine, but this is not very clear what exactly is meant by this. Also for routing SW it would be nice if we can distinguish at least two (if not more) places - point where the splitting line emerges and the point where it separate from the continuing lanes (point where the two lanes stop to be separated only by a full line and diverge). Apart from this there are also other interesting points, for example the point where the full line starts - i.e. the last point where I can choose whether I take the exit or not. Also there is a fourth place - the point where link and mainline stop to be connected by surface and separate. All these points can be several hundreds meters apart from each other. Also some of these splitting points are not only of academic interest, but they can be very useful for navigation SW which provide navigation in lanes.


We don't mark the point at which lines become solid on approaching an at-grade intersection. (Also, depending on where you are, it may be legal to cross a single solid line.) --NE2 16:10, 18 August 2011 (BST)

Clarification please

I have cleaned up the article to make it clearer and simpler, however there were a couple of things I did not understand. Can people please clarify:

  • The difference between 'exit-to' and 'destination'
  • What is meant by: 'Note for Germany: The links between the main motorways should only be tagged with the ref=* of the motorway they are going to if there are signs or other sources saying so.'
  • What is meant by: 'destination:ref=* and lanes=* can be used on the ways directly after the junction. The tag destination:lanes=* can be used on complex motorway_junctions. These tags may be needed to support a lane assistant in navigation devices'.


-- PeterIto 02:29, 20 January 2013 (UTC)

The first and third point are about where a link or a lane leads, i.e. the destination. There are usually standards in each country how this information is signposted. For example, in this case, the rightmost lane has (among other things) "Osnabrück" listed as destination, and A30 as destination:ref.
If all lanes of a highway=* way lead to the same destination, you can add an ordinary destination[:ref] tag on them. This is often, though not always, the case with highway=*_link ways. If a highway has lanes to different destinations, you can use the Lanes syntax, producing the keys destination[:ref]:lanes. Hence the text quoted in your third point.
The remark about lanes=* is probably based on the hope that you can omit the destination[:ref]:lanes key in simple cases because an application may guess the lane layout from the number of lanes on the ways after the split: For example, if there is an oneway road with 4 lanes, its end node connects to two 2-lane-roads, and the right one of these roads has destination=Paris, then it could be reasonably assumed that the to rightmost lanes of the 4-lane-road also had destination=Paris even if this is not tagged explicitly. I'm not sure whether relying on these assumptions is a good idea or even common practice, but afaik OsmAnd has such an heuristic (predating the Lanes syntax) and I guess that it is the inspiration for this remark.
exit_to and destination are different in where are used (and unfortunately, the page does no longer make this clear after your edit): destination is used on ways as described above, whereas exit_to is used on the highway=motorway_junction node. There has been some support for deprecating exit_to entirely (and imo it has indeed become redundant), but no unanimous consensus could be reached.
Finally, the second point says that ref tags should be used on German motorway_links if and only if either a sign like #401 or #405 is present or an official motorway directory or similar source lists that ref.
--Tordanik 03:33, 20 January 2013 (UTC)
Thanks for responding so promptly. Can I ask you to reflect the above in the article itself which will probably work better than my trying to interpret your comments? PeterIto 04:47, 20 January 2013 (UTC)
You added, "This node should be positioned as the last position at which is the legally possible to make the turn." That's counter to current practice, and would potentially cause problems for those of us who use OSM for routing - usually one wishes to enter the slip-road at its beginning (and that's what the 3-2-1 countdown markers indicate in GB). Having one's GPS indicate that the turn is at the last possible legal position (not even the last possible safe position) is certainly problematic. I cannot endorsed that wording.--tms13 19:29, 20 January 2013 (UTC)
Ideally, the main road would be split where the deceleration lane begins, and the lane=* tag changed accordingly for the duration of said lane. At the junction node, the deceleration lane becomes an off-ramp, i.e. a new way, and the main road continues again with the (usually) original lanes=* tag. Alv 22:17, 20 January 2013 (UTC)
I agree with User Alv in this case: the junction node should not be at the beginning but at its ending. The argument regarding routing is none: every serious navigation device gives you instruction ahead of fork of ways. If the fork is at the beginning the navigation devices will give wrong instructions e.g. in the cases of a series of exits that are only a few hundred meters apart. If you want to indicate the start of the slip-laned use - as Alv suggested - the lanes tag and maybe also the turn:lanes/change:lanes tag. This would provide the router with accurate information about the start and end of the slip lane. And I also want to add that in my region this is not counter to current practice: most of the splits are around the legal separation. --Imagic 08:32, 21 January 2013 (UTC)
Thanks for the comments. To be clear, I have no strong views on the above - my main objective with the wiki is to make things clearer with less words. As such do please make it fit with good practice. PeterIto 10:46, 21 January 2013 (UTC)

There is absolutely no standard practice as to where to start the link. I do it where it "flows best" - that is, where it doesn't introduce kinks in the way. (This is no different from mapping an acute at-grade intersection.) Others seem to apply special rules to links (which can produce horrible results when taken to the extreme - a weaving lane that's a separate way, or (on a surface road) a driveway that connects to the link rather than the main road as it should). --NE2 00:56, 22 January 2013 (UTC)

deprecating exit_to

Hi all - I see that this page still has some strong references to exit_to=*. As noted above, this tag has become pretty much redundant now that the more versatile destination=* has come into wide use. Routing engines like GraphHopper and MapQuest Open already favor this tag over exit_to=*. At Telenav we are also going to be using destination=* for signpost information. There is some discussion going on in the comments section of my diary entry. I already edited the exit_to=* page to reflect this and tone down the wording from 'should be used' to 'has traditionally been used'. Perhaps it is time to edit this page as well to not emphasize the use of exit_to=* and encourage the use of destination=* instead. I didn't want to do this without raising it here first though. Mvexel (talk) 16:12, 11 July 2014 (UTC)

Did you already do this? I am for further de-emphasizing exit_to here.--Jojo4u (talk) 09:06, 30 July 2015 (UTC)
What was proposed by Mvexel has not yet been done. That being said, personally I think it's time for exit_to=* to die already. Most of its page reads like a self-justification for the tag existing in the first place ('look at how many nodes have it, and look how much work it would be to change it!', to which I reply, 'That's irrelevant if there is a newer, superior, and better documented standard to do it.' -- which there now is.) In a year's time, 'destination' has already nearly overtaken exit_to in the United States itself, and destination is coming up with sensible augmentations to deal with United States NHTSA signs like destination:street destination:street:to, destination:ref:to, junction:ref on ways for double exit references, etc (See Exit Info). I'd like to see exit_to=* shown as deprecated on its own page, destination=* upgraded to defacto, and see exit_to eliminated entirely from this page, except where used for instructions to convert exit_to to destination=* tagging. Skybunny (talk) 22:27, 30 July 2015 (UTC)
De-emphasizing done. "Deprecating" should be accompanied by mailing list post. Something I'm not inclined to do since I'm not US-local. The wiki editing aftwards can be done by then, though.--Jojo4u (talk) 15:34, 13 September 2015 (UTC)

Junction for entrance

How (and) should entrance nodes for motorways be mapped? Even if they have a ref.

I guess this is partly done by destination=*, but what about refs?

Here is an example of an entrance to a motorway which may have a reference number: 27279140. I do not really no where both the name=* and the ref=* does come from. Because the contributor is not giving any source. But perhaps the source may be Bundesanstalt für Straßenwesen. (BTW: This seems to be an official Website, but I do not have any idea, whether this is a legitimate source for OSM.)--U715371 (talk) 10:21, 23 March 2015 (UTC)

Edit war about destination

I currently can't get the following change through: [1]. The reason I remove destination=* from the list is because the list is about the motorway_exit node: The following tags may also be used at the same point:. But destination is tagged on the way that branches off, as taginfo is proving.

So what to now? I'm asking User:Verdy_p to explain his reverts better because the current explanation "It has been documùented like this this long and yes it is used and documetned at bottom of page as well, with several alternatives" is not enough to explain the node<->way disparity. I also has not been documented this long because it was recently switched from exit_to to destination.--Jojo4u (talk) 14:16, 25 September 2016 (UTC)

User:Jojo4u has it right. Verdy_p is even using verbiage that exit_to uses (there IS no left/right nomenclature in destination, and never has been). Verdy_p is confusing the older exit_to tagging with that of destination and assuming(?) that they're the same thing. They're not, and destinations belong on associated ways, not on the node itself. (the fact that destination belongs on the associated way is why it's better, but that's another discussion.) Skybunny (talk) 14:25, 25 September 2016 (UTC)
Note: you did not ask anything except on this page. May be, but the doc is explaining the various alternatives. Has it been really been migrated in the data ? I can still see many places where this is tagged this way. — Verdy_p (talk) 15:18, 25 September 2016 (UTC)
Also left/right do exist at end of motorways connecting to another (different directions) or two other distinguished motorways (branches), or non motorways (primary or even streets). You'll find examples with motorways encing on a circular motorway around large cities. On signs, located at precise nodes along a way where the exits starts, you have thoise destrinations physically and explicitly listed. Tagging on exitways is often breaking, relations may be used but it is almost unused for now. Migration has still not been clearly defined (several candaidates), so renderers still render what is on nodes, as this was done for now.
When deprecating tags, you should better document by what it is being replaced and how. Removing old docs will not help the migration (instead of removing you should juast say it is the deprecated way of doing and give the alternatives). — Verdy_p (talk) 15:21, 25 September 2016 (UTC)
If this is becoming a discussion about how exit_to 'has to be included in that section' (because it is node based tagging) and by definition, then, destination can't be, then I'm going to suggest instead that this article section be rewritten so that it is talking about 'recommended related tagging for motorway_junction nodes in general', so that destination=* *does* belong in this section. In the last year, destination=* has far exceeded the number of exit_to=* node tags, and is by numbers becoming a clear favorite, already by a ratio of almost 5:1. While I agree that exit_to tagging still exists, that doesn't mean that simply because it is tagging based on nodes, that it should get preferred emphasis simply because it's node tagging. In fact I'd argue the opposite. Skybunny (talk) 15:28, 25 September 2016 (UTC)
This said, oh man, I would love exit_to to just go away already. But this is just personal opinion talking here. In every edge case where exit_to falls down, destination has an answer, and yet when retiring the tag is brought up, it becomes a regional turf war. Skybunny (talk) 15:30, 25 September 2016 (UTC)
Correct, but since mid-2015 this migration was not documented at all and nothing changed recently. I still think that old tagging should be preserved, even if it is explicitly said it is depreacated. Because there is still work to do and not everyone (users, editor tools, renderers, routers) is aware of the suggested changes. It is not just a "regional" question. — Verdy_p (talk) 15:33, 25 September 2016 (UTC)
Deprecation by definition means that one thing should be eliminated in favor of another. (In other words, if exit_to is deprecated, it should be removed/changed to destination wherever it is found so that in a year's time (or whatever) it's gone.) It's what I'm in favor of for all involved, because it makes both editing the map easier (one best way to do it), and consuming (one tag structure to expect), but... well, I suspect another year or two of things going at their current pace will make that trend clear regardless. Skybunny (talk) 15:37, 25 September 2016 (UTC)
Additionally there's a note for Germany, adding "destination:ref" instead of detination for referencing the destination ways. But I don't think it is specific to Germany: destination signs are routinely displaying these refs (road numbers) and not just the names of cities/suburbs, street names, bridge names or wellknown amenities and services (e.g. stadiums, airport terminals, theater/opera, parkings, railway stations...). What is displayed in names varies a lot locally, ref numbers are used to group these by the first connecting highway to these destinations.
This destination:ref is also not clearly migrated from nodes to something else (ways or relations). — Verdy_p (talk) 15:43, 25 September 2016 (UTC)
Note: replacing "destination=*" by "exit_to=*" (including in the recent addition made within the "Example" section) does not change anything about the problem on nodes: we still need then "exit_to:left=*" and "exit_to:right=*" at end of a motorway (in some more rare cases we have three exists, each one with its lanes, including the central one).
Note also that tagging nodes or ways is equivalent on motorways, assuming they are all "oneway=yes", because this is a node on ways from which there's only one incoming way to this node and multiple outgoing ways from this node, and within them, one may (or may not) continue the coming way with the same ref (if not, ther's no continue-way, only multiple exits from the same junction point). If we tag only the ougoing ways from nodes then we com back to... "destination". We could as well use relations (similar to turn restriction relations with "from"/"to" member ways and the "via" node at the junction), but this is experimental for now. Tagging lanes for directions on the incoming way would also be preferable for exits (notably because lanes become separated with a continuous line or zebras on ground, and driving requires anticipation). — Verdy_p (talk) 20:26, 25 September 2016 (UTC)

I reworked the page, as suggested by Skybunnd: exit_to only needs to be mentioned once. I also removed some cruft.
Verdy_p, I find your arguments a bit hard to follow since you mix many topics into one large text. One question you often rise is "we still need then "exit_to:left=*" and "exit_to:right=*" at end of a motorway" is mentioned - could you please give an example where tagging this with destinaion=* fails?--Jojo4u (talk) 20:42, 25 September 2016 (UTC)

Another edit added another proposal with "destination:to" when there's a 2nd group of destinations to add a second one (farther way); but destinations should ordered by distance and groups of destinations by different ways (different refs) exists with more than 2 groups. Typically on many roads you have indications of directions for the largest motorways or highways which may be several kilometers away from this junction (you'll need to pass another junction): this is used in France to indicate the major destination via motorways (autoroute "A 10"), or national/departemental trunks ("N 10", "D 110"), the nearest destinations may indicate a more local suburb or street/avenue/bridge/airport terminal, or various services such as parkings, rest areas, police/customs/gendarmerie controls, or commercial centers (frequent around cities near important junctions), oil/gas stations, monuments, museums, stadiums, townhall...
I don't think the new proposed "destination:to" will fit for grouping these destinations, in fact it could just be "destination:1=name1;name2;..."+"destination:1:ref=N nnn", for the first group (farthest destinations, most important), then "destination:2=name3;name4..." + "destination:2:ref:=N nnnn" for the more local destination. Tagging outgoing ways generally applies to only the local destinations (they have a single local ref).
There are also restrictions or obligations to use some exits for some vehicles (notably trucks and other large/long/high/heavy vehicles, or diesel). Signage is clear about them, and the same destination may require using two different ways. — Verdy_p (talk) 20:48, 25 September 2016 (UTC)
The destination:to=*-scheme has a 1:1 relationship between ref and destination, the list is separated by semicolons. This is in contrast to destination:ref=* which applies to all destination=*. If on the example image there was an other destination:to like "N-121 Burgos (este)" the scheme would be:
  • destination:to=Burgos (Oeste);Burgos (Este)
  • destination:ref:to=N-120;N-121
Of course the division between destination and destination:to does not lead to proper sorting of distances. But this discussion should continue on the proposal page.--Jojo4u (talk) 21:20, 25 September 2016 (UTC)
No, there's 1:N relationship with multiple destinations (though rarely more than 3) grouped in the same ref (look at actual signages!), each group being clearly separated, and each one may have their own restrictions/obligations for some kinds of vehicles. Some destinations only indicate a ref number (notably when it will be taken in both directions after reaching its own junction), so we also have 1:0 relationships in these groups ! — Verdy_p (talk) 22:06, 25 September 2016 (UTC)
Personally I'm fine with destination=<semicolon separated destinations> in the order in which they appear on a sign. This way, it's not really up to an editor to determine what one destination is more important than another based on distance, importance, or any other criteria; the nice thing about doing it by the indication on the sign is that we don't have to care, and the right answer is always what the sign says in the order it says it. I pair this with destination:ref=<list of refs, which could someday allow shield generation for data consumers> and destination:ref:to (common in the US, where a sign will say 'WI 90' and also 'to I-95' which is in fact further away).
In any event, I like this kind of discussion, because it's productive, in the sense that we're taking an already fairly mature and extendable keyset (destination) and thinking of ways it can be used or someday augmented, in ways that a node based exit_to never can by its nature of existing on a node and not having knowledge of other in/out ways. Though as Jojo4u said, if there's more to be talked about there, there's the proposal elsewhere on the Wiki which has a lot of traction and has quite a lot of backing in terms of number of uses these days. Skybunny (talk) 22:27, 25 September 2016 (UTC)
It's not much the order of importance, or distance of these destinations that matters, but the fact that they are grouped and there's no such 1:1 matching between destination names, the ref's of highways leading to them, and their restrictions/obligations. Actual signage use groups, each group can contain a ref, one or several destination names, one or several restrictions/obligations for vehicles, each group is clearly separated vertically on signages (they could also use various text sizes or styles for local/regional/national importance, but it is not really important; however they may use significant colors depending on the kind of traffic, but usually based on the ref classification). Matching by order of the semicolons in separate tags is very fuzzy, these groups should be keyed. Editors never care about semicolons, they can freely reorder them, merge them (they don't accepte duplicate entries in semi-colon lists that are supposed to be **unordered** everywhere) — Verdy_p (talk) 23:02, 25 September 2016 (UTC)