German State Road Data cannot be reliably combined by importing geometries into the same database and mapping similarly named columns. The difficult part lies in network models, location referencing, attribute semantics, and different maintenance processes. For temporary traffic control contractors, these details determine whether public geodata becomes a useful operational tool or merely another map layer.
Why does a nationwide road network look easier on a map than it is in software?
At first glance, the task seems straightforward. A federal road in North Rhine-Westphalia is represented by a line. A state road in Brandenburg is a line as well. Hamburg publishes streets and roads as line features, while Bavaria provides its classified road network through geospatial services.
Import everything, transform the coordinate systems, put the layers on one map, and the nationwide network appears to be finished.
That is where the difficult work starts.
A geometry only tells an application where a road runs. A temporary traffic control company frequently needs much more: the applicable road section, its network nodes, stationing direction, administrative context, and the reference terminology used by the road authority.
Germany’s non-local road network covers approximately 229,500 kilometers, but this is not maintained as one uniform operational dataset. The relevant information is distributed across different state systems, publication services, administrative responsibilities, and network models.
This distinction matters once a map becomes part of a real workflow. A prototype may look convincing because users can search for a road and see it highlighted. Once the same application has to support work-zone preparation, traffic control planning, inspections, dispatch, or documentation, street geometry and a road name are no longer sufficient.
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
Why can the same attribute name represent different information?
One of the most common integration mistakes is to map columns by name.
street_name becomes street_name.station becomes station.road_class becomes road_class.
The database accepts the transformation, but the resulting information can still be wrong.
A street name may be maintained directly in a road information system, imported from another administrative source, or used only as a supplementary label. A road class may represent legal classification, administrative responsibility, or a category designed for the published service. Even length can represent a geometrically calculated line length, a maintained section length, or a value connected to the state’s stationing system.
For operational users, these distinctions are not academic.
If a traffic control order refers to a specific classified road, section, network node, and station, an application must identify the same network object used by the authority. A spatially nearby line is not necessarily a valid substitute.
A production data model therefore has to preserve meaning, not just values.
How do the state road network models differ?
German road information databases are more than digital maps. They represent an operational road referencing system.
Hamburg explicitly describes its road and pathway dataset as a node-edge model maintained in the HH-SIB road information database. The published information includes from-node and to-node references, stationing, road keys, route numbers, street names, carriageway characteristics, lane information, and road type.
North Rhine-Westphalia publishes sections and branches, network nodes, zero points, and additional road-related attributes. Its data documentation includes section identifiers, section numbers, stationing information, and a network status field.
Brandenburg publishes classified roads together with network nodes or zero points, stationing information, and motorway kilometer references.
Bavaria describes the road network as the core of BAYSIS, its road information system. Information from multiple technical areas is referenced back to that network, with stationing primarily based on the German ASB road referencing system.
These concepts have common foundations, but their public data products are not identical.
| Operational dimension | Bavaria | Hamburg | North Rhine-Westphalia | Brandenburg |
|---|---|---|---|---|
| Network reference | ASB-oriented classified road network | HH-SIB node-edge model | Sections, branches, network nodes, and zero points | Classified network with network nodes, zero points, and stationing |
| Typical published information | Road inventory and referenced technical information | Street names, road keys, lane data, carriageway characteristics, and road type | Section IDs, station values, network status, and related attributes | Road classes, stationing, kilometer referencing, and cycling information |
| Publication structure | Road information system services | Broad road and pathway dataset | State-specific open-data product | Multiple technical collections and layers |
| Published update approach | daily | weekly | Network status maintained as an attribute | quarterly |
This is the integration problem in condensed form. Even when familiar terminology appears in several datasets, coverage, publication structure, semantics, and lifecycle can differ.
Why do ASB and OKSTRA not eliminate all of these differences?
Germany has important standards for road information, including the Anweisung Straßeninformationsbank, commonly known as ASB, and OKSTRA, the object catalog for road and transportation data.
These standards matter. Without them, integrating road information across state borders would be substantially harder.
But a common standard does not mean that every public WFS endpoint exposes the same information in the same way.
States can publish different subsets of their source systems. Some provide additional attributes. Certain object types may be available only through separate services. Operational databases have also evolved over long periods and can reflect state-specific requirements, software generations, and administrative practices.
A useful analogy comes from temporary traffic control itself. Two traffic control plans may follow the same regulatory framework and still describe completely different sites and operating conditions. The standard provides common concepts. It does not make every project identical.
Software therefore needs standards as an integration foundation, not as a substitute for integration.
Why is INSPIRE not enough for every operational use case?
INSPIRE serves a different purpose from dispatch, project management, or work-zone operations software.
The European geospatial infrastructure is designed to make public spatial information discoverable and interoperable across organizations and borders. Source datasets are transformed into standardized target models so that information can be exchanged more consistently.
That is extremely valuable for geospatial infrastructure.
Operational software can still need information that does not fit completely into the standardized representation.
Current GDI-DE guidance explicitly discusses situations in which an original geospatial dataset contains relevant information that cannot be fully transformed into the INSPIRE target schema. That does not indicate a failure of INSPIRE. It demonstrates the difference between an interoperability model and the complete operational source model.
If an application must identify an exact road section, stationing direction, or state-specific road reference, developers should therefore determine whether the required information exists in the INSPIRE representation or only in the original road information dataset.
For many specialist workflows, the original state data remains indispensable.
What usually goes wrong when state datasets are merged?
The first recurring problem is designing the unified database too early.
A universal table is created, and each state is forced into it. Attributes that do not fit are placed in generic text fields or discarded. The first import looks simple, but special cases accumulate as more states are added.
The second problem is geometry-first matching.
Two lines occupy almost the same location, so the import assumes that they represent the same road object. That may work for a background map. It is risky for a referenced road network. A branch, directional carriageway, interchange component, or newly divided section may occupy nearly the same space while having a different operational identity.
The third problem is overwriting history.
Network nodes change. Sections are split. Roads are reclassified. References can be reorganized. If every import simply replaces the previous state, older projects may lose the road reference that was valid when the job was planned.
For temporary traffic control contractors, this becomes important when reviewing an older permit, inspection record, traffic control plan, or completed work order. Historical operational records should remain understandable even after the underlying road network has changed.
Why are update cycles an operational issue rather than just an IT issue?
It is tempting to treat road data refreshes as a routine infrastructure task: run an import job, replace records, and invalidate a cache.
The source lifecycle makes that approach insufficient.
Bavaria publishes important BAYSIS WFS road data on a daily basis. Hamburg transfers its maintained HH-SIB road and pathway information into the available services weekly. Brandenburg states that its classified road network services are refreshed quarterly.
A nationwide product therefore does not have one moment at which “Germany is current.”
Instead, the application has to understand what current means for each source.
A successful import from yesterday does not necessarily mean the underlying authority changed its data yesterday. Likewise, a temporary source outage should not automatically make a previously validated local dataset unusable.
Production architecture should therefore store the source, retrieval event, source dataset status, validation outcome, and import version separately from the business object exposed to users.
What should a production-grade ingestion process look like?
A more durable architecture separates raw source data, normalized data, and the operational product model.
The original source should first be retained with as little modification as practical. That creates an audit trail of what the authority actually published. Transformation comes afterward.
During normalization, road classes can be mapped into a shared internal vocabulary, network-node identifiers can be separated from section IDs, stationing directions can be normalized, and state-specific attributes can be assigned to defined domain fields.
Information that does not fit the common model should not simply disappear.
Quality assurance then has to inspect more than geometries. It should evaluate network relationships. Does the referenced node exist? Do the section endpoints make sense? Did an identifier change? Was a previously available object really removed, or is the latest source delivery incomplete?
Only a validated dataset should feed the production API and user interface.
This intermediate engineering layer is what converts public open data into an operational data product.
Why does versioning matter so much for network nodes and road sections?
A work zone does not exist on an abstract polyline. It exists on a road network that was valid at a particular point in time.
When a project is created, the system should therefore retain the network version used for its road reference. This matters especially when network nodes, section IDs, or station values appear in customer documents or communications with public authorities.
If old source records are overwritten, a project may later resolve to a different section or a stored station value may no longer correspond to the current network configuration.
A better design separates internal identity from source validity.
An imported road object receives a persistent internal identity, while changes from the public source are versioned. Current projects can use the latest validated network, while completed projects can still reference the network state under which they were prepared.
That is far more useful for documentation and auditability than a database containing only the newest snapshot.
How does this normalization help temporary traffic control contractors?
The value becomes visible in the workflow rather than the database.
A dispatcher should not have to know which WFS feature type supplied a road section. The dispatcher needs to find the road, select the appropriate network reference, and pass that information into project preparation without manually translating between systems.
During planning, an official station value can be more useful than an arbitrary map pin. When coordinating with a road authority, section and network-node references can reduce ambiguity in the operational process. During later inspections, the company should still be able to determine the exact location that the original work order referred to.
The Vextario Network Node Navigator applies this principle by treating road references as part of the underlying road network rather than as isolated coordinates.
The operational benefit is straightforward: less manual translation between map, work order, authority documentation, dispatch, and field operations.
Why should software preserve state-specific information?
A common internal model is useful. A lowest-common-denominator model is not.
The platform needs shared concepts such as road, network object, section, station, direction, geometry, administrative context, and validity. At the same time, it must retain state-specific attributes where those attributes carry operational meaning.
This distinction is important.
A good normalization layer does not claim that every German state publishes the same road data. It identifies which concepts are equivalent, which can be transformed, and which need to remain source-specific.
That approach is especially relevant for mid-sized companies. Employees can work with one consistent application while the platform absorbs the complexity of the different public data sources.
Vextario extends the same approach across a broader product portfolio for temporary traffic control companies, where specialized data services can become reusable components of operational workflows rather than isolated map tools.
When does a map integration become a production road data product?
Not when the first WFS request succeeds.
A production road data product exists when the origin, meaning, network reference, validity, and history of the relevant objects can be reconstructed. That requires source versioning, normalization, quality assurance, historical tracking, and controlled publication.
Most of this engineering should remain invisible to operational users.
A project manager or dispatcher should not have to understand why one state models a particular road reference differently from another. The platform should handle that complexity before the data reaches the workflow.
Only then can distributed public road information support work preparation, dispatch, location referencing, inspections, project documentation, and other operational processes across state borders.
FAQ
Can all German state road datasets simply be imported into PostGIS?
Technically, yes. A common coordinate system and spatial database solve storage and geometry handling, but they do not harmonize section logic, stationing, attribute semantics, or validity periods. That may be enough for visualization. Operational software also needs to understand what each object represents, how it relates to the road network, and which source definition applies.
Are network nodes structured the same way in every German state?
The general concept of network nodes and stationing is broadly established in German road administration, but published state datasets are not identical. Identifiers, available objects, attributes, geometries, and supplementary information can vary. A production application should therefore preserve source provenance and interpret each state’s network model rather than assuming that similarly named fields are automatically equivalent.
Why is a street name not enough to reference a work zone?
Street names are useful for people but often insufficient as operational identifiers. Names can be duplicated, missing, or changed. Classified roads may additionally require road designation, section, network node, station, and direction. For temporary traffic control projects, these references can describe a location more reproducibly than a street name and map marker alone, especially when coordinating with road authorities.
What is the difference between stationing and GPS coordinates?
GPS coordinates describe a location in geographic space. Stationing describes a location within a defined road section and therefore within an administrative road referencing system. That relationship can be important for construction, maintenance, and permit workflows. If the network changes, the application must also understand which network version the station value originally referred to rather than treating it as a generic distance.
Can INSPIRE data eliminate the differences between state road datasets?
INSPIRE significantly improves interoperability, but it does not necessarily reproduce every detail of the original state road information system. Some source information may remain outside the target schema. Standardized INSPIRE datasets are highly useful for cross-organizational use, while applications that depend on sections, stationing, or specialized road attributes should also evaluate the original state-level source data.
Why should road data imports retain historical versions?
Road networks change over time. Sections may be divided, identifiers replaced, roads reclassified, and network references reorganized. If every new import overwrites the previous records, historical projects can lose their original reference. Versioning allows a platform to use the latest validated road network while still reconstructing the network state associated with an older work order, permit, inspection, or project record.
How can software determine whether road sections from different sources are identical?
Geometry alone is not enough. Matching should also consider road designation, network nodes, section identifiers, stationing, direction, administrative attributes, and temporal validity. Network changes can cause geometrically similar features to represent different operational objects. A robust integration process therefore combines multiple domain attributes and sends uncertain matches for review instead of automatically merging every spatially overlapping line.
Which road attributes matter most to temporary traffic control companies?
Useful information commonly includes road geometry, classification, road designation, network nodes, section or branch identifiers, stationing, direction, and administrative context. Additional attributes may matter depending on the workflow. The key requirement is that the data can move reliably from location search into work preparation, authority communication, dispatch, field operations, inspections, and documentation without repeated manual interpretation.
How frequently should a production application refresh state road data?
There is no single appropriate refresh interval for every source. The ingestion schedule should reflect the authority’s actual publication process while also tolerating service outages. More important than polling as frequently as possible is recording the source dataset status, successful retrieval time, validation result, and rule for promoting a newly imported dataset into production use.
What metadata should a SaaS platform retain for German state road data?
In addition to normalized road attributes, the platform should retain provenance, source identifiers, import versions, validity information, and the relevant source-data status. State-specific attributes should remain available when they carry domain meaning. This allows the data model to evolve as public sources change without forcing the platform to reinterpret existing project references or discard information that does not fit the shared core model.
Sources for the figures and update cycles used in this article
- German Federal Statistical Office – Transport infrastructure data: https://www.destatis.de/EN/Themes/Economic-Sectors-Enterprises/Transport/Enterprises-Infrastructure-Vehicle-Stock/Tables/transport-infrastructure.html
- Bavarian Road Information System – Web Feature Services: https://www.baysis.bayern.de/internet/geodaten_dienste/wfs/index.html
- Hamburg Transparency Portal – HH-SIB road and pathway network: https://suche.transparenz.hamburg.de/dataset/strassen-und-wegenetz-hamburg-hh-sib34
- GovData – Brandenburg stationing dataset: https://data.gov.de/suche/daten/klassifiziertes-strassennetz-brandenburg-stationierung8e72f
Further reading
- OKSTRA – current schema documentation: https://okstra.bast.de/schema.html
- Open Data NRW – road network data documentation: https://www.opengeodata.nrw.de/produkte/transport_verkehr/strassennetz/datenbeschreibung_strassennetz.pdf
- GDI-DE – recommendations for providing geospatial data for INSPIRE: https://www.gdi-de.org/download/GDI-DE_Handlungsempfehlung_Bereitstellung_Geodaten_fuer_INSPIRE.pdf
