Unrealistic speed on very steep sections about gpxstudio.github.io

[consultantseo]

Yes, you're right. A formula will never reflect accurately all these settings. That's why I suggested to let the user define 2 speeds: either the min and max speeds, or the average and the max speed. I think the output would then be realistic, at least much more realistic than it is now.

The problem with MTB (I'm a mountain biker myself) is that an application won't know if a track is technical or not. Some sections are not doable on a mtb and you must walk. It (almost) never happens with a road bike and it's not a problem when running, as you run all the way.

[vcoppe]

I have updated the formulas for the speed generation, I hope it is better now.
I will close this issue since I iteratively improve this functionality.

[consultantseo]

I made some tests: it's much too fast when running downhill (but it would do on a bike, for example. So I suggest adding the option to chose whether it's running or cycling). Nobody runs faster than Usain Bolt, even when running downhill, especially in the mountains. If the average speed is 10 km/h (up and down), for example, the downhill speed should not exceed 18 km/h on a soft slope and it's slower as the slope is going steeper, in fact. I'd say that when the slope is around 15 % it starts to decrease and when it's around 30 % and above, you're maximum 20 % above the average speed (so 12 km/h if the average speed is 10 km/h). Does it make sense?

With a bike, of course, it's different. And it's even different whether you're cycling on a road or on a singletrack with a mountain bike: max around 70 km/h on a road bike and on a very steep and straight road, max 20 km/h on a mountain bike.

I hope my feedbacks help.

[vcoppe]

It is already the case that the activity chosen in the settings impacts the speed generated, I have added this information to the dialog in commit a2a73c6.

If you want to have a look at the current logic, the function slopeFactor in js/trace.js returns the number by which the speed on flat terrain is divided.

Some of the numbers are taken from this article and I derived the rest. Please tell me if you think it seems unreasonable, but in any case I think it is impossible to mimic all types of runners/cyclists with such simple logic.

[consultantseo]

Hello,

This article is very interesting. One thing that I noticed is that it confirms that even when cycling, over a certain angle/steepness downhill, speed doesn't increase, as cyclists are braking. The same phenomenon happens with runners, whether running on the road or on tracks.

● Where is the button to set if this trace will be ran or cycled?
● I suggest letting users add their maximum speed on the trace (as well as the average one) or the min and max speeds on a given trace instead of the average speed.

The slope factor is too simple and apparently it's not calculating uphills and downhills differently. I'm taking the average speed defined by user as a reference. It's for running:

Uphill
0% to 5 % → 0.8
5.1% to 10 % → 0.7
10.1% to 15% → 0.6
15% to 25% → 0.5
25.1 to 35% → 0.4
35.1 to 60% → 0.3
Over 60% → 0.2

Downhill
0% to 5 % → 1.9
5.1% to 10 % → 1.0
10.1% to 15% → 0.8
15% to 25% → 0.7
25.1 to 35% → 0.6
35.1 to 60% → 0.3
Over 60% → 0.2

Does it make sense?
For cycling, road cycling and mountain biking should be differentiated.

[IdrissaD]

Hello,

As a biker (both road and MTB), just a quick remark on the incredibly difficult task to differentiate speeds depending on the terrain. In order to do this, you would need to check the tracktype or the surface of each OSM way the route is using. Then estimate what would be the speed uphill or downhill depending of those attributes.
But it also depends of your tires, your skills, the geometry of your bike, the weather, etc. If you create a MTB and a road bike profile, then you should adapt the algorithm so it favors little paths and tracks instead of paved roads, because if the only difference is the calculated speed it's a lot of work for not much.

Actually, I can only think of Komoot and BRouter as apps that propose MTB profiles for routing. And on bike social networks groups, I read a lot of complaints on Komoot's routing engine as long as it's not the road one ("it was too that, not enough this", etc). I think, as seducing the idea of specific routing engines is, the challenge is huge and the efficiency not high enough yet to be worth the effort.

[IdrissaD]

Yes that's the main problem with MTB! Maybe some day the mtb:scale OSM attribute will be enough used for it to be useful to routing apps. Way to go...

Good idea for the min and max speeds defined by the users!

Edit: By the way, here is the choice of routing engine: