LoRouter route planner generates time stamps - why and for what?

[Graf Geo]

Since I sometimes have problems with the ETA during (track)navigation in the current version (unrealistic, sometimes nonsensical times are displayed from time to time, usually much too short), I took a look at the planned routes as a gpx file:

The LoRouter generates timestamps when creating a route. Unfortunately, this is now also the case if you create a route without navigation commands. It is completely unclear to me what the purpose of timestamps is for a planned route. Logically, they make sense for a recorded track, but for a planned route?

Are they needed for the navigation commands and if so, why? The time is irrelevant, and they would be unnecessary for a planned route without navigation commands.

Just to calculate a fictitious route time in the planned route? Which is also too short by default (5 km/h or even more is always assumed for "walking", which is definitely too fast). 

No other route planner generates time stamps. Not GraphHopper, not BRouter Web, not openrouteservice.org and not even the Locus web planner. And you can navigate with their tracks without any problems.

If someone can explain this to me briefly and clearly (unfortunately I am not a geoinformatics specialist), I would be grateful. I couldn't find anything useful on the Internet.

It would also be interesting to know how the ETA is calculated during track navigation. All you really need is the current speed, the length of the remaining distance and (if available) the gradients. As I said, the values are sometimes given in an absurdly short form and are therefore not reliable.


EDIT: I just found my posts (in german) in this 3 year old thread. There were already problems back then.
 

[Menion]

Hello,

saving times to trackpoints was done in 06/2023. The main reason was to display the time-based chart for planned routes. Also in the case "Include nav. instructions" are disabled, these times are used for time estimates if I remember correctly.

Generally, is there any problem with timestamps stored within the trackpoints?

ETA during navigation ... I know it is not perfect and I really do not want to explain (again) full complex logic
behind this now. Anyway, it is not as easy as "distance / average speed". Computed time currently considers routing profile, surface, elevation etc. What should be improved, is automatic updating of this time by user performance during the ride. At least this. Anyway, I believe, that current times computed by the LoRouter should be quite usable without problematic values as before. If there is any non-sense, it is best to simulate the same issue on the web planner and report it.

[0709]

No other route planner generates time stamps.

Well, some other do, by means of a configurable avg speed set up.
A correctly timestamped track can so be quite informative.
In attachment a simple timestamped track.  Avg speed set: 4 kmh.
According to the route planner, you need 1h32' to walk from the train station to my local pub.
The terrain is flat and simple so the timestamps calculated by avg speed are representative.

Also the Plotaroute web planner adds reference timestamps in track points.
The Plotaroute web planner seems to be very optimised for ETA calculations. 
https://www.plotaroute.com/tip/11/how-to-estimate-the-time-to-complete-a-route
I did not try all this, anyway those interested can give it a try anyway.
Gpx downloads by Plotaroute can add Locus compatible navigation hints (if set).
Download as: GPS > GPX > Track > Directions > Download this route.

[Graf Geo]

... The main reason was to display the time-based chart for planned routes. ...

Generally, is there any problem with timestamps stored within the trackpoints?

ETA during navigation ... I know it is not perfect and I really do not want to explain (again) full complex logic
behind this now. Anyway, it is not as easy as "distance / average speed". Computed time currently considers routing profile, surface, elevation etc. What should be improved, is automatic updating of this time by user performance during the ride. At least this. ...

Time-based chart: I understand, but as I said, this is not very helpful if the time is always given too low. 5 km/h is too fast. And when I plan a route up a steep hill, the time is usually given as about 20% less than I actually need. I have compared it with many of the tracks I have recorded and I am not particularly slow. The basic speed used should be lower (4.2 - 4.5 km/h when walking) or, even better, individually adjustable.

ETA during navigation: sorry and thanks for your patience. At least you agree that there is room for improvement here.
We mainly hike and walk in flat or slightly hilly areas without difficult terrain, so a simple time/distance calculation would be sufficient. (Perhaps this could be set as an option in the settings.)
Unfortunately, the remaining time for track navigation is often unreliable and then usually much too short. It would therefore be really nice if user performance could be better taken into account when travelling in future.

Gesendet von meinem SM-G973F mit Tapatalk

[Graf Geo]

@0709: I sent you a message.



Gesendet von meinem SM-G973F mit Tapatalk