From 50 to 30 km/h in Utrecht:
Why the digital map Didn’t Change Immediately
272 streets, four navigation systems, and one implementation date: July 10. On paper, it seemed like a straightforward task. In practice, however, updating the digital map proved to be more complex.
On July 10, 2026, the city of Utrecht lowered the speed limit on 272 streets from 50 to 30 km/h. It wasn’t just the traffic signs that had to be changed; Waze, Google Maps, TomTom, and Apple Maps also had to update their data to reflect the new speed limits. TripService submitted the changes to the various navigation providers well before July 10. Still, not everything was going well on July 10. How could this go wrong?
Physical and digital reality do not change at the same time
Permanent speed limit changes are implemented through map updates. Each provider has its own processes, verification procedures, and update cycles for this. These do not automatically align with the effective date of a traffic regulation.
Submitting information well in advance does not automatically mean that a change will go live on the desired date.
In the weeks leading up to July 10, we were therefore unable to guarantee to the City of Utrecht that all 272 streets would be processed correctly and on time. We chose to be transparent about this and to monitor progress more closely as time went on.
What did we see on July 10?
On July 10, we drove through Utrecht ourselves to check the changes in various navigation systems. The city also conducted inspections.
This revealed that not all speed limits had been set correctly yet. Apple Maps was the only provider to confirm that all submitted changes had been processed by July 10. On Waze, the changes were fully visible by July 11. TomTom followed later. Discrepancies remained visible on various streets, particularly on Google Maps.
Why was Google Maps more difficult?
Google uses multiple data sources to check and verify changes. The information we provided is therefore part of a broader verification process. When our checks and those of the municipality revealed that several roads were not yet listed correctly, we escalated the issue directly to the Google team in the United States. Additional changes were then implemented.
On August 19, we conducted another inspection round. The roads we checked during this round were now correctly listed on Google Maps.
What have we learned from this?
Above all, this project shows that submitting content is not the same as publishing it. We’ve learned three important lessons:
- Take into account the processes used by navigation providers. A policy date and a map update do not automatically coincide.
- Make sure you have high-quality data from multiple sources. Examples include traffic regulations, geodata, photos of installed traffic signs, and floating car data. This information can help support proposed changes.
- Continue to monitor and escalate. Our role doesn’t end once a file has been delivered. It is precisely after that that we must monitor what is actually live and take action when information is incorrect.
Digital traffic measures require coordination. Of course, we would have preferred that all 272 streets be correctly updated immediately by every navigation provider on July 10. That was not the case.
That is precisely why this assignment is valuable to us.
Physical reality changes as soon as a road authority implements a measure. Digital reality has its own processes. To ensure that these two worlds align properly, more is needed than simply sending data. You have to monitor, follow up, and be able to coordinate with navigation providers when something goes wrong.
For us, that is the most important lesson from Utrecht:
Digital traffic management isn’t just about sending a dataset. It’s about maintaining control until the digital world aligns with physical reality.
