Talk:OSM tags for routing

maxweight/maxheight

todo here: mention access, and maxweight/maxheight. Morwen 14:35, 9 November 2007 (UTC)

done with a link to the access-restrictions -page. --MarcusWolschon 15:26, 19 November 2007 (UTC)

Speed

inferring maxspeed

'The default maximum-speed if not given by "maxspeed"=<number> is [dependent on the country and rural / urban classification]' This approach has many disadvantages :

• Testing to see if a point lies in a country Germany is quite difficult. In or outside an urban area is even worse.
• It means multiple routing applications (gosmore, traveling-salesman etc) all contain similar code. Writing, maintaining and testing all these implementations is unproductive.
• The OSM approach has always been not to rely heavily on defaults or implied tags. E.g. religion=christianity does not imply amenity=place_of_worship.
• Mappers are not (supposed to be) lazy. The guides want them to record all kinds of trivial information like source, so they should also be encouraged to add maxspeed tags.

I suggest we move all these recommendations to the relevant country tagging standards pages.

This would be great but I have some arguments why we still need the defaults

a) There will always be roads with no maxspeed tag

b) Regulations change and then there is no way to see if speed is limited by default or by a sign.

c) Speed-limits ARE very different in other counties. A German Autobahn and a US-highway are 2 separate beasts.

d) Actually testing if you are inside a polygon is trivial. Just draw a line downward, count the number of intersections and see if they are an odd number. Inner and outher Bounding-boxes speed up this process very well. --MarcusWolschon 12:11, 25 October 2007 (BST)

Regulations change. So do street names and route numbers. OSM copes by having many energetic mappers.

Routing software is for people new to an area. They are generally not brave enough to drive at 200km and they tend to fly between major metropolitan areas.

Furthermore, you will find that the fastest route between 2 points in different cities will rarely change if the average speeds on the motorways changes by 50%. It's like trying to dodge traffic.

A much easier solution employed by software like Mapsource is to allow the user to specify his preferences. -- Nic 13:57, 25 October 2007 (BST)

Routing-software not only has to give the fastest route (if that metric is chosen) but also the expected time of arrival. These are speed-limits, thus they form an upper limit to user-entered/automatically determined average-speeds to properly reflect zones where that speed can not be legally reached. If you suggest to ignore speed-related information in the map, then ignore it but don't suggest that others should not include it in the map and find ways to properly evaluate it algorithmically. --MarcusWolschon 05:30, 4 January 2008 (UTC)

if you don't want to rely on implied tags, you should support efficient data entry. There should not be a need to add maxspeed tags, as long as there's a common rule within the country (e.g. by laws), and to tag exceptions only. Routing should consider those common rules within a country. Otherwise I'd propose a bot that would add maxspeed:implied whereever required. --Traut 15:42, 3 January 2008 (UTC)

What are you proposing? This page is about how to evaluate the existing and used tags. I consider maxspeed=implied to be a waste of bandwidth because "implied" is simply the default-value for the "maxspeed"-tag. --MarcusWolschon 05:33, 4 January 2008 (UTC)

The text above claims: Mappers are not (supposed to be) lazy. The guides want them to record all kinds of trivial information like source, so they should also be encouraged to add maxspeed tags.. En contraire. my proposal is NOT to assign maxspeed tags wherever they are the default value within this country. Tagged should be exceptions, but not the defaults. If there would be a need for tags everywhere, those tags should be added by a bot - and they should be marked in a way to differ bot tags from manual tags. --Traut 13:06, 4 January 2008 (UTC)

The criteria to find out whether a road is inside an urban area (in order to infer maxspeed) seems to be very wrong.

• admin_level=8 boundaries are different for each country, these do not mean the same thing for every country.
• there are independent cities which have boundaries with lower admin_level
• a rural territory (say a farm) can administratively belong to a city, in other words included into city's municipal borders. But that does not mean at all that you can drive only with urban speed, quite opposite indeed.
• testing for landuse polygons seems like a 'dirty hack', moreover it's error-prone. For example many mappers limit landuse=residential quarters by nearby streets, in other words streets are not part of these polygons. Also what happens when the list of landuse permitted values extended? For example added landuse=wood.
• the idea of checking nearby places again is not right. Cities/towns can be of any kind of form. A city can be very thin and very long... A motorway or trunk road can pass around the city but not going inside city borders.

I think the criteria should be both simple, easy to implement, and give an exact answer whether a point or way is in urban or rural area. So I am suggesting only checking whether a point or way is in place=* polygon. If so urban maxspeed should apply, otherwise rural. Of course if not specified explicitly with maxspeed=*. --Yuri Nazarov 15:11, 24 August 2009 (UTC)

average speed

B.t.w. why don't we have an averagespeed tag ?

And why doesn't this page mention extraction of average speed data from GPS tracks ? -- Nic 09:47, 25 October 2007 (BST)

I proposed the average-speed from the osm-gps-tracks myself but it was concluded that this would only work out for the motorways. Because people mapping are driving significantly slower and different from the average user later.

In fact, I am preparing to collect average speeds for roads in my own navigation-program traveling-salesman but for people who selected "fastest road", "shortest road" and "most fuel-efficient road" and the car-type the user selected "fast", "slow", "bike", "truck",... separately. --MarcusWolschon 12:11, 25 October 2007 (BST)

See Speedcollector. --MarcusWolschon 12:56, 20 February 2009 (UTC)

motorway_link is not always oneway; concept of lanes

Assuming "highway"="motorway_link" to always be oneway is incorrect. At least in Germany there are lots of ways marked by

which are not oneway, but have two lanes of opposite direction (nothing in between other than maybe a painted centerline). In fact, they are something starting from "highway"="service" up to "highway"="secondary", being marked on a part near the Autobahn as belonging to the Autobahn.

If you ask me, a better concept would have been to map each and every lane on its own and then bundle them to ways

(since we do now have relations for that purpose, or is it too late already?) --Nodilution 17:48, 26 October 2007 (BST)

Actually all German motorways I have seen in the map and on the road are 2 oneway-ways (separated by a barrier). That motorway implied oneway is also stated on the German map-features -page. If a single osm-way is used for apart of the road that can be driven in both directions then this is clearly a bug in the map and should be corrected.

Having a highway as oneway=false in a router would lead to all kinds of problems starting with the router wanting you to turn around or enter the highway on the wrong lane.

Nic: The parts marked as motorway using that sign would that have no separated lanes (these are required in the law "StVO") would probably better be labeled as trunks with restrictions similar to a "Kraftfahrstraße" as no vehicle <70Km/h is allowed there. --MarcusWolschon 11:11, 31 October 2007 (UTC)

In the UK there are a couple of single-carriageway sections of motorway still in existence. They have standard motorway restrictions: no stopping, no slow vehicles, 70 mph speed limit, but no physical barrier. E.g. the motorway at Walton Summit, the A601(M) etc. Oneway_yes should not be merely assumed, it *should* be tagged. Richard B 13:06, 31 October 2007 (UTC)

This is clearly the exception. Thus IMHO "oneway"="no" should be tagged on these few motorways, "oneway"="yes" be assumed and the fact be made known in the documentation for "motorway" and "british tagging-guidelines". --MarcusWolschon 17:49, 19 November 2007 (UTC)

It's important to make a difference between "motorway"s and "motorway_link"s. Motorways are always oneway (in Germany, too :) ), but in fact, the links to motorways are often divided in to two parts. The first part starts at the road as a bidirectional way, but already has restrictions like a motorway. Then second part follows. The ways gets splitted in a way that comes from the motorway and a way that leads to the motorway. So the two ways of the second part need to be oneway and the first part doesn't.
In short: "highway=motorway" -> "oneway=yes" can be assumed, but "highway=motorway_link" -> "oneway" needs to be set manually and cannot be assumed. --MasterMG 19:23, 20 December 2007 (UTC)

