Traffic & mobility demand forecasting

Road operators, cities, transit agencies and mobility providers all need the same answer: how many vehicles or passengers will be where, and when. Today that answer often comes from static timetables, last year's counts or a strategic transport model that is updated every few years. AI forecasting combines live detector and probe data, ticketing and passenger counts, calendars, events and weather in gradient-boosted, graph-neural or foundation time-series models. The results are congestion forecasts for the next hour, occupancy forecasts for every train, and hourly demand per zone for sharing, ridepooling, parking and charging. These feed signal control, dispatch, fleet rebalancing and passenger information, so operators can act before the jam or the overcrowded train happens.

Problem & value

• Today: traffic control centres react to congestion once it is visible. Transit agencies plan capacity from annual counts. Sharing and ridepooling operators rebalance vehicles by rule of thumb. Strategic planning relies on macroscopic four-step or agent-based models calibrated on surveys. Short-term operations have little forecast support.
• AI value: forecasts let operators act before problems appear. Examples are rerouting or changing signal plans before queues form, adding cars to trains that are predicted to be full, showing passengers less crowded departures, placing scooters and ridepooling vehicles where demand will be, and sizing charging and parking capacity.
• Evidence:
• Google Maps / DeepMind: graph neural networks improved real-time ETA accuracy by up to 50% in several cities, including Berlin. Reported gains range from 16% (London, Copenhagen) to 51% (Taichung) [1].
• PTV Optima, Abu Dhabi: PTV was selected in October 2024 (as subcontractor to ST Engineering) to deliver it as the real-time prediction engine of the city's multimodal ITS platform, forecasting queues and delays up to 60 minutes ahead [2].
• SBB: Swiss Federal Railways began building its nationwide agent-based MATSim model (SIMBA MOBi) in 2017; it has been an established planning product since about 2020 [3].
• Data push: the revised EU ITS Directive (2023/2661) and the delegated regulations on real-time traffic information (2022/670) and multimodal travel information (2017/1926, amended by 2024/490) require road, traffic and travel data to be available through National Access Points. In Germany that is the Mobilithek. This makes much better training data available to cities and SMBs [4][5].

Variants

• Road traffic (short-term): flow, speed, travel time and queue length per segment, 5–60 min ahead, for traffic control centres, motorway operators (e.g. Autobahn GmbH) and city ITS. This feeds OPT-025 (adaptive signal control) and incident management.
• Public transport ridership & occupancy: passengers per trip, line and stop, and in-vehicle crowding (published as GTFS-Realtime occupancy_status [6]). Used for capacity planning, train formation and passenger information ("this train is busy").
• Shared & on-demand mobility: hourly demand per hexagon for bike and scooter sharing, car sharing, taxis and ridepooling. This drives rebalancing and the fleet positioning for OPT-028.
• Parking & EV charging: forecasts of garage and on-street occupancy and of charge-point usage. Inputs to parking guidance systems and to depot and public charging planning (OPT-021, PRED-007).
• Events, tourism & venues: visitor flows for stadiums, trade fairs, airports and city centres, combined with footfall counts (VIS-008).
• Strategic & scenario forecasting: origin-destination (OD) matrices and multi-year demand for new lines, roadworks or mobility policies. This is classic transport modelling (PTV Visum, MATSim, ActivitySim) increasingly calibrated with ML and mobile-network data.
• Logistics: expected travel times per corridor and time window for tour planning (OPT-001) and ETA prediction (PRED-018, which owns per-shipment ETA).
• Private use: departure-time planning in consumer navigation apps ("leave at 7:40") and transit apps that show crowding. People use this through Google Maps, HERE WeGo or operator apps rather than building it themselves.

How it works

1. data intake (detectors / DATEX II, probe data, GTFS-RT, APC, ticketing, sharing & charging logs)
2. cleaning & imputation (detector outages, map matching, APC calibration, privacy aggregation)
3. spatial model of the network (road graph / stop & line graph / H3 hexagons)
4. feature join (calendar, holidays, events, roadworks, weather forecast, incidents)
5. forecasting model (GBM per segment | spatio-temporal GNN | TS foundation model | simulation)
6. probabilistic forecast + anomaly / incident flags
7. consumers: traffic-control centre, dispatch & rebalancing, passenger info, planning dashboards
8. human-in-the-loop: operator approves control measures; planners validate scenarios

• Short-term road forecasting works best with spatio-temporal models that use the network graph. Options are graph neural networks (DCRNN, Graph WaveNet, STGCN and successors) or hybrid model-plus-ML engines such as PTV Optima, which combine dynamic traffic assignment with ML [2].
• Ridership & zone demand: gradient boosting (LightGBM/XGBoost) on calendar, weather and event features is still the strongest and most explainable baseline. Global models trained over all lines or zones handle sparse series well.
• Foundation time-series models (Chronos-2, Moirai 2.0, TimesFM) give zero-shot baselines for new stops, stations or charging sites with little history [7][8][9].
• Simulation (SUMO, MATSim, PTV Visum/Vissim) answers "what-if" questions that pure ML cannot, such as the effect of a new line, a closure or a policy change, because those situations are not in the history [3][10].
• Human-in-the-loop: forecasts are decision support. Traffic-control measures, train formation and service changes are approved by operators. Planners review scenario results before decisions.

Data preparation

Needed data: road detector counts and DATEX II feeds, probe or floating-car speeds, GTFS and NeTEx timetables with real-time updates, ticketing and passenger-count data, parking and charging sessions, plus events, school holidays and weather. It lives at road operators, transit agencies, in ticketing systems, in vendor portals and in Excel exports from counting campaigns.

Typical gaps: failed detectors, changed sensor locations, ticketing data without trip assignment, different network versions over the years, missing event calendars, and strict access rules, since passenger and vehicle data may be personal.

Preparation steps: - Inventory sources, owners and licences (PREP-001, PREP-004). - Map sensors and stops to one road or line network version. - Detect and impute sensor outages; flag construction sites and special events. - Aggregate or pseudonymise individual trips (PREP-022) and check purpose and legal basis (PREP-025). - Add calendar, event and weather features (PRED-017). - Build a back-test set with known disruptions (PREP-018).

Tools: GTFS tooling, PostGIS, pandas, a time-series store. Share of total effort: about 50 to 60 percent, the highest of the model workload. See DATA-003 for time-series handling and DATA-008 for geodata.

Implementation paths

Which path for whom

• smb (A): Small operators (parking, fleets, shuttle services) are best served by established traffic-data and forecasting products with EU hosting.
• enterprise (B): Mobility providers need forecasts tied to own booking, fleet and ridership data, so cloud APIs plus own models fit.
• developer (C): Open traffic datasets, GTFS feeds and open-source time-series and graph models run on modest hardware (HW1).
• public (C): Cities and transit agencies hold the data, face procurement and sovereignty rules, and benefit from open standards and open-source stacks on sovereign infrastructure.
• private (A): Navigation and transit apps already show traffic and crowding forecasts.

Path A — Buy (recommended for most SMBs and cities)

• Traffic-management platforms with forecasting: PTV Optima / PTV Flows (PTV Group, DE), Yunex Traffic (DE), Kapsch TrafficCom (AT), Aimsun Live (ES). Typical buyers are cities, regions and motorway operators.
• Traffic data & prediction services: TomTom (NL), HERE (NL), INRIX (US). They provide historical and live speeds, travel times and typical-traffic profiles. TomTom Traffic Stats covers more than 70 countries [11].
• Public transport: APC hardware and analytics from transit ITS vendors such as INIT (DE) and IVU (DE), plus occupancy forecasts in operator apps. Mobile-network mobility analytics provide anonymised OD flows.
• Strategic modelling: PTV Visum / Vissim (DE) for demand models and scenarios.
• Choose A when you need forecasts embedded in an operational system (control centre, AVL/ITCS) or you are an SMB that only needs travel-time forecasts for planning.

