Talk:Key:maxspeed

backward direction maxspeed

• what about speed limits that differ for driving directions, despite there being no separating isle ? for example, a direction leading towards intersection has a decreasing speed limit 90-70-50, but the direction leading away from the intersection (same road) has no rerstrictions.

one solution could be something like maxspeed_oneway=yes/maxspeed_oneway=-1, similar to what oneway=* does, but is that sensible ? --Richlv 10:41, 9 September 2008 (UTC)

In my experience such situations are quite common - not only rare exceptions. A solution for this problem is necessary to adequately record speed limits! --Infobaer 17:49, 26 May 2009 (UTC)

For me, this sounds like the same problem that traffic signs have. Tagging an intersection with e.g. highway=stop doesn't work because it isn't valid for all directions; the same applies for unidirectional speed limits. A possible solution would be to use 1 and -1 as hints to the direction (like with oneway=-1), following the pattern of the proposed uri/url/wikipedia keys (e.g. wikipedia:en; wikipedia:de). This would result in maxspeed:1=50, maxspeed:-1=30. -- MapFlea 09:51, 27 November 2008 (UTC)

• What to do if the same physical way has multiple speed limits depending on direction?

• Tag the minimum speed as maxspeed=*
• Tag the upper speed limit as maxspeed:forward=* or maxspeed:backward=* depending on the direction of the way.

I'm trying to use maxspeed to put in speed limits for roads in my local area.
One of the roads has a speed limit of 55mph if you are northbound, but 50mph if you are southbound.
Another road has a speed limit of 70mph in the daytime, but 65mph at nighttime. —Preceding unsigned comment added by SwaJime (talk • contribs) 23:26, 5. Dec. 2008

As this old discussion seems so get resurrected from time to time: The proposal Conditions for access tags recommends maxspeed:forward=* and maxspeed:backward=* for directions (depends on way direction) and maxspeed:night=* for nighttime (normal maxspeed=* for day). --Tordanik 18:08, 26 May 2009 (UTC)

I think maxspeed_opposite=value is better, since "_opposite" is already known for bicycle tracks in opposite direction. --Lulu-Ann 18:37, 27 July 2009 (UTC)

"_" is used as a replacement for a space in OSM, which is not appropriate here (this is not a space within a single expression, this is a syntactic separator with the part before and after the separator being separate entities). "opposite" alone isn't enough, either, because we'd need a replacement for "forward", too. ("forward"-"backward" being a matching pair, "forward"-"opposite" not so much). --Tordanik 07:43, 28 July 2009 (UTC)

Resolved: documented at [[1]] Mateusz Konieczny (talk) 09:16, 18 November 2020 (UTC)

Special cases

• If there is no speed limit, like on some German motorways, please use maxspeed=none. --Lulu-Ann 08:51, 23 July 2008 (UTC)

Also read: Proposed_features/maxspeed_none --Cbm 07:57, 3 October 2008 (UTC)

• If there are automatic traffic signals with speed limitations, please use maxspeed=signals. --Lulu-Ann 08:51, 23 July 2008 (UTC)

• • How should I specify the default speed for an electronic sign (i.e., it always shows 90 km/h, but can change in emergencies)? --Brainwad 14:38, 26 December 2009 (UTC)
    • I've used maxspeed:variable:min=* and maxspeed:variable:max=* just to record what the signs could read sometimes and plain maxspeed=* for the "almost always" value; depending on contruction the set of available numbers might be limited to two or three values. That's naturally not "in map features", but should be sufficiently descriptive if anyone comes up with a use case. Here's an example way from a local motorway: [2] Alv 12:40, 27 December 2009 (UTC)

• If there is no specific numeric maxspeed given e.g. in pedestrians precincts in Germany or Austria, please use maxspeed=walk --Cbm 07:57, 3 October 2008 (UTC)

Also read: Proposed_features/maxspeed_walk --Cbm 07:57, 3 October 2008 (UTC)

• what about speedlimits that differ for different types of transport ? for example, cars get speedlimit 90, trucks - 70. --Richlv 16:27, 1 September 2008 (UTC)

