New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing onFasterRoute API #4233
Comments
Hey thanks for the feedback! Some of the confusions are due to; porting an interface from v1 navigation, adding ideas, learning about the issues you listed. After we realized this is mostly about alternatives, there was some discussion about repurposing it as such (check linked issues) That's the background. Below will answer the numbered questions
Altering the RouteProgress into an object of relevant info is a good idea too. I just tried that for Arrival, but ended up using RouteProgress. Happy to chat more about this
This was a product ask, see "Feature Change: Faster Route API" linked issue.
Also love this idea. The 10% limit came from legacy. Would like to loop in iOS to make something consistent. |
We spoke about estimating the work in this ticket, and agreed it was still too ambiguous to start work. I've translated it into a actionable proposal here https://github.com/mapbox/navigation-sdks/issues/956 The goal of the proposal is to address and close this ticket |
Currently faster route logic will fetch faster route every 5 minutes (customizable, but not less then 2 minutes), and determine that route is faster, if it's at least 10% (not customizable) faster than the current one.
Then, after 5 minutes when faster route is requested, there are two possible situations:
FasterRouteObserver will call onFasterRoute with current route and an alternatives list,
isAlternativeFaster == true
; alternatives will still contain current route in the list of alternatives.FasterRouteObserver will call onFasterRoute with current route, alternatives list with
alternatives[0]
the same current route andisAlternativesFaster == false
. That was fixed at Faster route does not guarantee new route is different #3144 / Compare routes using step names #3301.Couple of questions / notes regarding this:
If user would like to still make use of it, even if we don't say new route is faster, they'll need to filter current route in some way (also, maybe compare it with the current RouteProgress), facing with the same complexities that we've dealt in Compare routes using step names #3301.
What I would expect is that
alternatives
list should not contain the current route at all. Suppose we could filter it out from the alternatives.By the way why the minimum 2 minutes limit was introduced? It's a bit weird that setting this value less that 2 minutes will just crash the application in runtime without any prior warnings.
Could we customize 10% limit when calculating logic of faster route? We've ended up implementing similar logic on our side since had a requirement to show any faster route, even 1 second faster than current.
cc @mapbox/navigation-android; @kmadsen since you've implemented #3301
The text was updated successfully, but these errors were encountered: