Slope walking speed calculation is not accurate

[gmellemstrand]

The current rule for slope calculation does not seem to be usable. Costs do not make sense, and positive and negative slopes are treated the same.

We have proposed a new way to calculate slope costs, that center around -8% slope (fastest) and then increases exponentially for both positive and negative slopes around this point.

EDIT: The linked pull request uses a simpler exponential algorithm with has cutoffs at 1.0 (for neutral and negative slopes) and 3.

[t2gran]

PR: #2580

[t2gran]

@gmellemstrand:

1. Can you update the title or description to clarify this about WALKING calculation cost.
2. The description above is not consistent with the PR Changed calculation of slope costs (#2579) #2580 were the cut of is at slope cost 3.0 and 1.0(at slope 0 degree), or did I miss something?

[t2gran]

There is a few things that I want to bring to peoples attentions - and that I think is open for discussion. For background information se the articles at the end of this comment.

1. Witch algorithm should be used: Naismith (OTP current, but broken) , Tobler or MTI (PR2580)?
2. Should there be any cutoffs?

Relevant information

• https://en.wikipedia.org/wiki/Naismith%27s_rule
• https://en.wikipedia.org/wiki/Tobler%27s_hiking_function
• http://mtntactical.com/research/walking-uphill-10-grade-cuts-speed-13not-12/

[t2gran]

My opinion on the above questions is:

1. OTP should use the Tobler function. It is more resent than Naismith and the MTI is based on only a few samples and tests on a treadmill. The difference between Tobler and MTI is not much (same formula, but different constants).
2. The Tobler have the fastest walking speed at -2.86°. Then using a walking speed 1.33 m/s (configurable) at 0 degrees we get:

Slope(deg)	Gradient(dh/dx)	Speed m/s
−50,00	−1,19	0,03
−30,00	−0,58	0,25
−20,00	−0,36	0,53
−10,00	−0,18	1,02
−5,00	−0,09	1,39
−2,86	−0,05	1,59
0,00	0,00	1,33
1,00	0,02	1,25
5,00	0,09	0,98
10,00	0,18	0,72
20,00	0,36	0,37
30,00	0,58	0,18

Formula: Speed = C * V * EXP(-3,5 * ABS(dh/dx+0,05))

Where:

• C=1,19403 The maximum speed factor at -2,86 degrees.
• V=1,33 The speed at flat terrain.
• dx/dh The gradient (slope factor).

This is a small change to the existing PR (A bit of work to adjust the tests).

The remaining question is then if there should be a cut off for for very steep slopes (pos/neg)?

I think not, but there might be good reasons for it:

• short legs of waking might get super steep due to inaccurate slope calculation; hence take unrealistically long time to walk. Most path and roads are not steeper than +/-35 degrees so that should probably be a good cut-off.

[abyrd]

I'm completely in favor of replacing these cost functions in light of the comments in this ticket. However remember that output of the cost function will be compromised by the fact that the input slopes are not particularly accurate - they're often drawn from somewhat low resolution data sets, and even when the resolution is higher an OSM way may accidentally drape over a building or cliff edge in a DEM.

[t2gran]

Good point @abyrd. I have not looked into the code that calculate the slope - ideally there should be some sanity checks there. The cut-off will decrease the impact in such cases. Also, the Tobler function have less impact than the MTI, but slightly worse for Naismith when the slope is uphill > 23 degrees. (https://upload.wikimedia.org/wikipedia/commons/thumb/d/d8/Hiking_speed.svg/2000px-Hiking_speed.svg.png)

[gmellemstrand]

As you mentioned, @t2gran , there should probably be some cutoffs. I think what we tested was to cut off the walk cost multiplier at 3.

Another point to discuss is what to do with negative slopes. Should walk speed increase, decrease or no change?

[t2gran]

@gmellemstrand I think we should do Tobler - which is defined for negative slopes, and yes implement a cut-off.

I would preferere the cut-off to be tied to angle not cost. The reason is that if the horizontal speed changes, so does the cost. For a "fast" walker the cut-off would happen at let say 30 degrees, for a given kost, while it would happen at 32 degrees for a "slow" worker - that is probably not desirable.

If the cut-off is configurable it can tuned to a reasonable value with regard to the data quality.

[gmellemstrand]

I realize cost is not a very accurate term. It is really used as a walking distance multiplier, so in this case the cutoff would not be affected by walking speed. It would correspond to an angle.

[t2gran]

Good, so specifying the cut-off values as an angles (neg/pos) or a maximum walking distance multiplier (absolute value) is more or less equivalent.

Maybe the OTP should log an info message at startup with both the maximum walking distance multiplier and witch angle this occur at.

[gmellemstrand]

I think we could do that. Use the Tobler function and have parameters for the minimum and maximum multiplier (as well as the corresponding slope angles reported by OTP at startup). I imagine not everyone would want walk speed to increase beyond the set speed because of negative slopes, so the minimum cutoff multiplier could default to 1.

[optionsome]

I did some testing with these changes. With Helsinki metropolitan area OSM data and 10m grid DEM data, the average walk speed went up from 1.10 m/s to 1.46 m/s. I set the walkSpeed to be 1.222 (m/s) in requests. Sample size was 2000 requests. I think the speed should be on average less or equal to the set walkSpeed on even a medium sample size. There are some cases where it would make sense that individual requests would have faster walk speed because of downhill but on average It seems illogical that the actual walk speed would be higher than the requested walk speed.

[t2gran]

Tank you for testing this - Yes, and increase in walk speed is not expected, because of the exponential nature of this function you should se a small decrease in speed. We will look into this.

[t2gran]

@optionsome There was a bug in the walkingDistance calculation witch resulted in all walkingDistances to be only 0.75 of the expected. We have provided a new commit with a fix.