Netzknotendaten versionieren: Historie statt Überschreiben

Netzknotendaten müssen versioniert werden, weil sich Straßenordnungssysteme durch neue Kreuzungen, Umbauten, verschobene Netzknoten und geänderte Abschnitte laufend verändern. Wird nur der aktuelle Stand gespeichert, verlieren historische Aufträge ihren damaligen Netzbezug. Eine zeitbezogene Versionierung bewahrt Stationierung, Abschnittsreferenz und Dokumentation so, wie sie zum Zeitpunkt des Einsatzes galten.

Warum verändert sich ein Netzknoten überhaupt?

Ein Netzknoten ist kein dauerhaft festgeschriebener Punkt, der nach seiner erstmaligen Erfassung für immer unverändert bestehen bleibt. Das Straßennetz wird gebaut, umgebaut, abgestuft, aufgestuft, neu trassiert und an geänderte Verkehrsströme angepasst. Aus einer gewöhnlichen Kreuzung kann ein Kreisverkehr werden. Eine neue Anschlussstelle verändert die Netzstruktur. Ein bestehender Abschnitt kann geteilt werden, weil ein zusätzlicher Knoten entsteht. Umgekehrt können Netzelemente entfallen oder zusammengeführt werden.

Für einen Verkehrssicherer ist das mehr als eine kartografische Änderung. Ein Abschnitt zwischen zwei Netzknoten bildet häufig den fachlichen Bezug für Arbeitsstellen, Verkehrszeichenpläne, verkehrsrechtliche Anordnungen, Kontrollfahrten, Aufmaß, Dokumentation und Abrechnung. Ändert sich dieser Abschnitt, betrifft das damit potentiell jeden Datensatz, der auf ihn verweist.

Dass Netzänderungen als eigene fachliche Vorgänge behandelt werden müssen, ist auch im deutschen Straßenwesen angelegt. Das OKSTRA-Netzänderungsprotokoll beschreibt unter anderem das Anlegen, Verschieben und Löschen von Netzknoten sowie Änderungen an Abschnitten und Ästen. Dazu gehören auch Teilungen, Zusammenführungen und Änderungen der Abschnittslänge.

Die entscheidende Konsequenz lautet deshalb: Wer Netzknotendaten versionieren will, darf einen neuen Datenstand nicht einfach über den vorherigen schreiben.

Warum wird einfaches Überschreiben bei historischen Aufträgen zum Problem?

Nehmen wir einen typischen Fall aus der Verkehrssicherung. Eine Arbeitsstelle wurde vor längerer Zeit über einen bestimmten Abschnitt und eine Stationierung beschrieben. Dazu existieren die Anordnung, ein Verkehrszeichenplan, Kontrollnachweise, Fotos, Aufmaße und möglicherweise spätere Nachträge.

Danach wird der betreffende Knotenpunkt umgebaut. Der bisherige Abschnitt wird aufgeteilt und erhält Nachfolger. Vielleicht verändert sich zusätzlich die Stationierungslogik.

Wird in der Datenbank ausschließlich der neue Netzstand gehalten, entsteht eine merkwürdige Situation: Der historische Auftrag enthält formal richtige Angaben aus seiner Entstehungszeit, die aktuelle Anwendung kann diese Angaben aber nicht mehr richtig auflösen. Im ungünstigsten Fall wird die alte Station gegen einen heutigen Abschnitt gerechnet und dadurch an einer anderen Stelle interpretiert.

Eine GPS-Koordinate kann das nur teilweise auffangen. Sie zeigt, wo ein Punkt geometrisch lag. Sie sagt jedoch nicht, auf welchem damaligen Abschnitt der Auftrag geführt wurde, in welcher Stationierungsrichtung gearbeitet wurde oder welcher heutige Abschnitt aus dem historischen Abschnitt hervorgegangen ist.

Bei einer kurzen Baustelle fällt das möglicherweise nie auf. Bei wiederkehrenden Maßnahmen, Gewährleistungsfragen, Nachträgen, Schadenfällen oder späteren Prüfungen wird daraus schnell ein Datenproblem.

Was unterscheidet einen überschriebenen Datenbestand von einem versionierten Netz?

Die Tabelle zeigt auch, warum Versionierung keine technische Zusatzfunktion für Geodatenexperten ist. Sie beeinflusst unmittelbar, ob ein Auftrag Jahre später noch mit denselben fachlichen Grundlagen angezeigt werden kann.

