Focus vehicles on exact trip geometry and stops#1893
Merged
Conversation
|
Warning Review limit reached
Next review available in: 48 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughSelected vehicle trips now load exact trip geometry and scheduled stops, project stops onto that geometry, and render focused route polylines, badges, framing, and stop presentations. ChangesSelected trip presentation
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant VehicleSelection
participant RouteMapController
participant TripObservationRepository
participant MapRenderState
VehicleSelection->>RouteMapController: select trip ID
RouteMapController->>TripObservationRepository: load exact shape and schedule
TripObservationRepository-->>RouteMapController: return selected trip data
RouteMapController->>MapRenderState: publish focused polylines and stops
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
bmander
marked this pull request as ready for review
July 16, 2026 17:34
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@onebusaway-android/src/main/java/org/onebusaway/android/map/RouteMapController.kt`:
- Around line 613-615: Update the selectedRouteUnderlay branch in
RouteMapController to derive the underlay from
routeShape.shapeForDirection(selectedRoute.directionId) rather than
basePolylines, using the selected trip’s direction; preserve emptyList() when no
trip is selected and apply the existing deemphasized underlay transformation to
the direction-specific shape.
- Around line 678-680: Update selectedTripPresentation() so it returns null
unless both state?.polyline?.points and state?.schedule?.stopTimes are present;
only construct SelectedTripPresentation after both resources resolve, rather
than converting missing data with orEmpty(). Preserve the existing mapping for
non-null shape and schedule data so the base stop presentation remains visible
during loading or failed lookups.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f0e0d3d6-23ff-4139-843a-3ebeac361366
📒 Files selected for processing (5)
onebusaway-android/src/main/java/org/onebusaway/android/map/RouteMapController.ktonebusaway-android/src/main/java/org/onebusaway/android/map/RouteMapRepository.ktonebusaway-android/src/main/java/org/onebusaway/android/map/RouteViewGeometry.ktonebusaway-android/src/test/java/org/onebusaway/android/map/RouteDirectionFocusTest.ktonebusaway-android/src/test/java/org/onebusaway/android/map/RouteViewGeometryTest.kt
- Derive the selected-trip underlay from the trip's own direction shape rather than basePolylines, which in whole-route mode merges both directions and would surface the opposite direction beneath the trip. - Return null from selectedTripPresentation() until both the exact shape and schedule resolve, so a half-loaded selection no longer blanks the base stops behind an empty selected-trip presentation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…etry # Conflicts: # onebusaway-android/src/main/java/org/onebusaway/android/map/RouteMapController.kt # onebusaway-android/src/test/java/org/onebusaway/android/map/RouteViewGeometryTest.kt
- Unify the selected-vehicle presentation into a single guard clause instead of threading it piecemeal through both focus branches. When a trip is selected it is always active and (in whole-route mode) focusedGeometry is empty, so toTripFocusedRoutePolylines collapses to underlay + trip — the branches produced identical output. Hoist the shared badge computation. - Extract directionPolylines(directionId), shared by showDirectionPolylines and selectedDirectionUnderlay, removing the duplicated shape→polyline block. - Warm the selection's shape/schedule with launch instead of async/await (the results are discarded; only the cache side effect matters). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
bmander
added a commit
that referenced
this pull request
Jul 16, 2026
…1899) #1893 routed every vehicle selection through publishMapPresentation(), whose new selected-trip branch always drew the exact trip in the route's GTFS color (currentRouteColor()) over a generic direction underlay. Inside stop focus, where the emphasized route is drawn in its adjacency color, tapping a vehicle therefore reverted the route to its GTFS hue and layered the trip over the generic route-direction geometry — reading as standalone route mode. Resolve the selected trip's color from the adjacency palette (routeColors[selected.routeDirection]) when the route is emphasized in stop focus, falling back to the GTFS color only in whole-route mode where no adjacency entry exists. In that emphasized case also drop the generic direction underlay: the adjacency-colored trip already reads on its own, and the underlay is what made it look like route mode. Whole-route standalone selection is unchanged (GTFS trip + underlay). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jul 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Why
A selected vehicle previously added its extrapolation and continuation overlays while leaving the route-direction geometry and stops in place. One direction can combine substantially different trip patterns, so the displayed line could diverge from the tracked trip and make a continuation appear to branch from the middle of the route.
Impact
Vehicle focus now follows the actual trip path and scheduled stops. Riders retain route and stop-focus context through thin underlays, while the selected trip remains visually dominant.
Validation
./gradlew :onebusaway-android:testObaGoogleDebugUnitTest --tests 'org.onebusaway.android.map.*'git diff --checkSummary by CodeRabbit
New Features
Bug Fixes