Data Flow

Startup Sequence

config.yaml Load Config → Check Cache Cache valid? YES Load cache sub-second NO Parse GTFS Build RAPTOR 10-30 seconds Load BAN data addresses Start Actix-web Serve API + SPA

GTFS Data Model

Glove loads the following GTFS files:

FileContentRust Struct
agency.txtTransit agenciesAgency
routes.txtTransit routes (lines)Route
stops.txtStop locationsStop
trips.txtIndividual tripsTrip
stop_times.txtArrival/departure at each stopStopTime
calendar.txtWeekly service schedulesCalendar
calendar_dates.txtService exceptionsCalendarDate
transfers.txtTransfer connections between stopsTransfer

Query Flow

Public Transit Journey

Client Request Parse query parameters from, to, datetime Find nearest stops origin and destination Run RAPTOR Collect Pareto-optimal journeys Enough? NO exclude patterns YES Reconstruct journeys Tag · Format Navitia response JSON Response

Walk / Bike / Car Journey

Client Request Build Valhalla request costing model + options Call Valhalla /route HTTP on localhost:8002 Decode polyline · Extract maneuvers Elevation colors (bike) · Format Navitia response JSON Response

Hot Reload

The hot reload mechanism allows updating GTFS data without downtime:

  1. POST /api/gtfs/reload is called (requires api_key)
  2. A background thread loads new GTFS data and builds a fresh RAPTOR index
  3. The new index is swapped in atomically via ArcSwap
  4. All in-flight requests continue using the old index until they complete
  5. The old index is dropped when the last reference is released

Transfer Enrichment

When maneuvers=true is requested, transfer sections in public transport journeys are enriched with Valhalla walking routes. The enrichment logic depends on the transfer type:

  • Outdoor transfers (stops with different parent_station): Valhalla is always called to obtain the actual walking route shape, which is displayed on the map as a polyline.
  • Indoor transfers (stops sharing the same parent_station): Valhalla is only called when indoor maneuvers (elevator, stairs, escalator) exist in OSM data for that station.
  • Polyline rendering: transfer sections use the Valhalla shape (actual walking route) when available; otherwise a straight line is drawn between the two stops.

Transfer enrichment calls are batched in parallel using futures::join_all for performance. When maneuvers is not requested (the default), transfer Valhalla enrichment is skipped entirely