{maxspeed=90 + maxspeed:hgv=70 --Skippern 06:33, 23 August 2009 (UTC)

I've started using maxspeed=90 + maxspeed:truck=55 in Oregon, USA -- IamPersistent 01:08, 23 October 2009 (UTC)

Resolved: now this cases are documented at the page Mateusz Konieczny (talk) 09:17, 18 November 2020 (UTC)

units

I still think that the editors should calculate mph to km/h and not the users, and that we shall not have units in the values and that we shall stick to SI units. If you want to use mph, go ask the JOSM, Potlatch and Mercaartor programmers to give that as a feature. --Lulu-Ann 17:01, 27 October 2008 (UTC)

The Highway Code specifies converted values for UK purposes. As the Highway Code is considered a definitive indication of the law, the values presented there should be used for roads in Great Britain (unsure if this also applies to Northern Ireland). Eagle-eyed observers will notice that these values are always rounded down. Chriscf 17:03, 28 October 2008 (UTC)

The signs that are on the A120 out of Harwich for visitors from mainland Europe don't use the same conversion as does the Highway Code

. The only reliable way to tag UK speeds, as is widely the case already, is to tag maxspeed=20mph or whatever. Sorry the image is a bit dark but it was getting late. EdLoach 16:50, 1 December 2008 (UTC)

maxspeed=national

There's a national speed sign in the uk (see http://www.abd.org.uk/speed_limit_signs.htm#limits fig 671). What do people think about using speed=national for road that are marked with this sign? Could be handy as the government are thinking of changing the national speed limit on some road classifications.--Pobice 21:26, 16 March 2009 (UTC)

I guess you mean this part

"Diagram 670 can indicate any speed limit from 20 to 70mph (usually in multiples of 10mph) and the signs can be from 300mm to 1500mm in diameter. Diagram 671, sometimes known as the 'derestriction' sign, has the international meaning 'end of maximum speed limit'. In the UK, however, it has been given the meaning 'national speed limit applies', which means a 60mph speed limit on single carriageway roads and a 70mph speed limit on dual carriageway roads. (A different part of the Act deals with motorway speed limits, as a result of which diagram 671 is never used on motorways.) Signs to diagram 671 can be from 450mm to 1500mm in diameter."

The best way to catch implicit maxspeed limits should be maxspeed=default and define the area here -> OSM_tags_for_routing/Maxspeed --Cbm 04:28, 17 March 2009 (UTC)

Yes maxspeed=default looks a more universal way of catching the data. I think this needs adding to the key:maxspeed page as well. Looking at tagwatch-gb there are 8 uses of national and none for default. This may help stop the use of national in the uk.--Pobice 11:10, 17 March 2009 (UTC)

Except that there's never a need to tag the default maximum speed, as that's what is implied when there is no maxspeed tag at all. --Eimai 11:22, 17 March 2009 (UTC)

correct. if no maxspeed-Tag or maxspeed=default should have the same handling. Never the less the implied defaults for these areas must be collected anyway (best: link above) --Cbm 12:08, 17 March 2009 (UTC)

I would argue that it is needed. No tag could mean the data has not been collected and therefore the defualt speed could easily be wrong. If you set maxspeed=default then its an indiction that the data is more likely to be correct.--Pobice 16:06, 17 March 2009 (UTC)

It's similar to solving the issue of streets without names. It makes sense to come up with some general option for those (like name:absent=yes and maxspeed:absent=yes or something similar-. For now you can just add a note to the way saying the speed limit is just the default. --Eimai 17:58, 17 March 2009 (UTC)

I've re-read the document again and the national speed limit actually raises the speed limit in somecases. The defualt speed limit on road with street lights (all classes bar motorways) is actually 30mph. After reading this I think maxspeed=national is needed after all.--Pobice 00:03, 18 March 2009 (UTC)

is this "raise in some cases" in a special area or it this behaviour uk-wide "in some cases"? If it's UK-wide catch this implicit limit here (OSM_tags_for_routing/Maxspeed) in the UK section or create a subsection for this region. IS_IN="special region" could also be a possibility. --Cbm 09:58, 18 March 2009 (UTC)

Its a uk wide thing. I might have to bring this up with talk-GB and see what they think. The UK section does mention it but probably could be made a bit clearer. Just to make it clearer the national speed is the default for roads without regular street lights. However when a national speed sign is used on roads with street lights it raises the speed limit from the default 30mph to 70mph (dual carriageway) or 60mph (single carriageway)--Pobice 16:58, 18 March 2009 (UTC)

how does such a sign look like? if it's uk-wide please check this section here OSM_tags_for_routing/Maxspeed#United_Kingdom add missing behaviours and let's discuss a solution there in the Talk-section. --Cbm 09:36, 19 March 2009 (UTC)

It looks like this: http://en.wikipedia.org/wiki/File:Natspeedlimit.jpg --Pobice 15:55, 19 March 2009 (UTC)

Personally I think that the tagging should match the signposts, so if the signpost is the national speed limit sign then the tag should be "national" not 60mph or 70mph. The sat navs should then figure out what that means based on dual carriage way etc. If there is an exceptional limit, such as a 60 on a dual carriage way then there will be a 60 sign not a national speed limit sign. There seems to be a lot of inconsistency in the data I've been looking at. --Tim abell 00:17, 15 December 2010 (UTC)

The only way some routers determine what a dual carriageway is the concurrency of highway=trunk and oneway=yes, which is used because quite a lot of ways (if not the majority of ways) aren't tagged with maxspeed=*. The 'national speed limit' sign used in the United Kingdom is not a derestriction sign like those found in European countries; it states that the speed limit for low-end motor vehicles not towing anything is 60 mph on single carriageway roads (≠ oneway=yes) and 70 mph on dual carriageways. (Actually, the Speed Limit Order for the road in question states the speed limit.) I'm not suggesting using {{|key|maxspeed:hgv}} or similar 'colon variants' but I'm having second thoughts about using maxspeed=national. Kevin Steinhardt 02:40, 4 March 2011 (UTC)

Spaces before units

The page currently recommends "30 mph", that is, a space before the unit. Tagwatch, however, reports 4649 instances of "30mph" and only 173 instances of "30 mph". An application will try not to depend on spaces anyway and I personally prefer spaces, but I wonder whether we should switch recommendations to match actual tagging? --Tordanik 19:54, 3 April 2009 (UTC)

I changed it and added a regular expression specifying the values that can be considered valid.

Erm, do we need kph, kmh and multiple spaces? Next to nobody is using them anyway -- 2 uses of kmh and 19 of kph in all of Europe --, and not every application can handle regular expressions well; for those, a list of exact matches "30", "30 km/h", "30km/h" should still work. (Not declaring them valid wouldn't mean you couldn't evaluate them, btw, but there is no reason to encourage more than one way of writing a unit. It makes evaluation possibly harder and there appears to be no demand for that level of tagging freedom according to Tagwatch.)

What I'd recommend (for mappers) is: "[0-9][0-9]*([ ]?(km/h|mph))?" --Tordanik 08:17, 4 April 2009 (UTC)

What about now? --MarcusWolschon 09:51, 4 April 2009 (UTC)

Well, with that disclaimer it's ok. I've also changed the inline example in the introduction. --Tordanik 11:28, 5 April 2009 (UTC)

there is no reason for leaving the space out but only bad knowledge of typography and perhaps also of the international standardized use of units. If what "everybody" does would be a good reason, all street references in germany would still be wrong (it is B 2 and not B2 - this one is fortunately done for germany). The space costs nearly no place in the database, it's easy to process - no reason for wrong typography here. -- Schusch 01:52, 1 May 2009 (UTC)

Off-topic, but the fact that you store a road number as B 2 just because it appears on the signs like that is just wrong. You shouldn't put typographic rules in OSM, but you should store data. Because by adding the space you may have actually chosen the wrong kind of space. Who says it isn't a half width space, a non-breaking space, a half width non-breaking space, a hair space, a thin space... So you basically can't make any claim that a normal space has to be used in road numbers, and you're basically putting wrong typograhical rules into the database. Typography is only something the renderer should take care of (so it can choose itself how to render it with the kind of space or other symbol between letter and number, or no space at all). --Eimai 10:46, 1 May 2009 (UTC)

ok I see what you mean--but the renderer can do what is wanted, it doesn't matter, if there is a space or not; so there is still no reason to leave it out, because you read it while editing. No space is bad typography, a space is at least a better approximation, and it may be right. So the space is still the better solution. During editing the text should be human readable - and that is, what typography is for. -- Schusch 00:29, 2 May 2009 (UTC)

Customary usage in written texts is not to have a space when the unit is an inherent part of the word. The speed limit is "20mph" which has become a single concept. This is much the same way that english loses hyphens and stops in abbreviations. "20 m.p.h." might once have been more correct, but hardly anyone writes that any more.--RichardMann 11:54, 22 May 2009 (UTC)

it's always easy to claim something as "customary usage" ... but a claim is not a proof. And I don't see the million of amateurs in www as a good example for good print. Everybody may do it as he wants as long as it doesn't affect everybody. A database, where thousands or maybe million of people work in is something different. The omitting of the space wisely doesn't apply to careful print. It is still a lot easier to capture the information with a space and not without a space--that's why the space is still in use, in unlike the stops etc. -- Schusch 07:55, 5 August 2009 (UTC)

Resolved: nowadays version with space is clearly more popular - see https://taginfo.openstreetmap.org/keys/maxspeed#values Mateusz Konieczny (talk) 09:18, 18 November 2020 (UTC)

Tagging only in km/h

How about a bot to calculate mph values to metric? --Lulu-Ann 13:02, 7 April 2009 (UTC)

Why? Where the limit is given in mph it should be tagged in mph. Else no mapper will know if it is correct without using a calculator. It's not a local, special case but a whole continent you are talking about. --MarcusWolschon 13:13, 7 April 2009 (UTC)

I'm with Marcus. If the Limit is given in mph we shold collect them this way and not in a transformed way. This is work for the applications not for the OSM-Data itself. --Cbm 16:43, 7 April 2009 (UTC)

Editors and routing softwares shall learn to display the value in the desired system, but the data shall be only in one system, and that's SI. --Lulu-Ann 20:38, 7 April 2009 (UTC)

But therefore we MUST use the exact transformed value and no roundup-value. e.g. 30mph ==> 48.280 and not just ~48 --Cbm 12:43, 8 April 2009 (UTC)

I disagree. Nobody but a standman can drive exactly on the maximum speed limit mile or km. Not even police measures more precisely than ~3 km/h. Make sure it rounds to common numbers, that's enough. --Lulu-Ann 14:26, 8 April 2009 (UTC)

This is no matter of what somebody can or can't do. OSM is about collecting facts. And e.g. for UK maxspeeds are set in mph and has a exact conversion factor to km/h. As you can see here the official rounding of the UK law is another than a mathematical logical . What's the best one for OSM? None of both ;-). We have no need for rounding so we should avoid it in any case. --Cbm 06:46, 10 April 2009 (UTC)