Welche Zeitlogik braucht ein produktives Netzdatenmodell?

Eine belastbare Historie benötigt mindestens zwei unterschiedliche Zeitinformationen.

Zum einen braucht ein Netzelement einen fachlichen Gültigkeitszeitraum. Er beschreibt, wann ein Netzknoten, Abschnitt oder eine bestimmte Netzzuordnung tatsächlich gegolten hat.

Zum anderen sollte gespeichert werden, wann der Datensatz technisch übernommen, geprüft oder veröffentlicht wurde. Beides ist nicht automatisch identisch. Eine Straßenverwaltung kann eine Änderung zu einem bestimmten Zeitpunkt wirksam werden lassen, während die Veröffentlichung im Geodatendienst später erfolgt.

In einer Datenbank bedeutet das beispielsweise, dass ein bestehender Abschnitt bei einer fachlichen Änderung nicht aktualisiert und damit überschrieben wird. Sein Gültigkeitsende wird gesetzt. Der neue Zustand erhält einen eigenen Datensatz mit neuem Gültigkeitsbeginn. Über Vorgänger-Nachfolger-Beziehungen bleibt dokumentiert, wie sich die Struktur entwickelt hat.

Wichtig ist dabei ein Grundsatz, der in der Praxis gern übergangen wird: Liefert die Quelle kein belastbares fachliches Wirksamkeitsdatum, sollte das System keines erfinden. Dann werden Veröffentlichungsdatum, Importzeitpunkt und tatsächliche fachliche Gültigkeit getrennt behandelt.

Wie sollten Netzänderungen technisch verarbeitet werden?

Ein produktiver Import beginnt nicht mit DELETE und anschließendem Neuimport. Er beginnt mit einem Vergleich.

Der neue amtliche Datenstand wird zunächst gegen den bisher produktiven Bestand gestellt. Dabei geht es nicht nur um die Frage, welche Datensätze hinzugekommen oder verschwunden sind. Relevanter ist, was sich fachlich verändert hat.

Ein Netzknoten kann dieselbe Kennung besitzen und dennoch eine neue Position erhalten. Ein Abschnitt kann geometrisch verändert worden sein, obwohl Anfangs- und Endknoten gleich geblieben sind. Ein neuer Netzknoten kann einen bestehenden Abschnitt teilen. Eine Straßenbezeichnung kann wechseln, während die physische Verbindung bestehen bleibt.

Das OKSTRA-Netzänderungsprotokoll geht genau von solchen Vorgängen aus. Es unterscheidet verschiedene Operationen für Netzknoten, Nullpunkte, Abschnitte, Äste und Straßen, damit auf das Straßennetz referenzierte Fachdaten auf Netzänderungen reagieren können.

Für produktive Anwendungen bedeutet das: Änderungen müssen zunächst klassifiziert werden. Erst anschließend wird entschieden, ob lediglich ein Attribut fortgeschrieben, ein neuer Netzstand erzeugt, eine Vorgänger-Nachfolger-Beziehung angelegt oder eine manuelle Prüfung notwendig wird.

Warum reicht die Geometrie für historische Netzreferenzen nicht aus?

Ein Linienzug auf der Karte und ein fachlicher Straßenabschnitt sind nicht dasselbe.

Die Geometrie beschreibt den räumlichen Verlauf. Das Ordnungssystem beschreibt zusätzlich Beziehungen: Netzknoten, Nullpunkte, Abschnitte, Äste, Stationierungsrichtung, Straßenbezug und weitere Eigenschaften. Gerade diese Beziehungen machen einen Straßenabschnitt für Fachprozesse nutzbar.

Das OKSTRA-Straßennetzmodell trennt deshalb die Fachinformationen von den eigentlichen Elementen des Netzmodells. Referenzierte Fachdaten müssen dadurch nicht automatisch verändert werden, nur weil das zugrunde liegende Ordnungssystem fortgeschrieben wird.

Für Verkehrssicherungsunternehmen ist dieser Unterschied praktisch relevant. Ein Kontrollbericht kann weiterhin exakt zu dem Auftrag gehören, für den er erzeugt wurde, selbst wenn die Straßenverwaltung den zugrunde liegenden Abschnitt später anders organisiert.

Genau hier liegt der Mehrwert historisierter Netzdaten: Nicht die Vergangenheit wird an die heutige Datenstruktur angepasst, sondern der frühere Zusammenhang bleibt erhalten.

