Proposal talk:Implicit maxspeed

Separate information on whether it is signed or not and in what traffic zone the road is located

I fear this proposal is not thought through. Tagging explicit and implicit speed limits all in one key will not solve our problems.

One major issue (especially in regard to StreetComplete) with maxspeed:type=* (etc) is that it puts two infos in one:

• that there is no maxspeed sign
• in what kind of traffic zone the road is located

Which means, it is not possible to record one (e.g. "there is no sign / there is a sign") without the other. Someone having access to the information whether there is a sign or not (=whether it is an implicit speed limit) doesn't necessarily know in which traffic zone a section of road is located. Default_speed_limits shows that there are many different kind of traffic zones, each dependent of the country. There is not only urban, rural and zone30 (for which it might be reasonably easy to decide).

So, this proposal does not solve that issue.

Instead, one may argue that it aggravates the issue, because with maxspeed=<country code>:<traffic zone>, one tag now consists of three infos instead of two:

• whether there is a maxspeed sign
• if there is no maxspeed sign, in what kind of traffic zone the road is located
• if there is a maxspeed sign, what is the value on that sign

Why is this a problem beyond the principle that one tag should contain one info?

Because the information about in what kind of traffic zone a road is located can not only be used by software to determine default speed limits. It can be used in a couple of more different cases. For example:

• outside settlements, no parking lanes are expected, parking is forbidden
• outside settlements, no sidewalks are expected, no street lighting is expected
• inside settlements, no shoulders are expected
• inside settlements, roads usually have names, outside settlements, roads usually have refs
• ...and probably many more

But if this information is generally missing whenever an explicit speed limit is posted, this would be unfortunate. Or actually, this is unfortunate, because this is the case currently. A proposal that fixes maxspeed tagging should take this into account and fix this too.

I didn't completely think this through, but I want to make a counter-suggestion:

1. Introduce maxspeed:signed=yes / no
2. Maybe instead bless zone:traffic=<country code>:<traffic zone> (it already exists and is in use). Or instead, introduce a tag like urban=yes / no
3. Define maxspeed=* to be numbers only

--Westnordost (talk) 10:02, 7 September 2021 (UTC)

While I share your critique, I do not believe the effects of knowing the traffic zone context are as described: outside settlements, no parking lanes are expected but you can usually/often park aside the road, which is not generally forbidden. Whether you can expect sidewalks outside of settlements depends on the area. Similarly, you cannot expect roads to have either refs or names based on the location outside or inside a built-up area, these are all assumptions based on some local situation which cannot at all be generalized. Neither can you globally expect roads in settlements to have names, not can you expect roads outside settlements to not have them. --Dieterdreist (talk) 10:14, 7 September 2021 (UTC)

Yeah, maybe I am too creative / exaggerating the possible use cases of when the traffic zone is always tagged independent of implicit or explict maxspeeds. Point is: It makes for reasonable assumed defaults, i.e. if it is not tagged, a data consumer may assume with some certainty that e.g. the road is not lit when outside a settlement. As developer of StreetComplete, I often get feedback from the (German forum) community along the lines of e.g. "do we really want to tag sidewalk=*/other tags on every single road when it is clear that outside settlements, there is clearly no sidewalk?". And I am like - well, how should software know if any given road is in or outside of a settlement? In or outside of a school zone, a 30 km/h zone etc? I'd be glad to let the app not ask certain questions outside of settlements, but for that, I need this information --Westnordost (talk) 10:25, 7 September 2021 (UTC)

Sure, I understand the frustration that some information is easy to be "assumed" by humans but hard to figure out without explicit tags. I think in this example SC should continue to ask the same question for maxspeed, but if there's an explicit limit the user is then asked in a follow-up quest to specify if the road is inside or outside of the urban area. If an implicit maxspeed tag is the answer by the user, this information can just be added without having a dedicated quest afterward. --RubenKelevra (talk) 10:37, 7 September 2021 (UTC)

Well, I think there's a misunderstanding. There are maxspeed signs for implicit maxspeed zones, in Germany for example there's the yellow "city limit" sign. Tagging maxspeed=50 on the other hand is wrong, there's no sign "on the ground" which states that a certain street has a speed limit of 50 - it's implicitly applied for the whole area.

This proposal does not change anything about the "zone:traffic"-Tag, which should be used IMHO.

I agree, the maxspeed tag should focus on one thing. But if you ask someone on the street how fast one is allowed to drive on a road the response would be "50, cause you're in the city". So tagging that a city limit applies is the best solution to transfer this information. The only other option would be to tag maxspeed=None and use zone:traffic=DE:urban to declare the default assumption. But this would violate the general idea of the maxspeed tag to always state the legal speed limit.