Not a good idea, imo. Currently, few applications need to do conversions. Your suggestion would require a lot of software that isn't really supposed to understand the meaning of tags (Tagwatch, data layer, most parts of editors, ...) to add conversions to avoid displaying strange values. Also, I generally don't think it's a good idea to have black box magic in editors: Doing so would make documentation more complicated (different information for mappers and API users required) and cause massive problems if one editor doesn't offer the feature. --Tordanik 21:09, 7 April 2009 (UTC)

I do not think anyome was refering to editors or tagwatch. Editors show the tags as they are. Routers use only one system internally (usually SI) anyway regadless of the geographic location. If the user gets to choose the prefered unit for display it will show mph even in Italy or km/h even in the US. --MarcusWolschon 06:28, 8 April 2009 (UTC)

How is "Editors [...] shall learn to display the value in the desired system" not referring to editors? If I understand Lulu-Ann's suggestion correctly, it is that we would have only SI data in our database and add conversions in editors to allow mappers to work with those units they are used to (and that are used on the traffic signs where they map). You are describing the current (and, imo, desired) behaviour correctly, but the comment I responded to seems to suggest a change of that behaviour so editors would not simply show tags as they are. --Tordanik 06:54, 8 April 2009 (UTC)

Right, if the editors learn to convert the units the routing software does not need to convert in both (or even more) directions. --Lulu-Ann 07:22, 8 April 2009 (UTC)

Real SI which does not require units would be meters per second! To improve dataquality it would be wise to postfix km/h values with " kmph"! --Phobie 01:44, 26 May 2009 (UTC)

I'm with keeping maxspeed tags in the whatever is signed rather than all in km/h. This makes it much easier for mappers. I'll soften my view if you get most editors to include automatic conversion which doesn't slow the mapping process down, but until then lets keep things easy on the mappers and people entering data into the system.--Pobice 17:33, 30 April 2009 (UTC)

Of which whole continent do you talk about? The continent named United Kingdom or the one named United States? --Phobie 17:28, 6 June 2009 (UTC)

The north american continent. From what I see both countries "USA" and "Canada" use speed-limits in miles per hour. That's a LOT of roads and a lot of users for whom mapping mph speed-limits in SI makes no sense. --MarcusWolschon 09:07, 8 June 2009 (UTC)

Cannada uses SI-units. See wikipedia:Speed_limit#Units_of_measurement. On a other site I read that there are some rare cannadian speedlimits signs in mph. --Phobie 12:32, 23 June 2009 (UTC)

What about using a special tag for entering speeds in mph, e.g. maxspeed:mph?--Oli 15:31, 27 January 2010 (UTC)

Resolved: mph suffix is nowadays clearly accepted Mateusz Konieczny (talk) 09:19, 18 November 2020 (UTC)

Needless Vote

What about a vote of how many uses mph and how many uses km/h? I suggest that everybody who uses mph sign there name and state what country you are from under the mph headline, and same for km/h. --Skippern 17:59, 3 May 2009 (UTC)

I think your asking slightly the wrong question regarding whats been discussed here. Maybe we should be asking something like "should we map in the local units (eg mph) or only in km/h" ---Pobice 19:09, 3 May 2009 (UTC)

Maybe I wasn't clear enough, to have an idea of how to decide km/h or mph, we need to know the extent of usage. If there is a clear majority one way or another, or if there is an equal distribution, if people prefere to use local units, or convert to some unit etc. When we see how this is distributed, than we can make a proposal, and with the proposal a vote. See this as marketing. --Skippern 19:15, 3 May 2009 (UTC)

Only way to get somewhat reliable results on that is to get someone to sum up some statistics from planet.osm. Alv 21:28, 3 May 2009 (UTC)

That wouldn't give you any readable data for where only number values are used, unless you assume that numeric values are local units or numeric values are km/h. I guess many who are mapping in UK, USA, and other places where mph are in common use tag this without trailing mph, and that we might find places there tagged with numeric value + km/h. I am not able to do some statistics myself from planet.osm, so somebody else will have to do that (lacking highspeed connection to download planet and computers to process data) --Skippern 22:26, 3 May 2009 (UTC)

It would, as much as it would for any router. Posted limits happen to be at 5 mph or 10 kmh intervals, converted values mostly at values not divisible by 5. Even though we should assume numeric only values are always in km/h (as the guideline has been from the very start), we also know (most of) the countries that signpost the limits in mph and can, inside those countries, look for values that seem to be converted from mph (like 112 or 113 for 70 mph). Tagwatch shows only some isolated values (few hundred, at most, out of a total of hundreds of thousands) with a " km/h" (mostly) in the Australia-Oceania "continent", and few maxspeed values at all in the US. This does leave some values in ambiguity, that is those that when converted fall too near to being a plausible signposted number. For example, for the latest united_kingdom.osm, there's

• '80': 312 occurrences
• '80.4672' + '80.5': 37
• '50': 300
• '50mph': 250

There are no 80 mph limits in the UK afaik (at least not in osm data), but which of those plain "50" values are rounded up from 48 kmh=~30 mph and which are 50 mph limits? Likewise for 25mph/40kmh, but if they're interpreted as kmh, no harm will be done if they were in fact mph - someone might take a slower route but the data will be fixed eventually. Still the majority of values are obviously either converted-to-kmh values or have the mph suffix and reasonable statistics would be possible.

I personally don't care which people use (there's already both cases in the database), on the condition that values not in kmh always include the unit. Alv 08:56, 4 May 2009 (UTC)

I use mph

• ... if I would map in mph-related country... cbm - Germany--Cbm 18:21, 3 May 2009 (UTC)
• In mph countries only. If I mapped somewhere using km/h would map in km/h- pobice - UK --Pobice 19:09, 3 May 2009 (UTC)
• I'd go for mph (ie 20mph) if that's the digits and implicit units on the sign. Better to have something that is likely to be done exactly right.--RichardMann 12:02, 22 May 2009 (UTC)

I use km/h

• Brazil & Norway --Skippern 17:59, 3 May 2009 (UTC)
• The whole world uses SI units.
  • you mean they use m/s? ... Didn't think so.-- InsertUser 18:57, 7 October 2012 (BST)
• I do --Lulu-Ann 18:37, 27 July 2009 (UTC)

Resolved: mph suffix is nowadays clearly accepted Mateusz Konieczny (talk) 09:19, 18 November 2020 (UTC)

nodes?

This page contradicts Map Features by listing nodes as a possible element type for maxspeed tags. Does anyone know a reason why nodes with maxspeed information would make sense? --Tordanik 10:05, 28 April 2009 (UTC)

I can only think of intersections with a maxspeed as a use-case. --MarcusWolschon 11:00, 28 April 2009 (UTC)

Signed speed bumps have a speed limit over here, but those shouldn't be tagged, as they're implicit. --Eimai 13:55, 28 April 2009 (UTC)

Maxspeed makes sense on a node if you have a speed cam and you know what is the limit there but you did not collect the start and end position of the speed limit. --Lulu-Ann 19:04, 29 April 2009 (UTC)

I tag Maxspeed on the nodes where I have tagged the speedcam, and will also tag maxspeed on nodes where any form of fixed enforcement also use speed (such as a red light camera that also is a speed camera). IMO this makes just as much sense as tagging the different roads with maxspeed. --Skippern 18:35, 3 May 2009 (UTC)

The speed bump signs are usually advisory, not legal, that is they are a warning to slow down otherwise you might do damage to your vehicle, but you won't get a ticket if you exceed the posted limit. -- JohnSmith 02:41, 16 July 2010 (UTC)

I create nodes for the signs first, then tag the ways based on them. The sign nodes have a source_ref specifying the picture number and the ways have source_ref:maxspeed that specify the relevant pics as well. It's about traceability. I suppose that, once I've captured every speed sign along a route, the ones that do not represent a change could be removed. AM909 02:29, 16 July 2010 (UTC)

Seems redundant to tag nodes and ways with the maxspeed=* value, especially if multiple signs on the same segment of way have the same maxspeed=* value. -- JohnSmith 02:41, 16 July 2010 (UTC)

this Key is also use in combination to traffic_sign=* when mapping traffic signs. In this case it is usually a node.

As this is a documented use and already used often, I think that adding a note about this use in this page would be a good idea. --AnyFile (talk) 07:21, 5 September 2024 (UTC)

placeholder for set of implicit maxspeeds

on Talk:DE we discuss the possibility to use placeholder for streets without explicit maxspeed-signs. In Germany e.g. we have different implicit limits on motorways, in build-up-areas/cities and the rest (streets not in cities and not motorway-like). Instead of appointing a limit on these road where there are no explicit sign (because they are set by law) we could tag these ways with:

maxspeed=motorway:DE maxspeed=city:DE maxspeed=default:DE

This methode could bring lots of advantages. It's less work to tag (you only have to tag 1 tag to set a bunch of default-speeds where there is no explitic limit) and it's much more accurate.

e.G.:

default:DE
{
maxspeed:motorcar=100
maxspeed:motorcycle=100
maxspeep:goods=80
maxspeed:hgv=60
...
}

with with one placeholder-value :)--Cbm 15:07, 3 May 2009 (UTC)

I'm not too sure that a placeholder is needed like that, although we may need a way to say that there are no speed signs along a road. But I think that there's enough other information there to know the default speed on a road (country/state boundaries, number of lanes, dual carriage or not, defined built-up areas). Of course not all are tagged good enough currently, but we're getting there.

Little suggestion though, switch the country code and the road type, so it becomes "DE:default". --Eimai 15:36, 3 May 2009 (UTC)

e.g. the maxspeed=motorway:DE is not only for motorways in Germany, but also other motorway-like roads. Unfortunately you can't really catched that with you suggested methode. --Cbm 18:23, 3 May 2009 (UTC)

Er, so how would you know the default maximum speed when you're driving on it then, If there are no other features that tell what kind of road it is? --Eimai 19:19, 3 May 2009 (UTC)

Any reason why you don't go with the "speedzone" approach (tag name irrelevant) of using a key other than maxspeed? It seems strange to use a maxspeed value if you are really also setting values for maxspeed:hgv and so on. --Tordanik 22:24, 3 May 2009 (UTC)

A new Tag should only be introduced when it makes any sense not to maxspeed= as well. If it's only to become maxspeed letterfree it's not effective to create a new tag for this... --Cbm 15:48, 4 May 2009 (UTC)

Aren't the maxspeeds for hgv & goods not dependent on the sign but from vehicle class legislation? No matter what sign there is, a hgv may not exceed that value or the maximum speed for hgv's, whichever is lower? That's a national default and not dependent on whether or not the speed limit on a road is signed as such or implied from "in town" or not. Alv 12:34, 16 May 2009 (UTC)

e.g. in Germany there is "in town" a road with an explicit maxspeed=70 (50 per legislativ default in ) then HGV are allowed to drive up to 70km/h wheather the law normally only allowes 60km/h to them, But that is only "urban" not "not_in_town". --Cbm 18:37, 16 May 2009 (UTC)

Since urban roads can't be 80 or more, only the case of a maxspeed 70 "not-in-town" would need to be maxspeed=70 + maxspeed:hgv=60. Otherwise the hgv limit is 60 (or lower), unless it's a autobahn-like road, already identifiable with lanes=2+ + oneway=yes, where it's 80.

Hardly a reason to use anything but the roads speed limit as the value. I think the tip to use "de:place" should be removed promptly from the key:maxspeed documentation. Alv 12:44, 25 May 2009 (UTC)

So it's usable in Germany, but in other countries where "in town" / "outside" affects maxspeeds for all vehicles equally, it doesn't matter if people tag the maxspeeds explicitly. And they'll likely do. Alv 17:07, 19 May 2009 (UTC)

And I'd think it'd better be tagged explicitly; either set maxspeed:hgv where it's not the same as maxspeed (I'd prefer), or have a maxspeed:sign=citylimits/rural if it's not from a explicit maxspeed sign. Alv 16:47, 22 May 2009 (UTC)

I agree here. I the general case there is only one maxspeed for everyone. Seldomly there can be maxspeeds and minspeeds for individual vehicle-classes (like a minimum-speed for hgv on a hill) but the general limit makes no explicit distinction here. Pleas link to the related paragraphs in StVO if you think otherwise. --MarcusWolschon 05:55, 27 May 2009 (UTC)

a trafficzone implies much more than only _one_ maxspeed for. So it's not the same as simple explicit maxspped=*. See -> Proposed_features/trafficzone#Examples --Cbm 16:08, 27 May 2009 (UTC)

It's been 10 months now, and tagwatch shows 3100 occurrences of "DE:urban" vs. 67500 uses of "50" (in Germany, 151000 times in Europe). Key source:maxspeed is at this time at 1030 (DE:urban) + 550 (DE:rural) (Italy: "maxspeed=50" 9850, "source:maxspeed=IT:urban" 4535). Whenever there exists a numeric value for the maxspeed, it's much easier for data consumers and mappers to enter it as such, I think it's time to rewrite the disputed tips section with a "some have used maxspeed=<country code>:urban/rural, but tagging that as source:maxspeed=<country code>:urban/rural is preferred." Keeping the value stored in the maxspeed tag a numeral, whenever such a value exists, is more in line with previous conventions and current implementations. Alv 08:49, 2 March 2010 (UTC)

i don't see the need for country codes. routing programms should be able to determinate the location of a way by looking at the surrounding borders. so a maxspeed=city or maxspeed=urban should be enough. flaimo 03:49, 25 December 2010 (UTC)

Adding non-numerical values to this tag without voting

Alv, Phobie, Lulu-Ann: Why did you add the values "city_limit", "<country code>:city" and "<country code>:place" to this tag without putting them up for a vote first? maxspeed="signals" can be safely ignored like any value a parser sees as invalid but not these. --MarcusWolschon 10:02, 22 May 2009 (UTC)

I didn't add it, I'm hoping others on the mailing lists convince people not to use such. Wanted to point out that whatever the outcome of the debate, such use is not needed in most countries. Alv 12:16, 22 May 2009 (UTC)

IMHO it is needed in all countries to distinguish between implicit and explicit limits. The first ones could change by action of legislation and then it will be very useful to identify the related ways. There would also be no need for action to be taken with implicit limits mapped accordingly, while mixing them up would result in turning useless most maxspeed-values already tagged. -- Dieterdreist 13:17, 25 May 2009 (UTC)

Yet they would have to be resurveyed anyway, as local authorities enacting the signs would most definitively erect signs on some or most of those ways to keep the limits at their previous value. Alv 13:21, 25 May 2009 (UTC)

