Provide more realistic hiking times in mountain areas

[sfendrich]

This issue is based on the forum post https://ask.openrouteservice.org/t/hiking-path-time/3536, stating that one might get better estimations of hiking times by using the swiss-rando formula. The formula is found in the excel file linked on the page https://www.suisse-rando.ch/fr/signalisation/signalisation/temps-de-marche (Version 2020.1):

-- Valid haskell code:
--
-- t_to: time to walk from A to B
-- t_from: time to walk from B to A
-- l: horizontal distance (projected) from A to B
-- h: altitude difference, i.e. alt(B) - alt(A)
-- s: slope between A and B (100 * h / l) 

t_to s l = (l * (c0 + (c1 * s) + (c2 * s^2) + (c3 * s^3) + (c4 * s^4) + (c5 * s^5) + (c6 * s^6) + (c7 * s^7) + (c8 * s^8) + (c9 * s^9) + (c10 * s^10) + (c11 * s^11) + (c12 * s^12) + (c13 * s^13) + (c14 * s^14) + (c15 * s^15))) / 1000

t_from s l = (-l * (-c0 + (c1 * s) - (c2 * s^2) + (c3 * s^3) - (c4 * s^4) + (c5 * s^5) - (c6 * s^6) + (c7 * s^7) - (c8 * s^8) + (c9 * s^9) - (c10 * s^10) + (c11 * s^11) - (c12 * s^12) + (c13 * s^13) - (c14 * s^14) + (c15 * s^15))) / 1000

-- constants
c0 = 14.271
c1 = 0.36992
c2 = 0.025922
c3 = -0.0014384
c4 = 0.000032105
c5 = 0.0000081542
c6 = -0.000000090261
c7 = -0.000000020757
c8 = 0.00000000010192
c9 = 0.000000000028588
c10 = -0.000000000000057466
c11 = -0.000000000000021842
c12= 1.5176E-17
c13 = 8.6894E-018
c14 = -1.3584E-021
c15 = -1.4026E-021

The constants are given at two places in the excel sheet with two different precisions.

Currently, the status of this formula is unclear. As far as I have read, the formula has been derived as a polynomial approximation of a dataset of recorded hiking times. This is a purely numerical approximation and might be subject to overfitting. At least it is unclear what the different monomials mean intuitively, e.g., why is the third power of the slope scaled negatively and the fourth positively?

EDIT: constants updated to higher precision

[marq24]

I just want to leave my 2 cent here... I am not sure how I could start.

comparing just the elevation delta between two points (start & end) is IMHO not suitable at all - It's fine in the case you have a route from down of the valley to up the summit - but even then - a lot of times you have to pass "dips" on your way...

I have spend quite a while to implement some sort of climb detection (and calculation of overall altitude meters that need to be climb) on my app - where I use the route from A to B - then normalize the distance (cut into 25m sections) and calculate multiple alt-delta's per section... in order to get some reasonable data for slope and estimated effort data...

I would be very happy to share my experience with you guys.

[sfendrich]

A quick inspection of the data revealed the following insight: The swiss-rando polynomial makes no sense beyond a slope of 40%. Within the 40% it is easily approximated with a 2nd order polynomial with an error of less than 30s/km, e.g.:

t_to s l = l * (14.1399 + 0.485692 * s + 0.0242169 s^2)

It has a smoother curve and seems to make more sense from a modelling perspective.

[sfendrich]

@marq24 exactly, the swiss-rando model is applied to sections of constant slope, i.e., to estimate time from start to end one would have to split the route into such sections. We would be happy, if you would share your insights.

[Huntani]

The swiss-rando model is a curve fitting of this graph which, as far as I know, was based on measurements on the field. https://i0.wp.com/www.nellanatura.it/wp-content/uploads/2016/11/Diagramma-tempi.jpg?w=800&ssl=1

I've tested the formula to calculate the hiking time on kml traces extracted from openrouteservice, applying it to each point in the trace, and the results look reasonable.

I've looked at the second order approximation, it fits quite well except for negative slopes where it differs about 40% from the original formula. A better approximation could be the fourth order 1.4787E+01 + 2.9138E-01 x + 2.5086E-02 x^2 + 1.0963E-05 x^3 + 3.6935E-08 x^4

[Huntani]

For slopes above 40% it could be reasonable to keep a constant vertical speed, even if slopes above that one look more like a difficult ski slope than a hiking track.

[TheGreatRefrigerator]

The OP of the topic provided some code example: https://ask.openrouteservice.org/t/hiking-path-time/3536/6

[Huntani]

Sorry, I put a wrong formula above. This coefficient set is much better:

14.14221824, 0.293799084, 0.031619121, 3.88741E-05, -5.70469E-06, 3.37396E-08

The resulting fifth order equation matches the one from swisse-rando with less than 2% error in slopes ranging between -30% and +40%. Below and above those values, it is reasonable to keep a constant vertical speed.

[sfendrich]

@Huntani Of course, as for the original formula, downward slopes would need a different polynomial (t_from instead of t_to). The above is just an example.

EDIT see @Huntani's correction below

[Huntani]

@sfendrich The polynomial applies both for downward and upward slopes. The two formulas above are just used to calculate the time forwards and backwards, the second one is the same as the first one replacing "s" with "-s".

[sfendrich]

@Huntani Thanks for the clarification!

[sfendrich]

A fourth order polynomial that approximates the swiss-rando polynomial (SRP) well is f(x) = 14.1744 + 0.291215 * x + 0.0312744*x**2 + 6.20369e-05*x**3+-4.96421e-06*x**4. It has a smoother curve than the SRP, as its derivative lacks the bounces of the SRP derivative (see figure). However, like the SRP, f makes no sense for slopes beyond +/-40%. Similar things are true of @Huntani 's fifth order polynomial, which has a good continuation beyond +40%, but makes no sense beyond -40%. Maybe a good compromise between precision and other good properties might be a third order polynomial like 15.3174+0.291215*x+0.0242997*x**2+6.20369e-05*x**3.

[sfendrich]

Summary from internal discussions:

• The topic is definitively interesting for ORS
• It should not be difficult to add such estimations into the postprocessing of an already computed route
• However, using such estimates during routing is much more difficult because relevant altitude changes exist between two subsequent nodes of some OSM ways, i.e., the resolution of OSM ways does not match DEMs. This point requires more investigation.

[Huntani]

I think that using the resolution of the nodes during the routing is already better than using no altitude information. Postprocessing could be used just for a more accurate information once a route is selected.

On the other side, pre-processing an area adding the time for every edge in the graph would be too resource consuming?