AUTONEWS
A new AI framework could help cities plan for future traffic
AI traffic planning has spent two decades being reactive. A queue forms, a camera sees it, a control room retimes a signal, and the delay that already happened is shaved by a few seconds. A team at New York University’s Tandon School of Engineering has published a framework that tries to move the work upstream, forecasting where congestion will sit years out and letting a planner interrogate the result in plain English.
The paper, “Geospatial AI Applications for Reducing Traffic Congestion and Guiding Planning Decisions,” appears in Transactions in GIS, volume 30, issue 4, under DOI 10.1111/tgis.70327. Anton Rozhkov of NYU’s Center for Urban Science and Progress wrote it with Pranav Nitin Motarwar and Rudra Patil. Our AI models and tools hub tracks the model families this kind of applied work is built on, and the predictive analytics page covers the forecasting side in a business context.
This article sets out exactly what the framework does, what the numbers in it mean, where the arithmetic leads, and what the authors say it cannot yet do. The result is narrower than the headlines suggest and more useful because of it.
A forecasting layer with two competing models...The framework runs ARIMA, a conventional statistical time-series method, alongside an LSTM neural network, and compares them on the same held-out data. Keeping both is deliberate: the comparison is the evidence that the neural approach earns its complexity.
A spatial layer built on hexagons...AI traffic planning forecasts are laid onto Uber’s H3 hexagonal grid, which tiles the city into cells that can be zoomed in or out without changing shape. That lets the same data answer “which borough” and “which corridor” without a separate model for each question.
A clustering step that finds hotspots...On top of the hexagons, clustering groups cells that behave alike, which is how the framework locates congestion hotspots rather than reporting one flat number for the whole city.
A language interface grounded in the city’s own data...The last component is a customised portal built on Meta’s LLaMA model, connected to a project-specific traffic knowledge base and run zero-shot. Planners type a question; the portal answers from the project’s data rather than from whatever the base model absorbed in training. This is applied natural language processing doing an unglamorous job well.
Why it runs locally...Rozhkov’s stated motivation for AI traffic planning tooling was control over where the data sits. “We started with an idea: what if we developed our own AI platform, one that could be hosted locally and would be secure, intuitive and comfortable for planners to use in their day-to-day work,” he said — a platform agencies can run “behind their own firewall.”
Fifteen years in, four years out...The AI traffic planning framework was fitted on roughly 15 years of New York City traffic observations spanning 2009 to 2024, and evaluated on a 2021 to 2024 test set. Four years of testing against fifteen years of record is about 27% of the data held back, which is a generous split by forecasting standards.
The error gap, stated precisely...On that test set the LSTM returned a root mean square error of 342.56 vehicles per day. ARIMA returned 417.62. The difference is 75.06 vehicles per day, which is 17.97% of the ARIMA figure — the “roughly 18% improvement” the coverage quotes, and it checks out.
What that error looks like in context...Against the framework’s own 2025 baseline of 12,540 vehicles per day, an error of 342.56 is 2.73% of daily volume. ARIMA’s 417.62 is 3.33%. Both are small; the neural model is better by about six tenths of a percentage point of daily volume, not by an order of magnitude.
The forecast itself...The AI traffic planning framework projects average daily traffic volume rising from 12,540 vehicles in 2025 to 19,680 in 2029. That is 7,140 additional vehicles per day across four years, an average of 1,785 per year, and a 56.9% total increase.
The growth rate hiding inside it...Compounded rather than averaged, 12,540 to 19,680 over four years is about 11.9% per year. Treating that as a certainty would be a mistake — the researchers stress the forecasts carry substantial prediction intervals — but it is the number a capital plan would have to absorb.
Seasonality is real but partial...Motarwar’s summary of the baseline is blunt: “ARIMA gives you seasonality, which is true but not the whole story.” Weekly and annual rhythms are genuinely there, and a statistical model finds them cheaply.
The residual is where the gain lives...“The LSTM picks up the parts of the pattern that don’t repeat cleanly, and that’s where most of the improvement came from,” Motarwar said. That is an unusually precise attribution — the 18% is not diffuse model magic, it is the non-repeating remainder.
Which argues against replacing ARIMA...If the improvement lives in the residual, the statistical model is still doing most of the work on the bulk of the signal. Running both is not indecision; it is how you know which part of the forecast you should trust least.
The comparison is also the honesty check...A single-model paper reporting 342.56 vehicles per day of error would give a reader nothing to judge it against. The paired result is what makes the AI traffic planning claim falsifiable by the next team that tries it.
Where the approach is likely to travel...Any city with a long, dense count record and a mix of repeating and irregular demand has the same structure. Cities with short records, or with a single dominant commuting pattern, would likely see a smaller spread between the two models.
Averages hide the problem...“A citywide average doesn’t help the city planners,” Patil said. A single number rising by 56.9% tells an agency that something is coming, and nothing about where to put the money.
Corridors, not boroughs...“What they need to know is which corridors are badly impacted, and those turn out to be consistent year after year,” Patil said. Persistence is the operationally valuable finding: a hotspot that recurs is a hotspot you can plan against.
Hexagons make scale a dial, not a rebuild...H3 cells nest, so the same indexed forecast answers a borough-level question and a corridor-level question without re-modelling. That is a plumbing detail with real consequences for how often a planning team can actually ask something.
What the hotspot analysis surfaced...Manhattan came out as the highest-congestion borough, with Brooklyn and Queens also appearing in the analysis, and specific concentrations around Lower Manhattan and the approaches near LaGuardia Airport. None of that will surprise a New Yorker, which is the point — it is a sanity check on the method.
| Figure | Value | Source |
|---|
| LSTM test error | 342.56 vehicles/day | Published |
| ARIMA test error | 417.62 vehicles/day | Published |
| Absolute gap | 75.06 vehicles/day | Subtraction |
| Relative gap | 17.97% | 75.06 / 417.62 |
| 2025 baseline volume | 12,540 vehicles/day | Published |
| 2029 forecast volume | 19,680 vehicles/day | Published |
| Four-year increase | 7,140 vehicles/day, +56.9% | Subtraction, division |
| Implied annual growth | ≈11.9% compounded | Fourth root of 1.569 |
Consistency is the testable claim...If the same corridors recur year after year, then next year’s data is a live test. That makes this spatial layer of AI traffic planning easier to validate than the five-year volume forecast, which nobody can check until 2029.
Adaptive signal control is reactive by design...Systems that retime signals from live detector feeds are the current state of practice, and they work. They also start from a queue that already exists, which is the ceiling this AI traffic planning work is trying to lift.
Four-step travel demand models are slow to question...The classic regional demand model is powerful and expensive to run. A scenario takes weeks, which quietly limits how many scenarios get considered before a decision is made.
Navigation apps optimise for the driver, not the network...Commercial routing data tells a city where delay happened yesterday from the point of view of individual drivers. It does not give an agency a structural account of why that corridor fails.
Congestion pricing needs a forecast it can defend...Any charging scheme has to withstand a public inquiry. A published error figure on a held-out test set is the sort of thing that survives that process, which is one practical reason the AI traffic planning literature is moving toward stated baselines.
The gap this fills is speed of enquiry...None of the above is replaced. What changes is that a planner can ask a spatial question and get an answer in minutes, which is the difference between testing one option and testing eight.
The query portal is the part most cities would notice...The forecasting half is standard AI traffic planning practice done carefully. The interface is the part that changes who can use the output.
The failure mode it is built against...“A general chatbot gives you a reasonable-sounding generic paragraph about congestion,” Rozhkov said. That sentence describes the exact risk of bolting a commercial assistant onto a planning workflow: fluent output with no connection to the agency’s own counts.
Grounding is the whole mechanism...The portal is tied to a project-specific traffic knowledge base. “Planners need an answer that comes from their own data,” Motarwar said. Grounding turns the model from an author into a retriever with a readable voice.
Zero-shot, deliberately...Running the portal zero-shot means no task-specific fine-tuning was needed, which lowers the maintenance burden for an agency that does not have a machine learning team on staff.
Local hosting solves a procurement problem, not just a privacy one...Transport agencies hold movement data that is sensitive in aggregate and politically awkward in detail. A platform that runs inside the firewall sidesteps a data-sharing review that can take longer than the modelling.
It lowers the cost of asking a second question...The practical effect of good AI traffic planning tooling is not one brilliant answer. It is that the fifth follow-up question costs the same as the first, so scenarios get explored rather than commissioned.
What the AI traffic planning study does not establish...The authors are explicit about the limits of the AI traffic planning work, and the limits are the most important paragraph in any applied paper.
It has not been trialled at scale...The AI traffic planning framework has not been through large-scale trials with actual planning departments. Everything above is a research result, not a deployment record.
It cannot reduce congestion by itself...The researchers say plainly that the platform cannot solve congestion on its own. A forecast changes what a capital programme knows; it does not add road capacity or move a single vehicle.
The forecast intervals are wide...The 2029 figure carries substantial prediction intervals. Quoting 19,680 as a point estimate, as most coverage has, drops the uncertainty that the authors attached to it.
One city, one data regime...Every result here is New York’s. A framework fitted on fifteen years of dense counts in a dense city says nothing yet about a mid-size city with sparse sensors.
A grounded model still inherits its base model’s habits...Grounding constrains what the portal retrieves. It does not eliminate the possibility of a confidently worded synthesis that overstates what the underlying cells support.
How to Read an AI Traffic Planning Result If You Buy Technology...For anyone evaluating vendor claims in this space, the paper is a useful AI traffic planning yardstick precisely because it is modest.
Ask for the baseline, not the headline...An 18% improvement is only meaningful next to the thing it improved on. A vendor quoting an accuracy number with no stated baseline has told you nothing.
Ask what the error means in units you use...342.56 vehicles per day is interpretable. “97% accurate” is not, unless you know accurate at what and against which alternative.
Ask where the model runs...Local hosting is a genuine differentiator for public bodies, and it is testable at procurement rather than after deployment.
Ask what the system refuses to answer...A grounded portal should decline questions its knowledge base cannot support. A system that always has an answer is the failure mode Rozhkov described.
New York University’s Tandon School of Engineering
