Working With Live Traffic Feeds In A City That Refuses To Stay Still
I spent three years pulling raw telematics and camera feeds from the Seattle area, building models to predict where the I-5 backups would form during morning commute windows, and then watching WSDOT update their sensor firmware mid-project, which broke half my parsers overnight. It is not glamorous. It is also not as hopeless as people assume. The core problem with Seattle traffic is that the geography does not match any standard traffic model. You have a city shaped like a needle threaded between two bodies of water and a hill, which means most corridors are single points of failure. When the Aurora Bridge closes, you do not get a gradual slowdown. You get an immediate redistribution event across four parallel arterials, and the delay cascades into the entire region within eleven minutes. The data reflects this, but only if your ingestion layer can handle the burst. For anyone trying to work with real-time data in this market, you are dealing with at least three active streams. The primary one is WSDOT's API, which serves loop detector counts, camera snapshots, and message board text. The second is the Sound Transit feed, which tracks light rail schedules and delays on the Link lines. The third is usually a commercial feed from a provider like INRIX or TomTom, which fills the gaps where the public sensors simply do not exist, especially across the Mercer corridor and the Ballard bridges.
I stopped trying to build my own parsing layer around 2019 and moved to a stack built on Redash for ad hoc SQL queries against a Postgres instance, dbt for the transformation layer, and a Python pipeline running on Airflow to pull, validate, and publish the feeds every sixty seconds. The whole thing runs on a modest cloud setup, maybe a couple of medium instances and a managed database, and it chews through roughly four million records per day without breaking a sweat. If you want to get into this yourself, start by pulling the WSDOT camera image stream and the loop detector JSON endpoint and just sit with the raw output for a few days. The documentation is fine, but the field descriptions are inconsistent between regions. Some counties call a traffic count a volume field. Others call it a occupancy. If you map both to the same schema without normalizing them, your models will silently learn garbage.
What Actually Moves The Needle
The AI tools that matter here are not the flashy ones. The useful models are simpler than most people expect. A gradient boosted tree trained on about a year of historical data, paired with live inputs for weather, events at T-Mobile Park, and the current speed from adjacent segments, will outperform most neural networks on this problem. Neural nets require too much data to train and too much latency to run in real time, and they do not handle categorical shifts well. When a game ends and fifty thousand people flood onto the I-5 on-ramps at once, the model has no precedent for that pattern unless you feed it event data explicitly. My team used XGBoost for the baseline model and LightGBM when we needed faster inference on edge devices. We kept a simple Kalman filter running alongside it to smooth out the sensor noise from the loop detectors, because these things produce garbage readings when a heavy truck passes over them. The Kalman filter is basically a mathematical way of saying the last good reading is probably still close to right. It costs almost nothing to run and it removes a lot of the jitter that trips up naive alerting logic. For visualization, we pushed the predictions into a tile-based map layer using Mapbox and streamed the updates through a lightweight WebSocket endpoint. The dashboards were React based, and the whole thing rendered new estimates across the network in about two to three seconds. That is fast enough to be useful during incident management, slow enough that it does not stress the servers.
Get the Full Details
There is a common assumption that more data always means better accuracy. In Seattle, it does not. I learned this the hard way when we added a second commercial feed to the pipeline and the model performance actually dropped. The two feeds disagreed on speed estimates for the same stretch of road about eighteen percent of the time, and the model spent its capacity trying to average them rather than learning the actual traffic dynamics. We ended up keeping one feed and using the other only as a fallback when the primary went dark. This cut the training time in half and improved prediction accuracy by a few percentage points.
Where The System Breaks
You need to know the failure modes before you build on top of these tools. The biggest one is sensor dropout. The Seattle area has thousands of inductive loop detectors, and roughly seven percent of them are malfunctioning at any given time. Some are offline because of construction. Others are offline because the county that installed them stopped maintaining them. Your model will treat a broken sensor reporting zero vehicles as a valid data point unless you build in anomaly detection. We solved this by tracking the expected value for each sensor against its historical baseline and flagging any reading that deviated by more than three standard deviations. Those points got filtered out before they reached the model. Another problem is latency. Even when the data is accurate, it is rarely perfectly fresh. The WSDOT feed typically updates every thirty to sixty seconds, but the processing and model inference pipeline adds another few seconds. By the time your prediction lands on a dashboard, it is usually describing traffic conditions from about two minutes ago. This is acceptable for most planning purposes, but it is useless for anything requiring instantaneous response. If you need sub-minute latency, you are looking at a different architecture involving stream processors like Kafka and Flink, which is a much bigger engineering commitment and a lot more expensive to operate. Weather is also a multiplier that most projects underweight. Rain in Seattle is light enough that drivers do not slow down dramatically, but when it snows, even an inch causes the whole network to compress. The relationship between snowfall and congestion is not linear. The first inch takes twice as long to clear as the second inch, and the city's plowing schedule is not uniform across neighborhoods. If you are building a predictive model, include precipitation as a feature, but weight it differently for rain versus snow and account for the time of day. A snowstorm at 3 PM on a Friday behaves completely differently than one at 7 AM on a Tuesday.
Practical Steps To Get Started
If you want to experiment with this yourself, you do not need enterprise-grade infrastructure. Here is what works for a small team or an independent researcher. First, register for the WSDOT Open Data account. It is free and gives you access to the camera streams and detector data. Pull the data into a local database using a scheduled job that runs every minute. Do this with a simple Python script using the requests library and schedule it with cron or a task scheduler. The raw JSON is straightforward enough that you can parse it in an afternoon. Second, normalize the fields. Create a unified schema that maps WSDOT's volume, occupancy, and speed fields, plus any equivalent fields from commercial feeds, into a single table structure. Add a timestamp column with UTC time, a source column to track where each record came from, and a quality flag column. The quality flag is what saves you later when you need to debug why predictions went sideways.
Third, build a simple baseline model. Start with a linear regression to understand the relationships in the data. Then move to a tree-based model once you have cleaned the dataset. Use cross-validation across different times of day and different days of the week. Seattle traffic on a weekday morning is a fundamentally different system from Saturday afternoon, and your model should reflect that. I split the data into time-blocked folds rather than random folds because temporal leakage is a real risk here. Random splits can make your validation scores look artificially good. Fourth, set up monitoring. Track prediction accuracy over time using metrics like MAE and RMSE, but also track the drift in your input features. If the distribution of speeds on a particular corridor changes significantly from the training period, your model is degrading and you need to retrain. Automated retraining on a weekly schedule is usually sufficient for this use case.
What The Future Actually Looks Like
The direction the field is moving is toward higher resolution data and better integration between modal systems. Right now, traffic prediction and transit prediction are mostly separate projects. They should not be. A delayed Link train pushes people into cars, which changes the traffic pattern on adjacent roads, which creates delays for the next train cycle. The feedback loop matters, and modeling it requires shared data infrastructure. The city and state are slowly building toward a coordinated data platform. The Washington State Department of Transportation has been working on a statewide traffic management center that would unify data from multiple sources. Sound Transit is expanding its real-time analytics capabilities. Private companies are adding more vehicle-to-infrastructure pilots. None of this happens fast enough to solve today's problems, but it is moving in the right direction. The most impactful fix is not a model improvement. It is signal timing optimization using real-time adaptive control. The existing infrastructure at most major intersections in Seattle can already support adaptive signal control, but the deployment has been slow due to permitting, coordination with nearby jurisdictions, and budget constraints. Where adaptive signals have been installed, like parts of the I-90 corridor, travel time variability dropped by about twenty percent during peak hours. That is a measurable, real-world improvement that does not require a single line of AI code.
For anyone building tools in this space, the takeaway is to focus on the bottlenecks in the data pipeline first. Most projects fail not because the model is wrong but because the data is late, inconsistent, or incomplete. Fix the ingestion layer, validate the inputs rigorously, and then let a reasonably simple model do the rest. The margin for error is smaller than it looks, but the payoff is real if you pay attention to the details. I still check the raw feed data myself every now and then. Something about staring at the numbers directly keeps you honest, and it reminds you that behind every prediction is a physical road with cars on it that are trying to get somewhere. That is enough motivation for the work.
