Talk:Tag:highway=motorway link

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Tag:highway=motorway link


oneway

Is there any disadvantage to assuming that motorway links are oneway? I expect that the vast majority of them are, and requiring that it be specified in only the (relatively) few cases where they're not makes more sense than requiring that it be specified in all cases. --Hawke 14:29, 19th June 2008 (UTC)

Since the examples on this page explicitly mention that you have to add oneway=yes to the part that's only oneway, I can only assume that everyone who read the page tags the motorway_link without thinking it implies oneway=yes. It's not about what's more common (I agree that most motorway_links are oneway), but it's about changing something that's been explained on this page for ages and will thus break motorway_links from a lot of people. --Eimai 15:04, 19th June 2008 (UTC)
The examples on the page say nothing at all about what should be assumed if no value is provided. They do say that oneway=yes should be added, but that doesn't mean it's implicitly oneway=no if it's not. It won't *break* anyone's motorway_link, because any routing app that assumes an highway=motorway_link without a oneway tag is oneway=no could be incorrectly (and dangerously!) routing people the wrong way on that link. Either it's got a oneway tag (and that tag must be assumed to be correct), or it has no oneway tag and the only safe choice for a router is to assume it's one way. --Hawke 19:06, 20th June 2008 (UTC)
Quote from the page: "The green way in this example can then be a simple junction with highway=motorway_link without the oneway tag, as it is supposed to be used in both directions." That line more or less says to me that oneway=no is implied. Furthermore I believe that a person who is driving is still capable of looking outside his window while following instructions from a router. And the argument about it being dangerous to assume oneway=no could work for every type of road then, especially on the numerous roads in the database that were added with satellite images only and without surveying. --Eimai 19:44, 20th June 2008 (UTC)
Ah, I missed that example. Still, that's a really bad idea. Motorway links are far, far more likely to be one-way than two-way; other road classifications are far more likely to be two-way than one-way. And you're much more likely to be completely misrouted if a router assumes that motorway links are two-way. Can you explain how a motorway_link will be "broken" if oneway is implied? There might be a few places where a motorway_link is mistakenly avoided by a router, but that's not as big a deal as trying to send someone the wrong way up a motorway_link. --Hawke 07:12, 23rd June 2008 (UTC)
I agree with Hawke, motorways are oneway by default - and it is important to have a possibility to know about the situation without looking out of the window - the only chance for routing software to determine a possible and correct route to a target. It doesn't make sense to tag thousands of motorways as oneway=yes - the number of motorways with oneway=no is a lot smaller. And it makes sense to change a definition, if it safes a lot of work - even if it implies some work to reach the change for existing ways. -- Schusch 07:23, 23rd June 2008 (UTC)
PS: the example on the page should of course be changed -- Schusch 08:15, 23rd June 2008 (UTC)
Look, I'm certainly not arguing that oneway=yes by default is a much better idea here. I'm only arguing that this is a change of policy to suddenly imply oneway=yes, and that we need a good way of communicating this change to mappers instead of quietly changing this on the wiki page. And that we need some way to check all current twoway motorway_links without oneway tag to make sure they're correct. As for being broken, it probably only means that you need to make a detour. Not really a critical thing, but annoying, and the chance of it being rechecked by mappers if they're correctly tagged is small if they're not made aware of the change, and likely people will continue tagging it wrongly. So, a simple message to the mailing list marking the change and with a request to mappers to check motorways in the neighbourhoud if they know any twoway ones should be sufficient. And better, automatically add a fixme tag to all motorway_links without a oneway tag to make mappers check them. --Eimai 11:55, 23rd June 2008 (UTC)

Hi, now that routable maps are available, it seems to be important to tag oneway=no for the cases where it applies. I already have seen my GPS failing to select a proper highway exit just because of that: In France, it is quite frequent that motorway links are oneway up to the toll barrier, but then double way after that and until it joins with a nearby primary /secondary etc. User:Ger4rd 16:45, 18th May 2009

