Proposal talk:Dynamic maxspeed

Bad idea

Resolved

you want to replace a tag that is over 4000 times used? You goal can be reached by adding dynamic_maximum= (or something similar) to maxspeed=signals without changing an establish key/value pair. Afaik routers don't assume maxspeed=none if there no valid numeric value. Afaik OSRM use 90. SunCobalt 16:01, 20 September 2012 (BST)

I think this is not a bad idea. The tag maxspeed=signals was something that bothered me quite often for the reasons given in the proposals. The tag maxspeed should IMO contain the maximum allowed speed whenever possible, so that routers have at least a good guess of the possible speed. But I wouldn't use the key dynamic_maxspeed; I would prefer maxspeed:dynamic so that it is near the maxspeed key in editor. SunCobalt is of course right: 4000 times used is a lot. But: what information carry those 4000 tags? --Imagic 16:28, 20 September 2012 (BST)

The tag is up for discussion, not fixed. -- Eckhart 16:52, 20 September 2012 (BST)

your proposal to use maxspeed:dynamic is quite good as it does not require to change the established maxspeed=signal but could be used to specify it a bit more SunCobalt 19:49, 20 September 2012 (BST)

Of course routers may use any speed as an estimate if maxspeed=signals, which is exactly why the road default is the only sane choice.

OSRM using 90 for signals is a really bad idea. It explains why OSRM is the only router to route directly through Munich [1], and it shows that this proposal is really needed. -- Eckhart 17:13, 20 September 2012 (BST)

I appreciate it to bring more useful data for road segments with dynamic maxspeed signals. But changing an established key/value pair is always difficult. The tag change process will not reach many and will will end up with two different ways to tag it. Therefore I prefer a extension/specification over a change SunCobalt 19:49, 20 September 2012 (BST)

If the proposal only suggested to replace one tag by another, I'd probably agree with you. However, in this case information is added, and the replacement can (in fact, has to) take place while adding information.

Also, maxspeed=signals has always been a strange value in a list of numerical values (if you think of "none" as ∞). The proposal conveniently corrects this. -- Eckhart 20:29, 20 September 2012 (BST)

The proposal no longer deprecates maxspeed=signals. -- Eckhart 16:22, 15 October 2012 (BST)

more than yes/no

Resolved

I don't particularly like keys that only accept yes or no as a value. I think other keywords should also be allowed. Like in most European countries, they have a 30 kmph zone around schools, but (at least in Belgium) a lot of those zones are dynamic, so I would propose the tag combo

• maxspeed=50
• dynamic_maxspeed=school

Or when the smog limit is reached, 90 kmph is allowed on our motorways, so that could be the tag

• maxspeed=120
• dynamic_maxspeed=smog

