A metropolitan transit operator faces three coupled decisions: which bus lines to operate, at what frequency in each time band, and which stops each line serves. Canonical public-transport OR problem: Public Transit Network Design and Frequency Setting Problem (FSP).
In plain words
Sound familiar?
- We run 50-300 bus lines in a city; each line's route and stops were drawn years ago and not periodically reviewed — adding a line for a new neighborhood eats weeks of the planner's time.
- Each line's frequency (one bus every 8 min in peak, every 20 min off-peak, etc.) is set by the planner's intuition; the link between passenger-demand data and the numerical model is weak.
- Passenger complaints split into two: 'I waited 15 minutes at the morning peak and the bus was full when it came' and 'in the evening empty buses run while we burn taxpayer money' — we cannot optimise both ends numerically.
- At transfer hubs (the major interchange points) passengers wait for simultaneous arrivals; the transfer wait varies 8-20 minutes between two lines; we cannot hold a periodic clock-face schedule.
- Raising line frequency (= more buses) is tied to budget increase; in the annual budget negotiation we cannot present a structured 'if we add this many buses, passenger satisfaction rises by this much' report.
- The city expands and the demand pattern shifts (new business hubs, university campuses, off-transit connections); existing lines do not respond — no numerical method to optimise the line set.
- BRT (express bus) corridor or integration with metro/tram is on the table; in the current bus network we cannot numerically separate which lines are clearly feeders, which are direct services.
Why it matters
How it's solved
Technical depth
How it's solved
Technical depthIn one sentence: Feed the origin-destination passenger flow and the set of candidate lines; let a mathematical model jointly choose which lines to operate and the per-time-band frequency on each (5/8/10/15/20 min) — minimising passenger wait + travel time + operating cost.
In Operations Research (the discipline that uses math and computers to solve business decisions) literature this problem is the Public Transit Network Design and Frequency Setting Problem (FSP). The academic framing treats public-transport planning as a five-step hierarchy: (i) network design (line design — which lines, which routes), (ii) frequency setting (frequency per line per time band), (iii) timetabling (which trip on which minute), (iv) vehicle scheduling (which bus to which trip), (v) driver scheduling (which driver to which bus). #091 covers the first two layers; the remaining three are separate problems. Solution in three stages:
1. Modeling. Input data: (a) demand data — origin-destination matrix (stop-stop passenger flow per time band, from 6-12 months of ticket/smart-card history), (b) network data — road network (segment length, average speed, traffic by time band), candidate stop locations (existing + proposed), candidate line routes (typically 80-300 candidate lines, mostly existing plus a few proposed), (c) fleet data — total bus count, bus type (standard urban bus, articulated, midibus — different capacities and hourly costs), maintenance windows, depot capacity, (d) constraint parameters — passenger max walk distance (300-500 m), max wait time (peak < 8 min, off-peak < 15 min, night < 25 min targets), max travel time (incl. transfer), load-factor cap (85% of bus capacity). Decision variables: which candidate line is operated (0/1), for each operated line frequency per time band (continuous or discrete: 5/8/10/12/15/20 min), buses assigned per line (= frequency × cycle time). Constraints: total fleet budget (sum of line-buses ≤ fleet), every stop covered by at least one line, transfer-hub synchronisation, load-factor cap, passenger max walk, passenger max wait. Objective: multi-objective — minimum passenger wait + travel time (passenger satisfaction) plus weighted minimum operating cost (bus count × hourly cost + fuel + maintenance); the weight is a municipal-policy parameter.
2. Solver-driven decision. Classical two-stage formulation: first line design (set-covering-like), then frequency on each line by marginal analysis. Modern approach: combined MIP (Mixed-Integer Linear Programming — optimisation with some 0/1 variables and some continuous) — line design and frequency optimised jointly. Column-generation approach (start with a small pool of patterns and add useful ones step by step): each candidate line is a column (pattern), the master problem chooses lines and allocates frequency. Wait-time modelling: assuming Poisson passenger arrivals, mean wait = 1/(2×frequency) (analytical formula); for load-factor effects, non-linear correction. Mid scale (50-150 lines, 20-40 time bands) is solved in hours by mature MIP solvers; large scale (300+ lines, 50+ bands) needs column generation or metaheuristics (intelligent search methods — genetic, tabu search, large neighborhood search). Multi-objective via weighted sum or hierarchical (passenger time first, then cost); a Pareto-frontier analysis is presented to the municipal decision board.
3. Field integration. Output in three layers: (a) network design map — operated lines, each line’s route + stop list (operations-centre annual plan, seasonal revision), (b) frequency table — line × time-band frequency matrix (5/8/10/15/20 min), (c) periodic schedule draft — frequency × cycle time → estimated minute-of-departure per trip (next step: timetabling, separate solution). The FSP output feeds the Intelligent Transportation System (ITS) module: real-time passenger counting, bus location (AVL — Automatic Vehicle Location), ticket/smart-card data. Annual or seasonal network revision (summer/winter programme, new-neighbourhood integration), monthly frequency tuning (major holidays, school opening). Quarterly transport committee: actual vs plan wait time, line load-factor percentage, passenger-satisfaction survey, modal-shift report.
Alternatives
Manual plus spreadsheet
FreeZero license
Who it fits: Small municipality (<500K population), 10-40 bus lines, 80-150 bus fleet
- + Zero software cost
- + Planner's local network knowledge counts
- + Annual revision manageable in a small network
- − Above 50 lines the planner is mentally saturated
- − Frequency × line × time-band decision space cannot be optimised by hand
- − Passenger wait time is not numerically measured, only felt
- − Transfer synchronisation cannot be drawn manually
- − Capacity analysis (for investment) is weak
Local public-transit management software
Enterprise400K-2M TRY license + 150K-600K TRY/year maintenance (TR market observation)
Who it fits: Mid municipality (500K-2M population), 40-150 bus lines, 150-400 bus fleet
- + Turkish UI, local support
- + Smart-card + AVL data flows integrated
- + Line-stop-trip database + basic reports ready
- + Close to TR regulation (regulatory annual reporting)
- − FSP optimisation module typically absent — line and frequency decisions still manual
- − Multi-objective (passenger time vs cost) modelling weak
- − Transfer synchronisation limited
- − No integration with academic-style line-frequency optimisation
International transit-planning software
Enterprise1-4M EUR license + 200K-800K EUR/year maintenance (large-municipality market)
Who it fits: Large metropolitan (2M+ population), 150+ bus lines, 400+ bus fleet, integrated BRT/metro
- + Mature FSP optimisation module — MIP, column generation, metaheuristics
- + Multi-modal (bus + metro + tram) network design
- + Periodic clock-face + transfer synchronisation integrated
- + Rich capacity-analysis reports for investment
- − High license + long (18-30 month) deployment
- − Customisation to TR local data formats adds project time
- − Operations-team training is a wide programme
- − Local support usually remote
Open-source solver + custom FSP module
Open SourceLicense free; in-house build 24-48 weeks or 1-2.5M TRY consultancy
Who it fits: Metropolitan with a tech team, when integration with existing ITS is required
- + No license fee
- + Line-design + frequency-setting formulations well defined with open-source solvers
- + Column generation + metaheuristics available in open-source literature
- + Field data (smart card, AVL) integrated directly
- − OR specialist + ITS integration team required in-house
- − Transition from academic prototype to field system takes time
- − Maintenance responsibility stays in-house
- − Multi-modal integration is extra build
Recommendation
Ask in the meeting
- Do you have a network-design (line-set) module, or only frequency setting? When a line is added/removed, does the system re-optimise?
- Is the frequency-setting approach analytical (1/(2×frequency) formula), MIP or metaheuristic? How is the load-factor correction modelled?
- Is multi-objective optimisation (passenger wait vs operating cost) supported? How is the Pareto frontier presented to the municipal decision board?
- Is the transfer-hub synchronisation goal a hard or soft constraint in the model? How is the wait between two transferring lines optimised?
- In what format is passenger-demand data (smart card, OD matrix) ingested? Is the demand data refreshed every 6 months or annually?
- Fleet constraint (total bus count fixed) + maintenance windows + depot capacity — how are these integrated? Is the line × frequency × bus matching automatic?
- During a pilot, can you provide a 12-16 week comparison report (passenger wait time, line loading, operating cost) against the previous manual assignment?
- If the contract ends, in what format can we export the line-design history, frequency tables, demand matrix, loading statistics and schedule archive?
Technical details
Editor’s note
This problem is colloquially called “bus frequency”, “line planning” or “service programme”. In the academic literature it carries two linked but separate layers: Transit Network Design (line design — which lines run, which stops they serve) and Frequency Setting Problem (FSP) (per-line frequency per time band). Together they form the first two stages of the planning hierarchy; the remaining three stages are timetabling (as in #076 for railway periodic schedules), vehicle scheduling (which bus to which trip) and driver scheduling (which driver to which bus).
Problems that look close but are different: #039 School Bus Routing Problem (SBRP) is fixed-schedule student transport — school start times are hard, stop placement + student-to-stop assignment + routing are coupled; two trips per day in two directions; passengers’ identities are known. #076 Train Timetabling Problem (TTP) is railway scheduling — fixed infrastructure (single-track, passing loops), each train is individually scheduled, periodic clock-face coordination. #047 Dial-a-Ride Problem (DARP) is demand-responsive transport — no fixed route, the vehicle path is dynamic on passenger call. #091, by contrast, answers the question “which lines run + at what frequency” on the urban fixed-route bus network — passengers go to a fixed stop on a fixed line, the trips run on a cyclic pattern.
Most-skipped point in practice: the joint numerical trade-off between passenger satisfaction and operating cost. Practitioners adjust frequency one-variable-at-a-time by intuition (“this line is crowded, raise its frequency”); the academic approach pulls passenger wait time (analytical 1/(2×frequency), with non-linear correction for load factor) and transfer time into a numerical model and jointly optimises with operating cost (bus count × hourly cost + fuel + maintenance). With a Pareto frontier you can present the municipal decision board numerical choices such as “if the budget rises by 10%, passenger wait drops by 25%” — intuitive raise/lower decisions cannot build this frame.
Second skipped point: transfer-hub synchronisation. If two lines meet at the same interchange, with the arrival minute of one and the departure minute of the other planned 2-4 minutes apart, transfer time is minimised; without that, a 10-20 minute wait breaks passenger satisfaction. This requirement is handled with a periodic clock-face schedule (next step: timetabling, a separate solution). The FSP output should pull frequencies into a common period family (e.g. layered 6-12-24 minute frequencies); if not encoded, the synchronisation collapses in the field.
Step-by-step roadmap — for the SMB
Stage 1 — Measure before you plan. At least 12 months of passenger data: smart-card boardings/alightings (OD matrix where derivable), line × stop × time-band passenger counts, line load-factor percentages, actual vs plan wait time (stop survey + AVL data). Fleet inventory: bus count, bus type (capacity + hourly cost), maintenance schedule, depot-rotation plan. Network inventory: existing lines (routes + stops), stop locations, road-segment traffic by time band.
Stage 2 — Extract the knowledge capital. Demand pattern per time band (morning peak 07:00-09:00, mid-day, afternoon peak 17:00-19:00, evening, night). Passenger profile: work/school/shopping split. Line load-factor curve: which line is overcrowded at which hour (frequency too low), which is empty (frequency too high). Candidate new-line set (new neighbourhoods, business centres, university campuses). Interchange hubs and current transfer times.
Stage 3 — Pilot. 12-16 weeks. For a subset (e.g. 15-20 of the 80 existing lines, peak-focused) run the FSP MIP allocation in parallel with the current manual frequency. The decision stays with the transport committee; FSP gives a proposal. Success criteria set upfront: mean passenger wait −15% minimum, line load-factor standard deviation −20% (balance), operating cost flat or −5%.
Stage 4 — Roll-out. 18-30 months to full network + timetabling + vehicle scheduling + ITS integration. Annual network revision (summer/winter programme, new-neighbourhood integration). Quarterly transport committee: passenger-wait report, line load-factor update, passenger-satisfaction survey, modal-shift analysis.
Risks — what can go wrong
- Demand-forecast drift (demographic shift). The OD matrix is built from 6-12 months of history; new business centres, university campuses, residential areas and retail clustering rapidly change the demand pattern. Without 6-12 month recalibration the FSP output drifts from field reality. Monthly monitoring from smart-card data + annual full re-optimisation are mandatory.
- Budget cut (fleet shrinks). Municipal budgets are under cyclical pressure; a mid-year “30 buses pulled from the fleet” collapses the FSP assumption. A robust FSP variant (fleet ±15% scenarios) or a budget-conditional Pareto-frontier analysis should be presented to the decision board.
- Traffic-congestion travel-time growth. Line cycle time depends on traffic; the same frequency at peak requires more buses. If traffic data (road-segment speed by time band) is not fed into the model, the frequency plan does not materialise (not enough buses). Traffic measurements must be recalibrated every 6 months.
- Single-supplier ITS lock-in. If the ITS contract omits “annual standard-format export of smart-card data, AVL history, passenger-count statistics, line-trip archive”, leaving the system means losing operational memory. The FSP module and the ITS must remain decoupled (standard API).
Technical view of the solution methods
| Approach | Typical scale | Solve time | Guaranteed optimum? |
|---|---|---|---|
| Heuristic frequency (planner + rule) | Small network, <40 lines | instant | No, 50-70% optimum |
| Ceder-Wilson two-stage (line → frequency) | Mid network, 40-100 lines | minutes-hours | Yes (each stage locally) |
| Combined FSP MIP | Mid-large network, 50-150 lines | hours | Yes (within bound) |
| Column generation (Borndörfer et al.) | Large network, 150-300 lines | many hours | Good lower/upper bound |
| Metaheuristic (genetic, tabu, LNS) | Very large + multi-modal | hours-continuous | No, good practical quality |
Objective function choice:
- Objective 1 — Min passenger wait + travel time: Passenger-satisfaction focus. Wait = 1/(2×frequency) analytical; travel = cycle time + transfer time.
- Objective 2 — Min operating cost: Bus × hourly cost + fuel + maintenance. Budget focus.
- Objective 3 — Max ridership (modal shift): Pull into transit; gain from private car.
- Objective 4 — Balanced load factor (bus loading): Simultaneously balance overcrowded and empty lines; efficiency focus.
Multi-objective: weighted sum (passenger time weighted high, cost secondary) or hierarchical (budget constraint first, then passenger time) or Pareto-frontier analysis (numerical choice presented to the decision board).
Academic sources
Listed in the sources field of the page frontmatter.
Sources
- Ceder, A. and Wilson, N. H. M. (1986). Bus network design. Transportation Research Part B: Methodological, 20(4), 331-344. Foundational reference for transit line design.
- Ceder, A. (2007). Public Transit Planning and Operation: Theory, Modelling and Practice. Elsevier. Canonical textbook; planning hierarchy and frequency models.
- Ibarra-Rojas, O. J., Delgado, F., Giesen, R. and Munoz, J. C. (2015). Planning, operation, and control of bus transport systems: A literature review. Transportation Research Part B: Methodological, 77, 38-75. Modern comprehensive survey.
- Schöbel, A. (2012). Line planning in public transportation: models and methods. OR Spectrum, 34(3), 491-510. Line planning literature survey.
- Borndörfer, R., Grötschel, M. and Pfetsch, M. E. (2007). A column-generation approach to line planning in public transport. Transportation Science, 41(1), 123-132. Column-generation approach.
- YÖK Council of Higher Education Thesis Center — keyword: ’toplu taşıma’, ‘otobüs hat’ or ’transit ağ’ — 20+ theses from TR academia. tez.yok.gov.tr
Glossary
- Transit Network Design
- OR problem of choosing which bus (or tram, metro) lines to operate in an urban network, which stops each line serves and what route each line follows, subject to total operating budget, demand-coverage and transfer-quality constraints.
- Frequency Setting
- Operational sub-problem of determining how often each transit line is served (e.g., one bus every 6, 10, 20 minutes) per time band, based on demand profile, available fleet and target service quality.
- MIP
- An optimization model where some decision variables are forced to be whole numbers (e.g. number of trucks, number of shifts).
- School Bus Routing
- VRP (Vehicle Routing Problem) variant in which buses pick up and drop off students assigned to stops, subject to bus capacity, maximum ride time, bell-time coordination and walk-distance equity.