Transit Network Optimizer
Turn a real GTFS bus feed into an operating plan — minimum fleet, driver duties, and a weekly roster — solved live in your browser on real MARTA data, or upload your own agency's feed.
Understand exactly what you're looking at
The theory, how the data is acquired and cleaned, how to read the result — and what BIS would do for you next.
A bus network is a stack of decisions, each feeding the next. First: how few buses cover every scheduled trip? Chain a trip onto a bus only if the bus can finish the first, drive empty to the second’s start (“deadhead”) and still make it on time. Order the trips by time and that “can-follow” relation is a DAG — and the minimum number of buses is exactly the number of trips minus a maximum matching on it (Dilworth’s theorem / minimum path cover). We solve it exactly with Hopcroft–Karp — the fleet number on this page is provably optimal, not a guess.
Then the crew problems: cut each bus’s day into legal driver duties (max continuous driving, breaks, spread), and assign duties across the week to a balanced driver roster under rest and hour rules. Those two are NP-hard set-partitioning problems; here they run as clear, legal-by-construction heuristics.
The default network is real: MARTA, Atlanta’s transit agency, published as GTFS — the General Transit Feed Specification, the same format Google Maps, Transit, and every planning tool consume. It is the market standard, so this demo speaks the language your agency already exports.
MARTA’s full feed is ~145 MB (a single day of stop times alone is over 100 MB). We bound it to the five busiest bus routes on a typical weekday, a daytime service window, and 150 trips — enough to be real and legible, small enough to re-solve on every slider move. Upload your own GTFS .zip and it runs the same pipeline on your network, parsed entirely on your device.
Everything happens in the browser under a strict content-security policy — no server, no upload. The .zip is opened with a tiny pure-JS unzip, the CSV tables parsed by hand (GTFS stop names hide commas inside quotes; times run past 24:00 for after-midnight trips — both handled).
- Each trip’s start/end stop and time are derived from
stop_times.txt(min and max stop sequence), streamed row-by-row so a 100 MB file never blocks the page. - Deadhead is a transparent estimate — straight-line distance × a road factor at non-revenue speed, plus your layover buffer. A production build swaps in a real road matrix; the method is identical.
- Bounding is honest and stated on screen: which routes, which day, how many trips, and that BIS runs the whole network unbounded.
Toggle Baseline vs Optimized. Baseline is the naive plan — a fresh bus whenever one is free. Optimized is the exact minimum fleet; the gap is buses (and their fixed cost) removed without dropping a single trip.
The Gantt is each bus’s day: colored bars are revenue trips, thin links are deadhead, brackets are driver duties. The roster board tiles those duties across the week onto a balanced driver pool. Watch the KPIs move as you tighten the rules — deadhead and overtime are shown honestly, because that is where the real trade-offs live.
This is the exact shape of work Renan has shipped: leading Optibus’s reporting and exports for public-transit operators across three continents, a Progress Rail routing engine that cut vehicle needs ~20% across 40k+ locations, and column-generation crew scheduling with CPLEX at UniSoma — the production form of the run-cutting you see here.
BIS builds this for your agency, unbounded and exact: minimum fleet, optimal run-cutting and rostering as real set-partitioning models, wired to your GTFS and your work rules — fewer buses, legal duties, balanced crews, and the cost line to prove it.
This preview runs on real public data. Yours would run on your data.
We start with a conversation, prove the value on a focused POC with your real data, then ship it — in our environment or deployed into yours.