Straßendaten Bundesländer: Warum sie nicht zusammenpassen

Mit ChatGPT zusammenfassen Mit Perplexity zusammenfassen

Straßendaten verschiedener Bundesländer lassen sich nicht zuverlässig zusammenführen, indem man Geometrien in dieselbe Datenbank importiert und gleich benannte Spalten vereinheitlicht. Die eigentliche Schwierigkeit steckt in Netzmodellen, Referenzierung, Attributsemantik und unterschiedlichen Fortschreibungsprozessen. Für Verkehrssicherungsunternehmen entscheidet genau diese fachliche Ebene darüber, ob aus Geodaten ein brauchbares Arbeitsmittel wird.

Warum sieht ein bundesweites Straßennetz auf der Karte einfacher aus, als es technisch ist?

Auf einer Karte wirkt die Sache zunächst fast trivial. Eine Bundesstraße in Nordrhein-Westfalen ist eine Linie. Eine Landesstraße in Brandenburg ebenfalls. Hamburg liefert Straßen und Wege als Linienzüge, Bayern stellt sein klassifiziertes Straßennetz über Geodatendienste bereit. Also alles importieren, Koordinatensystem vereinheitlichen, Layer übereinanderlegen und fertig?

Genau an diesem Punkt beginnen in produktiven Anwendungen die Probleme.

Eine Linie beschreibt zunächst nur eine Geometrie. Für die Verkehrssicherung interessiert jedoch nicht nur, wo eine Straße ungefähr verläuft. Entscheidend kann sein, welcher Abschnitt betroffen ist, zwischen welchen Netzknoten er liegt, in welcher Stationierungsrichtung gearbeitet wird, welcher Baulastträger zuständig ist und wie eine Position in einer verkehrsrechtlichen Anordnung oder einem Aufmaß bezeichnet werden muss.

Deutschland verfügt allein beim überörtlichen Straßennetz über rund 229.500 Kilometer. Hinter dieser Zahl steht jedoch kein einzelner homogener Datenbestand. Die Informationen werden in unterschiedlichen Verwaltungsstrukturen geführt und für unterschiedliche Fachaufgaben veröffentlicht. Für eine Software, die bundesweit arbeiten soll, ist daher nicht die Kartendarstellung das eigentliche Problem, sondern die Übersetzung zwischen diesen Datenwelten.

In der Praxis zeigt sich das häufig erst spät. Ein erster Prototyp sieht überzeugend aus, weil Straßen auf einer Karte erscheinen und eine Suche Treffer liefert. Sobald daraus jedoch ein Arbeitsablauf für Baustelleneinrichtung, Beschilderungsplanung, Kontrollfahrt oder Auftragsübergabe entstehen soll, reichen Geometrie und Straßenname nicht mehr aus.

Warum bedeutet dasselbe Attribut nicht automatisch dasselbe?

Ein verbreiteter Fehler beim Aufbau bundesweiter Geodatenbestände besteht darin, Spalten nach ihrem Namen zuzuordnen.

street_name wird zu street_name.
station wird zu station.
road_class wird zu road_class.

Technisch funktioniert das. Fachlich kann es trotzdem falsch sein.

Ein Straßenname kann originär im Straßeninformationssystem geführt werden, aus einem anderen Verwaltungsbestand stammen oder lediglich eine ergänzende Bezeichnung sein. Eine Straßenklasse kann sich auf die Widmung, eine verwaltungsinterne Klassifikation oder die Darstellung innerhalb eines veröffentlichten Datendienstes beziehen. Selbst eine scheinbar einfache Länge kann als geometrisch berechnete Länge, fachlich geführte Abschnittslänge oder Bestandteil eines Stationierungssystems vorliegen.

Für einen Anwender aus der Verkehrssicherung ist dieser Unterschied relevant. Bei einer Anfrage wie „Arbeitsstelle auf der L-Straße zwischen Netzknoten A und B ab Station X“ reicht es nicht, dass die Software eine räumlich passende Linie gefunden hat. Die Referenz muss fachlich zu dem Netz passen, auf das Behörde, Straßenmeisterei oder Auftraggeber Bezug nehmen.

Das Datenmodell muss deshalb nicht nur Werte speichern, sondern auch deren Bedeutung.

KI für Verkehrssicherung von KrambergAI

Verkehrssicherungsanfragen strukturierter vorbereiten

