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:
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.
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
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.”
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.
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.
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.
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.
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
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.
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.
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.
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”)
Map an explicit (legal) zone, as opposed to some other area where maxspeed:type would apply? As I said, this might not apply in your country, but it might in others.