Path B — Build on cloud APIs

• Routing APIs with predictive traffic: Google Maps Platform Routes API with a future departureTime. The further ahead the departure, the more it relies on historical traffic [12]. HERE and TomTom routing APIs offer the same. This is the fastest path for logistics SMBs.
• Managed forecasting: Vertex AI / BigQuery ML (TimesFM is commercially usable via Google Cloud services [9]), Amazon SageMaker / AutoGluon with Chronos-2 [7], Azure ML. Use EU regions (Frankfurt, Amsterdam, Paris), or EU providers such as STACKIT, IONOS and OVHcloud for self-managed containers.
• Data: National Access Point feeds (Mobilithek in Germany [5]), GTFS / GTFS-RT, DATEX II, and own APC or sharing logs, landed in a cloud data warehouse.
• Choose B when you have your own operational data (fleet, sharing, charging network) and a small data team, but no on-prem constraint.

Path C — Self-host (open source)

• Modelling libraries: LightGBM/XGBoost, Nixtla statsforecast / neuralforecast, AutoGluon-TimeSeries, PyTorch Geometric Temporal for GNNs. LibCity provides 74 reproduced models across traffic-flow, speed, on-demand-service and OD prediction tasks (Apache-2.0) [13].
• Foundation models: Chronos-2 (Apache-2.0, 120M parameters; small 28M variant) [7] can be self-hosted; Moirai 2.0 [8] weights are CC-BY-NC-4.0 (non-commercial). Note that TimesFM 3.0 weights carry a non-commercial licence. Commercial use is only possible through Google Cloud services, and the older TimesFM 2.5 is Apache-2.0 [9].
• Simulation: SUMO 1.28 (EPL-2.0/GPL-2.0, an Eclipse Foundation project) [10], MATSim [3] and ActivitySim for agent-based demand.
• Benchmarks for model selection: LargeST covers 8,600 California sensors over 2017–2021 with 12 baselines [14]. PeMS/METR-LA are classic but small.
• Streaming & ops: Kafka or Redpanda, Apache Flink, TimescaleDB/PostGIS, and MLflow for model registry.
• Hardware: HW1 (CPU server) is enough for GBM and foundation-model inference at city scale. HW2 (one 24–32 GB GPU) is needed for training GNNs on large networks and for faster simulation calibration.

Path D — Custom training

Worth it for road operators, large transit agencies and mobility platforms with years of detector, probe or ticketing history. Typical work is training a spatio-temporal GNN on the own network, or fine-tuning a foundation model on all lines or zones. This needs at least 1–2 years of clean data at 5–15 min resolution, covering holidays and events, plus a maintained network graph. Most gains come from better data (detector imputation, event calendars, APC calibration), not from model architecture.

State of the art (2026)

• Production pattern: hybrid systems combine probe data, a network graph and ML or a GNN for minutes-to-an-hour horizons. The Google Maps GNN deployment [1] and PTV Optima's AI-plus-dynamic-model engine [2] are the reference examples. Gradient boosting remains the workhorse for ridership and zone demand.
• Foundation time-series models now handle covariates. Chronos-2 (Oct 2025) supports multivariate and covariate-informed forecasts zero-shot [7]. TimesFM 2.5 added covariates, and TimesFM 3.0 (Aug 2026) supports them natively [9]. Moirai 2.0 was released in Aug 2025 [8]. All of this helps with cold starts (new stations, new charging sites).
• Research: large-scale benchmarks (LargeST [14]) showed that many GNNs that beat baselines on small datasets scale poorly. Research focus has moved to scalable spatio-temporal models, LLM-based and foundation models for urban data, and OD-matrix estimation.
• Limits and failure modes:
• Forecasts break under regime changes such as pandemics, new lines, the Deutschlandticket fare change, strikes, major roadworks and one-off events. Use scenario simulation and fast retraining.
• Detector and APC data are noisy and full of gaps.
• Probe data is biased toward the vehicle fleets that report it.
• Forecasts that steer drivers can change behaviour and invalidate themselves.
• Rare incidents (accidents) are essentially unpredictable in time and place. Detect them quickly rather than trying to predict them.

