-
Notifications
You must be signed in to change notification settings - Fork 26
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
Fix incorrect geometry index after advancing #357
Fix incorrect geometry index after advancing #357
Conversation
if let Some(current_route_step) = remaining_steps.first() { | ||
// TODO: We could move this to the Route struct or NavigationController directly to only calculate it once. | ||
let current_step_linestring = current_route_step.get_linestring(); | ||
self.snap_user_to_line( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we be passing the original location here from the caller and using that instead of the snapped location?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also found this to be a struggle to understand as I built the snapping task.
@ianthetechie the core state logic feels like an area of the core where some substantial commenting may help us all down the road. Basically to:
- Explain what params produce the major state changes like step advancement.
- To outline cases where unexpected params/vars are used (e.g. the different location vars).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agreed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I probably won't get around to commenting up this before my week ends, but I haven't forgotten about it. Alternately if @ahmedre ends up putting more time into this and identifies missing comments, adding them to this PR would be great too. Otherwise I can tackle improving docs here next week.
I have no idea if this is the ideal fix or not, but I saw this case while testing, where, while logging:
I saw a case where the geometry index was greater than the geometry size (and, at that point, the current remaining steps size had decreased by 1). Looking at the code, it seems that there's no re-computation of the current step geometry index after the current step changes, causing this to be incorrect. |
After advancing the step, the geometry index sometimes incorrectly refers to an index in the previous RouteStep instead of the current one. This patch recomputes the geometry index when the RouteSteps change.
404fc4b
to
dfce24d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this doesn't actually solve the problem 😅 I've added some tests.
Thanks - I was doing the recalculation in the wrong function (in the advance function). The caller actually disregards all fields it isn't interested in, and the comment actually says that this is by design, since the caller should re-compute whatever it needs to. |
After advancing the step, the geometry index sometimes incorrectly refers to an index in the previous RouteStep instead of the current one. This patch recomputes the geometry index when the RouteSteps change.