To me the very idea of "implies one-way" is a confusing thing to be mentioning like this in tag documentation. Is that a message to mappers, or to people writing routing algorithms? Somebody developing a routing algorithm is going to have to decide what to imply where the information is missing. How to handle that is a tricky decision, but as far as mapping goes... the information is missing, so add it! Sure you could leave the tag out if you're feeling lazy (and really there's nothing wrong with mappers being lazy) but we should aim to have somebody else fill it in later.
Basically "implies one-way" is too brief and unclear. In my opinion we should write the following: "Most motorway_link roads will be tagged oneway=yes. Any unusual motorway link road which is two-way should be explicitly tagged oneway=no for the avoidance of doubt (Note that this can be important, since some tools interpret motorway link roads as implicitly oneway=yes unless tagged oneway=no)"
We should put the tags in. That's the way I see it, but I'm sure there's bazillions of mailing list arguments on this topic too.
-- Harry Wood 14:58, 15th June 2009 (UTC)
All motorway_link's I have seen are tagged with oneway=yes or without oneway. Therefore it would be a bad idea to imply oneway=yes on untagged ways! We should remove the implication statement and replace it by a "Always tag oneway=* for highway=*_link!" --Phobie 13:23, 17th June 2009 (UTC)
I see the point for motorway_link because 90 or 95% require the tag oneway=yes and 5 or 10% are unsure. So, assuming there is no default or "implied" oneway value for motorway_link, please, don't extend this rule to all other highways where 90% or 95% are NOT oneways by default. -- Pieren 13:59, 17th June 2009 (UTC)

Any form of implicit tagging with frequency distant from 100% is a poor idea as it discourages users from giving definitive tagging. Such implicit defaults for users could also change in future, casting doubt over the existing untagged motorways. It is for the routing applications alone to come up with sensible defaults (probably best on a per-country basis) when explicit tags are missing. Client-side defaults are fine for cases like highway=motorway where the majority of time a oneway=yes tag is required. --Pinkduck 15:28, 9 November 2009 (UTC)

I agree! The implicit oneway=yes for highway=motorway_link is very much unknown to lots of mappers. I have checked some european countries and have found hundreds of motorway links that should be tagged with oneway=no but they are not. This will result in a wrong map (renderers assume the implicit oneway tags) and in problems with routing applications. So please add the oneway=yes/no to ALL motorway_links. --WanMil 16:32, 31 October 2010 (UTC)

While the wiki text stated since 2013 "please tag explicitely", the implied oneway=yes has only been removed in april. Since no one objected I removed the implications from OSM Tags for Routing and Highway Link--Jojo4u (talk) 16:36, 9 September 2015 (UTC)

I drafted up a proposal about solving the oneway for motorway_link. Please comment.--Jojo4u (talk) 12:15, 10 September 2015 (UTC)

"Link roads should be members of all related route relations!"

Why is this? It seems useless. --NE2 05:21, 8 February 2010 (UTC)

Removing, since nobody's responded. --NE2 13:36, 11 February 2010 (UTC)


Name of motorway link