Shared resources & combinations

• Same time-series stack (time-series + tabular-ml + streaming): PRED-001 demand, PRED-007 energy load, PRED-011 staffing, PRED-017 weather impact, PRED-042 air quality. One feature store, one forecasting service (GBM plus Chronos-2/Moirai) and one HW1 server can serve all of them.
• Upstream sensing: VIS-012 (camera-based traffic counts and classification), VIS-008 (footfall), VIS-011 (ANPR / parking occupancy). These produce the counts this use case forecasts. Use one edge or video stack for counting and send aggregated counts here.
• Downstream optimisation: OPT-025 adaptive signal control, OPT-028 ridepooling/DRT dispatch and rebalancing, OPT-001 tour planning, OPT-020 disruption management, OPT-021 depot and EV charging. Forecasts are their key input, and they share the network graph and streaming pipeline.
• Sister forecasts: PRED-018 (per-trip ETA uses the same segment travel-time forecasts), PRED-042 (traffic forecasts are a major input to air-quality forecasts).
• Shared data pipelines: GTFS/NeTEx, DATEX II and National Access Point ingestion, PostGIS road graph and H3 grid, weather-forecast ingestion (shared with PRED-007 and PRED-017).

Effort, cost & KPIs

• Path A: traffic-data subscriptions or routing APIs take days to weeks. Traffic-management platforms are multi-month public procurements, with costs driven by network size, data licences and integration with the control centre.
• Path B: 2–4 months for a ridership or sharing-demand forecast in production. Cost drivers are probe-data licences and routing-API calls rather than compute.
• Path C/D: 3–9 months, including data engineering, network graph and integration. One CPU or small GPU server is enough. The main cost is a data and ML team plus detector maintenance.
• KPIs:
• Forecast error per horizon (MAE/MAPE/WAPE, pinball loss for quantiles) against a seasonal-naive baseline.
• Share of congestion events forecast ≥ 15 min ahead.
• Occupancy forecast accuracy per crowding class.
• Vehicle utilisation and rebalancing trips (sharing) and passenger wait times.
• Travel-time reliability on managed corridors.

People & change

Start with management and the department lead (traffic management, planning or operations) to fix the decision the forecast supports. IT and data owners (road authority, ticketing, parking operators) grant access; suppliers of probe data and ticketing must agree on licences. Legal and compliance check procurement and open-data rules; the DPO checks any individual-level mobility data.

Works council: usually no, since the forecast concerns traffic and demand, not employee behaviour. Depends if forecasts feed driver rosters or are built from staff vehicle data; then §87(1) no. 6 and §90(1) no. 3 BetrVG apply. In municipalities and transit agencies the Personalrat is the counterpart (GUIDE-004).

Data protection: trip and location traces can be personal data. Prefer aggregated counts, run a DPIA check under Art. 35 GDPR for systematic tracking and conclude AVVs (GUIDE-005).

AI literacy: support planners and operators with training on forecast uncertainty (GUIDE-006). Pilot on one corridor or line for a full seasonal cycle. Keep humans in control: dispatchers and traffic engineers decide on measures; the forecast is advice. Typical concern: "the model misses special events". Address it with an event calendar and visible prediction intervals (GUIDE-009, GUIDE-011).

Risks, regulation & compliance

