Fix invalid progress calculation #127
Conversation
| current_step_linestring: &LineString, | ||
| remaining_steps: &[RouteStep], | ||
| ) -> TripProgress { | ||
| if remaining_steps.is_empty() { | ||
| let Some(current_step) = remaining_steps.first() else { |
There was a problem hiding this comment.
Passing current_step explicitly here opened the door for potentially very confusing errors caused by this ambiguity. I've just made it impossible to make that mistake now.
| crate-type = ["cdylib", "staticlib", "lib"] |
There was a problem hiding this comment.
Linter catch: this didn't have any effect in a workspace sub-project ;)
| cargo build -p $basename --lib --release --target x86_64-apple-ios | ||
| cargo build -p $basename --lib --release --target aarch64-apple-ios-sim | ||
| cargo build -p $basename --lib --release --target aarch64-apple-ios |
There was a problem hiding this comment.
Minor improvement: we don't need to build uniffi-bindgen for any other architectures.
| let pct_remaining_current_step = if current_step.distance > 0f64 { | ||
| distance_to_next_maneuver / current_step.distance | ||
| } else { | ||
| 0f64 | ||
| }; |
There was a problem hiding this comment.
This was the core issue. If the snapped point is exactly at the end of the step, this results in division by zero.
| // This may look wrong, but it's actually how Valhalla (and presumably others) | ||
| // represent a point geometry for the arrival step. | ||
| let current_route_step = gen_dummy_route_step(x1, y1, x1, y1); |
There was a problem hiding this comment.
And this is why I noticed the issue; the last maneuver's geometry is the same point twice, so its length is zero; thus, the division by zero above, which ended up crashing one of the iOS formatters in the arrival view with a NaN.
This is probably the root cause of #126.