A route line is only as useful as the identity attached to it. R102 is a route family, but the map does not draw one undirected R102 line. The catalog stores R102:AM and R102:PM as separate directional services, each with its own ordered stop sequence.
That distinction is visible in the data. R102:AM runs from Toril District Hall through Matina Crossing to GE Torres (Sandawa) with 17 catalogued stops. R102:PM starts at Ecoland Terminal, passes through GE Torres (Sandawa), and ends at Toril District Hall with 16 stops. The two sequences are not simple reversals. Treating them as one line would lose the service identity that the planner, route detail, and map need to preserve.
The catalog is the source of route identity and stop order. The upstream bus stop records are the closest thing this repository has to official stop authority: they provide the named locations and coordinates that the catalog refers to. That is an authority rule for compilation, not operator sign-off. The current metadata says the reviewer is not assigned. The canonical bus geometry is a separate artifact generated from those ordered stops and an OSRM-compatible router. The map consumes the result; it does not infer a new route from pixels or from proximity between lines.
From catalog to rendered line
The current checked-in snapshot contains 9 route families, 18 directional route references, 85 normalized bus stops, and 18 canonical geometry features. The generated bus bundle identifies itself as 2026-08-28.958321 and carries SHA-256 fcbb0834e24523865011a2d97f33901a82011f3a2ffa228b543c78d3dfd149b5. These are artifact details for this checkout, not a promise that the operator's service has not changed.
The important boundary is between topology and geometry. The topology says which stop comes after which for R102:AM. The geometry says how to draw that service along a road network. The bundle keeps the validated result available to the application, while the tile release is an optional delivery format for map rendering at different zoom levels.
The route feature itself carries routeRef, routeId, direction, and source. Names and colors are joined from the catalog when the web map builds its features. This keeps the visual label from becoming a second route identity. A tile can change format without changing what service the line represents.
What happens when tiles are unavailable
The web application does not use an ordered stop sequence as though it were road geometry. If canonical geometry is missing, it can construct a line through the ordered stop coordinates and marks that result as approximate-fallback. The source code states the limit directly: ordered stops preserve topology, not road geometry.
The route-source decision is deliberately small:
export function planBusRouteSource(input: { manifest: BusRouteTileManifest | undefined manifestFailed: boolean hasBundle: boolean}): BusRouteSourcePlan { if (input.manifest) return { kind: "tiles", manifest: input.manifest } if (input.manifestFailed && input.hasBundle) return { kind: "bundle" } return { kind: "pending" }}That last state matters. A missing manifest during the first request is not the same as a confirmed tile failure. The map waits until it knows whether the tile source is available. Once the request has failed and a bundle exists, the map can remain useful while exposing a less precise geometry source to the rest of the rendering pipeline.
For an inspectable map artifact, open the current canonical bus GeoJSON. It contains the 18 road-routed directional features used by the bundle build. There is no checked-in before/after screenshot for this page, so the GeoJSON is the evidence rather than an invented image.
The data handoff is described in static transit bundles. The geometry decision is reconstructed in bus geometry reconstruction, and the delivery failure path is covered in vector tiles.
Sources: route-catalog.json, bus-route-data.ts, and bus-route-source.ts.