Additionally tagging maxspeed=100 instead of maxspeed=DE:rural is misleading, there's more than one legal speed limit on the road depending on the vehicle type as you're driving.

--RubenKelevra (talk) 10:23, 7 September 2021 (UTC)

It all boils down to your interpretation of the meaning of the maxspeed tag. Vehicle class based restrictions go on top and may be different, that’s clear and someone driving such a vehicle must take them into account. There are also weather based restrictions, e.g. 50km/h if visibility is inferior to 50m. Maxspeed is the maximum allowed speed, it does not imply everybody can drive at this speed. There have been discussions on this in the past, and it was therefore a good decision to prepare a proposal, but I am not very confident that the solution is a change in the definition for a tag that is used millions of times for almost 20 years.—Dieterdreist (talk) 12:55, 7 September 2021 (UTC)

So instead of having maxspeed=XX:yy which implies all the default speed limites documented here you want us to tag all those information explicitly on all ways in OSM? Or did I get you wrong here? --RubenKelevra (talk) 09:41, 3 May 2022 (UTC)

exactly, not on all ways but on all roads, and we are already doing it. —Dieterdreist (talk) 09:50, 3 May 2022 (UTC)

What would be the benefit of that over my proposal? --RubenKelevra (talk) 10:02, 3 May 2022 (UTC)

It has all already been said in various discussions where you have taken part as well, just read the wiki. First of all, the benefit should be demonstrated by who wants to change something, not who wants to keep the status quo, which is a benefit on its own. —Dieterdreist (talk) 10:09, 3 May 2022 (UTC)

I've never seen a tag for implicit speed limits for HGV anywhere in Germany before. So stop lying. --RubenKelevra (talk) 05:29, 9 May 2023 (UTC)

Makes it more complicated to get to a maxspeed value

If we went by this, it would mean every data consumer would have to know how to translate every implicit maxspeed value in the world to an actual number. What we have now is a system where the data consumers do not have to know any implicit maxspeeds at all, they get all maxspeed values in a consumable form (number). The source:maxspeed tags (and its duplicates like maxspeed:type and other) are only there for maintenance and for local mappers (QA, mass retagging in case the law changes, etc.), a routing application does not have to care at all about these. You proposed change would put a lot of burden on data consumers, create a new problem that we do not have now. IMHO the root of the current problems are people with the not invented here syndrome, who for some reasons believe it is better to introduce yet another duplicate tagging scheme, rather than using the established one. Let's talk to these... --Dieterdreist (talk) 10:10, 7 September 2021 (UTC)

Do you know the Default_speed_limits page and did you know that there is a parser for the table on that page that translates the values given in that table into an easily consumable JSON? Here is the output of that parser for Germany. Note that not a single source:maxspeed=<country_code>:<traffic zone> tag is needed to get the correct maxspeed values. If you didn't know this existed, does this change your opinion at all? Also, would you comment on my counter-suggestion? My counter-suggestion doesn't forbid to tag maxspeed=* if there is no sign, instead maxspeed:signed='yes / no' is tagged to indicate that. --Westnordost (talk) 10:20, 7 September 2021 (UTC)

Frankly, I prefer the simplest solution because I will likely not have an osm-default-speeds parser with me when I map. IMHO Streetcomplete, in this isolated instance and as a rare exception, is part of the problem because you choose the younger and less frequently used key (with the exact same values and semantics, IIRR) rather than confirming the established scheme. --Dieterdreist (talk) 10:30, 7 September 2021 (UTC)

Well using the value only works for cars. Heavy trucks for example have a different speed limit. So the parser would need to know what those values mean anyway. --RubenKelevra (talk) 10:25, 7 September 2021 (UTC)

For trucks there is maxspeed:hgv=*, and for other vehicle classes there are similar tags. It is not an issue. --Dieterdreist (talk) 10:32, 7 September 2021 (UTC)

Well, if you don't have the osm-default-speeds parser with you while mapping, how are you supposed to know what to add to this tag? Also, this cannot be verified on the ground, a city limit sign can. --RubenKelevra (talk) 10:40, 7 September 2021 (UTC)

Why would you need/want a osm-default-speeds parser with you when you map? The point I was trying to make is that for the most part, you don't need any <country_code>:<traffic zone> tagging for implicit speed limits to be inferred. Look, let's assume for a moment that maxspeed=* is not tagged but source:maxspeed=IT:rural (or something) is. Then, data consumer still need some sort of table that maps <country_code>:<traffic zone> values like IT:rural to actual speed limits. And this table doesn't exist. But what exists is another table that doesn't even need the <country_code>:<traffic zone> values to infer the actual speed limits. Ergo, for the most part, <country_code>:<traffic zone> is superfluous.