KrambergAI unterstützt Unternehmen der Verkehrssicherung dabei, Anfragen, Einsatzorte, Pläne, Auflagen, Fotos und Abstimmungen mit KI besser zu erfassen und für das Team nutzbar zu machen.

Praxisnah eingeführt · Branchenspezifisch angepasst · Made in Germany

Mehr erfahren Gesprächstermin vereinbaren

Wie unterscheiden sich die Netzlogiken der Länder?

Straßeninformationsbanken sind keine gewöhnlichen Straßenkarten. Sie bilden ein fachliches Ordnungssystem ab.

Hamburg beschreibt sein Straßen- und Wegenetz beispielsweise ausdrücklich als Knoten-Kanten-Modell. Der veröffentlichte Bestand enthält unter anderem Von- und Nach-Netzknoten, Stationen, Straßenschlüssel, Wegenummer, Straßenname, Bahnigkeit, Fahrstreifen und Wegeart.

Nordrhein-Westfalen veröffentlicht wiederum einen Bestand mit Abschnitten und Ästen, Netzknoten, Nullpunkten und weiteren straßenbezogenen Informationen. In der Datenbeschreibung finden sich beispielsweise Abschnittskennungen, Abschnittsnummern, Stationierungsinformationen und ein Netzstand.

Brandenburg veröffentlicht neben den klassifizierten Straßen unter anderem Netzknoten beziehungsweise Nullpunkte, Stationierungsinformationen und Autobahnkilometrierung.

Bayern beschreibt das Straßennetz als Kern seines Straßeninformationssystems BAYSIS. Verschiedene Fachinformationen werden auf dieses Netz referenziert. Die Stationierung erfolgt dabei primär nach dem ASB-Ordnungssystem.

Das klingt ähnlich – und die fachlichen Grundlagen überschneiden sich tatsächlich erheblich. Trotzdem bedeutet das nicht, dass die veröffentlichten Datenprodukte identisch strukturiert sind.

Fachlicher Aspekt	Bayern	Hamburg	Nordrhein-Westfalen	Brandenburg
Netzbezug	ASB-orientiertes klassifiziertes Straßennetz	Knoten-Kanten-Modell der HH-SIB	Abschnitte, Äste, Netzknoten und Nullpunkte	Klassifiziertes Netz mit Netzknoten, Nullpunkten und Stationierung
Typische veröffentlichte Merkmale	Straßenbestand und referenzierte Fachdaten	Straßenname, Schlüssel, Wegenummer, Fahrstreifen, Bahnigkeit, Wegeart	Abschnittskennungen, Stationen, Netzstand und weitere Fachattribute	Straßenklassen, Stationierung, Kilometrierung und Radverkehrsinformationen
Charakter der Veröffentlichung	fachlicher Straßeninformationsbestand	umfassendes Straßen- und Wegenetz	landesspezifischer Open-Data-Bestand	mehrere fachlich getrennte Collections beziehungsweise Layer
veröffentlichter Pflegezyklus	tagesaktuell	wöchentlich	Netzstand wird als Attribut mitgeführt	vierteljährlich

Die Tabelle zeigt das eigentliche Integrationsproblem: Selbst dort, wo dieselben Fachbegriffe vorkommen, unterscheiden sich Veröffentlichungsstruktur, Abdeckung und Lebenszyklus.

Warum lösen ASB und OKSTRA das Problem nicht vollständig?

Mit der Anweisung Straßeninformationsbank und OKSTRA existieren wichtige fachliche Standards. Das ist ein großer Vorteil, weil zentrale Begriffe und Netzbezüge nicht in jedem Land völlig neu erfunden werden.

Ein Standard beseitigt jedoch nicht automatisch Unterschiede zwischen den produktiven Datenbeständen.

Die Gründe liegen in der praktischen Umsetzung. Länder können unterschiedliche Teilsichten veröffentlichen, zusätzliche Attribute ergänzen, bestimmte Objektarten nicht bereitstellen oder Fachdaten über separate Dienste anbieten. Hinzu kommen historisch gewachsene Straßeninformationsbanken, unterschiedliche Softwaregenerationen und landesspezifische Verwaltungsanforderungen.

Auch ein standardisiertes Austauschmodell bedeutet nicht, dass zwei öffentliche WFS-Dienste dieselbe fachliche Granularität liefern.

