Roads Management Insights,
the complete guide.

Roads Management Insights is a feed-style product, not a finished application. Three primitives feed one pipeline, and that distinction is the difference between a deployment that ships in eight weeks and one that drifts for eight months.

The first primitive is the Roads Selection API. You hand Google the network you care about, by polygon, by GIS layer, by a list of national highway designations, and Google scopes everything downstream to that network. Pricing scales with the size of the selection. A state DOT covering 25,000 lane-kilometers pays more than a tier-2 city covering 800.

The second primitive is historical travel-time patterns, delivered to a BigQuery project of your choosing. Typical speeds and travel times by day-of-week and time-of-day, built from months of aggregated movement. This is the foundation for corridor studies, before-and-after analyses, capacity planning, and any analytics question that doesn't need to know what's happening right now.

The third primitive is near-real-time speed intervals, delivered as a Pub/Sub stream. Current speeds per road segment, refreshed approximately every two minutes. This is the signal behind live operations dashboards, incident detection, and dynamic re-routing. It is not fast enough for adaptive signal control, that requires sub-second response, but it is fast enough for almost everything humans look at on a screen.

What you don't get from Google: dashboards. Alerts. Incident correlation. Stakeholder reports. A user interface of any kind. RMI is plumbing. Everything downstream, the part operators actually see and act on, is built by your team, by a partner, or by a platform like TraffiCure that ships those layers pre-built.

Most agencies that try to self-build the layer above underestimate it. Thresholding logic, alert routing, incident correlation across feeds, role-based dashboards for engineers vs commissioners, exception reporting for stakeholders, that's four to six months of focused engineering work, even with a competent team. The Google docs make it look like it should take a week. It does not take a week.

The temptation, when a new dataset shows up, is to enumerate every analysis it makes possible. Most of those analyses will never be done because nobody on the operations team has time. The shorter, more honest list is the small set of things RMI changes about how a road authority operates.

It changes what you see. Before RMI, most cities had visibility into the 3% of road network covered by cameras and the maybe 15% covered by Bluetooth roadside detectors. The other 80%+ was operationally invisible. RMI fills almost all of it, almost immediately, with no hardware to install. The political and procurement implications take longer to process than the technical ones, but the technical change happens on day one.

It changes how fast you know. Before RMI, the standard incident-detection workflow at most road authorities was reactive: a citizen called, the call center logged it, somebody dispatched a unit, the unit reported back, and the operations center updated its understanding of the network. That cycle takes 15 to 90 minutes depending on the city. RMI compresses the first half, the network itself tells you something is wrong, in roughly two minutes, leaving the response cycle as the only thing left to optimize.

It changes what you can argue for. Cities that have RMI deployed can show before-and-after corridor performance with a level of evidence that previously required expensive third-party studies. A signal retiming, a one-way conversion, a bus-lane experiment, each one becomes legible in the data within days, not quarters. That changes which projects get funded, which get killed, and how aggressively elected officials defend transportation investments to their constituents.

It changes what you can answer. The single most common question road authorities get from journalists, mayors, and regulators is some variant of "is traffic getting better or worse?" Until RMI, the honest answer was "we don't know with the granularity you're asking about." With RMI, the honest answer is yes or no, by corridor, by hour, by week. That is a different kind of agency than most departments are used to.

The honest answer to "should we replace what we have with RMI?" is almost never yes-everything or no-nothing. It is some hybrid, and the hybrid depends on which corridors you're talking about and which decisions you're trying to make. Here's the dimensional comparison from a team that has deployed RMI alongside INRIX, TomTom Move, and traditional sensors.

We're a Google partner. We're also honest about where the product falls short, because that is what separates pilots that ship from pilots that stall. Four limits matter operationally; the rest are footnotes.

Sparse data on quiet roads. Rural segments and low-traffic suburbs can thin out, especially overnight. RMI's signal density is a function of how many Google Maps users are driving on the road in a given window. When the user count drops below Google's k-anonymity threshold for that segment, the segment goes dark for that interval. For most cities this is invisible. For state DOTs covering rural freeways at 2am, it is not.

No commercial-only visibility. RMI sees the consumer fleet. Freight-only corridors, private bus lanes, and routes dominated by drivers who don't run Maps in the foreground will under-report. If your decision depends on commercial-vehicle behavior, a port truck route, a haul road, an industrial spur, pair RMI with INRIX or TomTom Move, both of which built their products on fleet GPS feeds.

