Ideas for realistic and simple bicycle ETA calculations

[Poutnik Fornntp]

*Ideas for realistic and simple bicycle ETA calculations*

It is known that calculation of Estimated time of arrival ( ETA) is quite
tricky for bicycles.

One possible approach - and I think good one - is to take into account
elevation profiles from 3rd party provided GPX routes,
but implementation can be problematic.

But there are other possible, easy approaches.

*1/- configurable avg bike speed as cheap way to realistic ETA calculation,
based on biker experience.*

Average bike speed is strongly individual and should not use hardwired
built in value like current 20 km/h. It is matter of biker condition and
wearing, a route quality and length, hill slowdowns, biker's breaks. E.g.
my experience (*) shows there is for myself good estimation of *effective
average travel speed* 15 km/s (**).
An experienced user can tweak for every trip estimated avg speed,
according to route demanding level.

(*) long 100+ km trips, low to medium luggage, counting with some
hillyness and refreshment breaks
(**) That this value is used as default in GPSMid java OSM map application.

2

*/ ETA = time + travelled_time * ( remaining_distance) / (
passed_distance )*Simple statistic, based on simplified presumption you
will travel as fast as you have travelled until now.
If taking total time including breaks ( from start, or arbitrary point ),
it counts with future breaks as well.
It may be based on road distance or even air distance, estimating the same
"curvature level".

[Poutnik Fornntp]

Applicable on foot trips as well. Car routes are different case.

Note the for latter case of adaptive avg speed calculation,
air distances would obviously fail on round-line trips.

[Manfred]

Hi!

Forget it!

Average speed of the past can never be used for calculating the future one.
Think of riding up a hill for one hour at 8 km/h, rolling down on the other
side with 60 km/h will result in a bad result, calculated with your method.

Much worse than a rough guess, so why letting a machine calculate something
(setting al ot of parameter), what human brain can do much better?

Regards
Manfred

Post by Poutnik Fornntp
*Ideas for realistic and simple bicycle ETA calculations*
It is known that calculation of Estimated time of arrival ( ETA) is quite
tricky for bicycles.
One possible approach - and I think good one - is to take into account
elevation profiles from 3rd party provided GPX routes,
but implementation can be problematic.
But there are other possible, easy approaches.
*1/- configurable avg bike speed as cheap way to realistic ETA
calculation, based on biker experience.*
Average bike speed is strongly individual and should not use hardwired
built in value like current 20 km/h. It is matter of biker condition and
wearing, a route quality and length, hill slowdowns, biker's breaks. E.g.
my experience (*) shows there is for myself good estimation of *effective
average travel speed* 15 km/s (**).
An experienced user can tweak for every trip estimated avg speed,
according to route demanding level.
(*) long 100+ km trips, low to medium luggage, counting with some
hillyness and refreshment breaks
(**) That this value is used as default in GPSMid java OSM map application.
2
*/ ETA = time + travelled_time * ( remaining_distance) / (
passed_distance )*Simple statistic, based on simplified presumption you
will travel as fast as you have travelled until now.
If taking total time including breaks ( from start, or arbitrary point ),
it counts with future breaks as well.
It may be based on road distance or even air distance, estimating the same
"curvature level".

[Poutnik Fornntp]

Human brain knows that it is foolish to apply statistical method for
extreme cases, and than to make from that general conclusion.

For such case fail as well as constant speed method, as well the poor brain
method, if you do not knowm the profile in advance.
OTOH, in steady climbing, it gives correct result, whiwl constant 20 km/h
gives more than 100% error.

Over long distance, and for such case is such estimation the most
important, the mean speed value is statistically averaged.
Current display value based on 20 km/h is useless.

[Poutnik Fornntp]

I can do manual estimation, based on route length, my condition and total
ascend, similar as BikeRouteToaster online service does, or one can
estomate from Brouter route summary. If first 40 km of route took 3 hours,
it is reasonable to statistricaly expect next 20 km take 90 minutes and not
60.

As this method in reality apply adaptive biker average speed to estimate
ETA.

[Poutnik Fornntp]