Das lässt sich mit einem alltäglichen Beispiel aus der Verkehrssicherung vergleichen: Zwei Verkehrszeichenpläne können beide regelkonform aufgebaut sein und trotzdem völlig unterschiedliche Projekte, Örtlichkeiten und Randbedingungen abbilden. Der gemeinsame Standard schafft eine gemeinsame Sprache. Er macht die konkreten Fälle nicht identisch.

Für Softwarearchitektur bedeutet das: Standards sind die Grundlage der Harmonisierung, nicht deren Ersatz.

Warum reicht auch INSPIRE für operative Anwendungen nicht aus?

INSPIRE verfolgt ein anderes Ziel als eine Dispositions-, Projekt- oder Verkehrssicherungsanwendung. Die europäische Geodateninfrastruktur soll Geodaten grenzüberschreitend auffindbar und interoperabel machen. Dafür werden Ausgangsdaten in definierte Zielschemata überführt.

Das ist für Recherche, Geodateninfrastruktur und übergreifende Nutzung äußerst wertvoll.

Für einen operativen Prozess kann dabei jedoch genau die Information fehlen, die vor Ort benötigt wird.

Die aktuellen Empfehlungen der GDI-DE beschreiben ausdrücklich Szenarien, in denen ein originärer Geodatensatz Informationen enthält, die nicht vollständig in das INSPIRE-Zielschema transformiert werden können. Das ist kein Fehler im Konzept. Es zeigt lediglich, dass ein interoperables Veröffentlichungsmodell und ein vollständiges Fachmodell unterschiedliche Aufgaben erfüllen.

Wer beispielsweise eine Arbeitsstelle eindeutig einem Straßenabschnitt, einer Stationierungsrichtung oder einer landesspezifischen Netzkennung zuordnen möchte, sollte deshalb nicht automatisch davon ausgehen, dass eine INSPIRE-Darstellung alle Informationen des originären Straßeninformationsbestands enthält.

Für produktive Anwendungen ist häufig der originäre Fachbestand die wertvollere Quelle.

Was läuft bei der Zusammenführung in der Praxis üblicherweise falsch?

Der häufigste Fehler ist ein zu früher Fokus auf die gemeinsame Datenbank.

Zuerst wird ein universelles Schema entworfen. Danach versucht man, jedes Bundesland in dieses Schema zu pressen. Attribute, die nicht passen, landen in Freitextfeldern oder werden verworfen. Was zunächst pragmatisch wirkt, erzeugt später schwer nachvollziehbare Sonderfälle.

Ein zweites Problem entsteht durch räumliches Matching. Liegen zwei Geometrien nahezu übereinander, werden sie als fachlich identisch behandelt. Das kann bei Basiskarten funktionieren. Bei stationierten Straßennetzen ist es gefährlich. Ein Ast, eine getrennte Richtungsfahrbahn, eine Anschlussstelle oder ein neu zugeschnittener Abschnitt kann geometrisch ähnlich aussehen und trotzdem eine andere fachliche Identität besitzen.

Drittens wird Historisierung oft unterschätzt. Ein Netzknoten kann geändert werden, ein Abschnitt kann geteilt werden, Straßen können umgestuft oder Netzbezüge neu organisiert werden. Wird bei jedem Import lediglich der aktuelle Bestand überschrieben, verliert die Anwendung die Verbindung zu älteren Projekten.

Gerade im Verkehrssicherungsbetrieb ist das problematisch. Eine abgeschlossene Maßnahme, ein Kontrollnachweis oder eine frühere Anordnung sollte auch später noch nachvollziehbar bleiben, selbst wenn sich das zugrunde liegende Straßennetz inzwischen verändert hat.

Warum sind Aktualisierungszyklen ein fachliches und kein rein technisches Problem?

Bei SaaS-Anwendungen wird Datenaktualisierung häufig als Infrastrukturthema behandelt: Job starten, Datei laden, Datensätze ersetzen, Cache invalidieren.

Bei Straßendaten reicht das nicht.

Bayern stellt wesentliche BAYSIS-WFS-Daten tagesaktuell zur Verfügung. Hamburg beschreibt für seinen HH-SIB-Datensatz eine wöchentliche Überführung in die veröffentlichten Dienste. Brandenburg nennt für das klassifizierte Straßennetz einen vierteljährlichen Aktualisierungsrhythmus.

Damit existiert bei einer bundesweiten Anwendung kein einheitlicher Zeitpunkt, zu dem „Deutschland aktuell“ ist.

