An ordered stop sequence gives the bus planner topology, but it does not give the line a road shape. If the map connects each stop coordinate directly to the next one, the resulting segment cuts across whatever lies between the stops. That line may preserve the order while suggesting a street the bus never uses.
The repository does not contain a checked-in screenshot of the old overlay. The old shape can still be stated precisely: the stop-only fallback in the web map creates a LineString from ordered stop coordinates and labels it approximate-fallback. That is the chord-like representation. It is useful as a last-resort topology display, but it is not evidence of the road path.
Build-time routing experiment
The build-time experiment routed every directional bus service through its ordered stops using an OSRM-compatible service. Git records the geometry integration in d126d5f, dated 2026-08-18. The generator reads the raw stops and route catalog, transforms them into ordered waypoints, requests a full GeoJSON route, validates the result, and writes bus-routes.geojson.
The important change is where the expensive and uncertain work happens. The router is called during data preparation, where a failed request can stop the build and a malformed line can be rejected. The browser receives a checked-in geometry artifact rather than calling a routing service for every map view.
This is the core of generate-bus-route-geometry.ts:
const stopIds = topology.routeStops[routeRef] ?? [];const waypoints: [number, number][] = [];for (const stopId of stopIds) { const stop = stopsById.get(stopId); if (!stop) throw new Error(`${routeRef}: missing stop ${stopId}`); waypoints.push([stop.lng, stop.lat]);}if (waypoints.length < 2) { throw new Error(`${routeRef}: requires at least two ordered stops for road routing`);}const coordinates = await routeThroughWaypoints(routerBaseUrl, waypoints);The current output has 18 directional features, each marked source: "road-routed". That label describes how the geometry was produced. It does not claim that the routing service knows the operator's actual turn-by-turn path.
What validation can and cannot prove
The geometry validator checks route identity against the catalog, requires at least two ordered stops, rejects lines shorter than 100 metres, keeps the line within an expanded stop bounding box, requires every ordered stop to be within 250 metres of the line, and rejects sequence backtracking beyond 500 metres. The projection helper also gives the tracker a way to measure how far a coordinate lies from the line and how far along the line it projects.
Those checks catch a route that misses its input anchors or folds back on itself. They do not prove that a bus actually uses every road segment returned by OSRM. Road routing is evidence used to construct a consistent display geometry; the catalog and its directional stop sequence remain the transit identity.
The current fallback makes the distinction visible in code:
// This is intentionally approximate. Ordered stops preserve topology, not road geometry.const fallbackCoordinates = resolveStopCoords( transit, getRouteStopIds(transit, routeId, direction),)The fallback is not a hidden second geometry algorithm. It is an explicit degradation path for a missing canonical feature. The map can show where the service's ordered stops are, but the UI and documentation should not describe that line as road-following.
For the current artifact, inspect bus-routes.geojson. For the later tile pipeline, see the ff33b42 tile commit and bus route vector tiles.