Post by Manfred
Average speed of the past can never be used for calculating the future one.
Think of riding up a hill for one hour at 8 km/h, rolling down on the
other side with 60 km/h will result in a bad result, calculated with your
method.
Much worse than a rough guess, so why letting a machine calculate
something (setting al ot of parameter), what human brain can do much better?

If you planned 80 km trip and you passed first half in 3 hours, what does
your brain say ?
Does it say there is no way how to estimate you arrive in about another 3
hours ?

All my ETA topic is not targeted to downhill bikers, but for travelling,
flat and hill land trekking, with many small and less steep hills.
With some number of such hills behind and in front of me, it gives good
estimation.

"Remaining way is like passed way" approach is statistically much closer to
reality than "All ways are the same" approach.

[Poutnik Fornntp]

Post by Poutnik Fornntp
*1/- configurable avg bike speed as cheap way to realistic ETA
calculation, based on biker experience.*
*2/ ETA = time + travelled_time * ( remaining_distance) / (
passed_distance )*Simple statistic, based on simplified presumption you
will travel as fast as you have travelled until now.
If taking total time including breaks ( from start, or arbitrary point ),
it counts with future breaks as well.
The above can be combined, starting with user chosen typical avg speed

v_avg_user
and progressively put more weight to average past travel speed.

adaptive_avg_speed = ( v_avg_user + f(passed distance) ( *passed_distance /
*travelled*_time )*)/(1+ f(passed distance) )

It is easy to make some estimations while planning on the chair.
But outdoor, being tired, it is handy to pass some thinking on computer.

[Poutnik Fornntp]

One possible weighting option is

for passed distance > v_avg_user, e.g > 18 km, if v_avg_user is set to 18
km/h

adaptive speed = travelling_avg_speed = passed_distance /
traveled_time

for passed distance < v_avg_user

adaptive speed = [ v_avg_user * weight1 + travelling_avg_speed * weight2)/(
weight1 + weigth2) =

=[ v_avg_user * ( v_avg_user - passed_distance ) + ( passed_distance /
traveled_time ) * passed_distance ] / v_avg_user

for passed_distance = 0 adaptive speed = v_avg_user
for passed_distance = v_avg_user adaptive speed = passed_distance /
traveled_time

[Poutnik Fornntp]

Post by Poutnik Fornntp
2
*/ ETA = time + travelled_time * ( remaining_distance) / (
passed_distance )*Simple statistic, based on simplified presumption you
will travel as fast as you have travelled until now.
If taking total time including breaks ( from start, or arbitrary point ),
it counts with future breaks as well.
As option, travelled time and passed distance can be taken just from

arbitrary choiced last past part,
e.g. last 90 minutes ( or whole track if less ) if user choices,
or whatever is handy for OSMAnd.

[Harry van der Wolf]

Hi,

Your statistical methods would work in certain cases but not in all cases,
and there are quite some other cases.
As a simple example: I live in the Netherlands which is fairly flat. Not
much speed differences in climbing and descending. Weight is hardly a
factor to take into consideration in that case.
However, in our flat country you sometimes have half of your cycling tour
headwinds and half of the time downwinds (that's how I prefer to select
it). This will completely unbalance any algorithm which is based on your
parameters.

Secondly: I'm a "nice weather enjoying nature" rider. When I think it is
time to have a cup of coffee/tea/soda and see a nice cafe/restaurant I stop.
Now that maybe not relevant for you, but it is to a lot of cyclists. It
means that a general ETA will not work. In that case OsmAnd should detect
that there is no movement for 10/20/30 minutes and simply add that time to
the ETA algorithm.

In short: Your calculations might work, but need expansion and will
require, as Manfred mentions, a big amount of parameters depending whether
you're a mountain biker, a cyclist on a racing bike in flat conditions or
mountainous conditions, or like me, a relaxed rider.
I go cycling for 2, 3 or 4 hours and I know it will take that time for the
selected route in this weather based on my experience. I'm sure that is
just as accurate as any algorithm you might implement.
(And sometimes I decide to cut a loop from the tour or to add a loop to the
tour, because I simply decide that or my own estimation is not entirely
correct).

Harry

Post by Poutnik Fornntp

