Proposal talk:Practical maxspeed

Conditions in key vs. value

I'd rather see the conditional cases as separate keys:

• maxspeed:practical=90 + maxspeed:practical:rushhour=20 vs. maxspeed:practical=90;rushhour: 20

This is just something that needs to be polled. Alv 12:05, 16 September 2009 (UTC)

Yes, I'd also suggest this. It also happens to use the same syntax as my condition proposal, so I'd suggest to use it here, too. Of course, it doesn't have a "rushhour" condition yet, but sharing the syntax would still be a good idea. --Tordanik 22:24, 21 October 2009 (UTC)

Clarify definition of maxspeed:practical

Quote from edit to proposal page:

Practical does not equal "what is physically possible", which varies by vehicle, but roughly a median speed.

Unfortunately, I'm now confused what it is supposed to mean.

• speed that is physically possible
• speed that is possible taking traffic flow into account
• minimum of both?

Also, I'm not sure why you call it "practical maxspeed" then, rather than, say, "median speed" or "average speed". --Tordanik 17:52, 29 October 2009 (UTC)

I added that, even though I didn't create the proposal but find that it should been defined better from the start - but claiming that it'd be the physical speed only (as some objections state) can't be the intention. The most effective "practical speed" is likely the minimum of

• legal limit
• comfortable cornering speed, which is about something as low as 0.5 m/s² lateral acceleration, except on some curved acceleration lanes where more is needed to get up to motorway speeds in time
• median speed taking traffic flow and visibility safety margin (crossing pedestrians etc.) into account Alv 14:13, 31 October 2009 (UTC)

Not (inherently) subjective

The proposed format is not practical (ha!), but I wanted to note that the estimate of the average "practical speed" (roughly median speed, or 85th percentile speed if that's agreed upon) is not a subjective thing, as someone commented on the poll: "Every mapper would tag this different, because everyone thinks there is a different "practical" maxspeed". Sure, it's likely to be altered several times if someone enters them, but the estimator for the statistical median converges to some value. Alv 17:13, 1 April 2010 (UTC)

Comments after voting period

• I approve this proposal. my region has many places where 100 km/h is allowed, but definitely not advisable. --Kenji 23:01, 31 January 2012 (UTC)
• I approve this proposal. for Kenji reason - Stéphane 19:17, 18 April 2012 (BST)

reopen

can we reopen the discussion and vote for this tag? --Kenji (talk) 21:29, 15 May 2013 (UTC)

Generally, you can change a proposal to take into account objections from the previous vote, send out a new RFC, and start a new vote after 2 weeks. Before doing all this, you would usually contact the original author of the proposal.

In this case, however, the result was so clear that I don't really see a point in voting again. --Tordanik 22:34, 15 May 2013 (UTC)

I would love to see a way to tag with "realistic" or "average" speed. In theory it might be possible to map/tag all conditions which would allow navigation software to compute a realistic speed such as curvy winding roads, narrow or single lane roads. Some aspects though - like poor visibility in curves would require unrealistically detailed mapping and excessive computing power to evaluate at runtime. Other aspects - frequent pedestrian/bicycle traffic are inherently subjective but nevertheless very important. RicoZ (talk) 22:23, 12 October 2013 (UTC)

You may be interested in knowing that OsmAnd is using maxspeed:practical when calculating the fastest route. Rafmar (talk) 14:54, 24 January 2015 (UTC)

curious - how do you know? I found only this https://code.google.com/p/osmand/issues/detail?id=2059 and this https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml - but the routing.xml does not tell me much without knowing more about OsmAnd. RicoZ (talk) 19:03, 24 January 2015 (UTC)

Know more about OsmAnd in the meantime and pretty sure it uses this key. RicoZ (talk) 22:24, 12 December 2015 (UTC)

I would like to see this revised and reopened as well. In many developing countries there is no speed limits of any sort but there are practical or average speeds, and further they are quite dependent on season. I have spoken to groups that would like to collect gps tracks from fleet vehicles and other drivers and use them to determine practical average speeds. --Bgirardot (talk) 15:49, 12 December 2015 (UTC)

In the meantime I view the key as fairly well established, also used by OsmAnd at the very least. I think it should be extended in the style of Conditional restrictions instead of the current very adhoc conditions - would that be practical for your use case to differentiate the season? There were also some other proposals to gather average driving speed linked in "See also" - unfortunately all dysfunctional as far as I know. RicoZ (talk) 22:24, 12 December 2015 (UTC)

Very interesting. That is exactly what I was thinking, being able to use Conditional restrictions to indicate for example (feb - jun) and (jul - jan). I had not thought to look at the "See also" section, will do. --Bgirardot (talk) 02:38, 13 December 2015 (UTC)

I have tentatively described it in Key:maxspeed:practical#Use_with_conditions. RicoZ (talk) 14:20, 13 December 2015 (UTC)

OsmAnd currently does not support time dependent routing, neither for maxspeed, nor maxspeed:practical https://github.com/osmandapp/Osmand/issues/2051 . For some purposes you could preprocess the OSM data and generate different offline maps for different seasons.RicoZ (talk) 19:17, 15 December 2015 (UTC)