Die Software muss vielmehr je Quelle wissen, wie Aktualität interpretiert werden darf. Ein Bestand, dessen letzter erfolgreicher Import gestern erfolgte, kann technisch aktuell sein, fachlich aber auf einer Quelle beruhen, deren planmäßige Fortschreibung erst später erfolgt. Umgekehrt kann ein Dienst kurzfristig nicht erreichbar sein, obwohl lokal noch ein belastbarer letzter Stand vorhanden ist.

Eine belastbare Architektur speichert deshalb nicht nur Straßendaten, sondern auch Quellenzustand, Abrufzeitpunkt, fachlichen Datenstand und Importversion.

Wie sollte ein produktiver Importprozess stattdessen aussehen?

Bewährt hat sich eine Trennung zwischen Rohdaten, normalisierten Daten und dem fachlichen Produktmodell.

Die Rohdaten werden möglichst unverändert übernommen. Dadurch bleibt nachvollziehbar, was die Quelle tatsächlich geliefert hat. Erst anschließend beginnt die Normalisierung.

Dabei werden beispielsweise Straßenklassen auf ein gemeinsames internes Vokabular abgebildet, Netzknoten und Abschnittskennungen getrennt gespeichert, Stationierungsrichtungen vereinheitlicht und landesspezifische Attribute in definierte Fachfelder überführt. Informationen, für die es kein sinnvolles gemeinsames Attribut gibt, dürfen dabei nicht einfach verschwinden.

Danach folgt die Qualitätssicherung. Sie prüft nicht nur Geometrien, sondern auch Netzbeziehungen: Existiert der referenzierte Knoten? Sind Anfang und Ende eines Abschnitts plausibel? Haben sich Kennungen verändert? Ist ein bisher vorhandenes Objekt tatsächlich gelöscht worden oder fehlt es lediglich in einer fehlerhaften Quelllieferung?

Erst aus diesem geprüften Bestand sollte eine produktive API oder Benutzeroberfläche gespeist werden.

Genau diese Zwischenschicht macht aus öffentlichem Open Data ein nutzbares Datenprodukt.

Warum ist Versionierung bei Netzknoten und Abschnitten besonders wichtig?

Eine Baustelle findet nicht „auf einer Linie“ statt. Sie findet auf einem zu einem bestimmten Zeitpunkt gültigen Straßennetz statt.

Wenn ein Projekt angelegt wird, sollte deshalb festgehalten werden, auf welche Netzversion sich die Referenz bezieht. Das gilt besonders dann, wenn Netzknoten, Abschnitte oder Stationierungen Bestandteil des Auftrags oder einer behördlichen Kommunikation sind.

Ein einfaches Überschreiben alter Datenstände kann dazu führen, dass ein Projekt Monate später auf einen anderen Abschnitt zeigt oder eine gespeicherte Stationsangabe nicht mehr zum aktuellen Netz passt.

Die bessere Lösung besteht darin, technische Identität und fachliche Gültigkeit voneinander zu trennen. Ein importiertes Objekt erhält eine stabile interne Identität. Änderungen aus der Quelle werden historisiert. Anwendungen können dadurch mit dem aktuellen Netz arbeiten und trotzdem ältere Projektbezüge nachvollziehen.

Für Dokumentation und Nachweisführung ist das wesentlich belastbarer als eine Datenbank, in der nur der jüngste Stand existiert.

Welchen Nutzen hat diese Normalisierung konkret für Verkehrssicherungsunternehmen?

Der Nutzen zeigt sich nicht im Datenmodell, sondern im Arbeitsablauf.

Ein Disponent möchte einen Auftrag nicht danach beurteilen, aus welchem WFS-Layer ein Abschnitt stammt. Er möchte eine Straße finden, den richtigen Netzbezug übernehmen und diese Information ohne Medienbruch an Projektleitung oder Außendienst weitergeben.

Bei der Arbeitsvorbereitung kann die Stationierung aus einem amtlichen Netz wichtiger sein als eine frei gesetzte Kartenmarkierung. Bei der Kommunikation mit Straßenbaubehörden kann eine Abschnitts- oder Netzknotenreferenz die Zuordnung erleichtern. Bei späteren Kontrollfahrten muss wiederum nachvollziehbar sein, welche Örtlichkeit ursprünglich gemeint war.

Der Netzknoten Navigator von Vextario setzt genau an dieser fachlichen Ebene an: Straßenreferenzen sollen nicht als isolierte Koordinaten behandelt werden, sondern im Kontext des jeweiligen Straßennetzes nutzbar werden.

