Osmand claims it uses elevation data - but it doesn't

[jot ess]

Hi all,

I have been reading a bit in this forum and my impression is that I am not alone with my question and there has not been a clear answer yet: Osmand+ claims it uses elevation data - but obviously it doesn't. Or only under certain circumstances.

When I use Osmand+ for bicycle routing with Osmand routing engine and setting "use elevation data" set "on" it doesn't make any difference to "off". Nor does it make a difference whether I let it calculate a route leading up a steep incline or down.

The elevation graph clearly shows that the altitude data is present and at least roughly correct.

Have I missed any other setting? Have I missed an answer somewhere in the forum? Is there any additional add-on to Osmand that I would need? (I have the contours plugin, but as far as I understand this only plots graphical lines with no actual elevation data.)

Best regards

Joachim

[Bart Eisenberg]

This is just anecdotal and someone with an understanding of the algorithm would have a better answer, but using elevation data, I've made this work for  a couple of hiking routes where the two routes are close to each other and (of course) wind up in the same place.  One of them is in Yosemite, where the direct route climbs steeply via stairs and the alternative is a gentler climb, .6 km longer.  So I think it works for some circumstances, but I'm not sure which ones.  

The elevation data is embedded in the map; no contours required.  

[Bart Eisenberg]

I tried this on possible bicycle ride around here. With elevation data off, it routed over a ridge using fire roads. With the option on, it took a much flatter, but longer, route via surface streets.

[jot ess]

Obviously I have not made my problem clear. I have not systematically tried whether routing is different with different options. My point is, that elevation is not taken into account for calculation of time. I tried different options for a hill nearby (where there are no different possibilities for the route) and I let Osmand calculate those 1.7km with ~100m difference in elevation and it always takes 4 minutes. No matter whether on or of, no matter even whether up or down! This means I should cycle an incline of ~6% with 25km/h in both directions.

[Bart Eisenberg]

Ah, right.  And agreed. The time calculation on OsmAnd does not take elevation gain or loss into account.   

[A Thompson]

In an update to OsmAnd about a year ago, they introduced for the first time Naismith's rule to factor elevation into the calculation of WALKING times. Back then, I tested it and it worked. Numerous refinements to Naismith's rule  have been proposed, but a fundamental uncertainty is one's personal physical capabilities. I don't know anything about the bicycle case, but I suspect that the variability from person to person (even for a typical user) would be even greater?

In the long term, it ought to be possible for apps like OsmAnd to automatically calibrate to our recorded behaviour!

[Majka]

For bicycle, there is similar rule - the principle is the same, it just uses different values. Of course, the differences are here much bigger (easy ride x race). But as a rule of the thumb, I would suggest something around speed 20 km/h and 800 vertical meter / h for "faster" and 15 km/h and 600 Vm/h for "easier" or lighter off road (tracks, easy paths). 

Ideally, allow the user to manually set the numbers as variables - better trained/experienced people usually know their current numbers. There is a marked difference between my numbers in February/March and in July/August for the same route, ridden with no extra effort :)

The same - make use of user-set variables (or preset values) would work for walking as well.