# Talk:OSM tags for routing/Maxspeed

## acces-hgv

Well, I am wondering if the maxspeed for access=hgv is indeed just 60 km/h. AFAIR "trucks" are allowed to go 80 km/h on highways and trunks. I don't want to interfere with the author(s) of this article but I'd appreciate if she/he/they could check if the given values are correct. Regards, Ralf aka TigerDuck

## maxspeed=no /none

I think "no" should be replaced by "none", and not (as proposed in the table) the other way round. Concerning tagwatch, "none" is used more often then "no". --chris66 09:45, 22 February 2010 (UTC)

## Numbers

Routing algorithms work by calculating a cost for a path by some defined method, and then using the path with the lowest cost. This is generally done firstly in proportion to the length of the path, and then penalties are added. In general, negative penalties are not allowed, and where they are they must be a proportion rather than a fixed amount. For this, the length-relative cost must divide to produce a real number that is not zero, as zero-cost paths will be selected above all others. A path with a zero-cost characteristic results in a set of equal-value routes that for a journey between two adjacent junctions would include the direct route, the route involving continuing to the next junction and turning around, continuing for two junctions and turning around, continuing three junctions and turning around, etc. as the cost of this diversion is zero.

• INFINITY divides (generally) to zero, so cannot be used
• NULL divides to NULL, so cannot be used
• zero divides to INFINITY, so cannot be used

-- Chriscf 11:07, 8 October 2008 (UTC)

## Autobahn legal question

Is there a limit, in the German law, that the driver must always use such a speed that the vehicle can be stopped on the visible part of the road? Alv 15:46, 9 October 2008 (UTC)

Then I found it myself: yes. "Er darf nur so schnell fahren, daß er innerhalb der übersehbaren Strecke halten kann." (StVO § 3). Alv 11:03, 15 October 2008 (UTC)
Which, for a road on level ground and a viewer with eyes at a height of 1,3 meters (quite high for a car that fast) would lead to a visible road length of just over 4 kilometers and a speed of over 900 km/h. However, at a distance of two kilometers even the parallel lanes become indistinguishable to a naked eye (claimed minimum separation of 10 arc seconds). That equals (with optimal braking - reaction time is negligible compared to the braking time of 20 seconds) to a speed of 690 km/h. But then, going faster than (about) that does seem to be illegal. Alv 07:04, 22 October 2008 (UTC)
Show me the road-legal vehicle capable of achieving such a speed safely and you can start tagging maxspeed=690. Chriscf 08:49, 22 October 2008 (UTC)
nice idea. but the most correct value is and will ever be maxspeed=none=no=unlimited={} --Cbm 15:15, 22 October 2008 (UTC)

## Autobahn

As the 130 is plain wrong, I have a proposition if the German law has a section equal to ours: regardless of the posted or national speed limit, the driver must always be able to stop on the length of road visible to the driver. Most likely no one has ever been fined for exceeding such a speed, unless they did collide with something - they would have been able to avoid the crash had they complied with that. Is it the same way in Germany?

If it is, we can calculate how far a driver can see (on a flat straight road) with the earth being round an all, pretend that the car decelerates at a constant 9.8 m/s² and get a maximum speed. Any router ought have knowledge of the users' (likely) mechanical max speed (for pedestrians and cyclists they already have!) and then use that instead. Alv 12:14, 8 October 2008 (UTC)

