Hi,
I think this is not a new issue, but present all the time since I added ETA for Locus, but with BRouter 1.5.x this feature is released and also with the current Locus Version (3.40.2) it is not working correctly.
Displayed ETA is jumping at the turn-instruction locations.
The longer the distance between 2 turn-instructions, the more significant is the effect.
For example this bike-route-section here has a calculated travel time of 4 Minutes:
http://brouter.de/brouter-web/#map=16/50.1181/8.5253/standard&lonlats=8.525176,50.112708;8.512881,50.121238
But when I pass the northern junction displayed ETA jumps up by 8 Minutes.
So it seems for me as a bug in the linear interpolation of ETA between TR locations.
Hello,
thanks for pointing on this issue. I've improved compute a little bit, so in the next version, this just may be removed.
I've anyway found something surprising ...
Just open the attached GPX file. Check the second waypoint that defines distance 219 m, but 227 seconds?? It is the default "bike > fast" profile in app.
Quote from: menion on October 23, 2019, 08:12:32
Check the second waypoint that defines distance 219 m, but 227 seconds?? It is the default "bike > fast" profile in app.
Hi Menion,
ups ja, it seems I am putting at a TR waypoint:
- rteDistance as the distance to the *next* TR
- rteTime as the travel time from the *previous* TR
- rteSpeed = rteDistance / rteTime (in m/s) then is nonsense
So I will have to fix that.
Regardless whether I decide for next or previous, data is incomplete anyhow as long as I do not include a destination TR. Is it that you are adding a dummy destination TR based on a standard speed?
And I should provide rteDistance as "distance from previous"?
And rteSpeed in m/s or km/h ?
regards, Arndt
The system is not well documented on my side, sorry.
It is: always base units and always forward, so:
- distance: to next command in meters
- time: *to next* command in seconds
- speed: average speed for the segment between current and next command (so simple distance/time) in meters/sec
In case, there is no speed or no time defined, app uses the average speed of the user from the last few seconds of activity.
When I was fixing the problem you wrote here, I had an idea to improve times by comparing expected time (returned from BRouter) with real-time user spend on the segment and modify then expected total time by this ... so task on some calm evening :).
Quote from: menion on October 23, 2019, 15:38:16....When I was fixing the problem you wrote here, I had an idea to improve times by comparing expected time (returned from BRouter) with real-time user spend on the segment and modify then expected total time by this ... so task on some calm evening :).
I had exactly the same idea some time ago, it could be perhaps found on helpdesk or forum.
It was about confronting the "Nominal" prediction of needed time for given route segment ( or the whole already passed route ) with real time spent on it, and tuning the nominal ETA prediction, based on that.
In a trivial case, if I passed a recent long enough segment of the route by time 20 % longer than predicted, It would modify the ETA by these 20% as well.
It would take into account different performance of bikers, or their different momentary conditions.
Or the different car power and driver experience.
Sent from my Xiaomi MI A2 / Android 9, via Tapatalk
Additionally, it would be an ideal candidate for long term Kalman filtering of ETA prediction. ;-)
Sent from my Xiaomi MI A2 / Android 9, via Tapatalk
Quote from: abrensch on October 23, 2019, 15:28:29
So I will have to fix that.
So finally I fixed that in Version 1.6: http://brouter.de/brouter/revisions.html
(not yet on Google Play)
regards, Arndt