It doesn’t change the legal implication, though. And downhill, a bicycle can easily reach 50 km/h.
Nevertheless, we should prefer explicit tagging + source to just tagging “signs” or “regulations”. Otherwise, we would just be tagging traffic_sign=* and let the data consumers do the work.
I do not see a clear line here:
On one hand we want to explicit tag maxspeeds for (normal cars) because it is too complicated for data users
on the other hand we trust on default access values.
For example everyone in the world should know that in Germany:
pedestrians are not allowed on highway=path bicycle=designated.
mofas are allowed if a cycleway is out of town (which is also not explicit)
or even harder: maxspeed:bicycle=7 on a highway=footway with bicycle=yes
My point of view is:
Default values are fine, but there should be ONE machine-readable database listing these default implications. (A bunch of hard to find and non up to date wiki pages is not the right medium)
I read your points and I agree. There are already a lot of implicit defaults that data consumers have to assume. Some are documented, some are not. And the wiki is probably not the best way to store them. Maybe someone could come up with some sort of relation that we could use to define defaults? So that every country could define their own defaults. So some form of relation like this:
type=defaults
defaults_for:highway=motorway
maxspeed:advisory=130
maxspeed:bus=80
maxspeed:bus:conditional=60 @ (trailer)
[…]
or
type=limits
name=DE:urban
maxspeed:motor_vehicle=50
so you could use limits=DE:urban and it would pull in the values.
I’m not going to fully flesh out a proposal, just suggesting that having defaults or named limits in a form like this, would maybe be a way to tackle this, instead of yet another Wiki page. Of course, we could end up with hundreds of these relations and no one understanding which one is which. I’m more or less brainstorming a bit here, so take it with a pinch of salt.
1 Like
And once default speed limits change you are unable to update data without resurveying everything from scratch.
You need at least extra tags to denote whether it is signed or result of default speed limit (and which one!)
And mapper needs to be traffic lawyer to tag things correctly.
yes, then you need two tags and you are still able to automatic correct changes in default speeds.
eg. maxspeed=100 and source:maxspeed or maxspeed:type = XX:rural
I do not see this point, if we talk only about normal car maxspeed
1 Like
Bicycles and the like are excluded from that wiki page, see Default speed limits - OpenStreetMap Wiki
For the famous “no speed limit” to apply, it actually needs to be classified as a motorway.
maybe I didn’t understand you correctly, but there are other places where no limit applies: “ Diese Geschwindigkeitsbeschränkung 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.”
2 Likes
I dont get that? You strictly map what is set up as signs. Not less, not more. No need to be a lawyer, just wear your glasses.
And when Germany will decide to switch from 50 to 30 as a default for DE:urban we can to the simple search and replace in the Dataset with this pseudocode:
if (maxspeed=50 and maxspeed:type=DE:urban)
put maxspeed=30
Done - I dont see ANY of the complexity you envision.
Flo
2 Likes
And just as a Datapoint for this discussion:
In my maxspeed QA i have 18600+ tagging issues for maxspeed related issues in Northrhine-Westfalia alone - Just some examples:
- problem=“maxspeed=30 on living_street”
- problem=“maxspeed:type=DE:rural is 100 but maxspeed contains 70”
- problem=“source:maxspeed=mapdust-ticket is unknown”
- problem=“source:maxspeed=urban is unknown”
- problem=“maxspeed and maxspeed:forward/backward - overlapping values”
- problem=“source:maxspeed=mapillary is unknown”
- problem=“source:maxspeed=extrapolation is unknown”
- problem=“source:maxspeed=DE:rural is 100 but maxspeed contains 50”
- problem=“source:maxspeed=http://flickr.com/photos/jon_osm/1559473523/ is unknown”
- problem=“maxspeed:type=DEːurban is unknown” (Look at the colon)
- problem=“maxspeed=DE:urban is not numerical”
- problem=“maxspeed:type=DE:zone50 is unknown”
And there are ton of source:maxspeed/maxspeed:type related values which i highly doubt. Mappers do have issues in putting correct values in there so another datapoint with redundancy in cross-validating maxspeed and zone/source/type maxspeed tagging is highly welcome.
Most of the time this does not match, there is a lot more broken than that and worth looking at the surrounding.
Flo
1 Like
So what would you tag in case where there are no signs and speed limits defaults to some value?
Actual speed limit may depend on whether it is in urbanised area, is it dual carriageway, lane count and many other parameters.
OK, if you tag both then it can work. But you WILL get
as result
1 Like
As somebody who posesses a drivers license i typically know how fast i am allowed to go. Based on “where am i - Urban area or outside” or do i have gone past some signs. I would expect the average mapper to be able to take this decision aswell. So i would expect the mapper to be able to easily put in maxspeed and the auxiliary tags of the source of their wisdom.
I am trying to make it easy for mappers AND for consumers of the dataset. For this i would expect maxspeed to always be numerical (except the unit in kph/mph) for easy consumption of speeds.
For validation, change in legislation, confidence in the values i’d like to have the auxiliary tags.
And as i showed the redundancy in these values uncover a lot of errors people make. And these values only make it visible - The bug/mismatch/wrong tagging was there anyway, but now we can see something is broken.
And this is what i consider “good design” - Add a little redundancy which makes it possible to early detect problems.
Flo
2 Likes
zone:traffic=DE:<zone>
maxspeed=<the default for the zone>
source:maxspeed=DE:<zone>
This might feel redundant, but it tells you:
- Are there default limits to apply (
zone:traffic) - What’s the maximum speed?
- What’s the source of the maximum speed (implicit by
DE:<zone>, or explicit bysignormarkings)
This makes re-tagging easy, should the defaults change and, as @flohoff already wrote, they allow you to easily spot mistagging.
2 Likes
This violates the foundational process of normalizing a database. You are effectively adding data into one table that you already have stored in another. More importantly it now requires N changes to update all affected records (each street in the zone) instead just 1 change to update the speed zone record itself.
1 Like
This violates the foundational process of normalizing a database.
right, but it is done on purpose, because it makes evaluation of the maxspeed much easier and is in line with what data consumers are expecting, and allows for better maintenance (the reason of the limit is given and changes to legislation can be implemented much easier this way). Inconsistencies can be automatically detected and manually fixed. A crowd sourced database sometimes is better off with some redundancy and less complexity
2 Likes
Where can I find this speed limit record (data base)?
Is it machine readable?
https://wiki.openstreetmap.org/wiki/Default_speed_limits attempts this
OSM tagged data is not a normalized database and there are some trade-offs not present in a typical normalized database that is edited by software under centralized control.
2 Likes
My point is that you’re duplicating values. You are already stated that street fall under a particular set of staues that determine speed and other regulations. That street type is effectively a primary key for the particular regulations. Copyng values from record back to the street way creates redundancy and msy cause problems when the changes are converted to xml.
I looked at this again and thought about it.
source:maxspeed, zone:maxspeed, maxspeed:type describe the same thing. Also zone:maxspeed is not only for zone signs but also for general zones like urban, rural, motorway. However, it cannot take the value “sign”.
None of the tags were ever proposed properly, they are all simply in use.
I share the argument that source is something descriptive and not suitable for structured data. I therefore also consider maxspeed:type to be the best approach and zone:maxspeed to be completely superfluous. I see no reason to prefer it at signed zones.
e.g. Use in DE:
| zone | source:maxspeed | maxspeed:type | zone:maxspeed |
|---|---|---|---|
| DE:urban | 156 000 | 61 000 | 11 000 |
| DE:(zone)30 | 106 000 | 86 000 | 92 000 |
| DE:rural | 21 000 | 15 000 | 300 |
| DE:motorway | 20 000 | 840 | 60 |
| - | - | - | - |
| sign (intern.) | 444 000 | 196 000 | - |
| total (intern.) | 2 000 000 | 713 000 | 223 000 |
No. As an example, the latter two exist in the UK but are actually legally slightly different (and the tagging can be a bit variable**). Looking at the usage of the first, the most popular value is “sign”, which is clearly not the same. Usage may be interchangeable in some places, but not everywhere.
** partly due to the way that StreetComplete prompts for the information, and partly because it’s actually quite complicated to determine the on-the-ground situation sometimes, especially where signage isn’t great.
Sorry, I don’t get your point. Yes, there is as I already wrote the difference that I can’t use zone:maxspeed with value sign but what can I do with zone:maxspeed what I can’t do with maxspeed:type or source:maxspeed? There are differences in usage (counts), but the wiki pages describes since their creation the same (with the exception of “sign”)