Wie unterschiedlich schnell werden amtliche Straßendaten fortgeführt?

Es gibt keinen deutschlandweit identischen Aktualisierungsrhythmus. Schon amtliche Geodatenangebote zeigen, wie unterschiedlich Fortführung organisiert sein kann.

Beim Straßen- und Wegenetz der Hamburger Straßeninformationsbank wird der Bestand kontinuierlich gepflegt und wöchentlich aus der HH-SIB in die verfügbaren Datendienste übertragen.

Beim ATKIS-Basis-DLM der Landesvermessung und Geobasisinformation Brandenburg werden wichtige Objekt- und Attributarten im Rahmen der Spitzenaktualisierung innerhalb von drei bis zwölf Monaten überprüft und fortgeführt. Für die vollständige Grundaktualisierung des Modells wird ein Turnus von drei Jahren angegeben.

Diese Fristen sind keine allgemeingültigen Vorgaben für Netzknotendaten. Sie zeigen aber das eigentliche Problem: Datenstände verschiedener Quellen können gleichzeitig veröffentlicht werden und trotzdem unterschiedliche fachliche Bezugszeitpunkte besitzen.

Wer Daten mehrerer Länder oder Behörden zusammenführt, muss deshalb die jeweilige Quelle und deren Datenstand mitführen. Ein gemeinsames Importdatum allein reicht nicht.

Was läuft bei der Versionierung in der Praxis häufig falsch?

Ein typischer Fehler ist der vollständige Austausch einer Tabelle bei jedem neuen Import. Für eine einfache Kartenanwendung kann dieses Verfahren ausreichen. Für ein operatives System mit historischen Aufträgen ist es riskant.

Ein zweiter Fehler besteht darin, eine externe Netzknoten- oder Abschnittskennung unmittelbar als dauerhafte interne Objektidentität zu behandeln. Amtliche Kennungen sind fachlich wichtig, müssen aber nicht über jede Netzänderung hinweg dieselbe Bedeutung behalten.

Problematisch ist außerdem die automatische Umschreibung historischer Vorgänge. Wenn aus einem früheren Abschnitt zwei neue Abschnitte entstehen, darf ein System nicht allein aufgrund räumlicher Nähe entscheiden, welcher neue Abschnitt der historische Auftrag „jetzt“ sein soll. Der Auftrag war auf dem damaligen Abschnitt ausgeführt worden. Genau dieser Zustand muss erhalten bleiben.

Ebenso ungünstig ist es, bei jedem Import sämtliche Stationierungen neu zu berechnen, ohne die frühere Berechnungsgrundlage aufzubewahren. Eine Station ist kein isolierter Zahlenwert. Ihre Bedeutung entsteht erst durch den zugehörigen Abschnitt und dessen damalige Ausprägung.

Wie sieht das bei einem realen Auftrag eines Verkehrssicherers aus?

Beim Anlegen eines neuen Auftrags recherchiert die Disposition zunächst mit dem aktuellen Straßennetz. Der passende Netzknoten, Abschnitt und die Stationierung werden übernommen.

Entscheidend ist dann, dass der Auftrag nicht nur die sichtbare Abschnittskennung speichert. Er sollte zusätzlich mit dem zugrunde liegenden Netzstand und der Datenquelle verbunden werden.

Ein Jahr später kann sich das Netz geändert haben. Öffnet ein Mitarbeiter den abgeschlossenen Auftrag, lädt die Anwendung trotzdem den für diesen Vorgang relevanten historischen Stand. Parallel kann sie anzeigen, welcher Abschnitt heute an dieser Stelle geführt wird.

Damit lassen sich zwei Anforderungen miteinander verbinden, die im Tagesgeschäft häufig durcheinandergeraten: Für neue Einsätze wird mit den neuesten verfügbaren Netzdaten gearbeitet. Für abgeschlossene Einsätze bleibt die damalige Dokumentationsgrundlage erhalten.

Für die operative Recherche aktueller Netzbezüge bietet sich der Netzknoten Navigator an. Wenn der Netzbezug anschließend in Auftrag, Disposition, Dokumentation und weitere Abläufe übernommen werden soll, setzt das Vextario Produktportfolio für Verkehrssicherungsunternehmen genau an dieser Verbindung zwischen Fachdatum und operativem Prozess an.

