Locus/BRouter Arrival time glitches

Started by abrensch, October 17, 2019, 11:27:28

0 Members and 1 Guest are viewing this topic.

abrensch

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.

  •  

Menion

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.
- Official help (ideas, questions, problems): help.locusmap.eu
- Advanced topics, sharing of knowledges: you're here!
- LM 4 Beta download, LM 4 Release download
  •  

abrensch

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
  •  

Menion

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 :).

- Official help (ideas, questions, problems): help.locusmap.eu
- Advanced topics, sharing of knowledges: you're here!
- LM 4 Beta download, LM 4 Release download
  •  

poutnikl

#4
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

poutnikl

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


abrensch

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
  •  
    The following users thanked this post: Menion