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
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
Ah, right. And agreed. The time calculation on OsmAnd does not take
elevation gain or loss into account.
On Saturday, May 25, 2019 at 2:56:34 PM UTC-7, jot ess wrote:
>
> Obviously I have not made my problem clear. I have not systematically
> tried whether routing is different with
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
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.
--
You received this message because you are subscribed to the Google Groups
"Osmand" group.
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,
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