Because it is useful to explicitly tag implicit limits. As for landuse=* there are no useable defaults for maxspeed=* in most countries. The commonly used "city_limits" is from Tagwatch. I prefer "place".

Voting is not engaged or binding. It seems to be better to discuss on mailinglists and wiki.

No, "signals" can not be ignored there are several use-cases. Not all parsers will ignore those values... --Phobie 14:51, 25 May 2009 (UTC)

There could have well been alternative aproaches. Some may be better. While voting is not binding it is still a bad habit not to. Also it's a fact that only very few users are on the mailing-lists at all. They are for general discussion (hence the name "talk"), not everyone is interested in talk. Could you point out where this has been discussed at least on the talk-lists of the major languages, the routing-list (as it affects routing) and the dev-list(as it affects the work of developers)? --MarcusWolschon 05:58, 26 May 2009 (UTC)

Implicit limit = 100/50, explicit tag = maxspeed=100/50, right? If the zone is not implicit (maxspeed probably can't be 100 "in town" in Germany either) and affects the speeds for some vehicle type, either they'd be tagged too or given with a zone:traffic=*, if you wish.

Signals equals (for any routing software) "I can't know any better ... so I'll guess and use (the previous limit/national default for this highway type)." Alv 16:05, 25 May 2009 (UTC)

1. I think it is always right to tag a maxspeed, no matter if the traffic_sign=* is implicit or explicit.
2. If the traffic_sign=* is implicit maxspeed=* should also be implicit.

A zone:traffic=place + maxspeed=default would be sufficient but a maxspeed=DE:place would be better because it does not depend on zone:traffic=* and country boundaries. Therefore it is easier to parse.

To maxspeed=signals: For a Navi it could mean "Connect to the internet and ask the traffic service for the current values" or to show a special sign on the display. It is a bad idea to show a previous limit or the national default were the real maxspeed=* is unknown. --Phobie 01:07, 26 May 2009 (UTC)

Naturally they can't show it to the user as "this is the current limit", but rather "unknown limit". Yet for calculations the national limit is the only value they can use when any text that doesn't map to a value one-to-one, is encountered - unless it has a fancy internet connection and knows a server for variable speed limit signs. Alv 06:49, 26 May 2009 (UTC)

Back to topic guys, the topic is modifying the semantics of well established tags without a-priori proposal, discussion or voting. Not about if this modification is useful, needed or the best way to do it. It's about changing existing and well established semantics without discussing it first. --MarcusWolschon 05:45, 28 May 2009 (UTC)

Resolved: this tags are not listed on page and are not present in actual tagging Mateusz Konieczny (talk) 09:21, 18 November 2020 (UTC)

whole numbers only

MarcusWolschon, you added "Tag whole numbers only."! Why? For mappers it is easier to tag whole numbers, but it is perfectly ok to have converted mph2kmph values in the database and those values should never be rounded to whole numbers! --Phobie 17:28, 5 June 2009 (UTC)

also, now this page seems to contradict itself after the last edit - it says both :

"Please do not tag rounded values!" and

"Tag whole numbers only." --Richlv 17:51, 5 June 2009 (UTC)

It doesn't contradict itself at all, it just tells you not to convert mph into km/h. If you tag a 40 mph limit as "40 mph", you have a whole number (with unit prefix) that isn't a rounded value. --Tordanik 20:03, 5 June 2009 (UTC)

I rewrote the section to make it clearer! --Phobie 19:19, 6 June 2009 (UTC)

It doesn't make sense to tag whole numbers only if the sign gives a value that is not a whole number. ObExample: http://sites.google.com/site/am909geo/osm-1/DSCP8999.low.jpg at http://www.openstreetmap.org/?lat=34.143883&lon=-117.418624&zoom=19 :) AM909 03:21, 16 July 2010 (UTC)

That curious private land sign appears to be derived from European 25 km/h regulation and converted into US imperial. So arguably maxspeed=25 would be sensible to tag instead, without fraction. --Pink Duck (talk) 10:39, 7 June 2022 (UTC)

Resolved: seems to be solved as far as I can see Mateusz Konieczny (talk) 09:23, 18 November 2020 (UTC)

Default values

How default are the default values? I mean, if I add a road that is marked as 'Residential' then will the speed for that automatically be assumed to be 30mph or do I need to add maxspeed - 'DE:residential'?

There are an awful lot of residential roads etc to add as 30mph and I don;t want to be wasting my time if they are already defaulted to 30mph as they are residential roads. If this is the case then I can concentrate on those that break the norm such as those designated as 20mph areas etc.

may be this pages will help: OSM_tags_for_routing/Maxspeed and Proposed_features/trafficzone --Cbm 10:29, 22 August 2009 (UTC)

yes, i had read this but missed the line that said 'The default maximum-speed if not given by maxspeed=* is: ' - i just thought it was a page with the speeds for each country! - MaFt

I thought germany used metrics, and not imperials for speed units....? Sure you didn't mean km/h? --Skippern 06:25, 23 August 2009 (UTC)

again, i mis-read - i thought 'DE' stood for 'Default'

so, basically to answer my own question, yes, OSM does store the default speed values so i only need to edit those that break the norm. thanks

maxspeed:seasonal:winter

In Finland, many roads have different speed limits in winter and summer (motorways 100 km/h in winter, 120 km/h in summer). The signposts are either changed manually or electrically controlled. There's a convention of using maxspeed:seasonal:winter (also maxspeed:winter which probably should be changed to maxspeed:seasonal:winter) to mark speed limits for winter use. There's no definite date for when the limits are changed, and as it's done manually, it's not the same moment everywhere. I think the sensible thing to do with navigators (for overspeed warnings, possibly also route calculation) would be to let the user control if the navigator is in summer mode or winter mode. My question: can this convention about maxspeed:seasonal:winter be put on the Key:maxspeed page and/or Map features so mappers will find it straight away, or is some kind of proposal process required? --Jkp 14:37, 7 September 2009 (UTC)

Imo, that's something that should be integrated into Proposed features/Extended conditions for access tags as another possible set of conditions. It's a bit unfortunate, though, that there is no reliable definition - is it really just the arbitrary decision of whoever changes the sign or are there some laws (or at least conventions)?

To fit in with the other conditions (such as :wet, :forward/:backward, :hgv and so on), I would suggest to drop the "seasonal". It doesn't do anything except making the key longer anyway. --Tordanik 15:49, 7 September 2009 (UTC)

I think this falls into the same category as our lower Belgian speed limits on some motorways when a "smog alert" is declared (which happens several days each year): when air pollution gets too bad, speed limits on motorways near cities drop from 120 to 90 km/h. It's enforced by turning signs along the motorway or by overhead electronic signs. One could invent tags like maxspeed[smog]=90, and most of it can be mapped (just look backwards on a motorway to see the turned signs), except when speed limits are enforced by electronic signs, but in that case they're variable depending on traffic anyway, so not taggable at all. But I wonder if it really has to be mapped... In any case the tags wouldn't collide with other tags with a "smog" parameter, but with "winter" that's another issue (and as you say the exact period varies anyway)... --Eimai 16:08, 7 September 2009 (UTC)

According to tagwatch - http://tagwatch.stoecker.eu/Finland/En/tags.html - maxspeed:seasonal:winter outnumbers maxspeed:winter (100 (148), 120 (1) compared to 80 (18), 100 (15)), but I guess there are ways to automatically change the key if a decision is made the change is warranted. The convention is to change to/from winter limits when the weather is thought to be appropriate for the change, also probably mass movement of people (holidays) is considered. I think the change is made at different times in different parts of Finland, as the weather may be quite different in the North vs. South. The lowered speed limit may be applied for six months or perhaps more I think, so this is a much more common situation than the smog alert. I guess a case can be made to include :seasonal instead of just :winter so that seasonal tags can be found (by humans) with one keyword. Seasonal tags might need to be used for things like cycleways or footways not snowplowed in the winter or roads on ice which do not exists at summer; see e.g. http://wiki.openstreetmap.org/wiki/Proposed_features/Dry_weather --Jkp 21:35, 7 September 2009 (UTC)

Determining implied maxspeed, and advisory speeds

The Florida highway code defines the default (no sign present) speed limit as "30 miles per hour in business or residence districts, and 55 miles per hour at any time at all other locations". These districts are defined in a rather complicated manner that can't be easily determined. So what should be done if no sign is posted and it's not clear whether it's a business or residence district (example: suburban street with parking lots alongside)?

Also, I'm assuming this tag is only for regulatory speeds (white background in the US), not advisory speeds (yellow background in the US, posted at e.g. curves, where you can't be ticketed for going faster, but going faster can be evidence of driving recklessly if you get in a crash). --NE2 05:32, 23 February 2010 (UTC)

