Open westis opened 4 years ago
Questions: Would width
& trail_visibility
in one way or another be included in the above slider options? Or would they only need to be used under the hood (setting lower weight to paths with bad visibility)?
Possibly width
could be part of the "road to path" and/or "technicality" sliders.
There's a great effort at merging smoothness, tracktype, surface, mtb:scale and sac_scale to indicate the condition of a way at https://groups.google.com/forum/#!topic/osm-android-bikerouting/5lEL-gbiqV0
Obviously, for trail running purposes this would need to be expanded, as all mtb:scale=2 and above and sac_Scale=T2 and above get the highest penalty for bike navigation purposes. But a similar effort for running would be great!!
By the way, for each slider I would suggest a check-box to activate/deactivate. If deactivated, those tags are not at all considered in the calculation. If all are deselected, only the under-the-hood default values will be considered (such as avoiding trunk roads) and either the closest A to B or closest to user-selected distance will be preferred.
At first, there may be only check-boxes. If activated, the slider will display underneath, with a link to explanation about how it works.
@samcrawford Hmm, what would you think if each slider actually could have an "expand" option to expose the underlying tags that make up that particular calculation, with the default values selected? And then the user can fine-tune as they wish. Like surface. One slider from the "best" to "worst" surface may no suffice for everyone, while by expanding, the user can set the slider for each individual surface type.
Or would this cause too much post-processing?
Ideally users could both select from 0-10 (or whatever scale) to decide the weighting of each preference, but also to set limits (for example to completely avoid too technical parts for easy walking/running or all big roads for trail running).
highway
types, but also considering other tags to decide what kind of road, track or path it is, such assurface
,smoothness
,width
,tracktype
,foot=designated
,bicycle=designated
etc.). A bit similar to Surface, but more to avoid bigger roads or smaller paths. Similar to the current "Avoid potentially unsafe roads", but using a slider instead.smoothness
andsac_scale
, withmtb:scale
as fallback, as well assurface
and possiblywidth
andtrail_visibility
to determine how technical/runnable a way is. But also considering sharp turns of a way, as well as sharp inclines/declines)landuse=residential
,landuse=commercial
,landuse=industrial
. Possibly this could be part of the greenery slider, with higher cost to proximity to noisy areas.And then a general slider for preference to distance vs other weights.
Avoid unlit streets is probably better left as a check-box, as many ways are not tagged with this. And it's more of an on/off choice anyway. Currently though, ways without the
lit
tag may very well be included though. A warning would then be good, to tell the user that unlit streets may be included in the route, if that is the case.Would there be other sliders/options that a runner would need, without making it too complicated? Still, giving the user a lot of possibility to set preferences would set Trail Router apart from other apps where this is not left to the user to decide.