Trail Suitability Index for considering trail technicality when suggesting routes

[westis]

By combining tags like surface, width and perhaps smoothness, sac_scale, mtb:scale and trail_visibility a kind of a "Trail Suitability Index" can be calculated for each "highway" and users can select on a scale from "as technical as possible" to "as runnable as possible" to get route suggestions based on preference for technical trail vs road running. The entire route could then also get some kind of "technicality point", to give the user an idea of how technical/runnable it is.

This would probably need a new tag, trail_technicality, that sets the technicality of a path from a running point of view, similar to mtb:scale for MTB.

Preferably paths with bad trail_visibility should get a lower weight, unless they are connecting two better paths or if it's along a hiking route. Maybe that's a separate issue. :D

[westis]

Possibly slopes could be included in the calculation. That is, if there are steep slopes that hinders runnability, that can be considered more or less technical or suitable.

The type of highway will obviously also be part of the calculation, from forest paths to tracks to paved "paths" to roads.

[westis]

Looking at Brouter's MTB profiles, they seem to use something called "Roughness" for a path, which is combining mtb:scale and smoothness. It's part of the Trekking bike profile.

Brouter has some interesting terms for calculating "costs", although the English is not so easy to understand (https://github.com/poutnikl/Brouter-profiles/wiki/glossary)

• Equivalent length (basically to get routes of similar times, but various distances, taking into consideration costs for elevation & turns)
• Elevationcost (cost added for uphill/downhills & average slopes)
• Turncost =slowing down at way curves depending on curve angle & junctions/crossroads
• Uphill/Downhillcost (used for elevationcost and with additional uphill/downhillcutoff)
• Costfactor - features of a way can add or subtract a way's initial cost, depending on user's preference.
• InitialCost - which I suppose is similar to Trail Router's weight put on certain ways or even nodes (like crossings, barriers etc), such as avoiding trunk roads (=extremely high InitialCost)

It seems like Equivalent lengths is similar to ITRA:s term km-effort (1 point per km + 1 point per 100 m elevation = km-effort).

I don't really understand how all these work in Brouter, but I like the idea of different "costs". In Trail Router there could be sliders to put weight on these costs, from "ignore all elevation costs" to "give a lot of weight to elevation costs".

Roughness in Brouter is then similar to a slider from very technical path to asphalt road with excellent smoothness, or as in the original description above, from "as technical as possible" to "as runnable as possible".

Brouter is way too complicated for a normal user though, so there's a lot of potential for Trail Router to use similar ideas in a much more user-friendly way, particularly for runners. But Brouter is using all these value to calculate an estimated time as well (and basically comparing to flat pace with Equivalent Length).

As for "sliders", Routino (http://www.routino.org/uk/router.html) also gives options for highway preferences from 0-100 %, as well as paved, walking route, bicycle route etc. But also in a fairly unuser-friendly way. And the Brouter developer apparently thinks these configurations leave enough room for the user to set their preferences...

What I do like with Brouter is the idea of the possibility of giving all the control to the user in terms of routing preferences by being able to configure preferred costs for different features etc.

[westis]

And to continue this thread... Obviously many ways in OSM don't include all tags necessary to calculate some kind of "trail suitability index", which means there has to be fallbacks.

smoothness and sac_scale together seems to make up a longer scale from perfectly smooth asphalt to extremely advanced mountain climbing. But if not available, mtb:scale can be a good fallback.

I suppose, for technicality these three tags are the most important, but additionally "costs" can be added for sharp turns of ways, as well as very steep inclines/declines or different kinds of barriers on nodes and highway crossings.

trail_visibility could possibly be another "cost", where paths with very low visibility are avoided, unless the only possible way to reach the destination. Apart from that, trail_visibility doesn't necessarily need to be exposed to the user.

Well, quite unstructured, random thoughts. And I suppose much of this is already in Trail Router under the hood. This Brouter page for hiking profiles also gives some ideas: https://github.com/poutnikl/Hiking-Poutnik/wiki