I think other countries might have other types of dynamic maxspeeds that are used a lot. Those values could be included and documented per country on the wiki. Instead of thinking out difficult time notation schemas, this would work very intuitively and provide extra information to the routers (a school zone makes rush hour traffic even worse, as that's the time when most children come out of the schools, so don't take those streets at 5 pm. But you shouldn't take smog zones into account when routing, as it only happens 5 days in a year).--Sanderd17 16:51, 20 September 2012 (BST)

Just to make sure there is no misunderstanding: this is about dynamic speed limits like [2], not about static speed limits like [3]. -- Eckhart 17:06, 20 September 2012 (BST)

Maybe I should let the smog out, the signs are there, but they are turned around manually when there is smog (it's still a dynamic sign in a way though), see [4] as an example of a turned sign. The school zones are very pure dynamical speed limits, those are signs, only lit when childs are expected to enter or leave school [5]. As most villages have around two schools, and cities have a whole lot more (the right to found a school is a civil right in Belgium, any many have done so), this makes up a very big amount of such dynamical boards.--Sanderd17 17:45, 20 September 2012 (BST)

The proposal now allows for other reasons than just yes. -- Eckhart 16:23, 15 October 2012 (BST)

Active traffic management vs. LED road signs

Resolved

I am also not quite happy with maxspeed=signals, because it provides almost no useful information.

But we have to be aware that there are

• speed limits used for active traffic management, where the limit changes often and depending on the traffic density,
• and other speed limit signs that could be changed (technically possible) but almost never change pratically (if find them especially around and in tunnels in my area) - more or less behave like fixed value LED road signs.

Especially for the second type it is rather annoying to tag maxspeed=signals. I know a tunnel where I haven't seen any change of the speed limit in 3 years -- until they cleaned the tunnel one day... Even if there would be fixed road sign, it is and would have been possible to reduce speed temporary this single day.

My proposal:

• For speed limits that can technically be changed, but show fixed limits almost all the time 24/7, we treat them like fixed road signs: maxspeed=XX and source:maxspeed=signals could be used to indicate that the speed limit is "posted" on dynamic road signs and not on fixed road signs. dynamic_maxspeed is then unnecessary.
• For active traffic management I am not sure we should break existing tagging with maxspeed=signals. But we could agree or propose to just continue using it only where the maxspeed is determined by active traffic management. "Active" could be defined as "changes observed at least once a week in average" (arbitrary defintion from me).

One clear wish is to provide additional information about the traffic management: I started to use maxspeed:variable:max in addition to the maxspeed=signals to provide useful information about the traffic management. This which was already in use before ([6]), but sadly not documented in the wiki yet. maxspeed:variable:min is also used, but without documentation it is not clear when it should be used.

maxspeed:signals:max=value or signals:max=value would be potentially more consistent and logical and more OSM like, but up to now I used what already existed.--Martinq 17:08, 20 September 2012 (BST)

I guess I started the maxspeed:variable:min and maxspeed:variable:max back in 2009. Depending on the construction, those "led" signs might not be leds, but fiber optics with a single light source. If the limit is changed, they rotate a perforated disc, which selects different fibers and blocks the previous ones, so that different fiber ends light up, and the sign changes. Therefore the possible displays are limited to two or three different maxspeeds, out of which one is the minimum. IMO when the limit is known to be almost constant, it makes more sense to tag that together with the maxspeed:variable:min + :max tags. Alv 17:50, 20 September 2012 (BST)

Yes, LED is just used as example here. There are also some of these old signs consisting of rotatable prism elements. Maybe we can refer to all of them as 'electronically controlled signs' (technology neutral).--Martinq 18:57, 20 September 2012 (BST)

First of all, I agree with your statement about virtually fixed speed indicators. The same is true for LED indicators that only change according to fixed rules, e.g. an LED speed sign that displays 30 from 10pm till 6am, else 50, is treated like a static speed sign.

However, there is a reason why for active traffic management signs, I still want to put the maxspeed into maxspeed.

First of all, the distinction between those two types of signs is not always clear (technically, a lot of tunnels still have active traffic management, it just seldomly produces speed reductions).

Also, from the viewpoint of a data consumer, it is of almost no importance whether the speed information is static or dynamic: for a route calculation, this piece of information can probably ignored altogether, for navigation purposes, the only difference is that the speed limit should not be shown. -- Eckhart 17:32, 20 September 2012 (BST)

Sound a little bit like "tagging for the routing applications".

No, it's more like creating a new tagging scheme, while enjoying some synergy effects.

But let's follow this idea: If none, 100, 80 and 60 is typically shown, then the maximum maxspeed should be tagged in maxspeed (=none) or the 'typical' maxspeed?

The maximum maxspeed, in the same way maxspeed always contains the maximum speed. See below.

Yes, if signals wouldn't exist, this is exactly how maxspeed is defined: maximum legal speed limit (and not just speed limit).--Martinq 22:09, 20 September 2012 (BST)

No, I don´t think that is a good idea to change maxspeed=signals to maxspeed:variable=yes+maxspeed=none, because apps with understandig maxspeed=signals and without support for the proposed maxspeed:variable will be confused. Changing common tags in such a way (eg. maxspeed=signals => maxspeed=none) can break apps. I would prefer maxspeed=signals to maxspeed:variable=yes+maxspeed=signals abi12563 18:54, 08.02.2013

But is this really better for routing? IMO, if communities spend millions of dollars, euros or pounds for such a traffic management system, then there typically already a huge problem with queues -- and no matter what the routing application will use (even if start tagging maxspeed=none or maxspeed=100 instead of 'signals') can be fundamentally wrong either during rush hour or night. I am not sure I see the same benefit like you for routing applications when we scrap the widely used 'signals' - because in such cases there is often no 'good' single value for maxspeed. 'signals' as place holder for 'depends' is more honest then.

To improve routing routing applications would need access to live traffic data (queues, current limits) or statistical data (rush hour, etc.). Because this is sadly rarely available for public all OSM can do (with acceptable effort):

• Provide information about the traffic management in tags (maximum maxspeed in maxspeed:signals:max, etc.)
• Provide routing hints in tags (routing:queues_likely=06:00-09:00), independent from a traffic management [could be used at any road/highway]

But I understand that this is no quick fix and does not improve routing immediately (even though I question your proposal does). The usual problem will be: Routing applications may not use it as long as there is no significant use -- and vice versa nobody tags it because routing applications ignore it. Douh.--Martinq 18:57, 20 September 2012 (BST)

Sure, if we want to provide accurate routing, we have to take into account real-time data. However, this is outside the scope of this proposal.

What this proposal tries to solve is the problem that maxspeed=signals leaves no clue to the router on what to expect. Here are two examples:

• The A 100 in Berlin has dynamic speed signalling which is able to show "80" and "60", most of the time showing "80".
• The A 99 in Munch has dynamic speed signalling which is able to show everything between "no speed limit" and "30" (the LED panel is able to display 30, no idea whether the Munich administration can actually use it.), most of the time showing "120".

We obviously have different experience: In Vienna they installed a 17 million EUR traffic management system on the A23, which is active since September. Now we can see a fantastic shiny warning sign and the information "queue" above our heads - when we all still meet in the daily traffic congestion. No speed limit is shown in the congestion area (theoretically the queue could drive 130...), "80" otherwise and in dense traffic "60" (maybe more values are possible). In this case I am not sure if routing with maxspeed=80 is better. But I accept that it is at least not worse.--Martinq 22:09, 20 September 2012 (BST)

In both cases the maximum speed limit ("80" vs. "none") may not be an accurate representation of the actual speed, but it is a "good enough" estimate. This is actually a known concept: static maxspeed=50 on a road is no indication that one can actually go 50, but it is a good enough estimate.

Also, if administrations spend a lot of money on dynamic speed signalling, the reason is that this improves traffic flow considerably. Again using the A 99 in Munich: before dynamic signalling, the A 99 had a speed limit of 120, and average speeds of below 90 kmph. With the installation of dynamic signalling, the actual average speed went up to over 100 kmph – even though the average displayed speed limit is below 120. Also, the A 99 is a good example because it is one of the busiest motorways in Europe.

BTW: Other reasons for dynamic signalling: risk analysis (e.g. tunnels) or subsidies. -- Eckhart 21:00, 20 September 2012 (BST)

Obviously it is not against the intention of maxspeed to tag the maximum possible speed limit instead of 'signals' (actually this is already mapped in OSM even if there are electronic speed limit). But I have to think about the proposed dynamic_maxspeed tags [to my best knowledge in England a speed limit is called 'variable' not 'dynamic', potentially variable_maxspeed would be better?], but I will start a new thread then.--Martinq 22:09, 20 September 2012 (BST)

Especially I think we could tag something more useful than just yes/no about the traffic management system. We already identified in our discussion that there is a notable difference between e.g. tunnel and variable speed limits on motorways with lots of traffic.--Martinq 22:17, 20 September 2012 (BST)

I'm not sure I want to go down that road, as the number of reasons for dynamic maxspeed are countless. On the A 99, the maxspeed depends on weather conditions, traffic conditions, ongoing grass mowing operation (vehicle reports position to control center which automatically reduces speed in the affected section). However, then I'd just vote that everything other than "no" implies "yes". -- Eckhart 11:44, 21 September 2012 (BST)

maxspeed:variable "reasons"

I fundamentally agree that any value except "no" means: yes, the displayed maximum speed varies.

If people start using the key, it makes sense to capture more than yes as initial value. Thus I suggest following frequently observable initial "reasons" in the proposal (observable means observable for people often using the highway):

Table moved to main page (and maintained there): Proposed features/Dynamic maxspeed#Values for <reason>--Martinq 14:56, 7 November 2012 (UTC)

Modern traffic management systems are capable to reduce speed limit on all reasons. Then use the value/reason which causes the speed reduction in most cases. If a system has been installed in areas with frequent and dense fog for safety reasons, then use 'weather' even if it is also used exceptionally in case of highway service. In urban areas with rush hour reductions, use 'peak_traffic' even if the system also reduces speed during heavy rain.--Martinq 19:49, 5 November 2012 (UTC)

The proposal states that several reasons are allowed, the last paragraph is therefore not really necessary. Other than that, please go ahead and add the table to the proposal, ideally in a new section. -- Eckhart 20:52, 5 November 2012 (UTC)

I think your last paragraph is a bad idea. I have no problem vith the key, but if we do so, we should write down everything the system is programmed to, not just one thing, even it's the most used. Otherwise there will be a lot of chaos. I think those keys should rather be used if the system is only able to do one or two of these and in the other case maxspeed:variable=yes is far enough. --Hsimpson (talk) 18:54, 17 August 2015 (UTC)

Obstruction?

I'm trying to use the values to map variable speed limits. My problem is that I can't imagine one case where obstruction would not be included. So even if the speed limit is usually only lowered in case of bad weather, I still need to tag maxspeed:variable=weather;obstruction , because the speed limit will surely be lowered if there is some serious accident or road works, etc. So my question is: do we really need a separate value for obstruction? Or should it be more like "obstruction_only" to clearly state that the limit is only lowered in case of exceptional cases? --Imagic 07:42, 7 November 2012 (UTC)

I agree, but I am not confident about the solution. My preference is to go back to the single value approach (I originally had in my mind):

The original idea was to tag the most frequent reason for speed reduction only [typically the one for which the system was installed], which is typically peak_trafic > weather > obstruction. This value gives data consumers of the maxspeed key a hint about how fixed the maxspeed value is (and it does not matter if there are other lower frequent reasons too). However, the multi-value approach is now feeling more like tagging the properties of a traffic management system rather than the variable maxspeed. This should go into own keys, e.g. traffic_management=peak_traffic;weather, maybe further refined by traffic_management:weather=warning traffic_management:peak_traffic=overtaking;maxspeed;warning [as illustration, not for discussion here].

Becausing using frequent, irregular... is not very objective and verifiable, I decided to use values that are observable (e.g. I see a speed reduction on rain --> weather, I see speed reduction every morning -> peek_traffic), but this may has led us in the wrong direction.--Martinq 08:32, 7 November 2012 (UTC)

If we agree that the value should be the main reason why the system was installed, then - I guess - we should remove the obstruction value completely. I doubt that any such system will be installed for "exceptional cases". --Imagic 09:52, 7 November 2012 (UTC)

Such "safety only" systems are typically installed in tunnels and before the tunnel portals. In the tunnel there is no weather and outside of urban areas there is rarely demand to frequently control the traffic flow due the lack of ramps.--Martinq 10:50, 7 November 2012 (UTC)

Environmental

How about a value for environmental reasons, i.e. the speed limit is lowered in case of e.g. smog? --Imagic 07:42, 7 November 2012 (UTC)

Proposal:

Value environment moved into the table on the main page (and maintained there): Proposed features/Dynamic maxspeed#Values for <reason>

--Martinq 15:37, 7 November 2012 (UTC)

Looks fine to me. --Imagic 10:24, 9 November 2012 (UTC)

OK, merged it with the table on the the main page, of course still requesting comments (RFC).--Martinq 12:19, 9 November 2012 (UTC)

backward compatibility?

This proposal is changing the meaning of the tag maxspeed. Having this applied, a tagged maxspeed=x doesn't mean any longer there's a speed limit of x. I don't consider this as backward compatible. --HeikoE (talk) 07:14, 25 August 2015 (UTC)

Generally, the maxspeed being reduced further via dynamic signage is an exception rather than the norm; the tagged maxspeed=x would still hold true for the vast majority of the time, and would still be good enough for routing purposes. If routers really want to get fine grained enough, they could check for the presence of maxspeed:variable and introduce a routing penalty (in the same manner as some routers add penalties for traffic lights, speed bumps and the like -- though, in this case, any routing penalty would probably be small). Personally, I consider this an enhancement to existing data, not a breaking change. Certainly, it's an improvement over maxspeed=signals which leaves the actual maxspeed ambiguous (as per previous discussion). --Kelerei (talk) 09:36, 25 August 2015 (UTC)

Well, but it's still not backward compatible. Regarding improvements to maxspeed=signals, there were approaches in the previous discussion (e.g. maxspeed:signals:max=value) which have the potential for a solution not breaking current tagging. I'm sure the proposal could be further developed to gain some more maturity and backward compatibility. --HeikoE (talk) 15:51, 25 August 2015 (UTC)

"Backward compatibility", "breaking current tagging" - maybe, from a formal and academic perspective correct (see below) - but is there in reality any negative impact for practical applications or is it just a formal problem? What application is "broken" when we allow maxspeed values for 0.01% of our road network for which is wasn't allowed before? This would be helpful for discussion, since any change has advantages and disadvantages. When we make a change we need to balance pros and cons. When we stop every change just because someone finds a theoretical issue or con, then the whole community project loses any vitality and agility.

Furthermore I do not agree that there is any change of the meaning as you claim, current definition of maxspeed is The maxspeed=* tag is used to define the maximum legal speed limit for general traffic on a particular road, railway or waterway. If the speed limit can be changed between 40,60,80 with traffic management - then the maximum legal speed limit is 80, correct? So where is the change in meaning? I agree, it's a little bit hairsplitting. But this is the reason why it makes more sense to discuss tagging on a practical level. From a practical perspective: Your interpretation a tagged maxspeed=x doesn't mean any longer there's a speed limit of x is not true for current tagging (and already an intepretation of the definition). For example there might be temporary lower limit due construction work, etc. So practically every application - especially nagivation software and the drivers using it - must deal with the fact that the actual speed limit can be different. So no matter what the formal meaning exactly is - but 'maxspeed=x' cannot be interpreted as more than a hint that driving >x will most likely result in speeding. This interpretation is still possible and true with this proposal. Data quality and our ability to adapt to fast changes will never allow a stricter interpretation (for example "you can drive up to x without getting troubles").

Last point about your statement about "breaking tags" and "compatibility": The proposed tag is already widely used, interestingly so far there were no complains about "broken" maxspeed tags. In contrary, some sites even recommend it and some applications can already deal with it. So are you sure we are not just having an academic discussion about wordings and definitions here? --Martinq (talk) 17:07, 25 August 2015 (UTC)

btw, how would a mapper consider or verify the maxspeed value "true for the vast majority of the time" when he is passing a dynamic signal? --HeikoE (talk) 16:36, 25 August 2015 (UTC)

In principle right (not as easy verifiable as other tags), but I see a lack of pramatism. And not all tags in OSM are verifiable with a single visit, for example primary, secondary, tertiary - so it is accepted that some tagging requires local knowledge and mappers. For a local mapper it is typicallly no practical problem, since these traffic management system are only on a few major roads. Non-local mappers can still map maxspeed:variable=yes and simply omitting the maxspeed if they want to tag their observation (this contains exactly the same information as maxspeed=signals, so there is no drawback for an occassional non-local mapper, just a different tag name). However, since these variable maxspeeds are exceptional and mostly in urban areas with many mappers, I have no concerns that the higher burden to "verify" tagging has any practical impact on data quality (I don't think we get flooded with false maxspeeds due more difficult verifiability). --Martinq (talk) 17:07, 25 August 2015 (UTC)

So you agree my objections are formally correct/in principle right. What could be a reason not to follow an approach (as outlined above) which is avoiding such issues? --HeikoE (talk) 18:36, 25 August 2015 (UTC)

Relationship with maxspeed:type

I have just been reading this and it seems very sensible, but part of the discussion reminds me of one we had regarding UK speedlimits. At some time some of us added maxspeed=national for speedlimits indicated by an oblique black bar on white background (originally a sign which meant "no speedlimit applies"). Others started putting this information in source:maxspeed=*. Eventually a compromise was reached and the maxspeed tag either includes the signed maximum speed or the derived maximum speed (e.g., 30 mph if streetlighting present and no other signage, 60 mph on single lane roads, 70 mph on dual carriageways); and information about how the speedlimit value was arrived at in the maxspeed:type=*. Usual values for the latter are GB_nsl:single and GB_nsl:double. Presumably we could also use maxspeed:type=variable as well.

It seems to me that the reasons for advocating the dynamic maxspeed tag are rather similar to what occurred in the UK for other speed limit issues, and consideration should be given to using this tag which might reduce the proliferation of tags. I would also add that in these cases it is useful to map the actual signage as well as the roads which are affected (an approach used in Helsinki for some years). SK53 (talk) 18:13, 25 August 2015 (UTC)

Multiple values and infinite number of reasons (from voting)

From the voting: The proposed tags do not resolve the problems listed in the rationale. There's still no way to tag the set of speed limits, or the minimum/maximum/typical speed limit. Most supporters of this proposal use to point out that its main advantage is that we can specify reasons for variable maxspeed. But these reasons are variable as well, at least in Austria, and probably wherever variable maxspeeds exist. One user tagged myriads of Austrian motorways with maxspeed:variable=peak_traffic, but it turned out that all of them are wrong. Speed limits are reduced for numerous reasons, including not only peak traffic, but also rainfall, snow, ice, hail, fog, accidents, jams, construction sites, and wrong-way drivers. We could expand that list infinitely, so we'll end up with long semicolon-separated values that will never be complete, let alone verifyable. If we forget about reasons, this proposal offers nothing that can't already be done using standard keys. Say, maxspeed=<typical number> + either maxspeed:type=signals or source:maxspeed=signals. [by Fkv, see voting on main page]

Statement: The proposed tags do not resolve the problems listed in the rationale. There's still no way to tag the set of speed limits, or the minimum/maximum/typical speed limit.. The named section lists drawbacks of the current solution and yes, with this solution routers have more information than before and it is possible to warn about speeding. All listed points are improved, I cannot see that the problems are not solved. No tagging must solve all problems, e.g. also providing information about the typical speed.

The first part of the rationale mentions triprisms. Triprisms allow for 3 different values. This proposal allows for 1 value only. So it clearly misses its goal. The second part of the rationale says that "navigation systems cannot warn the user if he is speeding". This proposal does not solve this. This is simply unsolvable as the limits are variable. But I dont's see it as a problem in the first place. Drivers need to look at traffic signs anyway, so they know about the current speed limit, so they know when they are speeding. --Fkv (talk) 07:00, 26 August 2015 (UTC)

Oh my god! The introduction was not written carefully. Let's vote it down! Sorry for the sarcasm,

That's no sarcasm, that's what voting is meant for. Ever heard of quality assurance? When voters point out an error, correct the error and then start voting again. --Fkv (talk) 13:34, 27 August 2015 (UTC)

Yes - but it would be more constructive and helpful to use the RFC phase which is communicated on the same channel (tagging list) as the voting.--Martinq (talk) 15:54, 27 August 2015 (UTC)

but the discussion around the wording in an introduction section is not really bringing us forward.

Ignorance will not bring us forward either. If you want to bring us forward, correct the error. BTW: If you think that discussion won't bring us forward, you should delete this discussion page, all forums and the mailing lists too. --Fkv (talk) 13:34, 27 August 2015 (UTC)

Is there additional information compared to maxspeed=signals? Yes. Does it provide all possible information? No. Was it meant to achieve providing all information it when reading the complete text and not picking words in an introduction? No.--Martinq (talk) 08:58, 26 August 2015 (UTC)

What additional information are you referring to? The reasons provide no additional information as they have proven wrong in real-world usage. One rule of thumb for proposals is to make an RFC, then watch how the proposed tagging is working out in practice. In this case, it did not work out well. --Fkv (talk) 13:34, 27 August 2015 (UTC)

With this proposal the maximum allowed speed limit can and should be tagged in "maxspeed", which is no longer used for the value "signals"! "reason" is just a side topic - which by the way - you don't have to use if you don't want to use, because "maxspeed:variable=yes" is absolutely OK and not considered "wrong". Also data users have the choice just to use "no" and treat anything else as "yes".--Martinq (talk) 15:54, 27 August 2015 (UTC)

Make a better proposal if you think you have a tagging that solves more problems at the same time.

maxspeed=variable + variable_maximum=* + variable_typical=* + variable_minimum=*. --Fkv (talk) 07:00, 26 August 2015 (UTC)

variable_typical, seriously? But please go ahead, create a proposal page and make people using it. Once you have a critical mass of users I will support it without restriction. It would be helpful if people contribute their ideas - from which they think they are outstanding - into the wiki and the proposal process, so there can be a serious discussion.

BTDT. Austrian users repeatedly promised to support my proposals, but as soon as a proposal was done, they started hiding out. No support at all, neither in discussions nor at voting. As soon as voting was over, they were back and arguing. I will believe your promises only if you declare yourself a co-proponent right from the start. --Fkv (talk) 13:34, 27 August 2015 (UTC)

So you already experienced the hell of the proposal process. Hours of work, discussion and little benefit. BTW: I stay away from votings when I haven't contributed in RFC. IMO the voting process should shift more towards quality assurance, ensuring that tag descriptions are understandable and are neutral with respect to the description of advantage and disadvantages (in this example concerns regarding reasons and drawbacks for mappers, users). Ultimately the mappers decide simply by using or not using tags and values. But I do not have time to start endless discussions about voting process, I have a full time job too.--Martinq (talk) 15:54, 27 August 2015 (UTC)

By the way: Nothing stops us from adding dedicated tags for the missing information after the proposal. For most people the maximum variable speed is obviously of more interest than the other values (typical, minimum).--Martinq (talk) 08:58, 26 August 2015 (UTC)

I'd rather say that the typical speed limit is of more interest. The maximum and typical limits are often identical, but there have been exceptions. Remember Mister "Vorarlberg is too small" and his 160 km/h speed limits? They were supposed to apply only under best conditions. So, 130 would be the typical limit and 160 the maximum limit. However, we should leave it over to applications which of those 3 limits to use. Our task is just to provide tags to contain the data. --Fkv (talk) 13:34, 27 August 2015 (UTC)

Sadly the criteria for "typical" is difficult to define. "Most of the time" may not be as useful as expected, simply because of night times. During night time there is little traffic, for the majority of the drivers the limits during day time matter - which may not match the limit seen "most of the time". So we need something else (e.g. typical = most of the drivers?). This would be an interesting discussion, but we are getting a little bit off-topic here.--Martinq (talk) 15:54, 27 August 2015 (UTC)

Statement: Most supporters of this proposal use to point out that its main advantage is that we can specify reasons for variable maxspeed. -- really, you know most supporters or just the one you had a dispute with in Austria...?

I am mainly referring to this talk page. --Fkv (talk) 07:00, 26 August 2015 (UTC)

The main adavantage - and I say this as writer of the "reason" section - is that it provides additional indication about the frequency of the change,

No, there is no tag for the frequency, and it would be bogus anyway. I have never come across variable speed limits with a fixed frequency in the real world. --Fkv (talk) 07:00, 26 August 2015 (UTC)

it was never meant as exhaustive list, at least not be me. See also discussion #maxspeed:variable "reasons". OK, retrospectively it would have been better to restrict the reason value to the most frequent and dominant reason, but after 3 years and significant use it is difficult to modify the definitions...

Forget about the "significant use". The most dominant value (apart from "yes") is "peak_traffic", of which a considerable part is located in Austria where I know that it is wrong. --Fkv (talk) 07:00, 26 August 2015 (UTC)

a) Dominant reason in an actual case, not in taginfo.

b) It's wrong why? Because it does not list all reasons exhaustive - then I don't understand why you argue against using the dominant reason in a certain case? And why don't you fix it?--Martinq (talk) 08:58, 26 August 2015 (UTC)

I am tired of edit wars, and this case was already discussed at Talk-AT, so I won't repeat it here. --Fkv (talk) 13:34, 27 August 2015 (UTC)

But based on the very low number of value with multiple reasons on taginfo the use of the most important reason is what most mappers are doing anyway, so the bad decision obviously had little impact, except some over-formal person that insists that everything less than "all" reasons is wrong (this is not stated and not needed!).

The proposal says:

The value can provide additional information, why the speed limit is changed in the variable speed limit section. They should be observable by people frequently using the section with the variable speed limit. If the reason is not known, please use yes.

So by definition, it's about THE reason, not just the most important reason. Wherever there's more than one possible reason, the definition in the proposal only allows for the "yes" value, except when you concatenate all possible reasons with semicolons. When you say that mappers ignore the definitions in this proposal, well ok, that just means that this proposal has been obsoleted by deviating actual usage, so we should stop voting right now and adjust the proposal to actual usage before we proceed. --Fkv (talk) 07:00, 26 August 2015 (UTC)

You know the tag, you know the problems - where have you been during RFC and on the discussion page in order to fix wording issues? But yeah, it's a lot easier to vote something down because it states "the reason" and not "a reason".--Martinq (talk) 08:58, 26 August 2015 (UTC)

I am not Jesus. I cannot do a daytime job, do mapping and participate in thousands of discussions all at the same time. But I do have the time to cast a vote and explain my reasons. --Fkv (talk) 13:34, 27 August 2015 (UTC)

No problem, respected.--Martinq (talk) 15:54, 27 August 2015 (UTC)

The values imply a hint about the frequency of a speed limit changes.

Really? How frequent is "weather"? One hurricane a year, or British rain every day? --Fkv (talk) 07:00, 26 August 2015 (UTC)

Here is the reason why "variable_frequency" is a bad idea and why I decided not to use a rate/frequency value. "weather" bypasses this issue, but it is still reasonable to assume that frequency is somewhere between peak_traffic and obstruction (frequency not in the meaning of a technical rate like 1/s here) peak_traffic/school_zone > weather/environment > obstruction.--Martinq (talk) 08:58, 26 August 2015 (UTC)

Statement: Speed limits are reduced for numerous reasons, including not only peak traffic, but also rainfall, snow, ice, hail, fog, accidents, jams, construction sites, and wrong-way drivers. We could expand that list infinitely, so we'll end up with long semicolon-separated values that will never be complete, let alone verifyable.. "snow, ice, hail, fog" = weather; accidents, construction sites=obstruction, jam=peak_traffic except it is just occassional (=obstruction). So your examples do not really "expand the list infinitely", everything covered.

Where does the wrong-way driver fit in? --Fkv (talk) 07:00, 26 August 2015 (UTC)

Pragmatically, I would tag it as "obstruction", since it is safety related ("safety" would have been better than "obstruction", but sadly nobody suggested that during RFC). But if it is important for you and a specific application, we can introduce a specific reason for this. Otherwise there is simply no value for this yet - so what? Not all possible reasons must be given (and can't be, since the table contains only a limited number of choices).--Martinq (talk) 08:58, 26 August 2015 (UTC)

"obstruction" is by the way already implied in peak_traffic.

Is there any real-world example for variable speed limits where obstruction does not apply? I mean, "exceptional" things can occur anywhere and anytime, and you won't know beforehand. --Fkv (talk) 07:00, 26 August 2015 (UTC)

No. Therefore it is pretty useless to add it to the list of reasons if there is already another reason. For peak_traffic I stated this explicitely. But there are real world examples where there is no other reason than "obstruction" (safety), just think about tunnels and tunnel portals -- this is why the value exists.--Martinq (talk) 08:58, 26 August 2015 (UTC)

Do you know a sample tunnel where there can be no other reasons? --Fkv (talk) 13:34, 27 August 2015 (UTC)

For most tunnel in the Alps I do not see "peak_traffic" (occassional traffic jams are explictely excluded), "weather" (in the tunnel?), obviously "school_zone". "environment" may apply, but are untypical outside urban areas. No other values have been defined yet and for exceptional things like wrong-way drivers I don't think we need an extra value. Near Vienna I would put the tunnels on the S1 (north) into this category. --Martinq (talk) 15:54, 27 August 2015 (UTC)

Again, since the idea is to give a hint about the frequency (see proposal text),

Mission failed, see above (weather). If this was your idea, you should better use a straightforward tag like variable_frequency=daily/seasonal/episodical/whatever. --Fkv (talk) 07:00, 26 August 2015 (UTC)

Above you said: I have never come across variable speed limits with a fixed frequency in the real world., now you seriosly propose that a tag "frequency" would have been better? You brought up the weather example and still propose this approach as "better"? The "reason" avoids this problem, still gives a hint (peak_traffic/school_zone > weather/environment > obstruction) without struggling verifiability. Hint does not mean exact value. I don't think the idea "failed" - it is the good trade-off between an unrealistic "frequency" value, verifiability and the "frequency information" it contains (frequency by the way not in the meaning of rate like 1/s).--Martinq (talk) 08:58, 26 August 2015 (UTC)

I don't suggest a frequency tag. I am just saying that when you want to give a hint about the frequency, then a frequency tag is what you are looking for. My suggestion is to omit the whole reasons/frequency thing altogether. --Fkv (talk) 13:34, 27 August 2015 (UTC)

If I want to tag the frequency, I use a frequency tag. Because such a thing is hard to tag and unrealistic, I did not suggest this. So I did the next best thing: Using something, which at least gives a HINT, but is less subjective and less difficult to tag. Because it is fully optional because of the "yes" value, I thought it will get sufficient acceptance/support.--Martinq (talk) 15:54, 27 August 2015 (UTC)

an exhaustive list is not requested by the proposal. But do multiple values really hurt anyone in practice? For me the lack of an infrequent reason (in your Austrian case the lack of "weather" when only "peak_traffic" was used) is no "mistake", like width=3.5 is no mistake when the exactly measured width is 3.55 - it is simply an approximation as almost everywhere in OSM.

No, it's not an approximation, it was just a wrong guess by someone lacking experience on that route. And that's one of the problems with the maxspeed:variable values. They are not verifyable. One rule of thumb in OSM is to "map what we see". When we drive a road, we don't see in which cases the speed limit changes. We only see that it may change (because it is displayed on an electronic screen), and maybe the reason why it is changed right now. So when I am there, the reason is peak traffic, and when you are there, the reason is weather. The only way to objectively find out the most frequent reason is to collect statistics, e.g. by mounting a camera and observing the speed limit displays over years. That's of course unfeasible. And after all, the proposed definition (which we are currently voting upon) is not about the most frequent reason, it's about *the* reason, see above. So whereever the display allows for variable reason, the value must include *all* possible reasons in a semicolon-separated list. I am ok with semicolon-separated lists, but some mappers (e.g. Xxzme) are not, and long lists get combersome and error-prone. --Fkv (talk) 07:00, 26 August 2015 (UTC)

Yup. He wrote "THE" reason. Let's vote it down! Seriously: The overall text makes it clear that multiple values are possible but not mandatory (there is big table of reasons with additional text), even though there is an obvious phrasing error in the main table. Why do you think that all reasons must be listed? Can you point out this statement in the proposal?

Wherever tag definitions contain the singular case, we are used to add all matching data, either using semicolon notation (ref=A1;E1) or multiple keys (ref=A1 + int_ref=E1).

Again, if you think that the value should only contain the most dominant reason, go on and add that world to the definition. --Fkv (talk) 13:34, 27 August 2015 (UTC)

After 3 years of use and during the voting process this is sadly no longer an option.--Martinq (talk) 15:54, 27 August 2015 (UTC)

When definition and usage differ, this is an issue that needs to be touched. The voting stage is the best time to do that. What if the proposal is approved by voting, what will you write in the feature page? The approved definition, or the in-use definition? --Fkv (talk) 13:14, 31 August 2015 (UTC)

Of course tagging maxspeed:variable=peak_traffic is not WRONG, even if there is also the reason "weather". It is incomplete if you insist that ALL reasons must be stated even though the proposal does not require that (or was it now THE reason, I am getting confused from your double standards and word picking). But it is still an approximation. It is wrong if there is no frequent change due peak traffic. But then just FIX IT, it has nothing to do with the proposal itself, just a mapper tagging in areas without sufficient knowledge. For such persons the value "yes" exists.

It's not up to me to fix it. It's up to the proponent or the de-facto proponent who changed the status to voting. --Fkv (talk) 13:34, 27 August 2015 (UTC)

I meant fixing the wrong data in OSM, not the wiki page. But you already explained that you tried and that it ended up in an edit-war.--Martinq (talk) 15:54, 27 August 2015 (UTC)

I had an edit war with that user, but not concerning that tag. Anyway, fixing the data will be out of the question as long as the definition is not yet clear. First step needs to be fixing the definition. --Fkv (talk) 13:14, 31 August 2015 (UTC)

By the way: Verifiability is not a binary value (yes/no), it can be anything from easy and with a single visit to fully subjective. "what we see" does not mean instantly at every point in time, many tags and even things like coast lines require observation over a longer period of time -- the point is that it can be "seen" and is not just stated e.g. in some library. For this tag: As long as I don't know (single visit) I tag "yes", if I see reduction during heavy rain I tag "weather" ("what I see"), if I see queues every Monday morning and a reduction, I tag "peak_traffic" ("what I see"). Someone else can do the same and verify my observation.--Martinq (talk) 08:58, 26 August 2015 (UTC)

It still depends on luck and guessing, whereas coastlines can be measured. When a variable limit display is newly installed, the guessing factor is 100%, even when you're equipped with the most precise measurement tools. --Fkv (talk) 13:34, 27 August 2015 (UTC)

Even with precise measurement tools you cannot measure the coast line simply because there is an annoying thing called "tide". This was the reason I brought up this example. But you find similar things in OSM, for example I cannot confirm "christmas markets" or prepared slopes when I visit the place in summer, etc. All these things are still in OSM because even their verifiablity is not perfect, so there is no absolute rule about how much verifiability is required. I don't think we have dispute here, it is not as verifiable as width=3.5, but it is also not something completely subjective. If you think it is so hard to verify that it can affect data quality, then it's OK if you vote "no".--Martinq (talk) 15:54, 27 August 2015 (UTC)

Coastlines may vary, but they can be measured at any time. Christmas markets and prepared slopes can be observed at well-defined times, and there's plenty of evidence (official websites, tourism folders) throughout the year. In contrast, there's little information on the reasons for speed limits. No websites, no folders, no labels. Last drive I drove the A2 southward near Mödling there was a reduced speed limit (100) with no reason displayed. Even on a sunday morning, so it could not be considered "peak traffic". All you can do is ask the operator. I bet the mapper who set the maxspeed:variable=peak_traffic did not ask the operator (Asfinag). --Fkv (talk) 13:14, 31 August 2015 (UTC)

Statement: If we forget about reasons, this proposal offers nothing that can't already be done using standard keys. Say, maxspeed=<typical number> + either maxspeed:type=signals or source:maxspeed=signals. - The use of these "standard" tags for this purpose is by far not standard ("variable" not mentioned in the tag descriptions). In contrary, the use of source:maxspeed vs. maxspeed:type is disputed! So you need your own proposal for updating the tag(s), requiring touching these "burned" tags - without any adding value as you state (but will end up in endless discussions). I prefer a clear, dedicated tag over a tag with a long disputed history and blurry use for various undocumented purposes. The number of tags in OSM matter (no recycling needed), the clarity of there meaning is more important.--Martinq (talk) 19:06, 25 August 2015 (UTC)

source:maxspeed and maxspeed:type are essentially synonyms, so when we define a new value for them, it automatically goes to both keys. This does not add to the key name controversy. These keys are not burned, they are wildly used by both mappers and applications, if you like it or not. Over 660000 occurences according to taginfo. Compare this to 7748 maxspeed:variable=*, most of which are just "yes". --Fkv (talk) 07:00, 26 August 2015 (UTC)

source:maxspeed and maxspeed:type are essentially synonyms -- discussions and talk pages tell me something different. And for your specific purpose it is not established, since the tags have been used for other reasons and not "variable" (no matter what the tag count is). I am also not sure why overloading an existing tag with a new meaning (it will not take long until we see something like source:maxspeed=mapillary;variable;survery) is better than a dedicated tag. Less number of tags?--Martinq (talk) 08:58, 26 August 2015 (UTC)

Your source:maxspeed=mapillary;variable;survery example explains why I prefer maxspeed:type over source:maxspeed for values that do not relate to information source. There are no conflicts when you use maxspeed:type=signals. However, my favourite is still maxspeed=signals together with tags for the max/min/typical limits. --Fkv (talk) 13:34, 27 August 2015 (UTC)

From a technical perspective I agree. But it is a community project and there a human factor and the problem that something must reach a critical mass until it is considered by applications. But if no application considers a tag, it is hard to come to a critical mass. Before this proposal mappers already used maxspeed=X instead of maxspeed=signals, simply because they were tagging for their router (which is bad, but human). So this proposal follows the intuition of many mappers and tries not define something counter-intuitive.--Martinq (talk) 15:54, 27 August 2015 (UTC)

I'd say that maxspeed=signals is intuitive enough. Most mappers use the tags that are selectable in their editors. It's not about intuition, it's about reliance. I don't believe in a critical mass. Mappers see the outcome of their work in the map, but they don't see it in the routers, at least not directly. That's why most routing-related tagging (and edit-warfare) is done by a handful of people who are engaged in routing development in some way (occupation or studies). Of course they don't care for a good data model, they only care for their own needs. --Fkv (talk) 13:14, 31 August 2015 (UTC)