If you don't know the speed limit you can not tag the speed limit. leave the tag for another day/mapper. How do the police know what the speed limit is if there is no easy way to determine it? --Gnonthgol 06:15, 23 February 2010 (UTC)

The police know, and if you disagree you can fight them in court :) --NE2 06:18, 23 February 2010 (UTC)

It is useful to have a way to record that a mapper has checked the full length of a street and determined that there are no speed limit signs anywhere along it. I have been tagging these streets with maxspeed=unposted, source:maxspeed=survey; the OSM data system tracks the date of the tag. The vast majority of the cases I find like this are quiet residential streets, for which the speed is probably 25 mph or 30 mph, depending on the city or state. I'm open to other approaches, but we do need something to indicate that a street has been checked.--EdH 13:29, 13 July 2014 (UTC)

Different maxspeed for cars and trucks

In a certain residential area, I saw signs that have separate speed limits for cars and trucks. On major roads within the area, the speed limit for cars is 60 km/h while the speed limit for trucks is 40 km/h (for other roads, the maximum speed limits for cars and trucks are 40 km/h and 25 km/h respectively.) How to tag them? -Ianlopez1115 04:09, 25 April 2010 (UTC)

maxspeed=60 + maxspeed:hgv=40. Alv 08:47, 25 April 2010 (UTC)

Resolved: now documented at the page Mateusz Konieczny (talk) 09:23, 18 November 2020 (UTC)

Different maxspeed for directions

Some roads have different maxspeed depending on direction of traffic, eg. 70 just at the city limit for those leaving, but 50 well before the city limit for those approaching. According to the German version, the proposals maxspeed:forward=* and maxspeed:backward=* are already in use. --MattGPS 20:10, 15 June 2010 (UTC)

Similar for down/up hill (ie down 50km/h up 90km/h) --Jezevec 10:02, 10 December 2011 (UTC)

This doesn't really matter and should be tagged the same way by using :forward and :backward. --Scai 15:57, 10 December 2011 (UTC)

Resolved: now documented at the page Mateusz Konieczny (talk) 09:24, 18 November 2020 (UTC)

numbers + source:maxspeed

Regarding numbers + source:maxspeed solution, I have two ojections:

• If all maxspeed tags would have associated the source:maxspeed=<country code>:<identifier> (ex. source:maxspeed=DE:urban), a new lifetime task will be necessary to keep values synchronized checking if the tags (maxspeed and source:maxspeed) are in compliance. If the tags are not in compliance, next task is to find somehow the maxspeed value and to fix this issue. This is the effect of having redundant data.

• Having only a numeric value and no other associated tags for maxspeed, it implies the risk to make a costly effort to update all maxspeed values if the legislation regarding the speed limits is changed.

In my opinion the optimal way is to specify maxspeed as much as possible with abstract values as DE:urban, RO:urban, RO:trunk, etc. in order to:

1. Overcome the issues described before;
2. Quickly determine in which country the road is.
3. Have much less issues regarding how the value is specified: units, separators / no separators, float / integer values.

Of course, there are voices that are complaining about the compatibility of maxspeed values. Using maxspeed=<country code>:<identifier>, the incompatibility appears only on the roads with standard speed values (without special speed restrictions). But in this case, honestly, industrial scale processing tools can determine the speed limit values without heaving the maxspeed tags. So this is not a real and general problem. Maybe somebody can estimate the real impact having tags like 'maxspeed=<country code>:<identifier>.

In software design is a principle saying to depend on abstractions, not on details to make your life easier. Here the numeric value plus possible units are the details - opposite to the abstract values like DE:urban.

Finally the question is what is preferred: to pay lifetime tribute to several applications that use directly maxspeed values as numbers adding extra complexity to specifications (ex. source:maxspeed=IT:urban), or to have simple and clear specifications. -- Flaviu 14:21, 4 January 2011 (UTC)

The "what if legislation changes" is IMO almost irrelevant scenario: in such case the authorities will add and/or change maxspeed signs on a significant portion of the roads, and mappers will have to resurvey all roads anyway. And where the maxspeed is given together with an implicit source but is different from the would-be implied value, the real value, or whether the source tag should be removed or changed to =sign, can either be deduced from way history, relevant changeset comments, mailing the user who made the change, or (oh!) surveying again. The map is never ready, it's always good to resurvey. Alv 15:11, 4 January 2011 (UTC)

I'm in favor to specify the map in a way that needs less maintenance effort. Regarding legislation changes, for example in Romania the speed limit for European roads (E) has been changed some time ago from 90 km/h to 100 km/h. Maybe tomorrow it will be changed to 110 km/h. Thus, all European roads having maxspeed specified as number should be changed. If maxspeed is specified as RO:trunk (in Romania European roads are specified as trunk), nothing needs to be changed. Yes, you have to know for each country around 5 standard speed limits. As solution, it can be added an extension to specify the mapping for each country; something like:

<speedlimits unit="kmph">
  <general>
    <speed k="RO:urban" v="50"/>
    <speed k="RO:rural" v="90"/>
    <speed k="RO:trunk" v="100"/>
    <speed k="RO:motorway" v="130"/>
  </general>
  <hgv>
    <speed k="RO:urban" v="50"/>
    <speed k="RO:rural" v="80"/>
    <speed k="RO:trunk" v="90"/>
    <speed k="RO:motorway" v="110"/>
  </hgv>
</speedlimits> 

Using such abstraction mechanism a lot of changes can be avoided and the issues regarding the speed format (units, separators / no separators, float / integer values) are minimized. -- Flaviu 06:56, 5 January 2011 (UTC)

restriction from 22:00 to 06:00

How can I write restriction "maximum speed - 30 km/h from 22:00 to 06:00"? Dinamik 22:01, 8 July 2011 (BST)

If this is a standard nighttime restriction, maxspeed:night works reasonably. --NE2 23:09, 8 July 2011 (BST)

Resolved: now documented at the page (we use maxspeed:conditional=* for that) Mateusz Konieczny (talk) 09:24, 18 November 2020 (UTC)

Country code standard

The main page's recommendation to use country code prefixes for implicit limits is poorly defined: it does not state which standard we should use. May I suggest stating that ISO 3166-1 alpha-2, uppercased, must be used for these? One drawback to this is that the United Kingdom section of OSM_tags_for_routing/Maxspeed is currently recommending that we use "UK", not "GB". --achadwick 19:37, 23 October 2011 (BST)

