Feature Request: Ability to navigate along a route rather than just from A to B

[richjhart]

This is basically based on a number of comments on other issues, and the changes made in Navigation SDK 0.20.0 (and later) - and refers to a use case which used to be possible but isn't anymore.

The use case is to allow the navigation to take the user along a particular route. While some tolerance should be allowed (cutting corners, skipping small sections - or perhaps other calculations determined by the exact use case), in this use case the Navigator should not be able to skip too many steps ahead. The changes in 0.20.0 now only does navigation from A to B, with the position within that completely irrelevant.

In particular, one use case might be to send the user from A to B and back to A - in this case the current version might prematurely skip ahead from the A to B section to the B to A section. There may be other similar cases.

One workaround which nearly works would be to divide the route into separate legs, however this has some significant drawbacks:

• The user must then get very close to the waypoints in order for the next leg to start, but they may not be quite appropriate. If the user goes slightly off route and skips a waypoint, this may be acceptable, but the Navigator would not detect that the waypoint has been hit and move onto the next leg.
• Waypoints always assume the user will stop, which means the directions are incorrect (Arrive and then Depart, instead of a turn).
• It may be difficult for software to work out the correct location to put the waypoints to prevent skipping of sections
• Note that Feature Request - Waypoints as "Vias" #875 could help with the second point, and probably the third (as more waypoints could be provided), but probably not the first.

Is there any possibility to allow some flexibility of how the Navigator works. For example, an optional callback in NavigationRouteProcessor.buildNewRouteProgress to allow the application to ignore the NavigationStatus and generate our own RouteProgress (or perhaps even our own NavigationStatus), to limit jumping ahead (or backwards) based on our own logic.

Is anything like that possible (Or any other ideas for how it could work)?

Unfortunately, I can't see any other way of our use cases working and as a result we are stuck on version 0.19.0 for now.

[kevinkreiser]

@richjhart I believe your workaround will actually work but it seems you've caught us in a situation where we've not properly implemented multi-leg routes. At present we are failing to continue onto the leg n + 1 once the threshold for completing leg n has been met. We are working on getting this functionality back up to snuff.

As you note, even with simple logic for moving onto leg n + 1 in place, there are literal edge cases, where the user might not progress all the way to the beginning of leg n + 1 and so we need to work around these issues. We have some ideas there but we hope that the initial more simple implementation of continuing onto the next leg will suffice in most situations and until we implement an even more robust situation.

[richjhart]

@kevinkreiser I will have a look and see how well it handles a multi-leg route in terms of completing the route.

However, even if the recovery works perfectly for jumping to the next leg, we are still left with the original issue we had with multi-legs - the directions will be incorrect at the end/start of each leg. That was the reason we moved over to MapMatching in the first place, so we could use a single leg and all the directions would be continuous.

[richjhart]

@kevinkreiser We have actually worked out a method to get around the directions issue - which is a bit hacky, but I think should be fairly stable (we make the MapMatching request as a single leg, then manually generate multiple legs by splitting up the legs. That seems to basically work in terms of giving the right directions as we approach the first waypoint. (We have also had to override the ic_route_destination drawable in order to prevent it drawing the waypoints that now exist - which is partly what makes it feel like a hack).

As you note - jumping to the next leg isn't yet working. Is there an estimate for when that should be working? Are we expecting at least basic functionality in 0.23.0?

However, even once that is working, we are probably going to have an issue where we don't necessarily expect the user to hit the waypoint exactly, or in some cases even particularly closely. We currently have a separate algorithm for working out if the user is "allowed" to jump ahead or not if they have skipped steps - we might still be able to use that anyway, but it would be good if there was some way to pass down to the navigation engine if we are satisfied that the user has "hit" the end of the leg, so it's allowed to move on to the next leg. Is that something that is likely to be supported, or should I look at updating our existing "jump ahead" algorithm to take into account the multiple legs?