Warum ist Versionierung auch für mittelständische Betriebe wirtschaftlich relevant?

Historisierung klingt zunächst nach zusätzlichem Datenbankaufwand. Tatsächlich verschiebt sie Aufwand von späterer Rekonstruktion in eine systematische Datenhaltung.

Ohne Historie muss im Streitfall möglicherweise ermittelt werden, welche Abschnittskennung damals existierte, wie die Stationierung verlief und warum die heutige Karte nicht mehr zur alten Dokumentation passt. Häufig müssen dafür alte Unterlagen, Kartenstände oder Behördeninformationen zusammengesucht werden.

Mit versionierten Netzdaten wird diese Information Bestandteil des Auftrags.

Das ist besonders interessant für mittelständische Verkehrssicherungsunternehmen, deren Projekte nicht isoliert betrachtet werden. Verkehrsrechtliche Anordnung, Verkehrszeichenplan, Einrichtung, Kontrolle, Änderung, Rückbau und Abrechnung können sich über längere Zeiträume erstrecken. Gleichzeitig entwickelt sich das amtliche Straßennetz weiter.

Eine gute Datenarchitektur akzeptiert deshalb, dass die Gegenwart fortgeschrieben wird, ohne die Vergangenheit umzuschreiben.

Welche Quellen stützen die verwendeten Kennzahlen?

Quellenangabe

Straßen- und Wegenetz Hamburg – Hamburger Straßeninformationsbank, MetaVer
Kennzahl: kontinuierliche Pflege und wöchentliche Übertragung aus der HH-SIB in die verfügbaren Datendienste.
https://metaver.de/trefferanzeige?docuuid=5262159C-D358-11D5-88C8-000102DCCF41

Basis-DLM – Landesvermessung und Geobasisinformation Brandenburg
Kennzahlen: Spitzenaktualisierung bestimmter Objekt- und Attributarten innerhalb von drei bis zwölf Monaten; Grundaktualisierung des gesamten DLM im Dreijahresturnus.
https://geobasis-bb.de/lgb/de/geodaten/landschaftsmodelle/basis-dlm/~mais2redc124752de

Welche „Interessante Links“ vertiefen das Thema?

Interessante Links

OKSTRA – Vorschlag zur Erweiterung des Netzänderungsprotokolls
Technische Beschreibung von Änderungen an Netzknoten, Nullpunkten, Abschnitten, Ästen und Straßen.
https://www.okstra.de/docs/n-dokumente/n0171.pdf

OKSTRA – Fachmodell Straßennetz
Dokumentation des Netzknoten-Stationierungssystems und der Referenzierung von Fachdaten auf das Straßennetz.
https://okstra-bpb.bast.de/docs/2015/html/EARoot/EA26.htm

Europäische Kommission – INSPIRE Data Specification on Transport Networks
Technische Spezifikation für interoperable Verkehrsnetzdaten und Road Transport Networks.
https://knowledge-base.inspire.ec.europa.eu/publications/inspire-data-specification-transport-networks-technical-guidelines_en

FAQ

Warum reicht es nicht, immer nur aktuelle Netzknotendaten zu speichern?

Weil ein aktueller Netzstand nur die heutige Situation beschreibt. Wird ein Netzknoten verschoben, ein Abschnitt geteilt oder eine Kreuzung umgebaut, kann ein älterer Auftrag auf Referenzen zeigen, die heute anders aussehen oder nicht mehr existieren. Versionierung erhält den damaligen Zusammenhang zwischen Netzknoten, Abschnitt, Stationierung und Auftrag und macht spätere Prüfungen wesentlich verlässlicher.

Was passiert mit historischen Aufträgen nach einer Netzänderung?

Historische Aufträge sollten an dem Netzstand bleiben, der zum Zeitpunkt der Ausführung gültig war. Der Auftrag wird also nicht nachträglich auf die heutige Abschnittsstruktur umgeschrieben. Zusätzlich kann das System eine Beziehung zum aktuellen Netzstand führen, damit Nutzer sehen, welches heutige Netzelement dem früheren Bezug entspricht oder ob eine automatische Zuordnung nicht sinnvoll ist.

Muss jede kleine Geometrieänderung eine neue Version erzeugen?