The use of Ukranians "UK" for Great Britain ("GB") is simply an error. --Lulu-Ann 14:47, 2 November 2011 (UTC)

Allowed and practical maxspeed

die vorgeschriebenen sind natürlich durch schilder gekennzeichnet. aber es gibt auch strecken, z.b. kurvige abschnitte die trotz erlaubten 100km/h lieber langsamer durchfahren werden sollte. daführ sollte man noch ein zusätzliches tag haben --Kenji 17:59, 30 January 2012 (UTC)

Dafür gibt es bereits den Vorschlag maxspeed:practical=*. --Scai 20:13, 30 January 2012 (UTC)

Google is unfortunately not able to do a very good job of translating the above or I would have added it to the page. Can someone add a translation to help some of our readers! PeterIto 23:17, 30 January 2012 (UTC)

Kenji mentions roads (e.g. winding roads) where it would be reasonable to drive at a speed well below the signed speed limit, and suggests that there should be an additional tag for giving a speed recommendation. Scai links to a proposal where such a tag (maxspeed:practical=*) has already been proposed.

If I may add a remark: That proposal has been very clearly shot down during the vote, with mappers criticizing that a tag like that would be extremely subjective and situation-dependent. --Tordanik 08:40, 31 January 2012 (UTC)

Sometimes the highway department itself will post two limits (in the USA, generally one sign will be white [legally mandated] and the other will be lower speed and orange [recommended]): one for the speed at which one can legally go, and the other being the speed at which one should go if one is to be safe. I have seen this on very wiggly roads, and at a narrow bridge not far from me (I can upload a picture if need be). Arlo James Barnes (talk) 05:31, 15 November 2015 (UTC)

But then there are three different data points: The maximum legal speed, the recommended speed, and the practical speed (which may or may not be different from the other two). --Tordanik 18:01, 26 November 2015 (UTC)

I would be in favour of tagging the legal and recommended, but not "practical" (since that is not a physical feature whereas the others are in the form of signage). Of course, "recommended" is also just someone's opinion, but an informed one; I trust highway engineers to have done the math on what the safest speed might be. Besides, if anybody would be the authority, the traffic department would be. I suppose I should be responding at Proposed Features, however. Arlo James Barnes (talk) 02:26, 23 September 2017 (UTC)

not good due to the refusal. shall I tagging the roads strictly with 100 km/h out of town? or how can I mark dangerous places, although 100 km/h is allowed? --Kenji 22:56, 31 January 2012 (UTC)

I nevertheless think that such a tag can be quite useful for routing engines to estimate the required time and calculate the fastest route. This tag is obviously very subjective and depends on the car, the weather and the driver itself. But I know of several roads here which don't have a speed limit at all and don't allow higher speeds than ~30 km/h. There might be another possibility to automatically estimate the average speed by evaluating GPX tracks, but then you need additional information about whether the track has been recorded by a car driver or not. --Scai 20:09, 2 February 2012 (UTC)

With respect, the above discussion is out-of-scope for this article which is about legal speed limits not practical speed limits. Can I point you to Proposed features/Practical maxspeed which is a better place for further discussion? Can I suggest that we transfer this discussion to the associated talk page for that article? PeterIto 23:34, 2 February 2012 (UTC)

maxspeed direction + hgv

Is it maxspeed:hgv:backward or maxspeed:backward:hgv? Couldnt figure it out.

Should be maxspeed:hgv:backward. In my opinion the suffix backward/forward should always be at the end, because - in my understanding - those suffixes specify that the "main-key" (here: maxspeed:hgv) only refers to one driving direction (here: only backward). But some people will disagree with me, especially those who think of backward/forward as a condition. --Imagic 12:55, 9 August 2012 (BST)

Test of links: maxspeed:hgv:backward=*, maxspeed:backward:hgv=*, maxspeed:hgv:forward=*, maxspeed:forward:hgv=* Mateusz Konieczny (talk) 09:27, 18 November 2020 (UTC)

I created missing documentation pages, I think that it is sufficient Mateusz Konieczny (talk) 09:45, 18 November 2020 (UTC)

backward compatibility of extended tagging

Is it advised to always set maxspeed to a certain value, even if extended tagging already covers all cases?

Example:

- Option 1: maxspeed:forward=50; maxspeed:backward=60
- Option 2: maxspeed:forward=50; maxspeed:backward=60; maxspeed=50
- UPDATE: Option 3: maxspeed=50; maxspeed:backward=60

(And if yes, is it ok to use the smaller value to be on the save side? :-)

-- NachtSpazz 21:17, 24 October 2012 (BST)

The suffixes :forward and :backward are well established, there shouldn't be any problem to only use them (option 1). For the :lanes and :conditional suffixes the situation is a little bit different: both are quite new so I would always set a specific maxspeed (or maxspeed:forward/maxspeed:backward) value and additionally maxspeed:lanes/maxspeed:conditional. --Imagic 08:11, 25 October 2012 (BST)

Thanks, Imagic. Would you consider option 2 (with :forward and :backward) as harmful or just as useless? -- NachtSpazz 19:59, 27 October 2012 (UTC)

Option 2 bears a risk. Imagine someone updates only maxspeed to be 40. The result would be:

maxspeed:forward=50; maxspeed:backward=60; maxspeed=40

What is now the correct speed limit? I would really just go for option 1. --Imagic 20:17, 27 October 2012 (UTC)

