Calculation of estimated time of arrival

[IanW]

Can someone explain how OsmAnd calculates estimated time of arrival? Whatever way it is done at the moment is not accurate. Yesterday, for example each time I looked at OsmAnd, my destination was 10 minutes away and that went on for about 30 minutes, until the last 10 minutes. It finally got it right when I arrive but 25 minutes later than the first guess.

I can think of several methods of calculation:

1. Use an assumed speed or the speed limit. Speed limit is no use for pedestrian mode and assumed speed likely to be very inaccurate.

2. Use instantaneous speed. Not much value if there are traffic lights, heavy traffic, hills, etc.

3. Average speed over the preceding period (say 5 minutes). This should be more accurate than the first 2.

4. Average rate at which distance to destination is reduced over a period of time. This looks mathematically similar to 3. but should be easier to calculate.

Thanks

[stf]

What was you mode of transportation? I have only barely tried navigation in bicycling or walking modes and don't recall even having the estimated arrival time displayed for those tests.

For auto, it appears to use the maxspeed values on the roads and falls back to assumed maxspeed values if the tagging is missing in OpenStreetMap. From my experience, the estimated arrival time for driving is pretty close as long as the highways are properly tagged.

Along that same line: If the highways are not tagged then the fastest route calculation may also be off as, at least in my area, the assumed maxspeeds are usually different that posted speed limits.

[P Wat]

I can confirm that in Bike mode there is definitely a display of ETA (or time to destination, I forget which), but I'm usually enjoying the ride too much to have analysed the accuracy.  Maybe tomorrow.....
PW

[Ian Wills]

I was walking, but the method of transport should not affect the method of calculation. After all, OsmAnd is registering everything needed to calculate it and should not need to make assumptions about speed limits etc. I have not checked it fully, but choosing car or pedestrian does not seem to change the calculated time.

BTW, I am using OsmAnd~ 2.0.0#8672M. To show estimated time of arrival go to configure screen and check "Time to go". Touching the time to go on the map screen toggles between time of arrival and time (hh:mm) to go.

--
You received this message because you are subscribed to a topic in the Google Groups "Osmand" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osmand/r0vPNsXba84/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osmand+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Osmandtrier]

Yes and no. In routing.xml there are speed values for every type of way depending on your vehicle. I using vor my own bicycle routing my personal speeds and it works pretty good.

But in the pedestrian section there are no such values, there are only a min-speed=3km/h and max-speed=5km/h at the beginning.

[P Wat]

1) Last year, on several fairly long bike rides, the ETAs generally, seemed fairly appropriate for the speed at which I was cycling.  This may have been coincidence, or perhaps good OsmAnd calculations.
2) Recently I've gained the impression that the accuracy of cycling ETA is not so good.
3) Tonight whilst car driving about 5 miles, I deliberately set OsmAnd to bike mode to see what would happen. Obviously I drove at car speed (not bike).  The ETA was accurate.  One cant help wondering why!
I'll aim to feed back when I've done more tests.
PW

[Ian Wills]

Thanks. I had a look at routing.xml and now understand what is going on. As I see it, all the default values are provided in this file in order to estimate time before you start. I guess Google maps does something similar. However if walking speed is 3-5 km/h (how does it know which to use) the calculation should still produce a consistent result. Say I am walking and my destination is 1 km away. When I start OsmAnd will calculate time to go as 20 minutes (3 km/h) or 12 minutes (5 km/h). It does not seem to get this right. Time to go just keeps on getting longer, not shorter. Eventually it is right, but only when I am 10 m away!

However, calculating on the basis of assumed speeds is OK when you are stationary but once you start moving OsmAnd has much better information available: current instantaneous speed and average speed. It will get more accurate results if it uses these rather than assumptions.

I will log this as a feature request.

--

[Osmandtrier]

However, calculating on the basis of assumed speeds is OK when you are stationary but once you start moving OsmAnd has much better information available: current instantaneous speed and average speed. It will get more accurate results if it uses these rather than assumptions.

Would not work. First half urban area with maxspeed=50km/h second half german motorway without any speedlimit. The estimation would be in the most time very wrong.

[stf]