On what basis is it "plain wrong"? Routers have to have something to go on, and 130 appears on the signs as a speed which it is recommended not to exceed. To use any other number would fall under the general heading of "making stuff up". Chriscf 13:00, 8 October 2008 (UTC)
Because the maximum allowed speed just isn't 130. Just like a road built with two oneway carriageways and fast traffic is not a motorway until it is signposted as such. Alv 13:04, 8 October 2008 (UTC)
Be that as it may, it is the only posted speed on those stretches. The only consumer of maxspeed=* data is routing programs, and it's very likely to stay that way. Curious minds are not a practical use case. First and foremost, tag for practicality. Don't tag specifically for the tools, but don't tag data without a practical use. Chriscf 13:54, 8 October 2008 (UTC)
we don't map nether for the Renderer nor for the Router, we oly map reality. Reality is Germany => maxspeed=no + recommended_speed=130. If the actual Routing-Software can't handle it, it must be updated (e.g. wherer maxspeed=no use recommended_speed; if there is no recommended speed use e.g. user_maxspeed=100 --Cbm 16:37, 8 October 2008 (UTC)
You seem to have missed the part about having an actual practical use case for your proposition to tag maxspeed=no recommended_speed=130. Chriscf 12:08, 9 October 2008 (UTC)
OSM is not a use case, osm is data. :)
Er ... what are you on about? Chriscf 16:27, 9 October 2008 (UTC)
(Seem to have forgotten to type the word 'about', so 'about use cases') Entered data should not be limited to "practical use cases" when the "unpractical" data does reflect reality and can be dealt with by simple additional modelling. In this case "car speed is limited by law and by technical performance" so the cost function just needs one parameter more. Alv 18:01, 9 October 2008 (UTC)
If a specific piece of data has no practical purpose, it has no place in the OSM database. Specific vehicle performance is not a factor. The fact that a car can easily exceed 130km/h is not a useful factor in route-finding. What is your intended use for the data? Without a minimum of believable user, a credible purpose (which the "curious minds" argument is not), and a real-life example to back it up, no tag should be approved. The argument of "don't tag for the router" is futile in the case of maxspeed=*, which not only is specifically intended for routing applications, but in fact has no other use. Chriscf 09:29, 10 October 2008 (UTC)
If somebody wants to write an application that warns you when you go faster than the speed limit, then it needs to be able to distinguish between roads with no speed limit and roads with a real speed limit of 130 km/h. Any routing application on the other hand should have no problem converting maxspeed=no to a value of 130 for internal use. --Cartinus 20:55, 10 October 2008 (UTC)
Both parts of your argument are flawed. In the latter case, how do we store "no" in a numeric data type? In the former case, in the one and only country in the world which has this situation, such an application would be illegal. Chriscf 09:58, 13 October 2008 (UTC)
the no value can easily be translated to 0/NULL/-1/FALSE and therefor be understood by any program as a numerical value, or the lack there of, and that way the program can see it as no speed limit or unknown speed limit. I would rather have the string value of 'no' so that users can read the tag as no speed limit, than use the value 0 or -1 is not really human readable and can be misinterpreted, the value FALSE will indicate that the maxspeed returns a 0 but the value is set, while NULL will indicate that no value is set. A better question should rather be what units a maxspeed should be stored in, but that deserves a different headline. --Skippern 13:46, 5 December 2008 (UTC)
Maxpeed is always in Km/h and it is up to the application to ignore or parse values that contain a unit e.g. "60 mph". --MarcusWolschon 13:36, 8 December 2008 (UTC)
There are no numeric datatypes in OSM. All tag values are free form texts. On top of it, the data is user input, so you have to validate it before you can use it in any calculation. At the same point of the routing application where it translates the text "80" into the number 80, the text "30mph" into the number 48 and discards the text "east street", it can just as well translate the text "no" into anything the application designer thinks is useful. Fancy, talking speedometers are not illegal in Germany. --Cartinus 01:53, 16 October 2008 (UTC)
Repeating "use case use case integer integer" won't make Autobahns have a speed limit. Alv 11:17, 13 October 2008 (UTC)
Who said anything about giving them a speed limit? Come up with a practical and credible use for this particular flavour of information, otherwise it's recording insignificant details for the sake of it. Chriscf 13:37, 13 October 2008 (UTC)
I don't have to come up with a use case, when it's the reality. If you seek to override the guideline "map what's on the ground" you should prove your view that having a made up value pretending to be the speed limit is relevant. Entering osm data is not directly/only about making a routable highway network, but aiming for storing geographical data as it's on the ground (and doing so will result among other things to a routable map). Claiming that the limit on autobahns is 130 is claiming that the limit is there when it's not. Software and computers in general are good at manipulating data based on rules, but they can not restore lost data. Alv 15:21, 13 October 2008 (UTC)
You don't use a numeric data type if you want to have it, you use a better data structure. In the openstreetmap database and the weekly planet.osm it's not a number, it's text attribute to be interpreted (as a number). If you Chriscf want your applications to consider any unlimited autobahn as being limited to 130, you do that when you import the osm data to your format. It'd be really hard to efficiently use the original osm xml-data in an application without preprocessing it to a more indexed format, be it a database or whatever. And are you a lawyer, to say with such confidence that a system telling the driver when they are exceeding the limit is illegal? Quite contrary such systems are being researched by several organizations and car manufacturers. You have mixed that with systems warning of speed camera locations, which can but is not necessarily illegal in some countries, which might or might not include Germany. And even if it were, it wouldn't have anything to do with what is on the ground - there is no speed limit, it must be stored as such in the osm database. Alv 10:40, 13 October 2008 (UTC)
It has been made abundantly clear on Proposed features/Traffic enforcement that possession of such devices in cars is illegal in Germany, and we cannot be concerning ourselves with the legalities of using or not using certain pieces of equipment, or how far the grey area extends. Without specific legal advice to the contrary, we can't support such uses. Provide one practical and credible use for storing "maxspeed=no" instead of a more practical and useful value that doesn't require anyone that wants to interface with our data to write a bundle of exceptional cases. Chriscf 13:40, 13 October 2008 (UTC)
On that page the only statement about legality in Germany relates only to telling the driver about the positions of the speed cameras used for enforcement, not telling (just) the speed limits themselves. German Siemens is making for the German BMW's such a system that reads speed limit signs and has the data within the navigator map, presumably ready to ship if not already being sold in the latest BMW 700-series. Alv 15:21, 13 October 2008 (UTC)
What has traffic-enforcements to do with the fact, that there is NO SPEEDLIMIT on some german motorways, and we need the value Template:Maxspeed for that? i think, nothing. So what's your point? --Cbm 16:05, 13 October 2008 (UTC)
Besides the case of finding the best route there can be other interested parties: an environmental agency wants to monitor how many, if any, unlimited roads have been limited in the last years to reduce noise and pollution; a car drivers' association wants to use the same measure for assessing local attitudes towards drivers, a concerned mothers' association can compare the amount of unlimited stretches to other regions to demand that some of them be limited to "comply with the national efforts for highway safety", a home owners' association wants to study the effects of increased noise near the unlimited motorways, etc.
Either the default value for German motorways has to be "no" or the maxspeed=no must be understood in some sensible way for the use case concerned. And working with osm data there will be and are "invalid" values entered for the maxspeed tag, which any software must be able to handle; either ignore and use the default for the highway type or try to interpret the curious values (e.g. maxspeed=Marbury Park. Alv 08:38, 11 October 2008 (UTC)
In the case of the environmental agency, the information will be better available elsewhere, and we dont' support safety-critical uses. Chriscf 09:58, 13 October 2008 (UTC)
Is making a (scientific) study now safety-critical, as in it might get you killed or injured? By starting with osm data anyone can make their initial tryouts of whether or not any correlations or whatever exists and base their decisions on spending money on some more accurate data on that if they want to. Don't tell them that they can't have that data because you have a fixation on storing integers only. Alv 10:40, 13 October 2008 (UTC)
Environmental studies of the sort you suggest require guaranteed data. OSM data may be kept up-to-date, but we cannot necessarily provide a margin of error (e.g. "correct to 10m"), and we certainly cannot provide financial guarantees that are needed for such uses. The "concerned mothers' association" will have to source information from those that are able to support safety-critical uses. It's generally accepted that the existence of crap is not an excuse to introduce more. Your other examples fall under the heading of "curious minds". Chriscf 13:37, 13 October 2008 (UTC)
You didn't read my comment in full. Once they've tested their hypothesis on the free osm data, they can evaluate for themselves whether it seems likely that the guaranteed-to-be-correct data would support it, too, likely enough to justify spending the money to get the data or whether it's pretty clear that it would be waste of money. I have never claimed that osm would be providing financial guarantees, I really don't know how you come to say anything about that. Isn't "technical restrictions - - in creative, productive, or unexpected ways" (quote Main_Page) exactly about creating possibilities for curious minds, too? What specifically are you claiming to be crap? Alv 15:21, 13 October 2008 (UTC)
For any supported transportation mode (pedestrian, bicycle, moped, hgv, motorcar, sports car, Citroën 2cv, canoe, speedboat, snowmobile, ambulance, ...) the routing software must know some maximum speed that the vehicle can reach, just like it must know (or guess) the height of the vehicle. Software can't blindly use a tagged maxspeed=200 (if such a way existed) for the cost function if the user just can't go that fast. Even maxspeed=120 is too fast for hgvs (truck modes already exist in some commercial navigators).
An advanced router could (won't happen in years, I presume, but could), take more of the vehicles and drivers properties into account: whether its fast around corners or needs to slow down considerably, does the driver like a steady speed on a big road or is it ok to use the back roads where the driver needs to look out for more things, is climbing a steep hill a hindrance, does it take 8 or 40 seconds 0 to 100 etc. If the defaults don't reflect the reality, a road with unlimited speed is indistinguishable from some other road with a 130 limit. Alv 15:46, 9 October 2008 (UTC)
In practice, a road with unlimited speed is indistinguishable from some other road with a 130 limit. The speed of a specific vehicle is not relevant to cost calculations, though is useful for time estimates (estimates are allowed to be wrong). A HGV might be hard-limited to 90km/h, but fast dual carriageways are still better places to send them than another road with a 90km/h limit. Ultimately, in practice, a high-quality dual carriageway with no limit is in fact indistinguishable from a high-quality dual carriageway with a 130km/h speed limit, mainly because it's going to have very little impact on travel time. You are not going to have a real scenario wherein someone manages to lose time because the alternative detour which adds 50km avoids a 110km/h or 130km/h speed limit. Chriscf 16:27, 9 October 2008 (UTC)
In practice, a road with unlimited speed IS NOT indistinguishable from some other road with a 130 limit. A road with unlimited speed you are allowed to drive faster. Where a distinct limit of 130km/h you are not. OSM catches data. And setting any speed at random don't make it correct. --Cbm 17:01, 11 October 2008 (UTC)
Your inability to process facts astounds me. The two are indistinguishable - this is indisputable fact. Stand at the side of one if you don't believe me. The only difference is of no consequence to us - namely that those drivers proceeding at 160km/h are driving illegally in one case. Chriscf 09:58, 13 October 2008 (UTC)
Then likewise a high-quality dual carriageway with a 120 limit is indistinguishable from a high-quality dual carriageway with a 80 limit. Should I then demand we purge all maxspeed values of over 80 and set them at 80? They're indistinguishable, only the sign is different. The only difference is of no consequence to us - namely that those drivers proceeding at 120km/h are driving illegally in one case. Alv 10:40, 13 October 2008 (UTC)
You will notice a general slowing of the traffic between 80 and 120. Above 120, the same is not the case as you begin to hit the limits of the abilities of both car and driver. Chriscf 13:37, 13 October 2008 (UTC)
So now (you say) the properties and abilities of the car do matter? You contradict yourself. Alv 15:21, 13 October 2008 (UTC)
IMO the speed of a specific vehicle is relevant: my summer car has a top speed of 110 on level ground and it definitely is great to know that taking a shorter primary is faster than driving the same speed on a somewhat longer route through another town, where I could use a motorway for half the journey. For hgvs the dual carriageway road is better only because if both roads were thought of as being 90 km/h, on that other one the "perfect" cost function would accumulate more penalties for narrower lanes, intersections, time and fuel lost accelerating after any queues, turns and such. It ought to be quite possible to find longer (>500 km) trips for which the alternative routes have a less than 10 km difference in lengths (say, Köln to München) but where the other could have much longer unrestricted sections. For me the motivation to this discussion is more about keeping the fact of "no legal limit so choose what you can". Since there's not yet a (widely or at all) accepted scheme for tagging or implying what can be expected to be the real average travel speed, I think all relevant opinions have been stated.
1. No legal limit.
2. Recommended speed is 130 and for most, but no all, motorcar users the "cost function speed" is quite close to that. Alv 18:01, 9 October 2008 (UTC)
It is a verifiable fact that the building I work in has exactly four south-facing windows. This particular fact will be of use to exactly zero people. It might help those that are looking for our company, if somehow they miss the metre-high lettering between the windows. The title of this page explicitly states that it documents tags for routing. These tags must therefore be readable by a routing engine. If you want people to be able to use our data on their devices, this has to be predictable. If OSM is to be a viable alternative to commercial sources, effectively turning around and saying "you have to have performance data for your specific vehicle" is akin to shooting off both your feet with a nuclear missile. Chriscf 09:29, 10 October 2008 (UTC)
Maybe you should read the start of OSM tags for routing (the parent of the page this discussion is about). It clearly states it is about tags you can use for routing. Not about tags that are created for the sole purpose of routing. As I demonstrated with the example above, maxspeed=* is usable for more than routing. --Cartinus 21:04, 10 October 2008 (UTC)

Back towards a possible usable solution for max and avg speeds. I propose to define no maxspeed for the motorways in Germany: just do not add a tag maxspeed on stretches where no hard maxspeed applies. Routing software needs to become aware of which maxspeeds apply in the country it's traveling and use default average speeds which can be overruled by new (yet to be defined?) average speed tagging and the existing maxspeed tag. This average speed tag system can also be used for other types of transport and road types and allows the navigation software to calculate trip times roughly and also signal the driver when driving faster then the legal limit. This proposal also allows for all the differences between countries and even road conditions, it requires no mapping which is already obvious (based on location). Lastly, it isn't difficult to implement in software (based on my knowledge of the Gosmore routing engine). --Lambertus 10:17, 11 February 2009 (UTC)

## Practical as opposed to Legal maximum

Is there anything to be gained from having a "maxspeed:legal = " tag and a "maxspeed:practical = " tag. Particularly on unclassified roads I have noted a number of instances where the legal maximum speed could not really be achieved due to the condition of the road. (either too narrow, too winding, or too pot-holed). This has led to routing programs not to choose the most desirable route, which someone more familiar with the conditions on the ground would have chosen. I do accept that maxspeed:practical would be a very subjective measure, every OSMer might have a different view as to what was possible on a stretch of road. Dmgroom 12:52, 8 October 2008 (UTC)

I like it, the word practical was the one I was waiting for. But I think it's more or only usable in the countryside in that form, though: in urban areas the traffic is what's limiting the speeds. Expanding that idea we'd then end up with maxspeed:practical:rushhour=10, maxspeed:practical=40, maxspeed:practical:nighttime=55. That could be fun to enter for a while but even more subjective and ambiguous (when does rush hour start or end etc. Just last summer in Spain I chose a mountain road, on which the comfortable speed was apparently about half of the value my GPS used for estimating the travel time. Alv 20:34, 8 October 2008 (UTC)
I think tagging rural roads with values such as maxspeed:practical=64 could be very useful. Also, the tag could be useful for residential areas with extreme traffic calming, e.g. some parts of Wandsworth, London, where the humps are considerably above regulation height, and anything over 25kph over each hump risks damage on most cars. (I would probably tag maxspeed:practical=32 as this is probably about the highest sensible average speed). Yes, it is subjective, but it is more useful than just the legal limit. I would use this only for the physical characteristics of the road. I think information regarding traffic should be stored separately. Perhaps in form of traffic delay at various times in a look-up table? Daveemtb 15:21, 20 May 2009 (UTC)
Some places operates with adviced speed limits, with signs looking very much like the maxspeed signs, only that the border is black instead of red. I have seen signposts with maxpeed of 80 but adviced speed of 30. That could be tagged maxspeed=80 with advicedspeed=30. --Skippern 16:09, 20 May 2009 (UTC)

## Austrian limits

I was wondering how the Austrian limits have been found. At least those areas I know a maxspeed=40 on residentials is quite seldom seen, it is either 50 or 30km/h. But I don't think the average would be the best decision for that case. I did not find the author of the Austrian part in the wiki history, so maybe someone will read the discussion page. -- BearT 17:40, 13 October 2008 (UTC)

## Reverts

Could you please discuss about the issue before reverting over and over again? Right now it looks more like a game of "who gives up first loses". --Eimai 12:14, 20 October 2008 (UTC)

See #Numbers above, and the section heading that makes it clear the values should be "computer readable". End of story. Chriscf 12:25, 20 October 2008 (UTC)
As I wrote in the comment: "these comments are only for better understanding the values and totally compatible with the preamble..." and your mentioned #Numbers-Section, becasue as you see: There are only numers in the tables. --Cbm 14:18, 20 October 2008 (UTC)
Unfortunately, the edit summary you used is inaccurate. Your additions directly contradict the table, which is intended to contain usable values for maxspeed=*. Chriscf 11:27, 21 October 2008 (UTC)
Others already seem to have agreed that we can have the inaccurate but "usable" numbers in the table; having the footnotes for a more advanced processing must then contradict the table or otherwise they wouldn't be needed at all. Alv 12:30, 21 October 2008 (UTC)
The footnotes are for humans. The phrases "walking pace" and "no speed limit" are human-readable. Proposing tags in the footnotes that contradict the table is a no-no. Chriscf 14:10, 21 October 2008 (UTC)
I don't want to get into this discussion too much, but personally I think the terms "walk" and "unlimited" can be in the table. I think a user should be able to set their preferred speed for these himself (so the router knows that user X wants to go at 180 km/h when he can, so it could make use of that when deciding some routes). --Eimai 16:17, 21 October 2008 (UTC)

## Beyond tables

In different countries there are various criteria that affect other road users' (default) maximum allowed speeds; a hgv is usually limited to 80 but otherwise like a motorcar; in some countries they might have to slow down to 60 even when others are driving 70 or 80. Anyone could add below, what's not yet included. Later a rule set for processing could be at least speculated.

Possible criteria for legal limits include (some applicable even when there is a posted speed limit):

• (obvious) vehicle type: motorcar, motorcycle, hgv, goods, psv, bicycle, ...
• vehicle weight
• the road being inside or outside a "built up area", defined by signs or street lightning
• number of lanes in the traversed direction
• single/dual carriage way
• trailer
• with or without brakes
• weight
• normal (has register plates) or "independent machinery"
• local time
• width of the berm

After the legal limit is known, possible criteria for calculating lower, practical maximum speeds include:

• the vehicles maximum attainable speed
• the drivers comfortable maximum speed
• surprisingly or excessively tight turns

Possible criteria for realistic median speeds include:

• the country
• the limit
• number of lanes in the traversed direction
• inside a built up area?
• local time (rush hour)
• crossings (in relation to nearby footway and applicable landuse density)
• traffic lights

The last list is probably best left for any project wanting to make such estimates.

## Relations!

Max-speed should be given in nation or state relations, and that way be a default value for the entire nation or state. The routing software need to have all such relations loaded for several reasons, so that is the best place to give that kind of information. --Skippern 16:31, 3 December 2008 (UTC)

I think this can be separate from the OSM data, basically as a table somewhere, used by a library that routers and other software can make use of to translate highway tags to speed limits (and other rules). --Eimai 17:09, 3 December 2008 (UTC)
Even better, an libosm with default national values or default values inside position polygons, that way we can enforce the library to actually have national-legal values without being in danger of too much tempering from edit-eager osm-newbies. But as long as they are to be stored inside OSM, relations is the best way. --Skippern 18:20, 3 December 2008 (UTC)

## Sense?

Now that this page has grown so big, will you begin to realize that this won't work? --Lulu-Ann 15:15, 11 March 2009 (UTC)

what does not work? This page is a collection of country-specific maxspeeds. So I can't see what's getting wrong --Cbm 21:02, 11 March 2009 (UTC)
Does not work? It looks like a fine data-collection. Building a single table of maxspeeds for all major countries to be incorporated into at least my navi looks possible. I should start to evaluate the completeness and consistency of our country-boundaries again to see if we are at a point where I can start implementing this. --MarcusWolschon 07:22, 12 March 2009 (UTC)
Why don't we stop this discussion and leave the responsibility where it belongs: The driver shall be able to set maxspeeds for
1. His vehicle
2. Motorways (National motorway limit if no maxspeed is given) (Set equal to vehicle maxspeed in Germany)
4. Residential and service (National limit if no other is given).

And: The driver can choose if these values shall be used for estimated time of arrival only or if they shall be shown as speed limit, too.

This presets need to be changed only if you cross a border, and then you can switch in your routing software between profiles. Lulu-Ann

Well, I cross national borders about 3 times a day while driving and I have never seen any navigation-program that requires you to enter basic traffic rules. You may sometimes customizes average speeds used for the metrics but never fixed national speedlimits. Not even when we where crossing 5 european countries in 2 days while camping. --MarcusWolschon 12:32, 24 March 2009 (UTC)
Sure. Non OSM navigation programs either have a maxspeed tag on each way, or none at all, or they make sure to have the borders of one country completely in the memory. The problem with OSM is, if you are crossing a bordern and only have some districts of a state loaded, you will not be able to figure out if you are in the borders or outside, even if you collect the national regulations here for the whole world.
Your point being? An application that wants to use this list has of cause to have a way of knowing the country to use for lookup. There are multiple ways to do that and it does not have any effect on the "sense" of collecting this list in the first place. --MarcusWolschon 09:02, 25 March 2009 (UTC)
Fine, tell me only one way that is working. Lulu-Ann

## UK Issues

There's a number of issues with the UK, mainly relating to the regulation that roads with regular street lights (bar motorways) have by default a max speed of 30mph. OSM data currently doesn't capture this well, and we could end up with numerous roads assumed to have a maxspeed of twice the real value.

There are a few ways to fix this:

I also would prefer lit=yes because maxspeed=* should be keep for explicit maxsppeds on the ways only. --Cbm 12:04, 22 March 2009 (UTC)

The problem will be getting people to tag them as such. Myself I'd prefer people mark roads as lit=yes and we then assume they have a default maxspeed of 30.

I'd also like to bring up the national speed sign. I think when you come across a lit road with such a sign it should be marked as maxspeed=national in-case the Government changes it. Unlit roads can be left, as this is the default speed limit anyway.--Pobice 18:38, 21 March 2009 (UTC)

is there no other indication than this sign? I would prefer to to these road the same ways e.g. the motor-roads in Germany ( any road-type could be a motor-road where only fast motor_vehicles (>60km/h) are allowed). There does also only an sign imply lots of restriction. These roads we tag motor_road=yes. An equivalent way we should find for these UK-national-roads und dont misuse the maxspeed-Tag for this. --Cbm 12:04, 22 March 2009 (UTC)
What's the exact meaning of that sign anyway in the UK? Perhaps I'm getting confused because we have such a sign in Belgium as well and its meaning is pretty clear: all prohibitions are lifted to all moving vehicles passing that sign. So if you had a sign "50km/h" that restriction is now lifted and you now have the default maximum speed for the type of road you're on. It also lifts up restrictions like not being allowed to overtake, or the prohibition to use cruise control. So it's pretty clear that the part behind this sign shouldn't have a maxspeed tag for example. So what exactly is the difference with the meaning of the sign in the UK? --Eimai 14:03, 22 March 2009 (UTC)
It's simply a road speed indicator. In some areas it simply means the default speed limit applies. On lit roads it indicates a higher speed limit. This page has good summary http://www.abd.org.uk/know_your_speed_limits.htm
national=yes could be another alternative but as its just to do with speed this seems messy.--Pobice 18:01, 22 March 2009 (UTC)
The meaning of that sign in the UK looks ugly to me :-) But also a tag like maxspeed=national. But I understand that maxspeed=default won't work here because the default on a lit road would be 30mph and this signs makes it higher... I'm not sure, here we have the built-up areas marked with specific signs, and I have the impression the national speed limit sign is trying to mimic that a bit, so maybe we should look into a similar solution to handle built-up areas (there's no solution as of yet) and the national speed limit sign... --Eimai 18:27, 22 March 2009 (UTC)
You may just document this lit=yes -rule here but I strongly suggest not to misuse the maxspeed-tag. If you can tag a road with a useless maxspeed=national you could as well already have tagged it as lit=yes and conveyed much more information. If the default-speed is different depending not only on highway but also on lit, then so be it. --MarcusWolschon 07:22, 23 March 2009 (UTC)

## First implementation in a navigation-application

I have started to implement these national default-maxspeed in Traveling Salesman. You can find the forum-thread on the topic here. Actually determining if one is inside a city is not yet implemented (I know a few ways to do this) but property-files with national defaults and a way to override the default-rules with country-specific special cases (like the german motorroad, the british lit=yes or US state-specific limits) are implemented. I am currently optimizing the code that determines in what country a road is. --MarcusWolschon 07:44, 26 March 2009 (UTC)

## Inside / outside built-up area

It's not clear to me how something is inside/outside the built-up area. As far as I know, it's inside / outside the built-up area that is important for the speed limit. This text and others seems to indicate that an area of place= means it's the built-up area. But a place is larger than the built-up area. At least in Belgium, everything is considered to be part of some city/municipalities. --Kurt Roeckx 22:04, 25 April 2009 (UTC)

What an area of place= actually means is not really strictly defined. On the other hand municipalities are mapped with boundary=administrative/admin_level=* and not with place=*. --Cartinus 14:07, 26 April 2009 (UTC)
if I remember right we habe the municipal-border of a city and the build-up area border in belgium. the municipal-border ist boundary=administrative, the built-up area is place=* --Cbm 14:09, 26 April 2009 (UTC)
There's nothing defined in Belgium to mark built-up areas, and I think it shouldn't be defined with polygons either. It's just marked with traffic signs along the road, so it makes sense to mark those points with nodes on the roads. --Eimai 14:30, 26 April 2009 (UTC)
Using nodes on roads is extremely error-prone. If a single node is missing, the area will "leak" and (depending on where you start) the whole world or nothing will be inside the built-up area. --Tordanik 15:28, 26 April 2009 (UTC)
I agree. Nodes are good for rendering the sign and that's it. There ARE lots of roads without a city-sign where you can leave/enter the city. Unless we have something better I can only support the place=* and admin-boundary -polygons in my software. As we have nothing better it is used for build-up-area, administrative boundary and postal-address for the time being. --MarcusWolschon 07:18, 27 April 2009 (UTC)
No there aren't. The placement of these signs is very important to know for example what the default maximum speed signs are. If you manage to enter a built-up area without seeing a sign you could do 90 km/h instead of 50. And there are other traffic rules depending on whether you're inside or outside a built-up area. If you can leave or enter such an area without a sign, it's a mistake by the authority that's managing the road and should be reported (and the traffic law specifically says that all roads leading into and out the built-up area have to have signs). --Eimai 11:21, 27 April 2009 (UTC)
I suggest you read up on your local traffic regulations. A build-up area starts and ends also where it is obvious that it does (to the human driver). There is no guarantee that there is a sign posted on every dirt-road that can be driven on that leaves the village/town/city. So, please provide a stable and robust algorithm in at most polynomial time to prove that your tagging-idea can be evaluated even in case of human error. --MarcusWolschon 13:35, 27 April 2009 (UTC)
In some countries it might be so, but in others the area starts and ends only where such signs are posted. Alv 14:11, 27 April 2009 (UTC)
I'm not familiar with your local traffic code, but over here it's in the definition of the signs marking the built-up areas: traffic sign F1 ([1]) has definition: "Start of built-up area: this traffic sign is placed on the right of each access road to a built-up area; it can be repeated on the left" (emphasis mine) (that's article 71.2 of Belgian traffic law). There's a similar definition for marking the end of a built-up area (sign F3). If we then dig into the technical regulations concerning placement of traffic signs, we get to article 12.1 that says how to place signs F1 and F3: "2. These traffic signs are placed at the same time on all entry and exit roads of a built-up area, more or less at the location where the public road gets or loses the appearance of a street". So that's strictly defined that all roads on the boundaries have to have signs, and luckily it is so strict. Houses next to a road is not sufficient for it to be a built-up area (especially in a country like Belgium with a lot of ribbon development), so your only clue is these signs. --Eimai 14:20, 27 April 2009 (UTC)
There is basically the same problem with zone's with a speed limit. You have signs marking the start and the end of the zone. And if you go and read the Belgian traffic code, you see that such F1/F3 signs also have an effect on zone restrictions. The zone restriction should be repeated once you leave the built-up area or an other speed restriction zone, but I know places that don't do that. So you basically can have a different speed restriction depending how you got there. But I don't think it's important to get that right, and we probably want to have the intentions on the map instead.--Kurt Roeckx 17:02, 27 April 2009 (UTC)
That is a nice thing for Belgium. So a) What about the rest of the world? b) What if some such signes are not mapped or have a typo? c) what is your proposed algorithm to evaluate these signs when tagged in the map "input=a wayID" "output=reference to the city it is a part of or null"? --MarcusWolschon 06:30, 28 April 2009 (UTC)
And if you use a polygon: What if someone uses a broken polygon to mark the area? What if people start tagging these polygons also with landuse=residential/layer=-1, because that renders so pretty? The solution to both the broken network and the broken polygon and any other broken data are all the same. You use some tool to display broken data, so you can fix it. It was amazing to see how many broken natural=water polygons there were when the Geofabrik Tools were launched and how quick they got fixed when they became so visible. --Cartinus 12:49, 28 April 2009 (UTC)
I think a solution based on some area/polygon is probably the best way to start for now. And if there are many problems with it, we could start looking for a different solution. But I'm not sure that area needs to have a place= tag. And administrative boundaries do not look like a solution either. So what I'm basicly looking for is a way to tag zone restriction, including things like max speed and max weight. And it should work for more than just the built-up area. But it would probably also be nice to tag that it's the built-up area since other traffic regulations change when you're inside the built-up area, and you could assign some default speed limit to the built-up area so that you don't have to tag it.--Kurt Roeckx 11:46, 28 April 2009 (UTC)
I've done a few zonal restrictions in Antwerp with relations, see Antwerpen/Zones. For a built-up area I'd say a relation with tags like "type=access", "zone=built-up area". Don't tag them with maxspeed (except when there's a speed sign above the F1 sign, because then that maxspeed applies to the entire built-up area -- but I've never seen that in practice yet), as the restrictions should follow from the road properties. --Eimai 13:50, 28 April 2009 (UTC)
What's the advantage of using a relation compared to using a tag on every single way? I'd consider using relations for basic information dangerous, as it reduces newbie-friendliness. --Tordanik 16:31, 28 April 2009 (UTC)
If at every introduction of a new kind of relation the response is "oh no, newbies cannot handle it", then newbies will never get familiar with relations since they'll stay something "advanced looking" rather than some basic structure (which they really are, if you don't know what relations are you're not ready to edit in OSM yet), so that's an invalid point.
Relations have the obvious benefit over tags on each way that they can contain more information, that doesn't have to get duplicated on each way. --Eimai 17:25, 28 April 2009 (UTC)
(a) I'm not familiar with traffic laws in other countries. The only other country where I've consciously looked at the signs is the Netherland and it looks pretty strictly defined over there as well. And for other countries, please tell me how it's there. There should be a way to tell whether you're in a built-up area or not, right, or how else would you know the traffic rules? So what other criteria are there (and wouldn't it then make sense to tag those criteria then)?
Germany: On major roads there is a sign but if there is no sign you are to infer that you have left the build-up area when it no longer apears to be one (e.g. a track or minor road leading out of the city and through the fields). --MarcusWolschon 06:44, 29 April 2009 (UTC)
(b) What do you mean typo? The exact text on the sign can vary anyway in real life (the signs don't even need a place name like [2]), so you don't need to try to make algorithms based on the text.
I ment a typo or other mistake made by the mapper. Mistyping the name of the tag, adding it to a node next to the way instead of on the way, only tagging one lane of a dual-carriageway, ...simple mistakes that jsut happen but should never make a large city of a few million people either spill out across earth or be considered not build-up. --MarcusWolschon 06:44, 29 April 2009 (UTC)
(c) And I understand the method of knowing if you're inside or outside a built-up area is harder than just a point in polygon problem, and if we do something with tagging nodes at the entry points, it will need some preprocessing -- and I'm also pretty sure now that some directionality is needed. The algorithm isn't too hard to make though, just grow your network until you've come across a boundary. The preprocessing phase has to take care of missing entry points, which is the hardest problem of course. But I'm leaning more towards relations for solving this anyway. But polygons just don't do it for me as you're giving the zonal restrictions a property they don't have (a piece of land wherein all roads have the restriction). --Eimai 13:50, 28 April 2009 (UTC)
If it's not so hard at all. Please specify the algorithm. I have given this quite extended thought but could not come up with something that is robust to minor errors. Relations have a big flaw. Cities can be huge and c1) if a user draws a new street somewhere inside a major city and forget to add it to that relation it is defined as being outside. b) relations have a practical limit on the member-count. Adding all streets of NY into one relation would just be too much. Please consider this in making your proposed feature. --MarcusWolschon 06:44, 29 April 2009 (UTC)
This is getting a bit too long for a wiki-page. What about taking this discussion to the forum?
And with polygons we don't know if the locations where the roads enter the area are correct or just interpolated somehow (and could be wrong). And it gets worse when for example a bridge or a tunnel with a road not part of the built-up area goes across one. How do you solve that with polygons? --Eimai 16:26, 26 April 2009 (UTC)
The "correct vs. interpolated"-problem is easily solvable by either not adding interpolated nodes to the polygon or marking those with appropriate notes. Bridges or tunnels require additional tagging if they are in the polygon, but not affected by it, something like is_in_built_up_area=no (just made that one up).
But how would you solve the leakage problem with nodes? Also, would it be possible to decide which side of the node is inside and which is outside the built-up area despite nodes lacking a direction? --Tordanik 16:38, 26 April 2009 (UTC)
Basically we want the same, but I just want an "imaginary" polygon (or rather a network with nodes marking the bounds of a subset of that network): mark the places where the traffic signs are placed, it's easy enough to collect all roads between those points (except it's not a point in polygon problem, but a "point in network" problem). But it needs some processing to fix up those leakages (which are basically done the same as with polygons, except it needs the roads to be connected to roads inside the area).
And I'm not entirely sure if we really need to define directionality to the nodes at the boundaries, I can certainly think of some awkward road configurations and don't know if it's really as easy as just saying: guess the latter one if you have to decide between the entire planet or a smaller set of roads (especially if the data isn't connected to many other roads).
I know a few villages where the area left and right of the road is part of the build-up-area but not the major street crossing through (city-sign at every intersection). --MarcusWolschon 07:18, 27 April 2009 (UTC)
btw, I've already been toying with the idea of using relations to tag one built-up area. That would really solve all ambiguity, but has the problem that one has to be very careful to tag all roads inside it (imagine all roads of entire cities inside one relation...).
And polygons have the problem that they take the word "built-up area" too literally and say it's an "area", while it's actually just a road property, just like maxspeed=50 or maxweight=3.5 is, except that it's a zonal property, so not every road is signed.
But given that there's no real satisfactory solution, for now just add a node where you see the traffic sign marking the boundary. --Eimai 18:31, 26 April 2009 (UTC)
And how would you mark such a node? ..except by making it a part of the polygon. ;) --MarcusWolschon 07:18, 27 April 2009 (UTC)
I'm just putting a node there with a note "entering built-up area", it can be improved later, but for now we're tagging the places at least in some way. --Eimai 11:21, 27 April 2009 (UTC)
Well. There you are. This is "Interpretation of OSM-Tags currently in general use for routing purposes". You don't even have a tag, let alone one that is in general use so it has no relevance to this page. Please take proposals for new tags to the Map_Features -pages. --MarcusWolschon 06:37, 28 April 2009 (UTC)

