TrailRouter / public-issues

3 stars 0 forks source link

General issue for listing possible sliders for user preference configuration #23

Open westis opened 4 years ago

westis commented 4 years ago

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).

  1. Greenery (from no to very high weight for greenery). That is, converting the current "Prefer green areas" to a slider.
  2. Elevation (as little elevation to as much elevation as possible) That is, converting the current "Avoid hills" to a slider.
  3. Surface (paved to unpaved to ground and all nuances in between). Possibly treat highways down to unclassified|service|residential|track (grade1) as paved, if they don't have the surface tag. Treat lower highways as unpaved. But then again, in some countries even highway=secondary might be unpaved.
  4. Road to path (based on OSM highway types, but also considering other tags to decide what kind of road, track or path it is, such as surface, 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.
  5. Technicality (from easy walking to hiking to technical running to alpinism/scrambling. Basically smoothness and sac_scale, with mtb:scale as fallback, as well as surface and possibly width and trail_visibility to determine how technical/runnable a way is. But also considering sharp turns of a way, as well as sharp inclines/declines)
  6. Hiking routes (from no to very high weight to hiking routes, and possibly mtb routes). Although the layer option is still good, it would also be good with a slider for the user to set weight to hiking routes when generating route suggestions.
  7. Quietness (from noisy to very quiet) Not sure how to calculate noise though. Probably by considering proximity to big roads, as well as 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.

westis commented 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.

westis commented 4 years ago

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!!

westis commented 4 years ago

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.

westis commented 4 years ago

@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?