Load bus stops in chunks so long routes stop timing out#4
Merged
Conversation
The route corridor was sent to Overpass as one all-or-nothing query that embedded the coordinate string four times (roads + three bus-stop tag clauses). On long routes that regularly exceeded the 25s server timeout, and because the caller swallowed errors, every bus stop and speed limit was silently lost — exactly the 'stops never load' failure. The 700-point corridor cap also widened point spacing far beyond the 90m search radius on very long routes, cutting corners past stops even when the query succeeded. Rework the fetch into independent corridor chunks (~12km each, two in flight, per-chunk timeouts): - Each chunk is a small, fast request; a failed chunk only loses its own stretch instead of the whole route, and failures are logged. - Bus stops stream onto the map as chunks arrive via an onPartialBusStops callback instead of appearing only at the end. - The three bus-stop tag clauses are collapsed into one regex clause (a single corridor pass server-side); exact filtering stays client-side in tagsDescribeBusStop. - Results are deduplicated across chunk seams by OSM element id, and stops mapped twice (platform + stop_position a few meters apart) are merged spatially so markers and dwells aren't doubled. - Corridor spacing now stays within the search radius up to ~285km of route (24 chunks x 160 points) instead of degrading past ~50km. Verified the exact generated query shape against the live Overpass API: HTTP 200 in ~2s, element ids/geometry/lat-lon match the decoder, and the regex clause returns both legacy and public_transport-schema stops. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DNqCsHShA4yNqgZ6ZZQy3
5 tasks
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
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
Bus stops weren't loading (or took too long) on longer routes. The corridor was sent to Overpass as one all-or-nothing query that embedded the coordinate string four times (roads + three separate bus-stop tag clauses). On long routes that regularly exceeded the 25s server timeout, and because the failure was swallowed, every bus stop and speed limit was silently lost. The 700-point corridor cap also widened point spacing past the 90m search radius on very long routes, cutting corners past stops even when the query did succeed.
Changes
onPartialBusStopscallback), instead of only appearing after the whole route finishes processing.highway=bus_stop,public_transport=platform,public_transport=stop_position) into a single regex clause — one corridor pass server-side instead of three, with exact filtering kept client-side intagsDescribeBusStop.Testing
highway=bus_stop) and modern (public_transportschema) stops.Screenshots
N/A — backend data-fetching change, no UI changes.
Generated by Claude Code