## Bicycle limits in Germany

I've now seen many claims that cyclists driving on a road don't have a speed limit; yet the Stvo 3 § that I found said that the default limits (80/50) apply to all vehicles - surely a bicycle is a vehicle or what am I missing? Alv 11:38, 20 May 2009 (UTC)

From what I see you are right. The only difference it that a cyclist needs to guess his/her speed so to be a violation it needs to be obvious to the naked eye. --MarcusWolschon 12:15, 20 May 2009 (UTC)
Maybe I'm missing something, but the only part of §3 referring to all "Fahrzeuge" (vehicles) is 1, which doesn't state a general maxspeed except for foggy/rainy weather. The ones that do state maxspeeds of 50 and 80 km/h refer to "Kraftfahrzeuge" (motor vehicles) - assuming the online version of the law is correct. --Tordanik 12:25, 20 May 2009 (UTC)
I must be blind - I was certain I didn't see that word yesterday nor last week... Further on, the signposted speed limits (Zeichen 274) don't mention Kraftfahrzeuge. The first part of §3 also limits all vehicle speed to "able to stop on the visible section" ("innerhalb der übersehbaren Strecke halten kann"); calculating this for some places on cycleways will most likely prove to be near impossible but could be beneficial. Has anyone read why the default limits in Germany have been been limited to motorized vehicles and not vehicles? It's not like that in some, or many, other countries. Alv 14:56, 20 May 2009 (UTC)
Maxspeed-Restrictions set bei signs (Zeichen 274) should be tagged with maxspeedd, because it's for all vehiclegroups. But implicit restrictions should only be set for the specific vehicletype. best way imho is to set is via trafficzone (as placeholder for a set of restrictions) --Cbm 17:17, 20 May 2009 (UTC)