Das ist kein Selbstzweck. Je weniger Übersetzungsarbeit zwischen Karte, Auftrag, Anordnung und Außendienst erforderlich ist, desto besser lässt sich ein digitaler Prozess tatsächlich in den Betriebsalltag integrieren.

Warum sollte ein Unternehmen trotzdem nicht versuchen, ein einziges Länderformat zu erzwingen?

Ein gemeinsames internes Modell ist sinnvoll. Ein künstliches Einheitsformat, das alle Besonderheiten entfernt, ist es nicht.

Die Architektur sollte einen gemeinsamen Kern besitzen: Straße, Netzobjekt, Abschnitt, Stationierung, Richtung, Verwaltungsbezug, Geometrie und Gültigkeit. Gleichzeitig muss sie landesspezifische Eigenschaften bewahren können.

Das ist ein wichtiger Unterschied.

Ein gutes Normalisierungsmodell sagt nicht: „Alle Bundesländer liefern dieselben Daten.“ Es sagt: „Wir wissen, welche Informationen fachlich vergleichbar sind, welche transformiert werden können und welche landesspezifisch bleiben müssen.“

Für mittelständische Unternehmen ist das meist die wirtschaftlichere Lösung. Die Fachanwender arbeiten mit einem gemeinsamen Bedienkonzept, während die Komplexität der Datenquellen in der Plattform verarbeitet wird.

Weitere Anwendungen aus diesem Ansatz – von spezialisierten Recherchewerkzeugen bis zu operativen Modulen für Verkehrssicherungsunternehmen – bündelt das Vextario Produktportfolio.

Wann wird aus einer Kartenintegration ein belastbares Straßendatenprodukt?

Nicht beim ersten erfolgreichen WFS-Import.

Ein Straßendatenprodukt entsteht erst, wenn Herkunft, Bedeutung, Netzbezug und zeitliche Gültigkeit jedes relevanten Objekts nachvollziehbar sind. Dazu gehören Quellenversionierung, Normalisierung, Qualitätssicherung, Historisierung und kontrollierte Veröffentlichung.

Für Verkehrssicherungsunternehmen ist diese Arbeit weitgehend unsichtbar. Genau das sollte sie auch sein. Im täglichen Betrieb sollte niemand darüber nachdenken müssen, ob ein Land Abschnittsobjekte anders modelliert als das nächste.

Die Anwendung muss diese Unterschiede verarbeiten.

Erst dann kann aus verteilten öffentlichen Straßendaten ein Werkzeug entstehen, das sich für Auftragsvorbereitung, Disposition, Standortreferenzierung und weitere operative Prozesse eignet.

FAQ

Kann man die Straßendaten aller Bundesländer nicht einfach in PostGIS importieren?

Technisch ist das problemlos möglich. Ein gemeinsames Koordinatensystem und eine räumliche Datenbank lösen jedoch nur die Speicherung. Sie vereinheitlichen weder Abschnittslogik noch Stationierung, Attributsemantik oder Gültigkeitszeiträume. Für eine reine Visualisierung kann ein solcher Import reichen. Für operative Prozesse muss zusätzlich feststehen, was jedes Objekt fachlich bedeutet und wie es sich zu anderen Netzobjekten verhält.

Sind Netzknoten in allen Bundesländern gleich aufgebaut?

Die grundlegende Idee des Netzknoten- und Stationierungssystems ist länderübergreifend etabliert, die veröffentlichten Datenprodukte sind jedoch nicht identisch. Unterschiede können bei Kennungen, Objektumfang, Attributen, Geometrien und bereitgestellten Zusatzinformationen auftreten. Eine produktive Anwendung sollte Netzknoten deshalb nicht allein über gleich benannte Felder zusammenführen, sondern die jeweilige Herkunft und Netzlogik berücksichtigen.

Warum reicht der Straßenname nicht als Referenz für eine Arbeitsstelle?

Straßennamen sind für Menschen hilfreich, aber als technische Referenz häufig nicht eindeutig genug. Namen können mehrfach vorkommen, fehlen oder sich ändern. Bei klassifizierten Straßen kommen Straßenbezeichnung, Abschnitt, Netzknoten, Station und Fahrtrichtung hinzu. Für Verkehrssicherungsmaßnahmen ist diese fachliche Referenzierung besonders wertvoll, weil sie eine Örtlichkeit reproduzierbarer beschreibt als Straßenname und Kartenpunkt allein.

