ETA calculation math/formula?

[pistika]

Hi!

I've been using Locus map for hiking and trekking for about a year now on a weekly basis and I really like it, but there's one thing that I can't figure out.

How is the "Estimated time of arrival" is calculated?

I've attached a screenshot and neither the current speed, nor the avg. speed gives a correct-ish estimate.
This ETA often gets me to worry and run for my finish point so that I won't miss the train/bus/whatever to get home in time, so I wouldn't have to wait 2 hours unnecessarily for the next one.

How is this calculated? What's the math behind it?

I would appreciate any guesses and formulas!
Thanks, Steve

You cannot view this attachment.

[Tapio]

I can't even tell... I searched the bigger discussion from last year, here also the dev from BRouter participated. Here:

https://forum.locusmap.eu/index.php?topic=7328

There was some more discussion around it, but I cannot find it.

[pistika]

I think I found the other thread, a support ticket topic:
https://help.locusmap.eu/topic/24639

It seems that the ETA is calculated when the route is planned and saved with the given planner service (LoRouter, BRouter, GraphHopper) and the set speed that is associated with it.
Or if the GPX was imported, it can have already saved data in it that will be used for this ETA calculation process.
Also, if you have a manually planned route or segment, that will also mess up this calculation even more.

Looks like your avg. speed and current speed have no real bearing on this number.

[Menion]

Hi guys,
it is a more complicated topic and currently, implementation is not perfectly reliable to be true. Currently, if we talk about BRouter or LoRouter service, time is computed internally by this service. During the navigation, the app deals with users' average speed during the last hour and uses it a little bit to modify computed ETA.

[freischneider]

The problem is that sometimes you run slower and then a too high time comes out. Or I have run the last 2 h very fast and therefore comes a value too low. It would be best if you can store a fixed value behind each activity or planning profile (personal experience). The calculation from now could be kept and the time of the personal value in brackets. So I know how long I need if I continue to run so and how long if I run as usual.

Translated with www.DeepL.com/Translator (free version)

[pistika]

Thanks Menion!

I'm completely fine with this now that I somewhat know how it works.
My problem was, that I was too reliant on the current/avg. speed calculation and I tought that it should be correct. Knowing, that it is calculated beforehand by the activity type's speed that is also different in different services... Yeah, it makes sense that it was missing the mark.

From now on, at the last hour or kilomenters, I'll just do some quick maths in my head and estimate myself.

[T-mo]

I also assume it's not a trivial task and definitely dependent on track section upfront and activity, and related dynamics (hiking vs cycling vs car) and maybe energy resources (muscles or motor) if you go wild and target sophisticated estimation
Sure, some averaged values of different time ranges and some clever weighting might do a quite good job.