A usable passenger volume forecast for a transportation hub relies on three elements: consistent historical count data spanning several months, variables that explain fluctuations, and a forecasting horizon aligned with the time needed to take action. Without the third element, the forecast remains merely an analytical exercise with no impact on operations.
The difference from real-time monitoring is clear. Monitoring allows for a response to congestion that has already occurred. Forecasting allows resources to be deployed before congestion forms: opening an additional checkpoint, rescheduling a break, enhancing passenger information, or adjusting staffing levels at a station. The shift from one to the other requires historical data, not a more powerful algorithm.
Real-time measurement answers the question “what is happening now”: density by zone, line length, estimated wait time. It feeds into monitoring and alert thresholds. Forecasting answers “what will happen in thirty minutes, two hours, or tomorrow morning.” It informs capacity planning decisions.
These two uses do not rely on the same data or the same stakeholders. Measurement is of interest to the command center; forecasting is of interest to planning and operations management. Confusing the two leads to dashboards that no one uses.
A forecast draws on past data. For a transportation hub, this means having passenger counts by zone and time slot over a period that covers the various seasonal patterns of activity: weekdays and weekends, school breaks and regular periods, and peak and off-peak seasons if the activity is seasonal.
Two requirements take precedence over the time frame. First, consistency: if a camera’s field of view has changed, if a zone has been redrawn, or if a counting method has been replaced, the data series is broken as of that date and should not be used as is. Second, completeness: missing data during peak hours—often due to outages or construction—skew the model training.
In practice, the first task in a forecasting project is to audit the available historical data and document any breaks in the data. This often takes longer than the modeling itself.
At a transportation hub, ridership is not an isolated phenomenon: it stems from transportation service offerings. The most useful variables are therefore those related to the operating schedule—theoretical departure and arrival times, vehicle capacity, assigned platforms and doors—as well as the discrepancies between theoretical and actual data, delays, and service cancellations.
Added to these are calendar-related variables—day of the week, the day before and after a holiday, school breaks—and contextual variables—weather, major nearby events, construction work altering routes, and incidents on the upstream network.
Not all of these are available at the same time. A variable known only after the fact is unusable for forecasting. It is therefore necessary to distinguish between those known in advance—such as the theoretical schedule—and those that become available only in real time, such as a delay.
The horizon is determined by the timeframe of the decision it is intended to inform. Opening an additional control line requires mobilizing available staff: the useful horizon is measured in tens of minutes. Decisions to adjust a team schedule are made the day before or the previous week, so the horizon is measured in days.
Producing a forecast with a time horizon that no one can use is pointless, even if it is accurate. Conversely, a less precise forecast that is available early enough to take action has real operational value. This point should be discussed with the operations teams before choosing a method.
Three criteria are sufficient to start with. The average error per time slot, expressed in the unit of measurement—number of people or minutes of wait time—rather than as an abstract percentage. Performance during peak periods, because a forecast that is generally accurate but consistently misses the peaks is of no help. Comparison to a simple benchmark, such as the value for the same time slot the previous week: if the sophisticated method does not perform better than this benchmark, it is not justified.
The evaluation is conducted over a period that the model has not seen, and using actual operational time slots, not a daily average that smooths everything out.
A forecast only becomes useful when combined with three explicit elements. A threshold, beyond which the forecasted situation is considered a cause for concern, defined by zone and expressed in a unit understood by the teams. A procedure specifying what actions are taken when the threshold is exceeded. A decision-maker who receives the information and makes the decision.
Without these three elements, the forecast simply appears on a screen and has no effect. Defining them is an operational task, not a data analysis task, and it is carried out with the teams involved.
A model trained on historical data reproduces what it has seen. An unprecedented situation—such as a major incident, an exceptional event, or a prolonged service outage—falls outside its scope of validity. Two precautions are essential: clearly indicate when a forecast deviates from normal conditions, and maintain a fallback procedure that does not depend on the forecast.
It is also helpful to plan for incorporating these episodes into the historical data once they have passed, by labeling them, so that the model can take them into account in the future without confusing them with ordinary situations.
The measurements used consist of counts and densities by zone, aggregated, without individual tracking or biometric processing. Facial recognition constitutes biometric data within the meaning of Article 9 of the GDPR and is not used in this type of system.
In areas open to the public, the underlying video surveillance system is governed by the Internal Security Code, requiring prefectural authorization, public notification, and image retention limited to one month. A data protection impact assessment is required whenever surveillance is systematic and large-scale in a publicly accessible area. When employees are filmed, the requirements for informing and consulting with employee representatives, as provided for in the Labor Code, apply.
CORE, XXII’s platform, uses footage from existing cameras to generate aggregated metrics by zone—such as counts, densities, and travel times—without facial recognition. These metrics serve as the raw data for forecasting: they provide the consistent historical data on which forecasts are based and the real-time measurements against which they are compared.
Three steps before any modeling project. Identify the two or three operational decisions that the forecast must support, and the timeline for each. Audit the available count history zone by zone, documenting any data gaps. Establish a naive baseline—for example, replicating the same time slot from the previous week—and measure its error. This baseline becomes the benchmark for any method considered thereafter.