Feature Request: Recover route from LOST state if back on course

[nebular]

If you go slightly off-course and the route enters the LOST state, there should be a way to recover back to normal state if we're back into the route (ie. calls to onSnapLocation happen again).

I've tried to set mRoute.lost to false via reflection if onSnapLocation is called again after the route was in LOST state, and it successfully recovers. This only happens apparently when the rider goes back to the same Instruction, but hey, it's something !

It would be fantastic if the route could be recovered when the rider approaches any point of the route. Why? For example, a user can setup an elaborated route, with lots of waypoints, etc. Then suddenly decides to leave the highway and go for an unplanned lunch. At some point he/she would join the route again, maybe skipping some instructions, but is interested in keeping all the calculated route intact.

[ecgreb]

Currently the RouteEngine expects that after invoking RouteListener#onRecaluclate(Location) a new route would be fetched from Valhalla using the given location as the starting point and set via RouteEnginer#setRoute(Route).

https://github.com/mapzen/on-the-road_android/blob/master/library/src/main/java/com/mapzen/helpers/RouteEngine.java#L147

This seems preferable to continuing to snap locations and make callbacks for a route that is already considered to be LOST. Unless for some reason the device no longer has network connectivity and is unable to fetch a new route but this use case is not really supported at this time.

[nebular]

Thanks for the answer @ecgreb. The problem is that, in our experience, sometimes the route is considered lost too quickly for a number of different reasons, for example a temporary GPS accuracy jump, a new junction ... I hope you consider the feature in the future.

[ecgreb]

@nebular thanks for the feedback we do appreciate it.

If you find the snap location algorithm is rerouting too aggressively we could make the threshold for measuring if the location is off route configurable.

https://github.com/mapzen/on-the-road_android/blob/master/library/src/main/java/com/mapzen/valhalla/Route.kt#L26

I'm not sure I totally understand the original use case you are describing though. In the case where the user leaves the highway for an unplanned lunch wouldn't you want to reroute them to get back to the highway?

In any event perhaps there is no harm in allowing a route to attempt to recover if a new route has not been set.

I'm curious if @dgearhart or @kevinkreiser have thoughts about this in their experience. Is there any downside to allowing a route that has been determined to be lost to recover if the user gets back on course that we may not be considering?

[dgearhart]

Hey @ecgreb
@dnesbitt61 discussed the possibility about rejoining a route if a user pulls off for gas or food but has not been implemented yet. Also, this might be easier when the network is known to make a determination to reroute or rejoin. Downside would be not rerouting fast enough when truly off route

[nebular]

Hi @ecgreb and @dnesbit!

My originally described use case is maybe too specific for our project (where complex routes are planned in advance) and I understand it won't make sense for everybody.

But testing the router these days (I love it !!) I've identified situations when the rerouting is triggered because of a temporary GPS accuracy jump, that is quite frequent on the cheap $200 phones, when entering a long tunnel, a newly built junction, etc.

Anyways, just having a method in Route to set lost to false covers most of our needs. I hacked it via reflection for a proof of concept and it works beautifully. What I do is:

• if onSnapLocation is called when route.isLost() is true, it means the user came back to the current route instruction. Then I force-set route.lost to false via reflection and the routing continues seamlessly. I use the provided location to paint the location icon.

• if onUpdateDistance is called when route.isLost() is true, It means onSnapLocation has not been called, the user is off-route, so I use the current GPS location to paint the location icon, and update a sign "BACK TO ROUTE" with distance and bearing to the latest known route point (saved in onSnapLocation). I plan on triggering auto-recalculation here if that distance goes beyond a threshold.

In any case, when receiving onRecalculate I always enable a button to trigger network recalculation, if the network is available. This button disappears when onSnapLocation is called and route.lost is false again.

So the final result is, if you pull off for gas or enter a newly-built junction, etc ... it recovers automatically. If you purposely divert from the route, you can always press the button to get a new route, or wait until the distance threshold has been surpassed to automatically get it.

@dnesbitt61 said:

Downside would be not rerouting fast enough when truly off route

Yes that might be a problem, but I think the functionality should be made optional, so you can programmatically enable route re-snapping or just trigger a recalculation.