Post by Poutnik Fornntp
2
*/ ETA = time + travelled_time * ( remaining_distance) / (
passed_distance )*Simple statistic, based on simplified presumption you
will travel as fast as you have travelled until now.
If taking total time including breaks ( from start, or arbitrary point ),
it counts with future breaks as well.
As option, travelled time and passed distance can be taken just from

arbitrary choiced last past part,
e.g. last 90 minutes ( or whole track if less ) if user choices,
or whatever is handy for OSMAnd.
--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Poutnik Fornntp]

My idea is, if you do something - like OSMand displaying ETA, that do it
reasonably well, otherwise it is not worthy to do it.
One ETA fits all is good approach to cars and pedestrians, but not to
bicycles.

No method works well in all cases. Neither brain method works well in all
cases, but we still use it. Current OSMAnd method is unbalanced in all
cases, when avg *effective* speed, including breaks, is different to 20
km/h. Travel speed based or user defined avg speed based ETA is not
perfect. But we do not need perfection to replace something near useless
like current bicycle ETA.

At least customizable user avg speed should be implemented. 1 single
parameter can address all, biker conditions, experience, refreshment breaks
and external conditions. If he thinks he can do avg 25, let him set it so.
If she thinks he can do avg just 15, let her set it so.

The only purpose of mentioned weighting extension is to avoid initial
estimation noise of adaptive speed. It is not basis of algoritm and not
required.

ETA based on travel speed makes sense even for flat land, as it would adapt
to your speed, given by your condition, wind or just a mood. With winds,
easy help to cut routes to upwind and downwind, or better, as mentioned,
evalute just last part to track.

I remember Netherland winds, it may easily happen you drive as fast as
walker. In such case you would appreciate adaptive ETA more than fixed 20
km/h ETA.

About cyclist stops, you may have not read carefully. As time is taken in
initial algo design total time, not travelling time. For long routes is
supposed for ETA estimation time percentage of stops is statistically the
same. If you ride 3 hours 40 km/h and during that time you had in total 1
hour of breaks, then estimated adaptive ETA for next 40 km ( 2nd half of
trip ) is 3 hours as well, as is expected you take next in total 1 hour of
breaks.

The expansion I have in mind is short / long route mode.
For the former, speed would be taken from last arbitrary interval.
For the latter, all the route and total time, including past and supposed
future breaks

[frieder.ferlemann-S0/]

Post by Poutnik Fornntp
*1/- configurable avg bike speed as cheap way to realistic ETA
calculation, based on biker experience.*
*2/ ETA = time + travelled_time * ( remaining_distance) / (
passed_distance )*

Add a third:

3. *ETA = time_now_s + estimated_energy_to_finish_J /
configured_rider_power_W*

*estimated_energy_to_finish_J* would have to include data from DEM (digital
elevation model) (not the same as gpx files).

*configured_rider_power_W* could be something like 100 W for a 75 kg rider
if currently an average bike speed 20 km/h is hardwired.



(Maybe of interest for speed vs power calculations:
www.rennradtraining.de/kreuzotter/english/espeed.htm )

[Poutnik Fornntp]

Post by frieder.ferlemann-S0/
3. *ETA = time_now_s + estimated_energy_to_finish_J /
configured_rider_power_W*
*estimated_energy_to_finish_J* would have to include data from DEM
(digital elevation model) (not the same as gpx files).
*configured_rider_power_W* could be something like 100 W for a 75 kg
rider if currently an average bike speed 20 km/h is hardwired.
www.rennradtraining.de/kreuzotter/english/espeed.htm )

Hmm, I see obstacles

1/ It would be seen as much complicated to OSMand developers.

2/ It would not be generally usable, depending on elevation data

3/ Elevation SRTM ( Shuttle Radar Topography Mission) data or equivalent
ones are troublesome,
as mentioned e.g. by Dr Arndt, author of Brouter in "OSM Android
bikerouting" Google group.
They contain much of artefact noise, pretending elevation jumps in many
scenarios, where there are none.
E.g. he uses in Brouter just filtered ascend, that passed through
elevation hysteresis filter.

4/ rider power is too unknown and variable parameter.( See also
http://www.ilovebicycling.com/comparing-power-to-weight-ratio/ )

5/ It consider only physical point of view.

IMHO, the purpose of ETA is not to say, how soon you are able to reach
destination,
but what is probable time when it happens.