Leo van den Berg WriterStay curious. Even in retirement.

Reflection · Data & ownership

The cycle of repetition can only be broken from within.

A reflection on data quality, ownership and the digital map as the foundation of Incident Management

A hand inserts a missing puzzle piece into a digital road map with a roundabout.
In this articleIntroductionThe digital map as a backboneThe missing piece: domain-specific and mission-critical attributesThe strength and vulnerability of fragmentationFrom maintenance to ownershipReflection and conclusion

Introduction

After more than forty years of involvement with Rijkswaterstaat, I see how strong the organisation is in execution — and also how persistent some structural patterns remain. The digital map is technically excellent, but the links between data, processes and ownership are often missing. The next step in data-driven traffic management requires a change in mindset rather than a new project.

After more than forty years working at and for Rijkswaterstaat, with recent decades focused mainly on Incident Management (IM) — one of Rijkswaterstaat's greatest successes in safety and traffic flow — I look back with mixed feelings. Not out of frustration, but with great appreciation for the commitment and professionalism of everyone who keeps the traffic control centres running every day — often despite ageing IT systems and an organisation that does not always provide the right support.

Over the years, I have written about this subject several times — about the crucial role of up-to-date data, dependence on the digital map, and the need to assign ownership and responsibility structurally. The same observation emerged each time: the desire to improve exists, but the coherence is missing.

That appreciation remains strong, because what people achieve every day is impressive. Operations continue, service levels are maintained, and Incident Management remains an example of how effective collaboration can be. At the same time, structural obstacles clearly prevent the next step in data-driven traffic management.

The digital map as a backbone

A traffic control centre's daily operations rest on several pillars — from expertise and collaboration to reliable technology and current information. But one element stands out: the digital map.

That map is more than a tool or a visualisation. It is the backbone of information provision in almost every process. It provides the visual context in which traffic operators make decisions, and underpins a growing number of IT systems managing traffic flows, assets and incidents.

What is often underestimated is the complexity of map management itself. The digital map is not a single file or an attractive picture like Google or Apple Maps. It is a continually evolving GIS environment (Geographic Information System) — an abstract representation of reality, in which thousands of objects and attributes must be managed and validated together. Each object — a carriageway, hectometre marker, link road, traffic sign or gantry — belongs to a network continually adapted to physical reality. Geometry is only part of the picture; the administrative and functional context matters just as much: who manages an object, what is its function, and who is responsible when it changes?

Maintaining that map carefully, including its topological consistency and data integrity, is a specialist discipline. And here it deserves to be said: Rijkswaterstaat's digital map is of exceptionally high substantive quality. That is not where the problem lies.

It can nevertheless be almost amusing to see heated meeting discussions about which provider displays the prettiest map, while the more fundamental question — who has the most current and reliable map data — receives little attention. The digital map is not a marketing product, but an operational truth on which decisions depend.

The missing piece: domain-specific and mission-critical attributes

The difficulty lies in connecting map data with the functional information used in operational systems. The map itself is solid, but some domain-specific and mission-critical attributes are missing — information that can only be properly defined by domain experts who understand the processes, responsibilities and operational reality.

A GIS map of Rotterdam with hectometre points and associated operational attributes.

This includes information such as:

  • which traffic control centre covers an incident's location,
  • which police control room is responsible for coordination,
  • whether a location is covered by the IM arrangements for recovery and incident handling,
  • and which authority or manager is responsible for a road section or object.

Timeliness is also increasingly important. When a new junction, tunnel or other asset enters service, the necessary information must already be available in the IT systems. As traffic switches to the new situation, traffic control centres, emergency control rooms and partner organisations must work with the same current map and contextual information. A delay of even days or weeks can lead to incorrect routing, slower incident handling or incorrect signals in other systems.

It is important to stress that this is not the map managers' responsibility — and certainly not that of the traffic control centres' end users. Map managers provide a consistent, high-quality foundation, and traffic operators work within the limits of the information available to them. The problem originates in the intermediate layer: where domain knowledge, process responsibility and information provision should meet, but in practice still too often pass one another by.

The base map comes from the Dutch National Road Database (NWB) — a robust and reliable source providing the geometric foundation — while road- and asset-specific attributes come from WEGGEG, with additional information from WKD, the road characteristics database.

Complexity arises precisely at these interfaces between maps, process data and management agreements: the systems are not fully aligned, and each team tries to solve a local problem within its own domain.

The result is that nobody owns the shared solution. This lack of coherence slows integration projects and fragments valuable knowledge across systems, departments and suppliers.

The strength and vulnerability of fragmentation

Anyone working in this domain every day will recognise the pattern:

  • “We are working on it.”
  • “We have been trying this for years.”
  • “That is not our responsibility.”
Book cover: 50 manieren om dwars te liggen (50 ways to be obstructive), by Frans Krips, published by Spectrum.

These phrases could come straight from the legendary booklet “50 manieren om dwars te liggen” — “50 ways to be obstructive”.

They are not excuses born of unwillingness, but of structural uncertainty about ownership. Responsibility for data, processes and systems is divided between departments, project teams and suppliers. Everyone manages their own piece, but nobody manages the whole.

Unless that end-to-end responsibility is explicitly assigned, the problems will keep recurring. A new application solves a local problem while creating dependencies elsewhere. A data field is added for one process, only to prove incompatible elsewhere. The cycle of repetition continues — not through unwillingness, but through a lack of coherence.

From maintenance to ownership

The solution is not more meeting structures or rewritten processes, but the willingness to take responsibility for the entire chain. That requires ownership at three levels:

  1. Data: someone must safeguard coherence between the map, attributes and process data.
  2. Process: process owners must explicitly define and manage their information structures.
  3. Organisation: management must ensure that responsibilities do not become blurred between departments.

In practice, this is difficult. Not only within Rijkswaterstaat, but also for its suppliers. Like me, they regularly encounter a bureaucratic wall — a structure in which decisions are postponed, responsibilities fade, and doing nothing can feel safer than getting something wrong.

Ownership goes beyond maintenance. It is the willingness to say:

“I am responsible for this information's accuracy, currency and usefulness — even when others interact with it.”

This is not simply a matter of defining another new project, but of changing the mindset: recognising that lasting quality only emerges when everyone feels responsible for the whole, rather than just their own part.

Reflection and conclusion

After more than forty years of involvement with Rijkswaterstaat, this chapter is almost closed for me — I will finish my work and retire at the end of this year. But my interest in the subject remains, because I see how much potential is still untapped.

The digital map is strong enough to support the future. What is needed is not a new generation of software, but a new generation of ownership: people taking responsibility for the connection between data, processes and decision-making — and recognising that information's value lies not only in its accuracy, but also in its timeliness.

Ultimately, that is what matters: the right data, at the right time, for the right decisions.

The cycle of repetition can only be broken from within — by taking responsibility rather than dividing it up.