You are probably right. We should not assume oneway=true in general on the links. Can we make a parser to explicitly tag motorway_link-segments that form a Y on a motorway where they have not been tagged in the map? Not change direction or split ways/reverse segments if a oneway=yes or oneway=no is given but add 2 oneway=yes with the correct direction and a oneway=no for the combined part as well as a relation that forbids changing direction at the center-point of the Y. Also add oneway=yes and check the direction of 4-cloverleaf-style intersection (I was more thinking about them then motorway<->trunk -links first.)? --MarcusWolschon 10:56, 23 December 2007 (UTC)

Why not assume oneway=true on links? If they're not one-way, they can be tagged oneway=no. --Hawke 19:49, 18 June 2008 (UTC)

I agree with Hawke, assume oneway=yes on highway=motorway_link unless otherwise tagged. In the US, all exit ramps built to modern (1960's+) standards are one-way; yes, there are places where a pair of them are very closely spaced and resemble a single roadway, but there's always some kind of division or barrier making it into a kind of divided highway which should be two ways by OSM standards relating to divided highways. In other countries, I can certainly picture the scenario where there is a single, two-lane, two-way portion of highway=motorway_link, which might as well be one way in OSM. That should be oneway=no. But that way is not likely going to intersect the motorway directly; it will probably split into two highway=motorway_links that are oneway=yes. Even if every motorway interchange on the planet is so structured, that's still twice as many highway=motorway_links which are oneway=yes than are oneway=no. Therefore, if a value for oneway=* is to be implied on highway=motorway_links — and routers have to assume one way or the other if not specified — then the implied value should be oneway=yes because that's the actual value of a significant majority (between two thirds and all) of the highway=motorway_links in existence. (There is a caveat here for the US; in the TIGER-imported interchanges, there's no correlation between a ramp's actual direction and the direction of the way representing it. So if a router assumes highway=motorway_link ⇒ oneway=yes then it will mess up an interchange that hasn't been touched since the TIGER import. Then again, most TIGER interchanges that aren't simple diamonds have totally screwed up topologies and need to be redrawn anyway. ) Vid the Kid 03:03, 22 April 2009 (UTC)

Here's a single-carriageway motorway_link built in 2006. --NE2 22:18, 24 January 2010 (UTC)

...and that can be tagged with oneway=no. Simple enough. --Hawke 02:14, 26 January 2010 (UTC)

Sure; I'm just conversing with Vid. (The bigger problem with leaving off the oneway tag is that it's difficult to verify that everything's pointing the right way.) --NE2 02:28, 26 January 2010 (UTC)

The talk page on highway=motorway_link came to the conclusion not to imply oneway=yes. That's why I striked implied onway=yes here.--Jojo4u (talk) 14:38, 9 September 2015 (UTC)

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

mph: units

How should speed units be handled e.g. within UK? Should all numbers be given in the common SI units such as km/h for speed or m (meters) for length, width, height? Should numbers be given as used within this country (e.g. mph, feet, stones, ...)? Should non-SI-units be named within the value (such as maxspeed=30mph)? If yes, should those numbers be given with or without space between number and unit? --Traut 15:46, 3 January 2008 (UTC)

The tags we have clearly state the metric system. You can use let the user choose any unit in the user-interface and convert but the saved map has one unit only at this point and this is good thing. (It started in the UK and still used SI.) --MarcusWolschon 05:21, 4 January 2008 (UTC)

The article here names within maxspeed/UK: UK mappers will often include units in the maxspeed tag, ie: maxspeed=20mph (miles per hour). What are they supposed to do? Should they name mph? I don't know which UI you refer to - there are different ones, while none of those I used had an option "my numbers will be entered in mph and will be converted to SI units automatically". --Traut 14:29, 4 January 2008 (UTC)

What precision should kph be given to if the actual speed limit is NOT an exact number in kph? Do I really need to set maxspeed=88.51392?

Just round to the nearest integer. Any integer speed in MPH, converted to km/h, rounded to an integer, and then converted back to MPH, is guaranteed to be the same, original value in MPH. That is, assuming the exact same conversion factor is used for both conversions. So while you're not representing the exact speed in the OSM data, if it gets converted back to MPH, it will look like the original, correct value. And then the only thing you need to worry about is speeds that are not integers in either MPH or km/h, but how often is that going to happen, and in what situation does the speed need to be reconstructed with such precision? Vid the Kid 03:20, 22 April 2009 (UTC)

A precision of 1Kph is more then enough. Everyone implementing strict by the wiki-page will ignore maxspeed-values that are not "[0-9]+"

but parsing "([0-9]+)[ ]*(|kph|mph|Kmh)" is not too much of a special case to implement.

Even "([0-9]+)(|,)([0-9]*)[ ]*(|kph|mph|Kmh)" can be done for bonus points. ;) Everything beyond that I think should be ignored. (I don't want to parse maxspeed in attoparsec per microfortnight) --MarcusWolschon 17:03, 21 September 2008 (UTC)

The world will turn to metrics. We should not be the ones to keep the funny counting systems. btw, it is "km/h", not "kmh". We can convert the miles values in the GPX, not in the routing software! --Lulu-Ann 13:50, 26 September 2008 (UTC)

Internal representations (i.e. the values stored in the OSM data) should be SI all the way. If routing software wants to present speeds and distances to its user in other units, it can do the conversion. If someone wants to make a units-aware editor so that mappers can enter values in non-SI units, they can feel free to do so, but said editor must convert the values to the correct units, or else it will be adding incorrect information to OSM. The only tag values which support multiple units would be those of currency, since exchange rates aren't fixed and therefore conversion to a single standard unit wouldn't work. Vid the Kid 03:20, 22 April 2009 (UTC)

see also

Have a look at proposed features/maxspeed none, please. --Lulu-Ann 16:04, 14 August 2008 (UTC)

proposed features/maxspeed walk

Signage

Not sure if this belongs here under routing, but I'll go ahead anyway. When intersections become complicated there is often signage that tells you that if you take this exit you will go to this road/place/whatever. Has anybody tagged this kind of information? It would be very good not for the routing itself, but for the instructions given after the routing has been done. Does it make sense to tag this on the exit link way? So, if the routing would include the exit link, the signage would be shown. Something like signage="Whatever the sign says" on the highway=*_link. Norpan 15:29, 24 November 2008 (UTC)

This is called "signposting". I remember Frederik Ramm talking about the need of it and how relations are required to model it back on the meeting in Kralsruhe, when we made the Karlsruhe Schema for mapping house-numbers. I am not aware of tags for it yet but I haven't looked yet. --MarcusWolschon 07:54, 25 November 2008 (UTC)

Relation:destination_sign --Jakubt 01:15, 18 August 2011 (BST)

diameter

I guess 600m for a village may be a bit small. Any suggestions? --MarcusWolschon 07:13, 27 September 2009 (UTC)

Road condition a.k.a. smoothness

Why is this not suggested/considered in routing? Important everywhere there is sparse population and not so well maintained roads.

Because nobody has been able to come up with verifiable criteria for each condition class. And even if they did come up with such checklists, it would be a long list and it would be too slow to add the tags extensively. Besides, how much slower is each condition, than the next better condition? In what vehicles? Alv (talk) 10:01, 19 February 2014 (UTC)

Authority?

When I look at this page, I don't see any references to applications / services actually supporting the conventions listed. Where does this page derive its authority from (if any)? Martijn van Exel (talk) 23:35, 1 July 2014 (UTC)

Default U-turn restrictions

In Queensland you must not do a U-turn at traffic lights unless there is an explicit permission sign. I'm aware of restriction=no_u_turn, but there are many unsigned "box" intersections that would have to be explicitly tagged just to prevent misrouting, and that surely would go against good practice. Is routing of U-turns going to be broken for this state? Or is there (say) a way to tag the state boundary to indicate a "default" U-turn restriction? And then how does one tag the permission signs? -Dle0 (talk) 14:14, 20 May 2015 (UTC)

As far as I know, there is no established solution right now. There is a related discussion at iD editor's issue tracker. I agree that it would be best to have a default for each region so mappers only need to indicate the exceptions to the rule. --Jgpacker (talk) 16:25, 20 May 2015 (UTC)