In Germany there is a new limit for Sign 239 "Gehweg": "Andere Verkehrsteilnehmer dürfen den Gehweg (§ 25 Absatz 1 Satz 1) nur benutzen, soweit dies durch Zusatzzeichen angezeigt ist. Fahrzeugführer müssen in diesem Fall auf Fußgänger Rücksicht nehmen und die Geschwindigkeit an den Fußgängerverkehr anpassen. Fußgänger dürfen weder gefährdet noch behindert werden. Wenn nötig, müssen Fahrzeugführer warten." That is why I changed maxspeed=walk to maxspeed="moderate"--KartoGrapHiti 10:09, 9 September 2009 (UTC)

So as this page is about giving usable interpretations of existing tags for existing routing-applications. Where is your definition of what speed "moderate" is? Metrics work with numbers. They cannot build a sum of words and compare that with other such sums to find the path of minimal cost. --MarcusWolschon 11:54, 10 September 2009 (UTC)

## zone:traffic

I re-added the warning that zone:traffic=* is still in status draft. This is not the place for discussing future tags or for proposals but for a coherent set of rules for interpretation of what is in general use now. --MarcusWolschon 05:41, 28 May 2009 (UTC)

## Whole idea does not work any more because of unapproved change on highway-tag.

There was a change on the highway key wiki page, that interferes with the concept presented here.

