Problem
The library currently uses different routing models in different places:
route / route_with use nearest-node snapping.
compute_matrix uses edge snapping.
compute_geometries delegates to route, so geometries and matrix values can disagree.
Why this matters
Callers can get inconsistent durations, distances, and route shapes for the same input coordinates depending on which API they use.
Scope
- Decide on a canonical routing model for public APIs.
- Either migrate all route APIs to edge-snapped routing or expose clearly separate node-snapped and edge-snapped families.
- Ensure batch geometry generation uses the same semantics as matrix generation.
Acceptance criteria
- Public routing APIs have consistent snapping semantics.
- Matrix and geometry batch methods agree with single-route methods for the same inputs.
- Tests cover consistency across API surfaces.
Problem
The library currently uses different routing models in different places:
route/route_withuse nearest-node snapping.compute_matrixuses edge snapping.compute_geometriesdelegates toroute, so geometries and matrix values can disagree.Why this matters
Callers can get inconsistent durations, distances, and route shapes for the same input coordinates depending on which API they use.
Scope
Acceptance criteria