Talk:Key:maxspeed:practical

Verifiability

[1] : there should be advice how to do it better.

It is interesting that verifiability lists sac_scale as an example - this is the ultimate proof that such keys are needed whether or not some people think they are verifiable. RicoZ (talk) 21:19, 9 April 2016 (UTC)

The problem with a key like maxspeed:practical is that the value is nearly meaningless. If you are a 75 year old pensioner who is driving an old RV (motorhome) down a curvy gravel road, you are likely to determine a much lower practical maxspeed than a young man riding an off-road sport motorcycle on that same road. Should the maxspeed:practical be set for motorcycles, for caravans, for mid-sized passenger sedans, for SUVs? How uncomfortable is still practical? If you are driving alone you can go much faster than when you have young, car-sick children in the back, on a curving road.

The reasonable way to determine the expected speed is to use statistics, based on many GPS records. This is what commercial routing software does to get realistic trip time estimates, and such data can also be adjusted for each user. We aren't going to successfully tag every highway with a speed estimate. That's why this tag was rejected. --Jeisenbe (talk) 13:58, 30 June 2019 (UTC)

Of course it is encouraged to set maxspeed:practical for motorcycles and other vehicles separately, see Key:maxspeed:practical#Use_with_conditions. In principle there is nothing to prevent you from using a condition like (driver_age>=75 AND pensioner=yes) - it would fit under the "user group" conditions. Not sure if "driver_age" has been used/defined previously but I would not be surprised if it will be needed anyway for other purposes. An alternative would be to use "daredevil", "normal", "cautious" and "anxious" as abstractions instead. Further, since daredevils probably don't care about maxspeed:practical and the values may be above legal limits and what is considered reasonable by OSM I think daredevil data should not be entered into OSM. So "normal" would come as default, leaving perhaps cautious, anxious, disabled and female as extra conditions.

The idea that statistics based on GPS records would be better is remote for the reasons you have explained yourself - unless the statistics are stratified according to age, pensioner,female,disabled,vehicle type, time of day, season, weather conditions and other variables. Also, this key is expected be used predominantly in less frequented areas where it would be even more difficult to gather all necessary data and as far as I can see all projects gathering those stats seem dead. RicoZ (talk) 20:17, 2 July 2019 (UTC)

"no legal speed limits"

Is there any case where there are no speed limits at all outside motorways? Many roads have no signed max speed but in such situation default max speed limits apply. And is it actually useful to tag maxspeed:practical=* on motorways, except cases where traffic jam are standard and speed is lower than expected from a motorway? Mateusz Konieczny (talk) 07:13, 3 July 2019 (UTC)

I think desert and wilderness tracks and similar don't have any implicit/default speed limits in many countries. Maybe legally the speed limits of regular highways would apply to them but don't think that would be terribly useful to consider. RicoZ (talk) 17:36, 11 July 2019 (UTC)

maxspeed:practical > maxspeed

Well, it's plausible. However, can this tag be used for cases when there's no explicit maxspeed=* tag but one wants to mark a road that can be used at greater speeds than the default? E.g., if we have a track with non-stabilized fine gravel surface (tracktype=grade2) but it's so smooth, flat and straight and has no crossings so that even dump trucks use it at 60 km/h. It's for sure that no router would assign such a high speed for an unpaved track. As this road is not maintained by any government organisations, I wouldn't tag it as highway=unclassified. Besides, an unpaved unclassified is still low-speed for the routers. ITineris (talk) 08:43, 14 May 2020 (UTC)

Probably the main issue here is ethical: should the router assume that drivers are generally willing to break the law when the law is considered silly for some reason? This seems contrary to the generally accepted idea of respecting turn and access restrictions. --Fernando Trebien (talk) 03:03, 16 July 2020 (UTC)

Nope, I wasn't mentioning the legal issues. (Though I often use it as an argument against Waze: It directs drivers through a 30 km/h zone. Because their statistic shows wazers use these streets at 50 km/h that is faster than the usual speed on the main road.)

My note is about situations where the road may be practically (and legally) used faster than one would expect by the tags. In our country one may drive at 90 km/h on dirt roads at rural areas. ITineris (talk) 16:16, 18 July 2020 (UTC)

You're right, I got it wrong. It makes sense as long as the average speed is mapped. --Fernando Trebien (talk) 22:57, 18 July 2020 (UTC)

Urban boundaries as an alternative to obtain reduced average speed in urban areas

Currently, this page says that In urban environments it can be applied where some roads are particularly slow due to congestion or other factors. Although this tag is used to "fix" routing in many situations, a common situation is to inform the router that the average speed drops in urban roads in relation to their speed limit. Generally, a reduced speed can be applied to all urban roads by checking if the road is within boundary=urban, so that the router knows that it should generally prefer going around instead of going through built-up areas. I think this partially solves a common problem and may help remove the practical need for this controversial tag in many cases. Certainly, for urban areas, the definitive solution is to write routing software integrations with average speed data sources. --Fernando Trebien (talk) 02:58, 16 July 2020 (UTC)