In a previous article, I wrote about the four fundamental questions behind Incident Management: What, Where, When and Who.
Of these four, Where is often the most underestimated.
That surprises me. Not because location is simple, but because it has always been one of the most complex challenges in traffic management.
My involvement with ITS and traffic management architecture dates back to the 1990s through several European initiatives. Even then, one thing was already clear: effective traffic management and Incident Management are inseparable from location. Without understanding where something happens, it becomes difficult to understand what happened, who should respond and which measures are most effective.
When I started developing my first Incident Management system, UDLS, around 2010, one of the first challenges we tackled was localisation. Operators do not think in coordinates, database records or GIS objects. They think in motorway references, carriageways and hectometre locations.
A traffic operator entering:
A13 Li 12.0
is not searching for a location.
They already know exactly where the incident is.
For those unfamiliar with Dutch motorway references, A13 Li 12.0 identifies a specific location on the A13 motorway near the city of Delft. To a traffic operator, that single reference immediately provides operational context. It is far more than a position on a map.
The challenge is not for the operator to find the location. The challenge is for the system to understand it.
That is why I have always considered a motorway reference to be a spatial key rather than a piece of text.
A spatial key should provide direct access to an operational model of the road network. The system should immediately understand where the location is, which carriageway it belongs to, which cameras are nearby, which traffic measures may be affected and which response resources are most relevant.
On a quiet afternoon, an additional search step may seem insignificant.
During rush hour, severe weather or a major incident, it becomes something else entirely.
Every unnecessary interaction delays decision-making. Every delay postpones the deployment of resources. And every postponement extends the period during which road users and responders remain exposed to risk.
Fortunately, the Netherlands has had an extraordinary foundation for this for decades: the National Road Database (Nationaal Wegen Bestand, NWB).
The first version of the NWB became available in 1982. At the time, the road section database occupied compressed approximately 47 MB. That may sound insignificant today, but in the early 1980s it represented a remarkable achievement and was primarily used by specialists with access to dedicated software, hardware and expertise.
Long before online maps, web services and cloud platforms existed, the NWB already provided a digital representation of the Dutch road network.
More than four decades later, the situation has changed dramatically.
The NWB has evolved into a dataset with an exceptional level of detail and quality. Today, it forms one of the most important spatial foundations of the Dutch traffic domain. Traffic data, road authority information, assets, incidents, roadworks and traffic measures all become significantly more valuable when they can be related to a common and trusted representation of the road network.
In many ways, the NWB is no longer just a digital map. It has become part of the operational foundation of modern traffic management.
At the same time, powerful open-source GIS tools have made advanced spatial processing accessible to almost anyone. Tasks that once required specialised environments can now be performed on an ordinary workstation.
Which raises an interesting question.
Given the maturity of digital road network modelling, it is remarkable that some modern traffic management systems still reduce location to little more than a pair of GPS coordinates rather than treating it as part of a spatially aware operational model.
A pair of GPS coordinates tells us where something is.
A spatial model tells us what that location means.
There is a significant difference.
The challenge becomes even greater when traffic management extends beyond the motorway network.
Operators may refer to hectometre locations, but they may just as easily refer to tunnels, bridges, junctions, landmarks or street names used by municipal and regional road authorities. A traffic operator might report an incident at A13 Li 12.0, while another refers to the Beneluxtunnel, the van Brienenoord brug, Coolsingel or a specific motorway interchange.
All of these references may ultimately describe the same operational reality.
The real challenge is therefore not converting a motorway reference into a pair of GPS coordinates.
The real challenge is understanding that a motorway reference, a tunnel name, a bridge, a street name and a pair of GPS coordinates may all describe the same location from different operational perspectives.
That is why a location is much more than a set of coordinates.
A location has meaning.
It exists within a road network. It belongs to a carriageway. It may be part of a tunnel, a bridge, a junction, a municipal road network or a traffic management area. It is connected to cameras, traffic measures, assets, response resources and operational procedures.
A mature spatial service understands those relationships.
It does not simply answer the question:
"Where is this?"
It also answers:
"What does this location mean?"
One misconception appears regularly in discussions about modern traffic management systems.
Many platforms proudly demonstrate that they contain a Google Maps, OpenStreetMap or similar map component.
While useful, the presence of a map should not be confused with spatial understanding.
A map is primarily a visual representation.
Spatial understanding is something entirely different.
Displaying a location on a map is relatively easy.
Understanding how that location relates to the road network, nearby assets, traffic measures, operational responsibilities and neighbouring infrastructure is considerably more difficult.
A system may display a perfectly accurate map and still have very little understanding of the operational meaning of a location.
In the same way that a database user interface is not the database itself, a map is not the spatial model.
The real value lies underneath.
That capability is what I would call spatial understanding.
There is another reason why this matters.
Spatial understanding is not a feature that can simply be bolted onto a platform later.
When location is treated as a first-class concept from the beginning, it naturally becomes part of the architecture, the data model and the operational workflows.
When it is not, the consequences often surface years later.
Road networks evolve. New assets are added. Operational processes become more integrated. Data sources multiply. Cooperation between national, regional and municipal road authorities increases.
As these requirements grow, systems without a solid spatial foundation often struggle to keep pace.
Adding spatial understanding afterwards is rarely straightforward. It affects data models, interfaces, workflows, integrations and operational procedures. In many cases it becomes one of the most complex and expensive enhancements a platform can undertake.
That is why spatial understanding should not be viewed as a specialised GIS capability.
It is a fundamental architectural choice.
One that determines whether a platform can evolve with future operational needs or whether it will eventually be constrained by decisions made years earlier.
One observation from more than three decades in the traffic management domain continues to stand out.
Technologies change.
Databases change.
Programming languages change.
Architectures change.
Technology hypes come and go.
During that same period, one challenge has remained remarkably constant: understanding where an incident occurs and what that location means in an operational context.
The Dutch National Road Database is perhaps one of the best examples of this.
Throughout multiple generations of technology, the NWB remained relevant.
Not because the technology remained the same, but because the underlying problem remained the same.
Over more than four decades, the NWB has consistently provided a reliable and increasingly detailed representation of the Dutch road network. Its importance to traffic management, traveller information, asset management and Incident Management has only increased.
That longevity is not accidental.
It demonstrates that a solid spatial foundation often proves more durable than the technology stacks built on top of it.
The lesson seems surprisingly simple.
Over the past four decades, technologies have changed repeatedly. The need to understand the road network has not.
That is why I increasingly believe that the defining characteristic of a future-proof Incident Management platform is not the technology stack it is built on, but the quality of the spatial foundation underneath it.
A mature spatial service does more than locate an incident.
It understands what that location means.
Because in traffic operations, uncertainty is never free.
Every additional search, every ambiguity and every unnecessary interpretation costs time.
Time delays decisions. Delayed decisions delay response.
And delayed response ultimately affects the safety of both road users and emergency responders.
Rijkswaterstaat · Nevron · NDW · Politie Nederland · Vereniging Bergings- en Mobiliteitsspecialisten (VBM) · VNG (Vereniging van Nederlandse Gemeenten)