Van 50 naar 30 km/u in Utrecht:
Waarom de digitale kaart niet direct werd aangepast
272 straten, vier navigatiesystemen en één ingangsdatum: 10 juli. Op papier een overzichtelijke opdracht. In de praktijk bleek het aanpassen van de digitale kaart complexer.
Op 10 juli 2026 verlaagde de gemeente Utrecht op 272 straten de maximumsnelheid van 50 naar 30 km/u. Niet alleen de verkeersborden moesten veranderen.
Ook Waze, Google Maps, TomTom en Apple Maps moesten de nieuwe snelheden verwerken. TripService leverde de wijzigingen ruim voor 10 juli aan bij de verschillende navigatieproviders. Toch stond op 10 juli niet alles goed. Hoe kan dit mis gaan?
De fysieke en digitale werkelijkheid veranderen niet tegelijkertijd
Permanente snelheidswijzigingen worden verwerkt via kaartupdates. Iedere provider heeft hiervoor eigen processen, verificaties en updatecycli. Die sluiten niet automatisch aan op de ingangsdatum van een verkeersbesluit.
Informatie ruim vooraf aanleveren betekent dus niet automatisch dat een wijziging op de gewenste datum live staat.
In de weken voor 10 juli konden we de gemeente Utrecht daarom niet garanderen dat alle 272 straten op tijd correct verwerkt zouden zijn. We kozen ervoor daar transparant over te zijn en de voortgang steeds intensiever te volgen.
Wat zagen we op 10 juli?
Op 10 juli reden we zelf door Utrecht om de wijzigingen in verschillende navigatiesystemen te controleren. Ook de gemeente voerde controles uit.
Daaruit bleek dat nog niet alle snelheden correct stonden. Apple Maps bevestigde als enige provider dat op 10 juli alle aangeleverde wijzigingen waren verwerkt. Bij Waze waren de wijzigingen op 11 juli volledig zichtbaar. TomTom volgde later. Vooral bij Google Maps bleven op verschillende straten afwijkingen zichtbaar.
Waarom was Google Maps lastiger?
Google gebruikt meerdere databronnen om wijzigingen te controleren en te verifiëren. Onze aangeleverde informatie is daarmee onderdeel van een breder verificatieproces. Toen uit onze controles en die van de gemeente bleek dat verschillende wegen nog niet correct stonden, hebben we dit rechtstreeks opgeschaald bij het Google-team in de Verenigde Staten. Daarna zijn aanvullende wijzigingen doorgevoerd.
Op 19 augustus hebben we opnieuw een controleronde uitgevoerd. De wegen die we tijdens deze ronde controleerden, stonden inmiddels correct in Google Maps.
Wat hebben we hiervan geleerd?
Dit project laat vooral zien dat aanleveren niet hetzelfde is als publiceren.
We nemen drie belangrijke lessen mee:
- Houd rekening met de processen van navigatieproviders. Een beleidsdatum en een kaartupdate lopen niet automatisch gelijk.
- Zorg voor goede en meerdere brondata. Denk aan verkeersbesluiten, geodata, foto’s van geplaatste verkeersborden en floating car data. Deze informatie kan helpen om wijzigingen te onderbouwen.
- Blijf controleren en escaleren. Onze rol stopt niet na het aanleveren van een bestand. Juist daarna moeten we volgen wat daadwerkelijk live staat en ingrijpen wanneer informatie niet klopt.
Digitale verkeersmaatregelen vragen om regie. We hadden natuurlijk liever gezien dat op 10 juli alle 272 straten direct bij iedere navigatieprovider correct waren aangepast. Dat was niet het geval.
Juist daarom is deze opdracht voor ons waardevol.
De fysieke werkelijkheid verandert zodra een wegbeheerder een maatregel invoert. De digitale werkelijkheid kent haar eigen processen. Om beide werelden goed op elkaar aan te laten sluiten, is meer nodig dan alleen het versturen van data. Je moet controleren, opvolgen en kunnen schakelen met navigatieproviders wanneer iets niet goed gaat.
Dat is voor ons de belangrijkste les uit Utrecht:
Digitaal verkeersmanagement gaat niet om het versturen van een dataset. Het gaat om regie houden totdat de digitale wereld aansluit op de fysieke werkelijkheid.