Was ist der Unterschied zwischen Stationierung und GPS-Koordinaten?

GPS-Koordinaten beschreiben eine Position im Raum. Eine Stationierung beschreibt dagegen eine Position innerhalb eines definierten Straßenabschnitts und damit innerhalb eines fachlichen Ordnungssystems. Ändert sich das Netzmodell, muss dieser Zusammenhang berücksichtigt werden. Für Bau-, Betriebs- und Verwaltungsprozesse kann die Stationierung deshalb aussagekräftiger sein, weil sie direkt auf die von der Straßenverwaltung verwendete Netzstruktur verweist.

Können INSPIRE-Daten die Länderunterschiede vollständig beseitigen?

INSPIRE verbessert die Interoperabilität erheblich, ersetzt aber nicht zwangsläufig die originären Fachmodelle der Straßenverwaltungen. Bei einer Transformation können Informationen außerhalb des vorgesehenen Zielschemas verbleiben. Für übergreifende Visualisierungen ist das standardisierte Modell sehr wertvoll. Anwendungen mit Anforderungen an Abschnitt, Stationierung oder spezielle Fachattribute sollten zusätzlich prüfen, welche Informationen nur im ursprünglichen Datenbestand vorhanden sind.

Warum muss ein Straßendatenimport historisiert werden?

Straßennetze verändern sich. Abschnitte können geteilt, Kennungen geändert, Straßen umgestuft oder Netzbezüge angepasst werden. Werden bei jedem Import lediglich vorhandene Datensätze überschrieben, können ältere Projekte ihre ursprüngliche Referenz verlieren. Historisierung ermöglicht dagegen, aktuelle Straßendaten zu verwenden und gleichzeitig nachzuvollziehen, auf welchem Netzstand ein früherer Auftrag, eine Dokumentation oder eine Kontrollfahrt basiert hat.

Wie erkennt man, ob zwei Straßenabschnitte aus unterschiedlichen Quellen identisch sind?

Geometrische Nähe allein reicht dafür nicht. Zusätzlich sollten Straßenbezeichnung, Netzknoten, Abschnittskennung, Stationierung, Richtung und gegebenenfalls weitere Verwaltungsmerkmale verglichen werden. Bei Netzänderungen muss außerdem die zeitliche Gültigkeit berücksichtigt werden. Ein robustes Matching arbeitet deshalb mit mehreren fachlichen Merkmalen und behandelt zweifelhafte Zuordnungen als Prüfbedarf, statt sie automatisch zu einem Objekt zusammenzufassen.

Welche Daten sind für Verkehrssicherungsunternehmen besonders relevant?

Neben der Straßengeometrie sind vor allem Straßenklasse, Straßenbezeichnung, Netzknoten, Abschnitt beziehungsweise Ast, Stationierung, Fahrtrichtung und belastbare Verwaltungsbezüge hilfreich. Je nach Prozess können weitere Merkmale hinzukommen. Entscheidend ist, dass die Daten nicht nur auf der Karte erscheinen, sondern zuverlässig in Auftrag, Arbeitsvorbereitung, Kommunikation mit Behörden, Disposition und Dokumentation übernommen werden können.

Wie oft müssen Straßendaten in einer produktiven Anwendung aktualisiert werden?

Das lässt sich nicht pauschal für alle Quellen festlegen. Der Import sollte sich am tatsächlichen Veröffentlichungsrhythmus der jeweiligen Datenquelle orientieren und zugleich Ausfälle verkraften. Wichtig ist deshalb weniger ein maximal kurzer Abrufabstand als ein kontrollierter Prozess mit Quellendatenstand, erfolgreichem Abrufzeitpunkt, Qualitätsprüfung und einer definierten Regel, wann neue Daten in den produktiven Bestand übernommen werden.

Was sollte eine SaaS-Plattform beim Umgang mit Länder-Straßendaten speichern?

Neben den normalisierten Fachdaten sollten mindestens Herkunft, externer Schlüssel, Importversion, fachliche Gültigkeit und der verwendete Quelldatenstand erhalten bleiben. Landesspezifische Informationen sollten nicht verloren gehen, nur weil sie nicht in das gemeinsame Kernmodell passen. Dadurch bleibt die Plattform erweiterbar und kann spätere Änderungen der Datenquellen verarbeiten, ohne bestehende Projektbezüge nachträglich neu interpretieren zu müssen.

Quellen zu den verwendeten Kennzahlen