Both source:maxspeed=sign and maxspeed:type=sign seem to mean exactly the same thing. Shouldn’t we deprecate one of them to avoid a future database mess? Or should I add both whenever I set maxspeed based on speed signs? (Or neither?)
I think a formal deprecation won’t be possible for some time.
I only tag maxspeed:type, and replace source:maxspeed in my area when I’m touching the roadways anyway.
Both have their place. The machine-readable format imo belongs into maxspeed:type, but there could be circumstances, where one might choose to use a more human language description. That one can then be added as source:maxspeed.
3 Likes
source:maxspeed and maxspeed:type are basically interchangeable - source:maxspeed was more in use in e.g. Germany whereas maxspeed:type was common in the UK.
If i remember correctly - StreetComplete started using maxspeed:type which then became the “defakto” standard.
Thats the reason i switched to using maxspeed:type
Flo
1 Like
See SC #492 comment for summary why maxspeed:type has been chosen by StreetComplete instead of source:maxspeed
Also, things like e.g. maxspeed=30 + maxspeed:type=HR:zone30 might theoretically also be source:maxspeed=HR:zone30 (i.e. implicit - only defined by law, without anything visible on the ground), source:maxspeed=sign (vertical signalization, i.e. traffic sign), or source:maxspeed=markings (horizontal signalization, i.e. only paint on the asphalt)…
But for most data consumers (i.e. mobile navigation apps), it does not really matter (they usually only care about maximum speed, so they mostly use maxspeed:type=XX:zzzzz as a fallback when maxspeed=* is not specified)
2 Likes
source:maxspeed and maxspeed:type are basically interchangeable - source:maxspeed was more in use in e.g. Germany whereas maxspeed:type was common in the UK.
I agree that it doesn’t matter, and it doesn’t lead to a “mess” either, as long as the tags are used consistently. Having several keys to mean the same thing is not a mess, at most it is a minor problem, the mess would be having the same tag intended to mean different things.
In this case, we started mapping these as source:maxspeed, the british liked the idea but didn’t like the key, so they reused the scheme with a different keyword, and as they got support from the author of a widely used app (Streetcomplete), we now have these synonyms in the database, really not a big deal.
1 Like
So you suggest adding/keeping both, despite the redundancy? To millions of ways?
if you mean dual tagging (adding both source:maxspeed and maxspeed:type with same value on the same way), then no, please don’t do that.
What is recommended (as I understand it) is to follow country consensus. If Germany prefers source:maxspeed, use that in Germany; if UK prefers maxspeed:type, use that in UK.
That approach creates minimum amount of friction; and data consumers who care about it already have to process both tags anyway.
Yeah, just leave existing ones as they are… As far as OSM tagging problems go, this one (multiple tags meaning mostly the same thing) is of the most benign possible variety.
I disagree on that. It leaves room for having both keys with different values on the same object. For sure it’s not the end of the world but still an issue which should be fixed.
1 Like
Yes, it does. And I’ve given example above in Source:maxspeed=sign vs maxspeed:type=sign - #4 by Matija_Nalis why it might be perfectly legitimate to have different source:maxspeed and maxspeed:type values in some cases (as the meaning and usage of those two tags is only very similar, and not 100% the same).
Here is one live example[1] which seems OK to me: Way: Meisenweg (28247487) | OpenStreetMap, even if those two tags differ in value.
But yeah, in many cases, they might be the same, and it thus would be preferable in those cases not to break 2NF (by having supposedly same things that can get out of sync[2]).
Well, how would you propose to fix it, then? Because I myself cannot fathom systematic way which would not create a lot more problems than it solves.
The best I can imagine is someone making perpetual auto-renewing MapRoulette task which uses overpass query like this to detect places which have maxspeed:type different from source:maxspeed, and have them manually verify if that is OK and should be ignored, or whether there is something that should be fixed (e.g. removing incorrect tag completely).
Perhaps some people would find joy in solving that QA task. I myself likely wouldn’t. 
Since you brought this up, what is the difference between maxspeed=30 + maxspeed:type=DE:zone30 and maxspeed=30 + maxspeed:type=sign? Why differentiate the speed limit that comes specifically from a zone sign? Does it make any difference for QA?
We don’t have “speed-limited zones” in Brazil, that’s why I ask. It appears to me that a “zone 30” can never have a speed limit different than 30, so if the law ever required a change to a zone with a speed limit of 40, that would require changing all signs to a “zone 40” anyway. How does zone30 help re-survey the affected ways? Or does zone30 represent an implicit type of speed limit not determined by local signage?
You could imagine a situation where you add the zone sign using traffic_sign=*. In practice, maxspeed:type=sign is used for signs that are in the vicinity of this way, while maxspeed:type=DE:zone30 means “There is no sign necessarily on this way, but there are in other places which mean that this street has a speed limit of 30”. So on re-survey, you might have to check adjacent streets too for the familiar
It also helps to show that there is nothing to be done if the law changes, which might be different if e.g. bicycle roads in Germany (currently maxspeed=30) were changed to 25.
2 Likes
“Zones” are unbroken areas (polygons) which contain multiple streets (and/or their parts). So, for QA, it help to know that if you have 90% of zone30 streets mapped, you will know the shape of that “zone” area, and thus will know what streets are missing the details.
For regular “30” signs there is no such implication - they apply only to the single road (or part of it), and a road between two maxspeed=30 roads can be e.g. maxspeed=60.
It is also related. If for example the country had a law that said that all “quiet traffic” areas are to be zone40, and later they reduced it further to zone30, you’ll know what needs to change (so you can even retag automatically). If it was just a regular sign saying that maximum speed is 30, you wouldn’t know, so you’d have not only to manually resurvey each street, but also have some sort of keeping track of what was resurveyed (e.g. either external tasking manager, or adding check_date:maxspeed on all of them so you can know which ones have been resurveyed after law change, and which were not resurveyed yet)
I guess it can be both (depending on jurisdiction).
In Croatia for example it is AFAIK always signed (via vertical signalization i.e. traffic signs), but not on every street / crossing (like regular maxspeed signs), but only on “entrances” to the zone. So you may pass e.g. 10 streets without any signage, but they could all still be limited to maxspeed:type=HR:zone30 (with implied maxspeed=30) instead of maxspeed:type=HR:urban (with implied maxspeed=50).
So you must keep track of when you’ve entering some zone, and when you’re exiting it, to have an idea what is actual maxspeed allowed in current area.
2 Likes
In addition, there is also zone:maxspeed=* to denote this information. This can be useful when inside the zone, there is another maxspeed:type=sign that further lowers the speed limit.
The situation in Germany is the same.
1 Like
To me it seems that it’s not possible to do this automatically because:
So, first you need to survey the area to check if the ¨zone 30” signs have been changed to “zone 40”. But, if the signage does not indicate the speed limit and instead indicates:
Then, of course, the signage is legally linked to a new speed limit when the law changes and automatic retagging is possible. But in that case, one would have to map it as something like maxspeed:type=quiettraffic or similar, using local law terminology.
However, most examples I see on the wiki show zone signs accompanied by an explicit speed limit. The two exceptions are living streets (highway=living_street) and bicycle roads (bicycle_road=yes), both easy to locate.
Do the urban speed limit types always correspond to single speed limits within the same country? Or can they refer to different speed limits in the same country based on, say, highway, or some other way tags or geometry properties (like being divided or not)? For example, could maxspeed=30 be valid on some maxspeed:type=DE:urban ways, or only maxspeed=50? I ask this because default speed limits for highway=residential seem oddly high for urban areas in most European countries in this table (even for hgv), far higher than most routing software have traditionally assumed the speed limit is while calculating routes.
Depends on local legislation. If the legal speed limit changes e.g. based on number of lanes or divided highways, then sure.
The legal speed limit is just that - the legal limit. Most traffic laws have some version of “Only go as fast as you can reasonably control” which of course depends a lot on circumstance, e.g. parking. Routers should not assume that the maxspeed can always be driven - but if they otherwise calculate something higher, then this is the limit.
urban should be the same limit in the country (or more generally in the entity that is in the prefix), every zone (speed limit traffic context) should have their own keywords, which zones exist depends on the law in the area.
In Germany, DE:urban always means 50, a limit of 30 can only come from a sign or a 30-zone (which are signed)
There could be municipality announcement saying they’ve changed that zone around school XYZ from “zone40” to “zone30”. When you already know what zone40 there was, it can be done without physical on-the-ground resurvey (note that depending on the municipality, that & some other features may have been armchair-mapped too).
No, they do not (i.e. they change depending on lots of stuff). See https://wiki.openstreetmap.org/wiki/Default_speed_limits and even better (and easy to play with) Legal Default Speed Limits webapp.
This apparently isn’t working at the moment. When I try highway=unclassified in Croatia, I get this:
maxspeed=90
maxspeed:bus=80
maxspeed:bus:conditional=70 @ (articulated)
maxspeed:conditional=80 @ (trailer); 80 @ (weightrating>3.5)
maxspeed:school_bus=80
But I get the idea.
This section defines that an “urban” condition is inferred from source:maxspeed, maxspeed:type, zone:maxspeed or zone:traffic values that end in the string “urban” (like DE:urban or BR:urban, but it would also include something like “suburban”, not in use though). In this order. So, if some way has source:maxspeed=DE:urban and maxspeed:type=DE:zone30, the urban rule will be activated instead of a zone30 (not yet listed). If no maxspeed is mapped, this results in an implicit maxspeed=50. In this specific example, maxspeed is rarely missing in practice (only 2 ways in Germany), but if maxspeed was removed, then the resulting speed limit would be wrong in more than 100 ways. This means that mapping maxspeed is expected regardless of this extra tagging, and so, that replacing it with any of these tags is not (at least for now) a goal, and it is necessary to keep them synchronized through validators. I also noticed that it is possible to use either source:maxspeed or maxspeed:type with these values, that’s why both continue to be used almost equally. source:maxspeed=sign, maxspeed:type=sign or source:maxspeed=implicit make no difference, so source:maxpeed=sign or maxpeed:type=sign are optional in practice and this currently allows combinations such as source:maxspeed=sign + maxspeed:type=DE:zone30 and source:maxspeed=DE:zone30 + maxspeed:type=sign, as well as source:maxspeed=implicit + maxspeed:type=DE:urban (in which case source:maxspeed is redundant). This is important to note regarding my original post, as there may be edit wars between mappers who strongly support one tag or another.
I just updated the filters for Brazil in that section. If data consumers are expected to follow this, it would now be ok to use only maxspeed:type=BR:urban and maxspeed:type=BR:rural, for all ways, major and minor, even without a mapped maxspeed. But if we used only source:maxspeed=implicit, this would also mostly work as long as the app can automatically detect if a way is in an urban area (as Valhalla does), with the exception of a some regional highways that cross urban areas (although most have a reduction to urban speeds; in any case, almost always with explicit speed limit signs). So, mapping urban and rural at a large scale seems like a tagging workaround for a complex feature that many apps are not willing to implement, but could.
For Brazil, if maxspeed is not mapped, only maxspeed:type or source:maxspeed are, then inferring rural from {has no sidewalk} would give poor results in many spots in urban areas (if sidewalk was completely mapped), but these stretches tend to be relatively short and the effect would be limited. But if this becomes a displayed speed limit in navigation software, it would induce drivers to drive much faster than allowed. This also does not work with sidewalks mapped as separate ways. Similarly, without maxspeed=*, inferring urban from lit=yes would result in an incorrect low speed limit on several major highways (if lit was completely mapped).
I also see that there is an incentive to map dual_carriageway=* . This is not common practice yet, but could become so if communicated to the local communities and foreign teams (Kaart, Apple, TomTom, etc.).
if some highway has these tags, it means the data is inkonsistent and should be resurveyed.
source:maxspeed=sign gives the reason why you had tagged maxspeed. Could be LocalKnowlede or a link to a public picture as well. Any value is applicable.
maxspeed:type=sign describes how a speed limit has been set into force.. Could be sign or DE:urban.