I'm using "AndNav2!" on my mobile phone and I've got a notion that it usually tells only the number of the motorway that I need to take at a junction, for example "Turn right to A 66" (I got the german version so I don't know the words exactly). It would be nice if the navigation software would also tell the direction where I have to drive to. May it makes sense to use a name tag, for example "name=A 66 Frankfurt" for motorway links? --S-jordan 18:41, 12 February 2010 (UTC)

We have this; see highway=motorway_junction. --NE2 20:03, 12 February 2010 (UTC)
I meant the name-tag of "highway=motorway_link". It is used very rarely in my local area. I will test it on some motorway links and see if it's useful. --S-jordan 09:11, 13 February 2010 (UTC)
Don't tag for the renderer. --NE2 14:06, 13 February 2010 (UTC)
Thanks for the hint. Maybe a navigation software can determine in which direction a motorway leads. For example it could use the name of the next upcoming junction of the motorway the link leads to. But the name of the next junction is not always the text that is printed on signs. So why don't use the name-tag of the motorway_link for that information? --S-jordan 21:58, 14 February 2010 (UTC)
We have Relation:destination sign; I don't know if any software supports it (yet). --NE2 21:01, 14 February 2010 (UTC)
This seems to be exactly the function I was looking for. I will have a closer look at it. Thanks a lot! --S-jordan 06:11, 15 February 2010 (UTC)
Also now destination=*. --NE2 22:47, 22 June 2010 (UTC)

ref on motorway_link

Because of a wide discussion in german talk-de mailinglist the result is to tag motorway_links only with ref=* if there's a sign or another data-source telling this. If there's a sign for the motorway-number on the motorway_link - no problem - there the ref-tag is made for. But it's not useful to tag a _link with the ref of a motorway, if it isn't explicit told- because the link is not the motorway itself. Routers have to see in the following motorway, what to announce. And not osm is to be tagged for those routers wich can't do that... --Steffterra 18:58, 12 June 2010 (UTC)

Links between non-motorway roads

These should correspond to the lower classification of the roads being linked. Otherwise it is virtually impossible to avoid rendering artefacts.--RichardMann 16:25, 22 June 2010 (UTC)

I'm a software developer for a commercial mobile mapping program with routing support, but an OSM newbie. I agree completely, and I'm honestly amazed that OSM classifies links at the level of the highest road instead of the lowest road. Tele Atlas and NavTeq data both classify links between roads according to the road with the lower level. Using the higher level can create more work for the routing algorithm and sometimes creates weird visual artifacts, as I can easily see by looking at OSM data for Calgary. (and since there's a talk page for each different kind of link, do I have to add this comment in all of them?) --Qwertie 23:56, 3 November 2011 (UTC)
Depends. If it's a simple traffic light bypass, I agree (unless it's part of a larger system of links: http://www.openstreetmap.org/?lat=40.413998&lon=-74.537131&zoom=18&layers=B000FTF. But if it's a more complicated junction (like a motorway junction that happens to be on a trunk road), I'd expect to see trunk_links: http://www.openstreetmap.org/?lat=40.535866&lon=-74.343041&zoom=18&layers=B000FTF. Any such "rendering artefacts" are no different from when rendering motorway_links.
What's possibly more complicated is when it does link a trunk to a trunk: http://www.openstreetmap.org/?lat=40.549458&lon=-74.475027&zoom=18&layers=B000FTF. This looks worse than any of the other links in the surrounding area. --NE2 22:46, 22 June 2010 (UTC)
I disagree. For consistency the *_link should always correspond to the same direction, and I think the higher of the two roads makes most sense. Apart from certain legal restrictions on motorways, there's very little difference between slip roads going to a large truck road and slip-roads going to a motorway. What rendering artefats are you referring to? I see no reason for a change to the current definitions, and every reason not to, given that we'd now have to re-do all our existing work. -- Rjw62 08:04, 23 June 2010 (UTC)
Rendering artefacts such as this - http://www.openstreetmap.org/?lat=51.737525&lon=-1.197289&zoom=18&layers=B000FTF - note the service road and cycleway rendered on top of the tertiary_link. It looked even worse when it was a trunk_link. The artefacts occur whenever you get roads involved other than the two ones being linked. The artefacts occur because Mapnik has pushed links under all other roads to reduce the number of artefacts. You need to push them down to below any road that they might come out on, but not below any other road that might join them in the mean time. These roads that "join them in the mean time" almost never come out on motorway links, because motorways are - by definition - specially built roads with controlled and limited access to the rest of the highway network. There are two potential solutions - try to guess where the balance is between "roads that it might connect to" and "roads that join it in the mean time", or pick a link value (ie tertiary_link in this instance) that tells the renderer what to do.--RichardMann 10:46, 24 June 2010 (UTC)
Most of the time rather the higher classification; links leading from and to a motorway don't lead anywhere else and are already off limits to traffic not allowed on the motorway - if not signposted as such, they're dead end streets for, for example, pedestrians. The same then goes for trunks and primaries, even if they might not have been banned for specific users, they're better described as being the access ways for traffic using the higher class road. Alv 08:05, 23 June 2010 (UTC)
Part of it is a question of where you draw the line, if you go by the lower classification. For example, is a channelized (assuming right-side driving) right turn lane from a trunk road onto a shopping center service road trunk_link or service? If trunk_link, what if all movements are channelized like here? Where does trunk_link end and service begin, especially if the only access to the shopping center is via the trunk road?
I think de facto there's no standard; different people map it differently. Perhaps only a single highway=link is really necessary (other than motorway_link), since the details are inherited from the connecting highways. Anything beyond that is really only determined by how it "looks" (not on a specific renderer but in a more general sense). --NE2 10:00, 23 June 2010 (UTC)

Motorway service areas

Some mappers are preferring to directly connect the highway=motorway with the highway=service, instead of using the link-tag. Is this usage common at other countries than at the Netherlands or Germany? If so, it should be documented, too. For the case at Germany I would recommend to map it with *_link in between, because it does not seem to be a healthy idea to use the discussed ways as pedestrian.--U715371 (talk) 00:05, 26 November 2014 (UTC)