• EU AI Act: forecasting for planning, passenger information, fleet rebalancing or logistics is minimal risk, with the AI-literacy duty (Art. 4) for staff. Annex III point 2 classifies AI used as a safety component in the management and operation of road traffic as high-risk [15]. If forecasts directly drive safety-related control without a human, the deployment can become high-risk under Art. 6, with risk management, logging, human oversight and accuracy documentation. Examples are automated lane or tunnel closures and speed-limit control. Decision support for operators normally stays outside that category. Assess each deployment.
• GDPR / ePrivacy:
• Probe data, GPS traces, ticketing and check-in/check-out data, Wi-Fi/Bluetooth counting and mobile-network data are personal or easily re-identifiable location data. Only aggregated or anonymised flows should reach the model.
• Check DPAs with data vendors and rely on k-anonymity / minimum-count thresholds.
• Run a DPIA for large-scale location processing.
• MAC-address tracking also falls under ePrivacy / TDDDG rules in Germany.
• Sector rules: ITS Directive and delegated regulations on data provision [4]. In Germany, PBefG data-provision duties for mobility providers and the Mobilithek [5]. Public procurement and open-data licences apply when reusing city data.
• Typical risks: self-defeating or self-fulfilling forecasts, bias toward well-sensed areas, and vendor lock-in on probe data. Mitigate with scenario testing, human approval of control measures, monitoring of forecast drift and fallbacks to timetables and seasonal profiles.

Getting started

1. Pick one decision the forecast must improve, such as corridor congestion, crowded trains, scooter rebalancing or charge-point sizing, and the horizon it needs.
2. Inventory data: own counts, APC and logs, plus free National Access Point feeds (Mobilithek, GTFS, DATEX II). Fix detector gaps and calendar/event data first.
3. Build a seasonal-naive and a LightGBM baseline, then test Chronos-2 or Moirai zero-shot on the same backtest.
4. For road networks, compare a vendor (TomTom/HERE/PTV) against an in-house GNN only if you own dense detector data.
5. Connect the forecast to one action loop (dispatch, passenger info, signal plans) with human approval, and monitor forecast error weekly.

Sources

1. Google DeepMind — Traffic prediction with advanced Graph Neural Networks — https://deepmind.google/discover/blog/traffic-prediction-with-advanced-graph-neural-networks/
2. PTV Group — PTV to deliver real-time traffic prediction module for Abu Dhabi's multimodal platform — https://ptvgroup.com/en/resources/news/company/ptv-group-deliver-real-time-traffic-prediction-module-abu-dhabis-new
3. MATSim — Multi-Agent Transport Simulation (show case: SBB SIMBA MOBi) — https://www.matsim.org/examples/sbb
4. European Commission — ITS Directive and Action Plan (Directive (EU) 2023/2661, Delegated Regulations 2022/670, 2017/1926, 2024/490) — https://transport.ec.europa.eu/transport-themes/smart-mobility/road/its-directive-and-action-plan_en
5. Mobilithek — German National Access Point for mobility data — https://mobilithek.info/
6. GTFS Realtime — Vehicle Positions (occupancy_status) — https://gtfs.org/documentation/realtime/feed-entities/vehicle-positions/
7. Amazon Science — Chronos / Chronos-2 forecasting models — https://github.com/amazon-science/chronos-forecasting
8. Salesforce AI Research — uni2ts / Moirai 2.0 — https://github.com/SalesforceAIResearch/uni2ts
9. Google Research — TimesFM — https://github.com/google-research/timesfm
10. Eclipse SUMO — Simulation of Urban MObility — https://eclipse.dev/sumo/
11. TomTom — Traffic Stats — https://www.tomtom.com/products/traffic-stats/
12. Google Maps Platform — Routes API: traffic-aware routing and departure time — https://developers.google.com/maps/documentation/routes/config_trade_offs
13. LibCity — urban spatio-temporal prediction library — https://github.com/LibCity/Bigscity-LibCity
14. LargeST — large-scale traffic forecasting benchmark (NeurIPS 2023) — https://github.com/liuxu77/LargeST
15. EU AI Act — Annex III (high-risk AI systems) — https://artificialintelligenceact.eu/annex/3/