Not for signal control. The two-minute refresh cadence is fine for live dashboards, incident detection, and operator situational awareness. It is not fine for adaptive signal control, ramp metering, or anything else that needs sub-second response. Loop detectors and radar units stay in the picture for those use cases. RMI complements them; it doesn't replace them.

Raw feed only. RMI ships dashboards, alerts, incident correlation, and stakeholder reporting in exactly zero quantity. You build all of that yourself, buy it from a partner, or pick a platform that ships it pre-built. Whichever you choose, factor four to six months of engineering work into the self-build estimate.

RMI is sold through the Google Maps Platform partner network, which means there are exactly three reasonable procurement paths. They differ on who holds the contract, who does the integration, and how long it takes from signature to a production dashboard. They do not differ on the data; once activated, the data is identical regardless of path.

Path A, buy RMI and the activation layer together. A single contract with a GMP partner who resells the RMI license and ships the decision platform on top. Available globally; we operate this path directly in India and the UAE as Lepton, and through partners elsewhere. Fastest to production: typically four to eight weeks from signature to operational dashboards.

Path B, partner-led, with an existing systems integrator. Your SI or cloud partner sells the RMI license and we, or another decision-platform vendor, plug in as the activation layer. The right path if you already have an SI relationship and procurement underway. Same final product as Path A; slightly more contractual surface area to manage.

Path C, activate an RMI subscription you already have. If you bought RMI directly from Google and your data is already landing in BigQuery, the fastest path to value is connecting a decision platform to the existing Pub/Sub stream and BigQuery tables. You keep your Google contract; we add the activation layer. Production-ready in two to four weeks because the data plumbing already exists.

Pricing for RMI itself is set by Google and depends on three things: the size of the road network you select, the refresh frequency you need, and the geography. Pricing for the activation layer depends on the number of users, the number of operations centers, and how much custom integration you want into existing GIS systems. Public list pricing isn't published for either layer; both are scoped per agency. We'll give you a real number on a 30-minute call.

The named early adopters, Colorado DOT on the I-70 corridor, Abertis on the Spanish toll network, CERTH for transport research in Greece, represent very different use cases and are doing very different things with the same data feeds. We've also been deploying RMI inside our own customer base since late 2025. Four observations from across both groups.

The dashboards everyone needs look the same. The logic underneath does not. Across cities of wildly different size and political shape, the first three operational dashboards an operations centre asks for are almost identical: a live network speed map, an incident-feed timeline, and a corridor-level "is this worse than yesterday" view. The dashboards are packageable. What is not packageable is the alert logic and the metrics underneath them, which corridors get watched at which thresholds, what counts as an exception, how alerts route to which team, how performance gets benchmarked. That layer needs to be tuned to each city's geography, traffic patterns, and operating model. It is the work that takes a generic product and turns it into something a city actually uses every day.

Real-time adoption has been the surprise. When we started, we expected planners and analysts to be the heaviest users. The actual usage pattern is different: cities have been adopting RMI fastest for live operations, because for the first time they have an active, network-wide layer of what is happening on their roads right now. That shifts the operations centre from reactive ("a citizen called about a jam") to proactive ("we already see the corridor degrading, here's where to send the response"). Once a control room has watched the network move in real time for a week, going back is not an option anyone wants to take.

The "before and after" use case is the highest-value one nobody talks about. Every road authority we've worked with has at least one signal retiming or geometric change they argued about for months. Once RMI is live, that argument resolves in a week, with evidence. That single use case has paid for the deployment in three of our four enterprise contracts so far.

The biggest unlock from the May 2026 release is simulation. Until this month, RMI gave us travel-time and speed data, powerful, but limited to "what is happening" and "what usually happens." With vehicle counts and the new incident feeds, we can now build genuine simulation and forecasting models on top of the same pipeline: capacity scenarios, signal-cycle what-ifs, incident-response time predictions, network-wide impact studies. That is the layer cities have been asking us for since the beginning, and it became possible the day Google shipped these new feeds.

We'll keep updating this section as we deploy more, including in cities we don't run directly. If you're considering RMI and want a candid conversation about what we've learned, the demo CTA below is the path.

The most likely thing to happen in the twelve months after this writing is that RMI becomes load-bearing infrastructure for cities and DOTs in the same way that Google Maps itself became load-bearing infrastructure for navigation. Once a road authority has watched the network move in real time for a quarter, the older procurement model, paying a third party for traffic data the agency never owned, starts to feel anachronistic. That shift will play out unevenly across markets and political contexts, but the direction is set.

The teams that move first will spend the next year learning how to ask better questions of the data. The teams that wait will spend the next year wondering whether to switch. We'd rather you were in the first group.