maplibre-navigation-android icon indicating copy to clipboard operation
maplibre-navigation-android copied to clipboard

Question about route progress updates

Open beto-alves opened this issue 1 year ago • 6 comments

Is there a way to force instructions to jump into determined route lag and step based on the current user's location? In our current project, we have a fixed route situation, like a delivery route from a warehouse to the factory for example. And for some scenarios, the user might be alongside and off route. The problem is when the user goes in the route and start the trip, we are not receiving the updates in the instruction view, I already debugged the NavigationRouteProcessor, NavigationHelper and OffRouteDetector. In this case the NavigationIndices are not receiving any updates in the NavigationRouteProcessor.

In this case, Is there any approach to solve the instructions update?

beto-alves avatar Sep 07 '23 21:09 beto-alves

You can set the leg and step index from the OffRouteDetector using the methods in the OffRouteCallback which is registered there.

boldtrn avatar Sep 13 '23 06:09 boldtrn

Hi @boldtrn thanks for your answer!

I have researched the usage of the OffRouteCallback you mentioned in the OffRouteDetector. I found the onShouldIncreaseIndex() method but couldn't find any use of the onShouldUpdateToIndex() method, which I believe would be suitable in this context.

I also investigated the OffRouteCallback and discovered that it can only be utilized within the OffRouteDetector. Unfortunately, it's not possible to use it with a custom off-route engine because the setOffRouteDetectorCallback method in NavigationHelper has a type check, limiting its compatibility to the OffRouteDetector.

So, I see two potential solutions: either modify the OffRouteDetector to accommodate this case or expose the setOffRouteCallback method, which is currently exclusive to the OffRouteDetector, to the OffRoute abstract class. This would enable the use of the callback with a custom off-route engine, which I believe is the optimal way to address this issue.

What are your thoughts on this? Do you think it's feasible to expose these methods? If yes, I'd be glad to create a pull request and contribute to this improvement.

beto-alves avatar Sep 13 '23 21:09 beto-alves

has a type check, limiting its compatibility to the OffRouteDetector

I think you can extend the OffRouteDetector and this will work.

modify the OffRouteDetector to accommodate this case or expose the setOffRouteCallback method

I think this is something we could add, this would make the code easier as well. Feel free to open a PR for this.

boldtrn avatar Sep 14 '23 06:09 boldtrn

Yes, extending the OffRouteDetector should also work. I will work on this and submit a pull request to expose the methods. Thank you for your support!

beto-alves avatar Sep 14 '23 12:09 beto-alves

Just to clarify, I think it would make sense to add setOffRouteDetectorCallback method to the abstract class OffRoute. I am not sure we should expose the method onShouldIncreaseIndex publicly, as this is kind of a corner case of OffrouteDetection.

boldtrn avatar Sep 14 '23 13:09 boldtrn

Yes, that's the approach I would take. Adding setOffRouteDetectorCallback to OffRoute makes more sense than altering the visibility of onShouldIncreaseIndex.

beto-alves avatar Sep 14 '23 13:09 beto-alves