-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix coordinate fallback when linking locations in the street graph #7056
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 coordinate fallback when linking locations in the street graph #7056
Conversation
When a GenericLocation contains both a stopId that doesn't exist in the graph and valid coordinates, the system should fall back to using the coordinates to create a temporary vertex. This was the behavior before PR opentripplanner#6972 (temporary-vertex-refactor). The regression was caused by mutually exclusive if/else if logic in LinkingContextFactory.getStreetVerticesForLocation(). When location.stopId was present but not found in the graph, the method would return an empty set without checking if coordinates were available. This commit restores the fallback behavior by checking if results are empty after the stop ID lookup and, if coordinates are available, using them to create a vertex. This allows robust queries that provide both place IDs and coordinates for redundancy. Fixes the issue where GraphQL trip queries with non-existing place IDs and valid coordinates would return empty results instead of using the coordinate fallback.
Add test case that verifies when a GenericLocation contains both a stopId that doesn't exist in the graph and valid coordinates, the system falls back to using the coordinates to create a temporary vertex rather than throwing a RoutingValidationException. This test documents the expected behavior that was broken by PR opentripplanner#6972 and is now fixed.
b8469ee to
7002ae6
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #7056 +/- ##
=============================================
+ Coverage 72.23% 72.49% +0.25%
- Complexity 20169 20456 +287
=============================================
Files 2188 2206 +18
Lines 81186 82240 +1054
Branches 8141 8229 +88
=============================================
+ Hits 58645 59619 +974
- Misses 19667 19699 +32
- Partials 2874 2922 +48 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Tested this in our staging environment, this fixes the problem that users reported. |
| var fromVertices = linkingContext.findVertices(from); | ||
| assertThat(fromVertices).hasSize(1); | ||
| assertThat(fromVertices).isNotEmpty(); | ||
|
|
||
| var toVertices = linkingContext.findVertices(to); | ||
| assertThat(toVertices).hasSize(1); | ||
| assertThat(toVertices).isNotEmpty(); |
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 think this you might want to check that these vertices are also of type TemporaryStreetLocation as stop vertices might also end up in these collection.
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.
Test updated.
Summary
This is a fix for #7055: it restores the fallback mechanism in case the provided place id is not found in the stop repository.
Issue
Closes #7055
Unit tests
Added unit test
Documentation
No
Changelog
skip