Public Transit AI in 2026: Demand Forecasting and Route Optimization
Public transit data is dense; ML is finally producing operational wins. The cities deploying it and the patterns that produce real results.
Public transit produces some of the densest real-time data of any sector — GTFS feeds, automatic passenger counters, fare-card taps, GPS pings, real-time vehicle telemetry. The data has been available for years. The operational wins from ML have been slower in coming, but by 2026 specific deployments at agencies in North America, Europe, and Asia have crossed the threshold from pilot to operational use. This post walks through what’s actually working.
Where the data lives#
Modern transit agencies generate several streams that matter for ML:
GTFS and GTFS-realtime — the schedule data plus live vehicle positions, delays, and alerts. Open standards, widely supported, the foundation for everything else.
Automatic Passenger Counters (APC) — sensors on buses and trains that count boardings and alightings by stop. Historically used for federal reporting; increasingly used for demand modeling.
Fare-card data — origin-destination patterns from smartcard taps. Privacy-sensitive but rich for travel-pattern analysis.
Vehicle telemetry — engine performance, energy consumption, driver behavior, mechanical sensors. Increasingly relevant as fleets electrify.
Customer-facing app data — search queries, planned trips, app sessions. The leading indicator of demand changes.
The hard part is integrating these streams. Agencies often have each one in a different vendor system that doesn’t talk cleanly to the others.
The use cases that are working#
Four ML applications have produced measurable operational impact at multiple agencies.
Short-horizon demand forecasting for route planning. Models predicting ridership by route and time-of-day, used to schedule service. Compared to the traditional approach of running surveys every five years and adjusting from there, ML-driven forecasting catches shifts faster — particularly post-pandemic where travel patterns have continued to shift.
Real-time delay prediction. Models that predict when a bus or train will arrive at a stop, accounting for upstream delays, traffic, and weather. The straightforward version is now standard in every major transit app. The sophisticated version, accounting for cascading effects across the network, is harder and rarer.
Crowd prediction. Models predicting how full a vehicle will be at a given stop. Useful for both rider information (“the next bus is full; the one after is empty”) and for capacity planning. Several agencies (TfL in London, MTA in New York, MARTA in Atlanta) have credible production deployments.
Demand-responsive transit routing. For microtransit and paratransit operations, ML-optimized routing replaces fixed routes with dynamic ones based on actual rider requests. The Via, Spare, and Routematch platforms underpin most of these deployments.
The use cases that are still emerging#
A few categories have substantial promise but less production maturity.
Energy-aware routing for electric bus fleets — optimizing charging schedules and route assignments based on battery state, grid pricing, and predicted demand. The infrastructure is being built; the operational deployments are early.
Multi-modal trip planning with intelligent transfers — combining bus, rail, bikeshare, and rideshare into integrated trips. Works in pilots; uneven in production.
Maintenance prediction for vehicles and infrastructure. The data is there; the predictive maintenance models are credible. Deployment depends on the agency’s broader asset management maturity.
The tools and the technical reality#
For agencies starting from a typical existing-systems baseline, the technical stack looks like:
- Data lake consolidating GTFS, APC, fare, and telemetry data — typically AWS S3 or equivalent.
- OpenTripPlanner or its successors for routing.
- Python ML stack (scikit-learn, XGBoost, PyTorch) for demand and delay models.
- Dashboarding through Looker, Tableau, or the various transit-specific tools.
- Integration with the agency’s GIS (ArcGIS, QGIS) for spatial analysis.
The work that distinguishes successful deployments isn’t model sophistication. It’s the data engineering — getting clean, joinable, real-time streams from multiple legacy systems into a single platform where the models can actually run.
What outsiders should know#
Public transit AI is harder than it looks. The data is messy. The legacy systems are heterogeneous. The procurement processes are slow. The political environment matters as much as the technical work — proposed service changes affect riders who organize and respond.
Vendors that succeed in this space invest heavily in the integration work and the change management, not just the ML. The agencies that succeed have champions who can navigate both the technical and the political sides.
Where pdpspectra fits#
Our data engineering practice has worked with transit operators on data integration, demand modeling, and the broader platform work. The ML is the visible part; the data plumbing is the work that actually ships.
Related reading: the AI fleet routing post, the smart cities data platforms post, and the government digitization RFP guide for Nepal.
Public transit AI is now operational reality. Talk to our team about your transit platform.