Nicht zwingend. Entscheidend ist, ob sich eine Änderung fachlich auf Referenzen, Stationierung, Abschnittsidentität oder die Interpretation bestehender Aufträge auswirkt. Eine rein kartografische Korrektur kann anders behandelt werden als eine Abschnittsteilung oder ein verschobener Nullpunkt. Dafür braucht es definierte Änderungsarten und Regeln, wann ein neuer fachlicher Netzstand entsteht.

Wie werden Netzknoten und Abschnitte sinnvoll versioniert?

Bewährt ist eine zeitbezogene Historie mit stabiler interner Identität, fachlicher Kennung und Gültigkeitszeitraum. Alte Datensätze werden nicht überschrieben, sondern beendet; der Nachfolger erhält einen neuen Gültigkeitsbeginn. Für Teilungen, Zusammenführungen, Umbenennungen oder Positionsänderungen werden Vorgänger-Nachfolger-Beziehungen gespeichert. So bleibt sowohl der frühere Zustand als auch die Entwicklung des Netzes auswertbar.

Was ist der Unterschied zwischen Versionierung und Backup?

Ein Backup schützt vor technischem Datenverlust und dient vor allem der Wiederherstellung eines Systems. Versionierung ist dagegen Bestandteil des fachlichen Datenmodells. Sie erlaubt reguläre Abfragen wie: Welcher Netzknoten, Abschnitt und welche Stationierung galten beim damaligen Auftrag? Ein Backup kann diese Frage nur umständlich beantworten und eignet sich nicht als produktiver Mechanismus für historische Netzbezüge.

Wie geht man mit geänderten Netzknotennummern um?

Eine geänderte Netzknotennummer sollte nicht dazu führen, dass der alte Bezug aus der Datenbank verschwindet. Sinnvoll ist, alte und neue Kennung mit ihren jeweiligen Gültigkeitszeiträumen zu speichern und zusätzlich ihre Beziehung zu dokumentieren. Dadurch bleiben alte Auftragsunterlagen auffindbar, während neue Vorgänge bereits mit der aktuellen Kennung arbeiten können, ohne historische Dokumente umzuschreiben.

Welche Rolle spielt die Stationierung bei historischen Aufträgen?

Stationierung ist häufig der fachliche Schlüssel, mit dem Arbeitsstellen, Verkehrszeichenpläne, Kontrollfahrten oder Genehmigungsunterlagen auf einen Straßenabschnitt bezogen werden. Ändert sich die Abschnittslänge, wird ein Abschnitt geteilt oder ein Nullpunkt verlagert, kann dieselbe Stationsangabe später einen anderen Bezug haben. Deshalb muss die Stationierung gemeinsam mit dem damals gültigen Netzstand gespeichert werden.

Wie häufig sollten Netzknotendaten aktualisiert werden?

Es gibt keinen sinnvollen Einheitsrhythmus für alle Quellen. Maßgeblich sind der Fortführungsprozess des jeweiligen Landes, die Veröffentlichungsweise und die Relevanz der Änderungen für den eigenen Betrieb. Produktiv sollte ein Import deshalb nicht nur nach Kalender laufen, sondern Änderungen erkennen, prüfen und erst danach als neuen Netzstand freigeben. Kritische Änderungen können zusätzlich anlassbezogen verarbeitet werden.

Wie lassen sich alte und neue Netzstände in einer Anwendung darstellen?

Im Tagesgeschäft sollte standardmäßig der aktuelle Netzstand erscheinen. Bei historischen Aufträgen braucht die Anwendung dagegen einen zeitbezogenen Aufruf, der automatisch den damals gültigen Stand verwendet. Hilfreich sind außerdem Hinweise auf Nachfolger oder Vorgänger eines Netzelements. Nutzer müssen dadurch nicht selbst rekonstruieren, warum eine alte Abschnittskennung heute nicht mehr in der aktuellen Suche auftaucht.

Welche Fehler treten bei der Versionierung in der Praxis häufig auf?

Häufig werden Quelldaten bei jedem Import vollständig überschrieben, Kennungen mit internen Primärschlüsseln verwechselt oder historische Aufträge nachträglich auf neue Abschnitte umgehängt. Ebenfalls problematisch sind fehlende Gültigkeitszeiträume und automatische Zuordnungen ohne fachliche Prüfung. Solche Abkürzungen funktionieren zunächst bequem, erzeugen aber spätestens bei Umbauten, Reklamationen, Nachweisen oder lang laufenden Projekten erhebliche Folgearbeit.