User Dieterdreist has changed the description so the highway tag is no longer used for the objective physical description but for a subjective feeling of "importance". Millions of highway tags would need to be reviewed if this change without proposal and approval would become valid.

Two important aspect of routing, the estimation of time to arrival and finding the fastest route, will fail if the highway tag does not stick to physical facts.

Several other established or proposed tags like maxspeed defaults are negatively affected by changing the highway concept of tagging.

New OSM contributors learn bad practice from the start when the first tag they learn is switched from hard facts so unsure estimation.

Probably new users have already done large damage to the map by mapping or changing highway tags from the facts to the feeling schema, resulting in worse quality of calculated routes.

IMHO this is a new dimension of vandalism. I don't think that this is done by concurring commercial map providers, but this subtile method of weakening the OSM tagging schema and therefor lowering the quality of OSM data would be a really cool attack against OSM, because it is not possible to search for and revert such changes systematically.

I think that we, the community, should not accept such severe changes made to extremely used and highly established without the proposal + approval workflow.

I ask you to support the reverting of the unapproved changes in the wiki and in the mailing lists.

--Lulu-Ann 10:19, 26 August 2009 (UTC)

## DE:place

What is the difference between DE:urban und DE:place? --chris66 15:38, 27 August 2009 (UTC)

ther isn't any. DE:place evolute to DE:urban, and maybe it isn't change allways ;) --Cbm 22:56, 28 August 2009 (UTC)
ok, I corrected the table