But anyway, just wanted to let you know that this exists, it is really a bit off topic because neither the original proposal nor my counter suggestion in the first comment includes to get rid of <country_code>:<traffic zone> tagging. --Westnordost (talk) 10:38, 7 September 2021 (UTC)

"they get all maxspeed values in a consumable form (number)." Unfortunately not. In germany there are a lot of different maxspeed-limits for different vehicles (for example hgv). OSM data should not only be for motor vehicles up to 3.5 t. Instead osm data should be as universal and independent of data users as possible. Less interpretation, more otg! OSMRogerWilco (talk) 06:00, 10 September 2021 (UTC)

Yeah exactly. There's a huge table available here which allows us to look up which is the default speed limit for each type of vehicle. maxspeed=YY:xx would just specify the class applied here as "being the default with no further restrictions". So a 50 kpm sign outside a city would need maxspeed=50 plus a zone:traffic=DE:rural to imply the other restrictions. While no sign, just the default would be maxspeed=DE:rural plus zone:traffic=DE:rural.

Just using zone:traffic=DE:rural would just mark it as "it's outside a city". The maxspeed=DE:rural does explicitly mark, that there's no further speed restriction sign – so the defaults apply. --RubenKelevra (talk) 10:02, 3 May 2022 (UTC)

I completely agree with "Dieterdreist 10:10, 7 September 2021" Pyram (talk) 18:54, 7 September 2021 (UTC)

How would this proposal help exactly?

It states "This proposal aims to rectify the fact that we now have four different ways to tag an implicit speed limit", and seems to hope to accomplish that by creating yet another different way to tag an implicit speed limit.

Obligatory xkcd: https://xkcd.com/927

"This proposal, if accepted, will deprecate and discourage the use of maxspeed:type=*, source:maxspeed=*, and zone:maxspeed=* for implicit maxspeed zone tagging in favor of implicit values to be used in the maxspeed-tag itself." OSMRogerWilco (talk) 05:47, 10 September 2021 (UTC)

The proposal documentation is not yet complete in regard to the consequences for established tagging. It would also mostly deprecate the key maxspeed=* in the current form and would introduce maxspeed tagging on a country and regional base (think for example US States) with zone references rather than the actual maxspeed as a number value. --Dieterdreist (talk) 16:13, 10 September 2021 (UTC)

One can "deprecate and discourage" all night long; it will not change the fact that for new tag to gain acceptance and replace all other tags, it will take quite some time (years at best, much more likely decades, if it ever happens), even if the proposal is fantastically good and covers all use cases exceptionally well (which this one does not: see other comments), and that in the meantime all existing router and other data consumers wanting to make use of speed limits will need to support not just this now proposal, but all popular existing tagging schemes. So their job will be just be harder, not easier, if such additional standard is accepted. Now, for new routers being created decades in the future, if the usage of other tags has dwindled beyond being noticeable, only then their job becomes easier - but until then it is going to be harder for everyone. And that is best case scenario, providing that there is overwhelming support in all OSM editors and they all jump in to support new scheme, it gets promoted on conferences, online and offline materials get updated with it, old users gain knowledge of it (or they'll just keep using what they know) and support it etc. It will not happen just with "OK, 50 people will vote and then we'll change the wiki and all is going to happen magically afterward" - one needs to be realistic about what is actually possible, and history of how other tag changes happened. You can use Taghistory for that research. For example, see how transition from `amenity=hospital` to `healthcare` is going. It has taken it 5 years to get to about 30% usage of old tag. But both tags are growing, so one would guess looking at the graph it would take at least another 15 years until they are evenly matched (or much longer, depending), and maybe another 50-200 years until new tag is so much more popular that old tag can be retired and data consumers rely only on new tag. That is what the `xkcd` comic is trying to explain to you: inventing a new standard will just add a new standard, it will not replace obsolete ones, not in any reasonably quick timeframe. --mnalis (talk) 21:15, 11 September 2021 (UTC)

Well, the issue is that there's no real "standard". We have just multiple different methods by "habit". The idea is to implement a standard by vote. This method has been widely used – as stated in the proposal: "In some countries implicit values, following the scheme maxspeed=<countrycode>:<zone type> has been widely used.". I feel like spreading this single information in multiple tags just doesn't make any sense. With the maxspeed class by country code, it should be possible to determine the maxspeed for all types of vehicles. Note that this is only about ways where there's no explicit speed restriction with a "30 kph" sign or something like that. So it's meant to tag maxspeed-zones and default max speeds explicitly. --RubenKelevra (talk) 09:36, 3 May 2022 (UTC)