Time at Arrival

[alanmcd]

I see questions from a long time ago (2013) on this but nothing much since. I notice that time to arrival for navigations are extremely underestimated. 500km is set to take 1hr 20m. 100km shows as 10mins away.
What do I have to do to get these estimates of arrival more realistic?
Alan

[poutnikl]

Hmm. the ETA ( Estimated Time at/of Arrival ) topic was discussed in last about 2 years quite a lot, either here or on the Helpdesk.  You may guess the proper ETA calculation is very tricky.

As the first step you could provide the procedure to reproduce the above results.

As you may know, LocusMap does not have its own routing feature.  It relies on the online or offline 3rd party routing services. The ETA can be either calculated by the routing service and returned to the LocusMap ( not sure if this happens as I am not a developer ), either LocusMap has to calculate it somehow.  But LocusMap has no idea about the quality and speed of particular route segments.

One option is to use hard coded nominal values, as some navigation software use.  E.g. 4 km/h for pedestrians, 15 km/h for bicycles, 60 km/h for cars. In average, they are neither very bad,  neither very good. There are many cases with significant bias to both sides.

Another option is to calculate ETA from the real time motion and motion history. This gives usually better results than nominal values, but can provide extremely wrong values in some cases. And here come the tricky part.......

If one gives too high weight to immediate speed, or uses too short history record, the ETA fluctuates, depending on short time variability of the speed history.

If one gives too low weight to immediate speed, or uses too long history record, the ETA gets too big bias, depending on long term variability of the speed history.

As far as I know, LocusMap currently uses ETA calculation based on the mean speed in last 3 or 5 minutes, based on the sliding exponential averaging. This is valid for real time navigation. If it generates a GPX navigation track, it puts there, AFAIK, some formal and funny time stamps.

[alanmcd]

OK - thanks for the detailed answer.
I can see then, that for Locus, things haven't changed much since the issue was raised so long ago.
I had thought it might be addressed by now via a webservice or the like, since when I do this with my Garmin device or Google maps, I can start out on a 5hr trip and arrive within just a few minutes of the initially predicted time. I'm always so surprised as to how Google and Garmin get it right.
Seems like, with Locus I just need to focus on distance to target and do the math myself.
Alan

[alanmcd]

Actually Google maps has a public API to provide a good estimate of travel time:
https://developers.google.com/maps/documentation/distance-matrix/

You've only got to ask it for the answer

Alan

[Menion]

Hello guys,
just to make it more precise. For quite a long time, time computed in Locus Map during navigation is based on longer time frame. Currently it's used exponential filter that use latest +- 1 hour of average speed for every activity separately. So time estimates during navigation may be quite precise. Some time predictions are anyway still not perfectly implemented.

[poutnikl]

[...] Currently it's used exponential filter that use latest +- 1 hour of average speed for every activity separately. [...]

I see. I may have confused it with the old time span for the navigation hints. They use rather seconds than minutes now, after our discussion,AFAIK. 

The solutions that perform all of a/route calculation, b/route following and c/ETA estimation have an advantage. As they can calculate a nominal route speed profile and provide very good ETA estimation based on nominal and real-time profile comparison.