## Belarus highway=living street - 20 km/h

Belarus ... Inside a city-area: ...

```   * highway=living street - 20 km/h
```

Are you sure about this? If living-street used for the same purpose as in e.g. Germany? --MarcusWolschon 11:15, 16 October 2009 (UTC)

## No Speed Limit on non-Autobahn highways in Germany

There is an error in the table for Germany. It states that maxspeed=no if highway=* + motorroad=yes + oneway=yes (means directions are seperated/segregated) + lanes=2+

This is incorrect. Outside the city limits, there is no speed limit if the directions are separated OR if there are two lanes in each direction (or if the highway is designated as an Autobahn). See StVO §3(3)2.c:

"Diese Geschwindigkeitsbeschränkung [100 km/h außerhalb geschlossener Ortschaften] gilt nicht auf Autobahnen (Zeichen 330.1) sowie auf anderen Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind. Sie gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben." --Geostationary 18:19, 6 January 2010 (UTC)

## source:maxspeed for Serbia needed

I guess there are no default speed-limit's for the Serbian country (RS) at the OSM-Project. Who can make this happen?

Here are the needed information:

Outside a city-area:

• motorway - highway=motorway - 120 km/h
• express ways - highway=trunk - 100 km/h
• default - highway=primary, highway=secondary, highway=tertiary 80 km/h

Inside a city-area:

• default: 50 km/h

My Suggestions:

• source:maxspeed=RS:urban as maxspeed=50
• source:maxspeed=RS:rural as maxspeed=80
• source:maxspeed=RS:motorway as maxspeed=120