Passenger Flow Forecasting: Where the Schedule Breaks
Passenger flow forecasts almost always diverge from actual boardings, and the issue is not model quality but the data it learns on.
Average demand on a route calculated over a month smooths peak load so much that during the morning rush hour the calculation is a quarter below actual boardings.
This then turns into two extremes: either transport leaves half-empty during off-peak, or people are left at the stop.
Uneven demand by day breaks averaging most severely. Monday and Friday behave like different routes: staggered school shifts, shifted work schedules, seasonal decline during vacations, one-off events such as a stadium or fair.
The same hour on different days produces discrepancies by multiples, and a model trained on a weekly average simply does not see this difference.
The second reason is incomplete trip data. Validators lose some records during peak hours, some cards remain unidentified, entries and exits are not always paired, and on routes with payment to the driver, data simply does not reach the storage.
If boardings are counted from such records, the real flow is systematically understated — and the forecast confidently reproduces this error.
The third is manual schedule edits. The dispatcher adjusts the schedule to yesterday's disruption: removes a trip, stretches the interval, moves a departure.
Edits live in a separate file, do not return to the calculation, and in the next cycle the system again calculates from the original plan rather than from what was actually performed.
A loop arises: the model learns on distorted data, the forecast drifts further from fact, and edits increase.
We examine how this is resolved.
Model Effect: Fewer Empty Trips and Schedule Disruptions
The model forecasts boardings for each hour of the day separately by route, direction, and stop — the grid is uneven, just like real demand.
The schedule and rolling stock deployment are planned from the forecast, not from average values for the previous period, which smooth both the morning peak and the gap between trips.
Hourly Calculation Accuracy
Forecasts at hourly intervals are compared with actual data from validators and sensors, so the discrepancy is visible for each trip, not only by day.
On stable weekdays, deviation remains within 8–12%, and during peak hours it is lower than that of a model trained on daily aggregates. This makes it possible to trust the forecast when rearranging departures.
Vehicle Deployment to Match Demand
The number of vehicles on a route is tied to expected load: where the forecast shows growth, trips are added and a shorter interval is used; where there is a decline, excess vehicles are removed. Route network load evens out, and overcrowding on individual directions stops being constant.
Reduction of Empty Trips
Trips where boardings do not justify deployment are monitored separately. Their share in total volume drops noticeably: some trips are shifted in time, some are reduced, and some are switched to lower capacity. This is the fastest effect from the model.
Planning Maintenance and Reserves
A forecast several weeks ahead provides decline windows where scheduled maintenance can be placed without harming passengers.
For peak days, vehicles and drivers are reserved in advance, and schedule data is consolidated with the carrier's GTFS feeds so that the forecast is calculated against the current network.
Passenger Flow Forecasting Formats: Batch, Streaming, Hybrid
The calculation mode is chosen not by "model power" but by the calculation horizon and model update frequency.
Batch recalculation runs the model entirely on a schedule; the streaming real-time model updates the estimate for each event; the hybrid calculation scheme combines both loops: the baseline curve is calculated in batch, and online correction catches deviations within a shift.
Before implementation, we fix two parameters: how far ahead the forecast is needed and how quickly it must update.
For planning rolling stock deployment for a day, a nightly recalculation based on accumulated data is enough; for managing boarding on the platform, a reaction within minutes is needed, otherwise the forecast loses meaning by the time a decision is made.
| Option | When It Fits | Limitations |
|---|---|---|
| Batch recalculation | Stable data flow from validators and turnstiles, forecast for a shift, day, week | Delay between event and recalculation; sharp disruptions — section closure, trip cancellations — enter the forecast late |
| Streaming real-time model | Reaction is needed within a shift: crowds, delays, one-off peaks | Sensitive to gaps in the data stream: sensor failure or packet loss distorts the estimate; input quality control is required |
| Hybrid calculation scheme | Mixed tasks — forward scheduling and operational adjustment on the same data | Harder to configure: aligning the calculation horizon across loops, model versioning discipline, and edit logging |
The hybrid scheme covers most route networks, but requires verifying both loops against unified error metrics: if the baseline curve and online correction diverge, the forecast becomes contradictory.
Limitations are removed not by changing the option but by controlling input data and a clear model retraining procedure — we will discuss which scheme fits your fleet.
Implementation: From Data Audit to Model Handover to Operations
Passenger flow forecasting breaks not on the model but on the data. Ticket transactions, onboard validators, vehicle tracks, and schedule files live in different systems, diverge by time and route keys, and some trips are not recorded at all.
Until this is consolidated into a single picture, any output figure looks plausible but is not verifiable.
- Trip Data Audit. We analyze sources for past periods: completeness by day, duplicates, gaps during communication outages, time zone shifts, anomalies of holidays and repairs. The output is a list of suitable features and a list of gaps that are closed before training.
- Data Flow Scheme. We fix where transactions and telemetry come from and at what frequency, where they are cleaned and aggregated, and how history is stored. The scheme marks failure points and the owner of each source.
- Model Setup for the Route. We account for headway, day type, seasonality, school holidays, weather, and city events. Setup is done by direction, not with one averaged curve for the entire network.
- Validation on Historical Periods. We separate training and control by time, otherwise the future gives away the answer. We look at error over a day and week horizon — separately during peak hours and during schedule disruptions.
- Model Handover to Operations. We deploy the calculation in the customer's environment, tie it to the update procedure, and enable alerts for accuracy drops and input data drift.
- Support Procedure. We hand over to the customer's team the retraining procedure after route network changes and the analysis of forecast-to-fact discrepancies.
This is how the forecast stops being an experiment and becomes a service that the customer's team runs itself.
What the Customer Retains: Configurations, Schemes, Procedures
The passenger flow forecasting model remains in your environment, and with it — a set of materials by which it can be supported, developed, and handed over to new engineers without our involvement.
The set is designed for two audiences: the IT service and analysts who work with data and infrastructure, and dispatchers who see the result in the interface.
- Model Documentation — which features participate in the calculation, how the forecast horizon is set, what each output metric means, and by what data the model is considered fit for operation.
- Update Procedure — retraining frequency, accuracy validation on a holdout period, conditions for rollback to the previous version if forecast quality has declined.
- Integration Schemes with Accounting Systems — where trip and validation data comes from, in what form the forecast is returned to the dispatch system and passenger information channels.
- Data Access Rules — roles and permission separation, export procedures, a separate de-identified environment for test runs and investigations.
- Dispatcher Instructions — how to read the forecast and its interval, what to do when fact diverges from the calculation, how to record an incident, and where to pass it.
- Version and Run Log — what was changed, on what period it was validated, what result was obtained, and what justifies the choice of the working version.
- Acceptance and Scheduled Work Checklist — quality control points, trigger thresholds, and the update procedure without stopping the service.
Case Study: How Accuracy Increased and Empty Trips Decreased
Project — for a city bus operator: several dozen routes, dispatchers assembled the daily schedule manually using average values for the previous month.
At turnarounds, during school holidays, and on city event days, the calculation diverged from actual boardings especially strongly.
What the Pre-Implementation Measurement Showed
On peak routes, divergence from fact reached 20-25%: in the morning, excess vehicles were deployed in residential areas, while transfer hubs lacked capacity.
The share of canceled trips remained around 6%, and schedule preparation took five working days — weather and event edits no longer made it in.
We assembled a unified data pipeline: validators, tracks, calendar, weather, city events.
The forecast is calculated by an ensemble of models at hourly and daily intervals, separately for weekdays, weekends, and school holidays, and we validate the quality of each version on a holdout period and reference weeks from past seasons.
Divergence on control routes decreased to 7-9%, cancellations to 2%, empty trips during off-peak hours fell almost threefold. The schedule is assembled in 3-4 hours and recalculated when weather changes or sections close.
Together with the customer, we handed over the models, pipeline, and recalculation rules to operations: we set up accuracy monitoring for each route and alerts for data drift, a retraining procedure, and dispatcher training. Next — monthly metric review and quarterly data completeness checks.
What to Do If Validator-Based Recording Is Already Handled In-House
If validator-based trip recording is already working, it does not need to be redone. The forecast is built on top of your data: the system reads the same events as the ticketing system and does not interfere with transactions.
It is enough to agree on the export format and frequency — once a day or more often, depending on the required forecast horizon.
The first step is importing historical data. A series of at least six months is needed so the algorithm can see seasonality: weekdays and weekends, school holidays, repairs, and road closures.
We take records as they are, together with gaps and equipment failures — we mark anomalies and keep them; they are useful as a signal about fleet condition.
Next is reconciliation of route directories. Route, stop, and trip codes differ for each carrier, and without alignment to a common directory, the forecast will not match reality.
We match by stable identifiers, and discrepancies — duplicates, renamings, seasonal schemes — are placed in a report and reviewed with your system administrator.
We expand coverage gradually: first one fleet or route network with the cleanest data, validation of the forecast against fact on a closed period, then the next section.
Your recording system continues to work as it did: integration with existing validators is read-only, and the passenger flow forecasting layer is added on top.
We need read access to exports, the system administrator's contact, and a description of directories from you — we handle the rest ourselves.
Concerns About Data, Accuracy, and Model Support
Incomplete boarding data is a working norm, not a failure: some validators do not send records, and door counters lose intervals.
Completeness and connectivity checks are in place at the input; we close gaps with estimates from neighboring stops and trips of the same profile, not with zero; if recovery is unreliable, the forecast comes with an interval and a low-confidence note.
Holidays, mass events, and disruptions are put into a separate feature calendar: day type, weather, closures, historical anomalies. On a holiday, the model behaves differently than on an ordinary Saturday, and a seasonal schedule change updates the route directory.
Routes change by season — will the model have to be retrained from scratch?
No. The route profile is stored separately from model weights: a change of alignment or seasonal schedule updates the directory, and the forecast is built for the new stops without full retraining.
Retraining is triggered by procedure — according to the seasonality calendar or when accuracy shifts noticeably.
Who supports the model after launch?
Monitoring compares the forecast with fact for each route, and a notification arrives upon systematic divergence. We hand over the update procedure and data documentation — your team can support the model itself, or we can take on support.
How explainable are the recommendations?
The forecast is accompanied by the contribution of factors: how much came from the day of the week, how much from weather, how much from stop history. The logic is checked before release to the line, rather than trusting a black box.
Let's Discuss the Task: We Will Select a Calculation Mode for Your Fleet
We start by analyzing current data: what passenger flow archives have already been accumulated, at what frequency they are captured, and whether there is linkage to routes, stops, and the event calendar.
This determines the selection of the calculation mode — short-term forecasting for a shift and medium-term forecasting for a week are built on different feature sets and are retrained differently when the route network changes.
What we clarify at the start and in what form we will return:
- sources of data and their suitability — turnstiles, validators, deployment data, external calendars;
- forecast horizon and step — how many hours or days ahead the result is needed;
- list of routes and hubs where forecast error is critical for the schedule;
- requirements for model updates during seasonal shifts and introduction of new stops;
- usage scenarios — deployment planning, interval adjustment, passenger notifications;
- infrastructure constraints and access mode to your systems;
- acceptance criteria — on what share of control periods the forecast must fall within the allowable deviation.
Based on the analysis, we send a staged implementation plan with an estimate of the scope of work: what we do on historical data, how we validate quality on holdout periods, how we bring the forecast into your environment, and who is responsible for support after launch.
Describe the calculation task — route network, available data, and forecast horizon. We will return with an estimate and implementation plan.
