Author Topic: Locus/BRouter Arrival time glitches  (Read 880 times)

Offline abrensch

  • Apprentice of Locus
  • **
  • Posts: 101
  • Thanked: 23 times
    • View Profile
Locus/BRouter Arrival time glitches
« on: October 17, 2019, 11:27:28 »
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.

 

Offline menion

  • Administrator
  • Professor of Locus
  • *****
  • Posts: 11569
  • Thanked: 349 times
    • View Profile
    • http://www.asamm.com
  • Device: SGS7
Re: Locus/BRouter Arrival time glitches
« Reply #1 on: October 23, 2019, 08:12:32 »
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.
Ideas, wishes, problems
Advanced topics, public discussion, sharing of knowledges, testing beta versions: you're here!
 

Offline abrensch

  • Apprentice of Locus
  • **
  • Posts: 101
  • Thanked: 23 times
    • View Profile
Re: Locus/BRouter Arrival time glitches
« Reply #2 on: October 23, 2019, 15:28:29 »
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
 

Offline menion

  • Administrator
  • Professor of Locus
  • *****
  • Posts: 11569
  • Thanked: 349 times
    • View Profile
    • http://www.asamm.com
  • Device: SGS7
Re: Locus/BRouter Arrival time glitches
« Reply #3 on: October 23, 2019, 15:38:16 »
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 :).

Ideas, wishes, problems
Advanced topics, public discussion, sharing of knowledges, testing beta versions: you're here!
 

Offline poutnikl

  • Padavan of Locus
  • ***
  • Posts: 498
  • Thanked: 47 times
    • View Profile
    • My Brouter Profiles
  • Device: Xiaomi MI A2 (6-128G) / And9-Pie / LocusMap Pro
Re: Locus/BRouter Arrival time glitches
« Reply #4 on: October 23, 2019, 19:12:43 »
....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
« Last Edit: October 23, 2019, 19:34:00 by poutnikl »
https://github.com/poutnikl/Brouter-profiles/wiki
When a user digs profiles up from the GitHub repositories,
they will be hopefully wrapped in some wiki knowledge....  :-)
 

Offline poutnikl

  • Padavan of Locus
  • ***
  • Posts: 498
  • Thanked: 47 times
    • View Profile
    • My Brouter Profiles
  • Device: Xiaomi MI A2 (6-128G) / And9-Pie / LocusMap Pro
Re: Locus/BRouter Arrival time glitches
« Reply #5 on: October 23, 2019, 19:31:12 »
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

https://github.com/poutnikl/Brouter-profiles/wiki
When a user digs profiles up from the GitHub repositories,
they will be hopefully wrapped in some wiki knowledge....  :-)