This is the reason why I think, it should be well defined. Of course, if there is no issue with backward compatibility (and probably that's the case), option 1 is best. However, if some software is unaware of extended tagging, it would not have any input from option 1. With option 2 it would have at least some input (even if it was 40). From more recent software, I would expect that it uses 50 or 60 and ignores 40, because 40 is kind of default (as in the case of speed limits for lanes). But I have to admit that I don't know how any such software actually behaves. -- NachtSpazz 21:40, 27 October 2012 (UTC)

That's just my opinion: what applicatons use this key? I guess most of them are some kind of routing engines. Routing engines have to be updated quite often to keep up with the development of tagging schemes. So I think that every relevant(!) routing engines already supports :forward/:backward. That's why I would choose option 1. BTW: don't forget option 3: maxpeed=50 and maxspeed:backward=60. Possible, valid, but in my opinion less readable. --Imagic 08:19, 28 October 2012 (UTC)

It seems that at least my favourite app does not yet support :forward/:backward: GpsMid:Tracker:Feature Requests. But actually, option 3 looks to me like a good compromise.

At least there's a feature request now for this ;-) --Imagic 08:13, 29 October 2012 (UTC)

I would not say advised, but it is perfectly fine. I agree that "maxspeed=50; maxspeed:backward=60" seems like a best fit Mateusz Konieczny (talk) 09:38, 18 November 2020 (UTC)

Blanket speed limit in a municipality

Can a "maxspeed" key be added to ways defining a municipality boundary if the speed limit on all streets in that municipality is a certain speed unless otherwise posted? We have those here in British Columbia. -- DENelson83 04:26, 30 December 2012 (UTC)

In my opinion this is pretty common practice. Additionally please consider to tag the reason/source of this limit in the source:maxspeed tag. --Imagic 08:24, 31 December 2012 (UTC)

Really? I have never seen maxspeed tags on the boundary (=the ways of the boundary) itself. There are ideas like this (e.g. "defaults" in relations), but all these ideas are IMO still very experimental. But it is common practice to set the maxspeed tag on all ways (streets) within the boundary and add a source:maxspeed tag (and values like AT:urban), telling other mappers that the value is not taken from a road sign, but implicit.--Martinq 14:48, 31 December 2012 (UTC)

You are right, I misinterpreted DENelson83. I fully agree with you: yes for maxspeed on the ways within the area, no to maxspeed on boundary ways. --Imagic 14:59, 2 January 2013 (UTC)

And I misinterpreted my own idea. If an area within a municipality is defined as a relation, can the maxspeed value be applied to the relation instead of the boundary ways themselves? Doing it that way is much easier on the editors and on the database than having to apply the max speed to all of the street ways in the municipality, which is just too tedious and very redundant. -- DENelson83 (talk) 00:30, 31 May 2013 (UTC)

Hi, I'm not sure that my question applies to this tag; in my town (Copertino, LE, Italy) there is an order of the Major which limits speed to 30 km/h on all the town roads (and there are maxspeed signs at town entrances, with the note "su tutto il territorio comunale"), because of bad surface. Not sure if this apply only to residential area or to every road into administrative boundary. Anyway, can I add a maxspeed=30 tag to the landuse=residential area? --Magooz (talk) 15:53, 10 June 2014 (UTC)

EDIT: After a new survey, it's now clear that limits on the question above are applied to residential area only (because of the sentence "su tutto il centro urbano"). --Magooz (talk) 17:04, 16 June 2014 (UTC)

New attempt at realistic driving speed

The maxspeed:practical proposal failed for obvious reasons, but some way to tag roads (or road stretches) with empirical data would be useful. There is mtb_scale, sac_scale and trail_visibility and while they are subject to same subjective bias as a maxspeed:practical people still find them useful.

So perhaps one way to go is to try several more or less independent attributes for roads.

• traffic_flow=0-6 - heavy traffic with insufficient passing possibilities or many traffic lights, 1-6 to be interpreted as 1-6x20% expected reduction from maxspeed
• rush_hour_traffic=0-6 - could also be applied to whole areas
• narrow_winding_road=0-6 - some people like it, other do not but most will agree seeing one
• sightseeing_traffic=0-6 - heavy nuisance for some, POI for others
• mountain_road=0-6
• pedestrian_traffic=0-6 - pedestrian traffic frequently limits travel speed
• frequent_animals=0-6 - separate for night & day?

Even if some regional variation in scaling will inevitably sneak in this is not such a bad thing as long as is it remains halfway consistent throughout an area.

Just a first thought.. RicoZ (talk) 21:39, 17 October 2013 (UTC)

Sadly, OSM feels like a bad place to store such info Mateusz Konieczny (talk) 09:37, 18 November 2020 (UTC)

Railway speeds

The main page makes a passing note that railway=rail ways can also have speed limits. I should point out that (at least in the US), many or most rail lines have multiple speed limits. Much like auto vs. heavy truck speed limits, passenger trains can usually go faster than freight trains on a given stretch of track. (Is this true in other countries?) Major lines also often have an intermediate speed limit for high-priority freight trains: intermodal services (with containers or truck trailers) and "unit" trains that run directly from point to point. If the editor only wants to tag a single speed, the passenger speed limit should probably be used for routes that carry such trains (generally rare in the US), or the highest of the freight limits for freight-only lines. If an editor wishes to tag multiple limits, I'd suggest maxspeed:passenger=*, maxspeed:high_priority=*, and maxspeed:freight=*. Of course, there are other possible subtleties, such as multiple passenger speeds (the Acela Express is able to go faster than other passenger services in the Northeast Corridor, for instance). Any thoughts? —Mulad (talk) 20:25, 3 January 2014 (UTC)

I'll also note that ITO has a railroad speed map available here: http://www.itoworld.com/map/219 —Mulad (talk) 20:29, 3 January 2014 (UTC)

When children are present

How do you tag the ubiquitous sign by schools: "speed limit 25 when children are present"? -T99 (talk) 07:39, 3 March 2015 (UTC)

Is that a legally binding sign, or more like a reminder? --Tordanik 02:45, 22 March 2015 (UTC)

It is legally binding in my locality/jurisdiction (Santa Fe, New Mexico, the United States of America). Arlo James Barnes (talk) 05:31, 15 November 2015 (UTC)

maxspeed:children_present = 25 mph is used almost 500 times. --Mueschel (talk) 17:12, 16 January 2016 (UTC)

That breaks the rules set by Conditional restrictions, though: Only transportation mode and traffic direction should be part of the key, other conditions should be part of the value. Therefore, maxspeed:conditional = 25 mph @ children_present should be preferred. --Tordanik 14:21, 20 January 2016 (UTC)

Yes, that's the preferred way to tag it - but we would have to write a description / proposal first. The other one is de facto in use already. --Mueschel (talk) 22:34, 20 January 2016 (UTC)

Look at the Taginfo result more closely: The maxspeed:children_present key has been used predominantly around LA, often in something that appears like some kind of concerted mapping effort 5-6 years ago. There are other oddities, too, such as the very high percentage of nodes. That is not how an established tag looks like, and when you combine these observations with the fact that it contradicts a widely-used tagging convention, I don't really see any argument to use it over the alternative I suggested. Of course, a proposal or documentation would still be helpful. --Tordanik 17:43, 21 January 2016 (UTC)

Some form of maxspeed:conditional, maybe something like maxspeed=50 + maxspeed:conditional=25 @ children_present? Mateusz Konieczny (talk) 09:36, 18 November 2020 (UTC)

Default speed limit in addition to variable limits

At least in Australia, most places where there are variable speed limits, a sign also appears telling us the limit that applies if the variable sign is "blacked out". Any reasonable existing way of tagging this, or could it become confusing? --Ortho is hot (talk) 04:44, 3 June 2019 (UTC)

The bottom of the page on variable limits suggests "maxspeed:variable=yes, maxspeed=80" although I'm not sure that entirely fits it? --Ortho is hot (talk) 04:46, 3 June 2019 (UTC)

If those signs show the maximum speed limit (that is, the variable sign can only reduce the speed limit), then it fits. Otherwise, I'd say it doesn't due to the definition on the Key:maxspeed:variable page. --Tordanik 12:01, 21 June 2019 (UTC)

Default speed limits handling

https://github.com/westnordost/StreetComplete/issues/1998#issuecomment-676787192 has very interesting overview of problems of tagging scheme for maxspeed. Including points raised there in the maxspeed documentation would be useful Mateusz Konieczny (talk) 09:48, 18 November 2020 (UTC)

maxspeed:type for context codes, maxspeed for numeric values

If you take a look at taginfo, you will see that in most countries (except RO and RU) it is common to use maxspeed:type for context codes and maxspeed only for numeric values. I would suggest changing the table in the wiki page in this way. discuss here: https://community.openstreetmap.org/t/maxspeed-type-vs-maxspeed/98222 --Langläufer (talk) 22:01, 20 April 2023 (UTC)

maxspeed=implicit and usage with traffic_sign key

In the developers section, Parse subsection, only one numeric value is allowed.

However there is a least on documented usage when a non-numeric value is used. The use of maxspeed=implicit is documented both in its own page maxspeed=implicit and the key traffic_sign=*

This should be documented in this page (both in the Parse subsection and elsewhere) and it should be also noted in this page that the key maxspeed is also use in combination to traffic_sign=* (with a somehow different meaning.)--AnyFile (talk) 07:48, 5 September 2024 (UTC)