Mobilithek construction data: How digital road work zones become visible to navigation and traffic management

Digital road work data becomes useful to navigation and traffic management when a work zone is represented not only by a plan or permit but as structured, georeferenced, continuously maintained traffic data. Germany’s Mobilithek provides an important access layer for that information. Reliable location referencing, status updates, timing, and standardized formats such as DATEX II determine whether the data can actually be used.

Why is a traffic control plan not enough for digital traffic information?

For a German traffic safety contractor, a work zone begins as an operational project. There may be a traffic authority order, a traffic control plan, crews, vehicles, signs, barriers, temporary traffic signals, inspection runs, and a scheduled setup and removal window.

A navigation engine views the same project from a completely different angle.

It needs to know which section of the road network is affected, in which direction, whether one lane or the entire roadway is unavailable, when the restriction becomes effective, when it ends, and whether the configuration changes during different construction phases.

A PDF traffic control plan may contain all of this information visually. That does not make the information machine-readable.

The digital work zone therefore begins at the point where operational project information is converted into structured transportation data. The system has to represent not merely the existence of construction activity but its effect on the usable road network.

This becomes significant at national scale. Die Autobahn GmbH des Bundes (https://www.autobahn.de/), Germany’s federal motorway operator, reports responsibility for approximately 13,200 kilometers of Autobahn. Every relevant construction event has to be associated with the correct road segment, direction, and time period if downstream digital services are expected to process it correctly.

AI for Traffic Safety by KrambergAI

Prepare traffic safety requests more efficiently

KrambergAI helps traffic safety companies structure customer requests, deployment locations, plans, requirements, photos and coordination details with AI for more usable handovers.

Implemented pragmatically · Adapted to industry workflows · Made in Germany

What does the Mobilithek actually do between a work zone and a navigation service?

Mobilithek (https://mobilithek.info/) is Germany’s National Access Point for mobility data. Under Germany’s revised Intelligent Transport Systems legislation adopted in 2026, the Bundesanstalt für Straßen- und Verkehrswesen, BASt (https://www.bast.de/), performs the functions of the national body and operates the Mobilithek National Access Point for third-party use of mobility data. The Bundesministerium für Verkehr, BMV (https://www.bmv.de/), describes this role within Germany’s current ITS framework.

Mobilithek should not be understood as another consumer navigation app.

Its role sits farther upstream in the data chain. Road operators, transportation authorities, public agencies, and other data providers can publish or describe mobility data. Data users can discover those offerings and, depending on the delivery model, retrieve the actual data from Mobilithek services or a linked source.

For frequently changing information, Mobilithek also provides broker mechanisms and standardized technical interfaces between provider and consumer systems. Its technical documentation supports, among other approaches, the distribution of DATEX II payloads through defined interfaces.

A simplified chain may therefore look like this:

work zone management system → structured work zone record → DATEX II publication → Mobilithek → traffic service or traffic management center → navigation and traveler information.

The important part is that each arrow represents an integration boundary. A work zone can be perfectly documented for field operations and still fail downstream because one of those boundaries does not carry enough structured information.

How does a physical road work zone become a machine-readable traffic event?

Humans are good at interpreting context. A dispatcher may immediately understand a note such as “B 27 toward Tübingen, after the interchange, right lane closed.”

A machine cannot safely rely on that interpretation.

A reusable digital road work event needs structured location information, temporal validity, event classification, direction of travel, affected roadway elements, and an indication of the actual traffic restriction.

DATEX II provides a European data model for precisely this type of exchange. Current DATEX II documentation lists Version 3.7 and includes specific Recommended Reference Profiles for roadworks. Road work events are represented through the Situation model and can be distributed within a SituationPublication. A separate recommended profile addresses short-term road works.

The model can distinguish construction activities from maintenance work and can be combined with other data categories such as road closures, lane closures, and temporary traffic management measures.

That distinction is essential because “construction exists here” and “traffic is restricted here” are not the same statement.

A road crew working behind a barrier without affecting through traffic may have little relevance to routing. A full closure changes network connectivity. A temporary lane closure may influence travel time but leave the route available. A short moving maintenance operation may require a different treatment again.

Useful construction data therefore describes the traffic effect, not merely the construction project.

Which data elements matter most in real operations?

The difference between conventional project documentation and machine-readable traffic data becomes more apparent when the two are compared directly.

InformationConventional work orderNavigation and traffic management need
Locationroad name, plan, written descriptionmachine-readable road reference and travel direction
Scheduleplanned setup and removalactual temporal validity and updates
Traffic patterntraffic control planstructured effect on roadway, direction, and lanes
Work typeinternal project descriptionstandardized roadwork or event classification
Closurevisible in plan or narrativeexplicit lane or road closure status
Statusplanned, installed, finishedplanned, active, modified, or terminated
Updatesphone, email, dispatcher notemachine-processable update to connected systems
Validationemployee reviews projectoperational and automated plausibility checks

One of the most common implementation mistakes is to treat a latitude and longitude pair as sufficient location information.

It often is not.

Divided highways, frontage roads, parallel streets, ramps, interchanges, branches, and closely spaced roadways can all occupy almost the same geographic position. The downstream system still has to determine which directional carriageway and which network link is affected.

Time information produces a similar problem. A geometrically correct event that remains digitally active after crews have removed the traffic control can continue influencing traveler information. The reverse case is equally damaging: a work zone that becomes active before its digital record is updated provides little value for real-time traffic services during the period when drivers most need the information.

How are German Autobahn work zones connected to digital traffic services today?

Die Autobahn GmbH des Bundes (https://www.autobahn.de/) provides a useful real-world example.

Its public construction map receives information from the Management- und Informationssystem für Arbeitsstellen, or MIA, the federal motorway operator’s management and information system for road work zones. The operator states that information is continuously updated and that work zone information is also provided through Mobilithek.

This architecture demonstrates an important principle for digital traffic control.

The National Access Point does not have to be the operational system in which crews, construction phases, and traffic control measures are originally planned.

An internal specialist system may remain the authoritative operational source. Relevant parts of that information can then be transformed and transmitted to external consumers.

That same model can work for mid-sized traffic safety contractors. Their operational platform does not need to become a national traffic information network. It needs to store the relevant project information in a form that can be handed to the appropriate authority, road operator, or connected specialist system without reconstructing the project manually from documents every time.

The difference is substantial.

If the operational database already knows the roadway, work zone limits, direction, active phase, affected lanes, scheduled validity, actual status, and responsible project, an interface can reuse those fields. If the same information exists only inside PDFs, emails, messaging threads, and employee knowledge, every digital handoff becomes a new interpretation exercise.

Why does DATEX II matter so much for road work data?

NAPCORE (https://napcore.eu/) describes DATEX II as Europe’s electronic language for exchanging road traffic and traffic management information. Because the model is independent of the language and presentation channel used for the final service, the same information can eventually be rendered as a map symbol, spoken warning, traffic management input, or routing restriction.

The European regulatory framework reinforces this role.

Commission Delegated Regulation (EU) 2022/670 covers EU-wide real-time traffic information services and identifies road closures, lane closures, roadworks, and temporary traffic management measures as crucial data types describing the state of the road network. The regulation has applied since January 1, 2025 and contains a transitional geographic provision through the end of 2027 for certain data types outside the comprehensive TEN-T network, other motorways, and primary roads. It also references established standards such as DATEX II for interoperable data exchange.

A technical project should nevertheless avoid assuming that every live Mobilithek feed already uses the latest DATEX II version.

Current DATEX II documentation identifies Version 3.7 as the current model release. Existing production services may intentionally remain on older versions because every producer and consumer in the chain must remain interoperable. Toll Collect GmbH (https://www.toll-collect.de/), for example, describes one Mobilithek-delivered service that still uses DATEX II Version 2.3 or Version 2 for compatibility with existing services.

For implementation teams, “supports DATEX II” is therefore not a sufficient interface specification.

The actual version, profile, schema, exchange mechanism, identifiers, update strategy, and supported location-reference method all have to match the concrete integration.

When does a road work event actually become visible in navigation?

This is where expectations often diverge from the real data chain.

Publishing a work zone through Mobilithek does not guarantee that every navigation app or in-vehicle service will immediately display it.

The National Access Point makes the data discoverable and accessible. A service provider still has to choose the dataset, integrate the technical feed, parse the publication, map its location references into the provider’s own road graph, reconcile the event with other traffic sources, and determine how the event affects routing or traveler information.

Different providers may therefore produce different results from the same public road work data.

One service may combine public-sector work zone information with probe speeds, floating-car data, incident feeds, vehicle-generated observations, and proprietary traffic models. Another may use only selected data categories. Update intervals can also differ.

This is why data availability and end-user visibility are separate questions.

Traffic management centers add another layer. They may combine the work zone event with measured traffic volume, traffic speeds, queues, diversion strategies, tunnel operations, variable-message signs, or other network events.

At that point, the road work record is no longer simply a symbol on a map. It becomes one input into network-level traffic management.

Why does data quality matter more than publishing more records?

A large catalog of road work events is useful only when the records can be trusted operationally.

NAPCORE (https://napcore.eu/) maintains a quality repository for road traffic data and discusses quality frameworks addressing areas such as roadworks and road closures. The underlying objective is practical: service providers need data of sufficient quality to include it in services delivered to road users.

The scale of machine-to-machine road safety information illustrates why this matters. During the Data for Road Safety (https://www.dataforroadsafety.eu/) proof of concept, approximately 28 million messages reached the Dutch National Access Point. Vehicle-generated information contributed to five of eight safety-related traffic information categories considered in the project.

A medium-sized traffic control contractor will obviously generate far fewer records. The architectural lesson is still relevant.

Automation multiplies both good and bad data.

If a wrong direction, obsolete end time, or incorrect closure status is entered once and then propagated automatically through several connected systems, the digital process can spread that error far more efficiently than the old phone-and-email workflow ever could.

Data governance therefore belongs inside the operational workflow rather than being treated as a cleanup activity after publication.

What usually goes wrong when road work data is digitized?

The first recurring problem is location referencing.

A work zone is placed on a map and appears reasonable to the dispatcher, but the record does not identify the correct directional carriageway or network segment. After the downstream service matches the coordinates to its road graph, the event may attach to the opposite direction, a ramp, or a parallel roadway.

The next problem is lifecycle management.

A record is created with the original scheduled start and end dates. Field operations later move the setup, extend the project, finish earlier, or switch into another traffic phase. Nobody updates the external data record because the operational project team has already communicated the change by phone.

The public data then describes yesterday’s plan rather than today’s road.

A third problem is confusing approval with activation. A permitted work zone is not necessarily an active traffic restriction. Conversely, an active restriction may change after setup because field conditions require an approved operational adjustment. Systems therefore need separate concepts for planned, authorized, active, modified, and terminated states where the process requires them.

Multi-phase construction creates another failure mode.

A project may begin with a shoulder closure, later switch to a lane crossover, then add a nighttime full closure, and finally return to a reduced lane configuration. Representing the entire project as one static event loses the information that routing and traffic management actually need.

Finally, organizations frequently maintain the same facts in several places.

The dispatcher updates the ERP. The project manager changes a spreadsheet. The road authority maintains its work zone application. Someone emails a traffic management center. A crew communicates a revised setup in a messaging group.

All records refer to the same physical work zone, yet no system holds the complete current operational state.

What would an end-to-end workflow look like for a mid-sized traffic safety contractor?

A better process begins at project intake rather than at data publication.

The work location should be captured as more than an address or map pin. Depending on the road class and available official network data, the system may store road identifiers, network nodes, section information, stationing, direction of travel, relevant ramps or branches, and a spatial geometry for the affected section.

Planning then adds the traffic impact.

Which lanes are affected? Is there a full closure? Does the work zone move? Are different traffic patterns planned for different phases? What is the scheduled validity? Which parts of this information originate from the traffic authority order and which represent operational execution?

The traffic control plan remains essential. The structured record complements it.

When the project is authorized, its planning state can change without prematurely marking the traffic restriction active. When crews actually install the traffic control, the operational state can be activated. A later field change updates the same work zone object rather than disappearing into an email note.

When the last signs and devices are removed, the digital event must also end.

That final step deserves more attention than it usually receives. For the crew, the job may be complete once the truck leaves the site. For a digital traffic system, the job is not complete until the road network is no longer being represented as restricted.

The same structured event can also support internal operations. Dispatch can see active work zones. Control runs can be linked to the currently valid traffic phase. Customer service can report the correct status. Documentation can preserve the sequence of changes. Interfaces can publish selected fields without exposing unrelated internal project information.

That is why structured road work data is more than a compliance exercise. It becomes an operational data model for the work itself.

Why will digital work zones matter increasingly to Germany’s mid-market?

Traffic control operations have traditionally revolved around documents: orders, traffic authority permits, traffic control plans, material lists, inspection records, measurements, photos, and completion documentation.

Those documents remain necessary.

But a second layer is forming beside them. The work zone itself becomes a data object that can be exchanged between operational systems, public authorities, road operators, National Access Points, traffic management platforms, and service providers.

For contractors working with larger road operators, civil engineering companies, utilities, municipalities, and infrastructure owners, this changes the quality of digital handoffs expected over time.

A company that already manages location, direction, validity, affected lanes, closure status, traffic phase, and work zone lifecycle as structured fields is better positioned for these interfaces than a company that must repeatedly derive the same information from plans and correspondence.

The benefit also exists before any external interface is implemented.

The same dataset supports dispatching, resource planning, work zone inspections, project status reporting, customer communication, documentation, and later analytics. A road work object can connect the traffic authority order, the physical setup, the operating phase, the control history, and the external traffic information derived from the project.

This is the larger shift behind Mobilithek construction data: digital visibility does not start at the National Access Point. It starts with the way the work zone is represented inside the operational process.

Sources for the statistics used

Die Autobahn GmbH des Bundes – “Was wir tun”: approximately 13,200 kilometers of Autobahn
https://www.autobahn.de/ueber-uns/was-wir-tun

Data for Road Safety – SRTI Ecosystem: approximately 28 million messages in the proof of concept; vehicle data contributed to five of eight SRTI categories
https://www.dataforroadsafety.eu/ecosystem

Further reading

German Federal Ministry of Transport – Intelligent Transport Systems and Germany’s current legal framework
https://www.bmv.de/SharedDocs/DE/Artikel/StV/Digitalisierung-der-Mobilitaet/intelligente-verkehrssysteme-ivs.html

DATEX II – Recommended Reference Profile for roadworks
https://docs.datex2.eu/recommended-profiles/rrp/rtti/rtti-670/4-sn-c-roadworks/

European Commission – National Access Points for transportation data
https://transport.ec.europa.eu/transport-themes/smart-mobility/road/its-directive-and-action-plan/national-access-points_en

FAQ

What is Mobilithek?

Mobilithek is Germany’s National Access Point for mobility data. It provides infrastructure for discovering, describing, accessing, and exchanging mobility datasets from different providers. It is not a consumer navigation application itself. Road work information can be made available through the platform so that traffic services, public agencies, researchers, and other data users can process it downstream.

Are all German road work zones automatically published through Mobilithek?

No. Publication depends on the responsible road operator, public authority, applicable data obligations, specialist systems, and the technical data chain in use. On federal motorways, Die Autobahn GmbH des Bundes (https://www.autobahn.de/) states that information from its work zone management environment is also made available through Mobilithek. Other road networks can follow different organizational and technical processes.

Does publishing a work zone make it appear automatically in Google Maps or other navigation services?

No. Publication through a National Access Point gives data consumers a standardized path to discover or access information. A navigation provider still decides which feeds to ingest, how frequently to process them, how to match locations to its own road graph, and how an event influences routing. Different services can therefore display the same work zone differently.

What is DATEX II?

DATEX II is a European standard for structured exchange of road traffic and traffic management information. It enables systems operated by different organizations to exchange events such as roadworks, lane closures, road closures, incidents, and traffic management measures in machine-readable form. The standard includes dedicated roadwork profiles and is widely used within Europe’s intelligent transportation systems ecosystem.

Which work zone information matters most to navigation systems?

The most important information includes dependable location referencing, direction of travel, temporal validity, affected lanes, road closure status, and the actual impact on traffic. The operational status also matters. A syntactically valid message with the wrong direction or an obsolete end time can create poor routing behavior even though the technical interface itself is functioning exactly as designed.

Can short-term work zones also be represented digitally?

Yes. DATEX II includes a Recommended Reference Profile specifically addressing short-term road works. These operations create a demanding timing problem because setup, movement, and removal can happen quickly. If data collection and distribution take longer than the physical work zone remains in a given configuration, the downstream information can become obsolete before a navigation or traffic service processes it.

Why is direction of travel so important in construction data?

On divided roads, almost identical coordinates can refer to opposite directions of travel. Interchanges, ramps, collector-distributor roads, service roads, and parallel streets make the problem even more difficult. A point on a map therefore often does not provide enough information. Downstream systems need a road-network reference that allows the event to be assigned to the correct directional roadway and segment.

What should happen when a work zone ends early or is extended?

The digital event should be updated along with the physical operation. If crews remove the traffic control but the data remains active, traffic services may continue warning drivers or influencing routes. If the project is extended but the digital record expires, the restriction disappears too soon. Lifecycle updates should therefore cover setup, operational changes, extensions, and final removal.

Does a traffic safety contractor need to publish DATEX II feeds directly?

Not necessarily. In many workflows, the formal publication function belongs to a road operator, public authority, transportation management system, or another designated platform. A contractor still benefits from structured internal data. If location, direction, timing, lane impact, and status are already stored as reusable fields, required information can be transferred to external systems without repeatedly interpreting plans and emails.

How can AI support digital road work data?

AI can help extract candidate information from orders, permits, plans, and correspondence, suggest structured fields, detect conflicting entries, and flag missing information. Traffic-critical values should not depend solely on a language model. Location references, direction, validity, closures, and operational status need controlled source data, deterministic validation where appropriate, and human approval for decisions carrying safety or operational consequences.