Technical overview
Subway Intel publishes live NYC subway intelligence from MTA GTFS-Realtime feeds — arrivals, vehicle positions, service alerts, and derived delay signals — refreshed every 30 seconds.
A FastAPI backend polls every MTA GTFS-Realtime feed (all NYC subway line groups) plus the camsys customer alerts JSON endpoint every 30 seconds. ETags and content hashes skip unchanged feeds to reduce parse cost.
MTA GTFS-RT (protobuf) + alerts JSON → parse_feed / parse_vehicle_positions / parse_alerts → LiveState (in-memory) → WebSocket broadcast + REST API + TimescaleDB writer
| View | Route | Description |
|---|---|---|
| Network Pulse | #/pulse | Per-line NOMINAL / DELAYED / DISRUPTED status, alerts, track diagram |
| My Stations | #/stations | Saved stops with live m:ss countdowns and direction filter |
| Nearby | #/nearby | GPS nearest stations; deep link ?near=STOP_ID |
| Delay Intel | #/intel | Heuristic delay signals from live trip deviation |
| Live Map | #/map | Mapbox GL JS + NYC DOT track GeoJSON + live vehicles |
| Plan | #/plan | Trip planning with one-transfer fallback |
Line health and Delay Intel signals are computed from live arrival headways, schedule deviation, and bunching detection — not from static MTA alert text alone. This surfaces congestion patterns before they appear in official customer alerts.
Users can confirm train presence via a HERE? feedback loop; per-route timing bias is stored and applied to displayed countdowns.
JSON REST + WebSocket on the same origin. No authentication required.
| Endpoint | Description |
|---|---|
GET /api/stations/{stop_id}/arrivals | Live arrivals for a stop |
GET /api/network | Per-line health summary |
GET /api/delay-intel | Heuristic delay signals |
GET /api/commute?origin=&destination= | Trip options with transfer routing |
GET /api/stops/search?q= | Station search |
GET /api/stops/nearest?lat=&lon= | Nearest stations |
WS /ws | Full live-state snapshot every poll cycle |
Full machine-readable index: llms-full.txt