On Thursday, January 15, 2015 at 6:21:37 AM UTC-8, Osmandtrier wrote:

Would not work. First half urban area with maxspeed=50km/h second half german motorway without any speedlimit. The estimation would be in the most time very wrong. 

It seems to me that estimated arrival time for driving are not an issue here but rather times when walking and possibly bicycling. Those are, or at least should be, different calculations than for driving which can use tagged or assumed maxspeed values.

[Ian Wills]

Correct. In order to overcome this, in the feature request I submitted, I proposed the real time calculation  be applied only to the current way type. 

Of course, when you are on the German motorway crawling at 5 km/h along because of an accident, having real time estimate of time to go will be much more helpful than for OsmAnd to assume you are going 110 km/h as it does in now in routing.xml.

On Fri, Jan 16, 2015 at 1:21 AM, Osmandtrier <stephan....@googlemail.com> wrote:

However, calculating on the basis of assumed speeds is OK when you are stationary but once you start moving OsmAnd has much better information available: current instantaneous speed and average speed. It will get more accurate results if it uses these rather than assumptions.

Would not work. First half urban area with maxspeed=50km/h second half german motorway without any speedlimit. The estimation would be in the most time very wrong.

--

[Ian Wills]

This is an issue for all modes of transport (even by boat) not just cycling and walking. 

For driving the problem of assuming speed = max speed is that it ignores so many possible scenarios. For example, in a city, travelling on a road at say 1 am I can make a journey in 20 minutes. 7 hours later, in peak time, it might take me an hour. In another case, two roads in rural areas might have the same legal speed limit but one is straight with a few gentle curves and the other a winding mountain road with many sharp bends. I can drive at the speed limit on one but will die if I try it on the other. Simple solution: if my real time average speed is 100 km/h on one, use it, if it is 50 on the other, use that, not the legal maximum.

--

[Poutnik]

Dne čtvrtek 15. ledna 2015 15:21:37 UTC+1 Osmandtrier napsal(a):

However, calculating on the basis of assumed speeds is OK when you are stationary but once you start moving OsmAnd has much better information available: current instantaneous speed and average speed. It will get more accurate results if it uses these rather than assumptions.

Would not work. First half urban area with maxspeed=50km/h second half german motorway without any speedlimit. The estimation would be in the most time very wrong.

What about combination of both ? Baseline for estimation would be nominal speeds for particular road types, but would get corrected with predicted versus real time profile ?
That is for cars.
For bicycles, anything not considering elevation profile will not be much accurate, unless statistical values over longer distance.

[Josef Kufner]

Poutnik wrote, on 20.1.2015 17:48:
> For bicycles, anything not considering elevation profile will not be
> much accurate, unless statistical values over longer distance.

This is very good point. When I saw time units on signposts in Tatry
(2000m mountains in Slovakia) instead of distance, I was a bit
surprised, but when significant elevation is in play, distance is not
realy that important. Also a road quality should be considered.

And not only for bicycles, pedestrians depend on elevation too, but with
different speed profile.

[Ian Wills]

Actually, I have done some research myself on speed when walking and to my great surprise, elevation change is not a significant variable. The most significant variable by far is surface condition. For example, on a well graded, sealed road I can average 4.5 km/h regardless of incline but on a good but unsealed road this drops to around 3.3 km/h, on a sandy beach it drops more and so on.

Either way, the problem is that we have two different issues that seem to be getting mixed together:

1. Estimating travel time when stationary. OsmAnd currently does this well for vehicles and reasonably well for bicycles and pedestrians.

2. Estimating travel time when moving. At present although OsmAnd has the data to do this it does not and instead uses the stationary estimates.

I would like to see item 2. incorporated in OsmAnd, perhaps confined to the current section of route. My 7 year old Garmin Oregon 300 does it and does it well so there is no reason why OsmAnd could not do it too.

[P Wat]

Hi Ian
My Garmin (ETrex) is even older, and simpler, but like yours, it does a good job of calculating ETA based on actual moving speed.
I've found equally good results on Android, with ViewRanger for example.  Plus screen visibility and GPS reception are better on Android, The only benefit of (my) Garmin now is that it is robust!
PW