Rider information your own staff can run.
Feeds, displays, alerts, and overrides are administered in web forms — by the people who manage service, on the day they need to change something.
Administration
Nothing here requires a developer or a deploy. If you can fill out a form, you can operate the platform.
Add a feed
Paste the URL of the GTFS zip you already publish and import. When the next service change lands, re-import — nothing your staff wrote by hand is lost.
Create a display
Pick a stop or route, pick a skin, and put the resulting URL on any screen with a browser. Shelter, station, or operations wall — same form.
Post an override
“Board across the street this weekend” is typed into a form, scheduled by time window, and disappears when it expires. Reroutes and stop closures work the same way.
Watch the fleet
Every screen phones home. The dashboard shows what's dark before riders do, with per-display permissions deciding who sees and edits what.
From a single stop to the whole network
One platform covers the shelter screen, the station pylon, the transit-center board, the live map on your website, and the timetable page — all fed by the same GTFS. Several feeds can run side by side, so regional and multi-operator setups are one site, not many.
- Displays for stops, routes, stations, and the systemwide view
- Live maps embedded in the website you already have
- Timetables by route, direction, and service day
- A public JSON API for the app developers who ask for one
Flexibility
- Skins for the hardware you own — LCD, e‑ink, pylons, portrait or landscape; custom skins when the catalog doesn't fit
- Overrides for the real world — closures, reroutes, and temporary stops, scheduled ahead of time
- Every language your riders speak — imported data is translatable content
- Your infrastructure or ours — self-host the open-source suite, or have us run it
Put your feed to work.
Bring the GTFS you already publish. Your staff runs the information; the servers are whoever's problem you want them to be — yours or ours.