We read the information NFTA already produces, work out the next departures for every location, and serve a plain web page any screen can show. This page is the whole system, end to end.
Technology: Python & FastAPI · PostgreSQL · Redis · runs in a container on Railway. The same kinds of tools NFTA's own team already works with, so it's straightforward to support long-term. Curious how the data is organized underneath? Explore the data model →
Screens keep showing the last good information with a small "as of" note. Riders never see a blank board or an error.
No single piece holds anything irreplaceable. Settings and schedules live safely in the database, and the live picture rebuilds itself within about 30 seconds.
The team is alerted right away and can fix it before anyone notices. The screens just keep counting down from the last good data.
Big stations have more than one screen. University has three, one for each set of boarding bays, and each shows only the departures for the bays it faces. Same system everywhere; each screen simply carries its own short list of stops. Try them:
And the same idea covers every other split: the MTC interior signs each show specific routes, and Allen's track-level sign shows one direction only. NFTA staff can change any screen's view at any time, without touching the screen itself.
Everything the platform knows lives in a few well-defined places. The first three run the screens today; the next three are already designed in, ready for Phase 2. Click any to peek inside.
Each display location is defined once: where it is and what it shows. The physical screens then point at a location, and several can share the same one.
That's what makes "100 screens, fewer locations" simple: define a location once, add as many screens as you like.
Which routes appear on each screen, and in what order. Filled in automatically from NFTA's data; nobody hand-picks routes. It can be fine-tuned later (hide one, reorder) if a location ever needs it.
NFTA's full bus and rail schedules, loaded, versioned and kept current, with the live bus information layered on top. This is the source every departure is worked out from.
Service messages to show on screens: a detour, an elevator outage, a weather note. The structure is in place now; the tools to post them come with the admin console in Phase 2.
Who is allowed to manage which screens. Set up so each department (bus, rail, and beyond) can run its own screens without affecting others.
A screen can hold more than departures. The structure already allows messages, weather and other content to be added as separate blocks, with no rebuild.