Warum öffentliche Geodaten nicht direkt in produktive Anwendungen gehören

Öffentliche Geodaten sind wertvolle Rohstoffe, aber öffentliche WFS-, WMS- oder API-Dienste sind nicht automatisch für den dauerhaften Betrieb einer Fachanwendung ausgelegt. Direkte Abhängigkeiten erzeugen Risiken bei Verfügbarkeit, Antwortzeiten, Schemaänderungen, Lizenzierung und Datenständen. Produktionsfähige Anwendungen brauchen deshalb eine kontrollierte Zwischenschicht aus Import, Prüfung, Versionierung, Caching und eigener Auslieferung.

Warum ist ein öffentlicher Geodatendienst noch keine Produktions-API?

Für eine Recherche ist ein öffentlicher WFS hervorragend. Man öffnet den Dienst, setzt einen räumlichen Filter, lädt einige Features und erhält genau die Informationen, die eine Landes- oder Kommunalverwaltung bereitstellt. Technisch funktioniert damit zunächst alles.

Im Alltag eines Verkehrssicherungsunternehmens gelten jedoch andere Bedingungen. Eine Disposition wartet nicht darauf, dass ein fremder Geoserver wieder reagiert. Ein Einsatzleiter möchte einen Abschnitt, eine Stationierung oder einen Netzknoten aufrufen, wenn er ihn benötigt. Ein Auftrag darf nicht deshalb hängen bleiben, weil ein Feature-Service am Nachmittag langsamer antwortet als am Morgen. Und eine mobile Anwendung für Besichtigung, Aufbau oder Kontrollfahrt sollte nicht plötzlich andere Attribute erhalten, nur weil der Datenbereitsteller sein Fachschema modernisiert hat.

Genau an dieser Stelle wird häufig ein Denkfehler gemacht: Ein öffentlich erreichbarer Geodatendienst wird mit einer dauerhaft verfügbaren Backend-Schnittstelle gleichgesetzt.

Das sind zwei verschiedene Aufgaben.

Öffentliche Geodateninfrastrukturen sollen Daten auffindbar, interoperabel und wiederverwendbar bereitstellen. Eine produktive B2B-Anwendung muss darüber hinaus definierte Antwortzeiten, kontrollierte Datenstände, eigene Fehlerbehandlung, nachvollziehbare Aktualisierungen und eine für den jeweiligen Fachprozess geeignete Datenstruktur bereitstellen.

Gerade bei Straßendaten ist dieser Unterschied erheblich. Ein WFS liefert möglicherweise Achsen, Knoten, Verwaltungsattribute und Fachkennzeichen. Die Verkehrssicherung benötigt dagegen häufig einen konkreten Zusammenhang aus Straße, Abschnitt, Station, Fahrtrichtung, Netzbezug und weiteren Informationen, die im Auftrag oder in der verkehrsrechtlichen Anordnung verwendet werden können.

Warum reicht selbst eine hohe Verfügbarkeit nicht für den Betriebsalltag?

Die europäischen INSPIRE-Vorgaben zeigen gut, wie unterschiedlich Infrastruktur- und Anwendungsanforderungen sein können. Für entsprechende Netzdienste ist eine Verfügbarkeit von 99 Prozent vorgesehen. Bei View Services wird für eine Kartenanfrage mit einer Bildgröße von 470 Kilobyte eine initiale Antwortzeit von maximal 5 Sekunden unter Normalbedingungen genannt; zugleich sieht die Vorgabe für View Services eine Mindestkapazität von 20 Anfragen pro Sekunde vor.

Diese Werte sind für standardisierte Geodateninfrastrukturen sinnvoll. Für eine operative Anwendung beantworten sie aber nicht alle entscheidenden Fragen.

Was passiert bei einem regionalen Ausfall? Gibt es ein Service-Level gegenüber dem Verkehrssicherungsunternehmen? Wie verhält sich der Dienst bei einem größeren Datenabruf? Werden Antwortzeiten auch dann erreicht, wenn eine Anwendung räumliche Filter über umfangreiche Straßennetze ausführt? Gibt es Wartungsfenster? Ändert sich die Service-URL? Wird ein Layer ersetzt oder vorübergehend nicht veröffentlicht?

Eine Anwendung, die direkt auf einen externen Dienst zugreift, übernimmt dessen Betriebsverhalten automatisch in den eigenen Prozess.

Damit wird aus einem Problem des Datenbereitstellers sehr schnell ein Problem in Disposition, Arbeitsvorbereitung oder Außendienst.

Warum wird Performance gerade bei Straßennetzen schnell zum Problem?

Geodatenabfragen sehen in einer Entwicklungsumgebung oft harmlos aus. Einige Punkte werden geladen, ein Kartenausschnitt geöffnet, ein Abschnitt gesucht. Die Anwendung reagiert zufriedenstellend.

Im produktiven Betrieb verändert sich die Situation. Mehrere Nutzer greifen parallel zu. Kartenausschnitte bewegen sich. Suchvorgänge werden wiederholt. Filter betreffen nicht nur einen Datensatz, sondern mehrere Layer. Geometrien müssen transformiert, Attribute ausgewertet und Beziehungen hergestellt werden.

Ein öffentlicher WFS wurde möglicherweise dafür eingerichtet, Fachanwendern standardisierten Zugriff auf einen Datenbestand zu ermöglichen. Er muss deshalb nicht dieselbe Abfragecharakteristik unterstützen wie eine SaaS-Anwendung, in der zahlreiche Nutzer in kurzer Folge dieselben Netzknoten, Straßenabschnitte oder Verwaltungsgebiete aufrufen.

Noch problematischer wird es bei mobilen Anwendungen. Schwankende Mobilfunkverbindungen treffen dort auf schwankende Antwortzeiten des Ursprungsdienstes. Zwei voneinander unabhängige Unsicherheiten liegen hintereinander.

In einer produktiven Architektur werden solche Zugriffe deshalb typischerweise entkoppelt. Der Ursprungsdienst dient als Datenquelle. Die Fachanwendung arbeitet mit einem kontrollierten, für den Anwendungsfall vorbereiteten Bestand.

Was passiert, wenn sich das Schema eines WFS verändert?

Ein häufiger Fehler besteht darin, ein externes Attribut direkt mit der internen Anwendung zu verdrahten.

Heute heißt ein Feld beispielsweise strasse, morgen strassenname. Eine Stationierung wird bisher numerisch geliefert und nach einer Umstellung als Zeichenkette ausgegeben. Ein bisher gefülltes Attribut wird optional. Ein Feature-Type erhält zusätzliche Objektarten. Eine Behörde trennt einen Layer in zwei fachlich genauer definierte Layer.

Für einen GIS-Anwender ist eine solche Änderung lösbar. Für eine unbeaufsichtigt laufende produktive Datenpipeline kann sie einen Import stoppen oder, noch unangenehmer, scheinbar erfolgreiche aber fachlich fehlerhafte Daten erzeugen.

Das zweite Problem ist meist gefährlicher als ein vollständiger Ausfall.

Wenn ein Import mit einem Fehler abbricht, kann ein Monitoring anschlagen. Wenn dagegen Stationierungswerte in der falschen Einheit übernommen werden oder ein Feld semantisch anders verwendet wird, sieht der Datensatz technisch möglicherweise weiterhin gültig aus.

Deshalb sollten öffentliche Geodaten niemals ausschließlich nach dem Prinzip „HTTP 200 bedeutet erfolgreich“ übernommen werden.

Notwendig sind Schema-Prüfungen, Pflichtfeldkontrollen, Wertebereichsprüfungen, Geometrieprüfungen, Mengenvergleiche und fachliche Plausibilitätsregeln.

Warum gehört Lizenzierung in dieselbe Pipeline wie Technik und Qualitätssicherung?

Die technische Erreichbarkeit eines Datensatzes beantwortet nicht die Frage, ob und unter welchen Bedingungen er in einem kommerziellen Produkt verwendet werden darf.

Das ist bei öffentlichen Daten besonders wichtig, weil sich unter dem allgemeinen Begriff Open Data unterschiedliche Nutzungsbedingungen verbergen können. Manche Daten dürfen ohne Bedingungen weiterverwendet werden. Andere verlangen Namensnennung, einen Verweis auf die Lizenz, die Angabe des konkreten Datensatzes oder einen Hinweis auf Veränderungen.

Für ein Verkehrssicherungsunternehmen ist das zunächst kein operatives Thema. Für den Anbieter der Fachanwendung sehr wohl.

Lizenzinformationen sollten deshalb nicht in einer Excel-Liste neben der eigentlichen Datenpipeline leben. Sinnvoller ist es, Quelle, Nutzungsrecht, vorgeschriebenen Quellenvermerk, Abrufdatum, Datensatzversion und gegebenenfalls notwendige Änderungshinweise gemeinsam mit dem importierten Datenbestand zu verwalten.

So lässt sich beispielsweise verhindern, dass ein technisch funktionierender Import automatisch aktiviert wird, obwohl die kommerzielle Weiterverwendung noch geprüft werden muss.

Wie sollte der Weg von der Behördenquelle zur produktiven Anwendung aussehen?

Zwischen dem öffentlichen Dienst und dem Nutzer sollte eine kontrollierte Verarbeitungsebene liegen.

Der Ursprung bleibt dabei relevant. Er wird nicht versteckt und auch nicht durch eine erfundene Datenquelle ersetzt. Aber er wird vom Laufzeitbetrieb der Anwendung getrennt.

Ein typischer Ablauf sieht so aus: Zunächst wird der Datenstand aus WFS, API oder Downloadquelle abgerufen. Danach wird geprüft, ob Struktur, Geometrien und erwartete Merkmale noch zum bekannten Datenvertrag passen. Anschließend werden die Daten normalisiert, intern referenziert, versioniert und erst nach bestandener Qualitätssicherung für die Anwendung freigegeben.

Die Anwendung selbst fragt anschließend nicht den externen Behördenserver ab, sondern eine eigene Datenbank beziehungsweise eine kontrollierte API.

Diese Architektur kostet zunächst mehr Arbeit als ein direkter Fetch aus dem Frontend. Sie spart diese Arbeit später an der unangenehmsten Stelle: im laufenden Betrieb.

Was geht in der Praxis bei öffentlichen Geodaten besonders häufig schief?

Viele Probleme sind erstaunlich unspektakulär.

Eine Download-URL wird geändert. Ein WFS liefert zeitweise nur einen Teil seiner Features. Eine Geometrie ist ungültig. Ein Datensatz enthält plötzlich ein Objekt ohne Straßennamen. Ein Identifier wird neu vergeben. Ein bisher leerer Wert wird mit einem neuen Code befüllt. Die Datenmenge sinkt erheblich, obwohl der Request technisch erfolgreich war.

Wer nur prüft, ob der Dienst erreichbar ist, bemerkt davon wenig.

In der Praxis hat sich deshalb ein Vergleich mit dem vorherigen freigegebenen Datenstand bewährt. Wie viele Objekte sind hinzugekommen? Wie viele verschwunden? Welche Schlüssel haben sich verändert? Gibt es neue Nullwerte? Haben sich Geometrietypen geändert? Liegen Objekte plötzlich außerhalb des erwarteten Gebiets?

Gerade bei einem Straßennetz kann ein Mengenunterschied fachlich vollkommen legitim sein. Eine Straße wurde umgebaut, ein Abschnitt neu stationiert oder ein Netzmodell fortgeschrieben. Deshalb sollte QA nicht automatisch jede Änderung blockieren. Sie sollte ungewöhnliche Veränderungen sichtbar machen, bevor diese den produktiven Bestand ersetzen.

Warum spielt Versionierung bei Netzreferenzen eine besondere Rolle?

Straßennetze sind keine statischen Hintergrundkarten.

Netzknoten können fortgeschrieben werden, Abschnitte entstehen oder entfallen, Stationierungen verändern sich und Attribute werden berichtigt. Gleichzeitig existieren im betrieblichen Alltag alte Aufträge, abgeschlossene Kontrollfahrten, Abnahmen, Fotos und Dokumentationen, deren räumlicher Bezug weiterhin nachvollziehbar bleiben muss.

Würde eine Anwendung ausschließlich den jeweils aktuellen Behördenstand verwenden, könnte eine ältere Projektreferenz nach einer Netzfortschreibung anders interpretiert werden oder gar nicht mehr gefunden werden.

Eine produktive Datenhaltung sollte deshalb zwischen dem aktuellen Netz und historischen Referenzen unterscheiden können. Ein Auftrag benötigt nicht nur „einen Punkt auf der Karte“, sondern den fachlichen Netzbezug, der zum Zeitpunkt des Vorgangs verwendet wurde.

Das ist einer der Gründe, warum ein eigener Datenbestand nicht bloß ein Cache ist. Er bildet eine fachliche Historie.

Warum ist Caching mehr als eine Maßnahme für schnellere Karten?

Caching wird bei Geodaten häufig als reines Performance-Thema behandelt. Das greift zu kurz.

Natürlich reduziert ein Cache wiederholte Abfragen. Wenn zehn Nutzer denselben Netzabschnitt benötigen, muss dieser nicht zehnmal aus einer externen Infrastruktur gelesen werden.

Wichtiger ist aber die betriebliche Entkopplung. Ein geprüfter Datenstand kann weiter ausgeliefert werden, auch wenn die Quelle währenddessen vorübergehend nicht erreichbar ist. Die Anwendung weiß außerdem, welchen Stand sie verwendet. Ein Update wird nicht zufällig mitten in einem laufenden Prozess aktiv, sondern nach einem definierten Import- und Freigabevorgang.

Für Fachanwendungen in der Verkehrssicherung ist das meist wichtiger als einige Millisekunden Antwortzeit.

Wo zeigt sich der Unterschied konkret im Netzknoten Navigator?

Ein typischer Anwendungsfall ist die Suche nach einer Netzreferenz für einen Einsatzort. Der Nutzer möchte nicht wissen, welche technische Behörde welchen WFS betreibt. Er möchte Straße, Netzknoten, Abschnitt und Stationierung für seinen betrieblichen Vorgang ermitteln.

Der Vextario Netzknoten Navigator unter https://netzknoten-navigator.vextario.com/ verfolgt genau diese anwendungsbezogene Perspektive. Öffentliche Straßendaten werden nicht als Selbstzweck dargestellt, sondern in eine Arbeitsoberfläche übersetzt, die auf die Recherche von Netzreferenzen ausgerichtet ist.

Damit verändert sich auch die technische Verantwortung. Die Anwendung muss mit unterschiedlichen Datenmodellen, Aktualisierungswegen und regionalen Besonderheiten umgehen, ohne diese Komplexität vollständig an den Nutzer weiterzugeben.

Für Verkehrssicherungsunternehmen ist das letztlich der relevante Punkt: Ein Werkzeug muss den betrieblichen Vorgang unterstützen und nicht die technische Struktur einer Geodateninfrastruktur nachbilden.

Warum wird dieses Architekturprinzip für Verkehrssicherungssoftware wichtiger?

Mit zunehmender Digitalisierung werden Geodaten nicht nur auf Karten angezeigt. Sie fließen in Auftragsvorbereitung, Zuständigkeitsprüfung, Arbeitsstellenplanung, Kontrollfahrten, Dokumentation, Auswertung und später möglicherweise in Schnittstellen zu weiteren Systemen ein.

Damit wächst die Bedeutung der Datenqualität.

Ein falscher Kartenhintergrund ist ärgerlich. Eine falsche Netzreferenz, die in einen Auftrag übernommen und anschließend durch mehrere Prozessschritte weitergereicht wird, ist eine andere Kategorie von Problem.

Deshalb sollte jede Information, die operative Folgeprozesse beeinflusst, einen nachvollziehbaren Weg von der Quelle bis zur Anwendung besitzen.

Genau dieser Ansatz lässt sich auch auf andere Datenbestände übertragen: Verwaltungsgrenzen, Zuständigkeiten, Arbeitsstellenmeldungen, Geschwindigkeitsinformationen, Bauwerke oder weitere für die Verkehrssicherung relevante Fachdaten.

Wer sich mit dieser breiteren Digitalisierung von Verkehrssicherungsprozessen beschäftigt, findet das Vextario Produktportfolio für Verkehrssicherungsunternehmen unter https://vextario.com.

Können öffentliche Geodaten trotzdem die richtige Grundlage sein?

Unbedingt. Die Schlussfolgerung lautet nicht, öffentliche Geodaten zu vermeiden.

Im Gegenteil: Amtliche und andere öffentliche Geodaten sind für viele Anwendungen die sachlich geeignete Ausgangsbasis. Sie liefern Informationen, die ein einzelner Softwareanbieter weder sinnvoll noch wirtschaftlich selbst erfassen könnte.

Der entscheidende Unterschied liegt zwischen Datenquelle und Produktionsabhängigkeit.

Eine gute Architektur respektiert die öffentliche Quelle, dokumentiert ihre Herkunft, aktualisiert sie regelmäßig und übernimmt relevante Änderungen. Sie verhindert lediglich, dass jede Schwankung des Ursprungsdienstes unmittelbar bis zum Anwender durchschlägt.

Öffentliche Geodaten gehören deshalb sehr wohl in produktive Anwendungen. Sie sollten nur nicht ungeprüft und direkt deren Laufzeit-Backend bilden.

Kennzahlenquelle

Europäische Kommission – Verordnung (EG) Nr. 976/2009 zur Durchführung der INSPIRE-Richtlinie hinsichtlich der Netzdienste: https://eur-lex.europa.eu/eli/reg/2009/976/oj/eng
Verwendete Kennzahlen: 99 Prozent Verfügbarkeit, maximal 5 Sekunden initiale Antwortzeit für den beschriebenen View-Service-Anwendungsfall und Mindestkapazität von 20 Anfragen pro Sekunde für View Services.

Interessante Links

W3C und Open Geospatial Consortium – Spatial Data on the Web Best Practices
https://www.w3.org/TR/sdw-bp/
Praxisorientierte Empfehlungen zu Veröffentlichung, Versionierung, Datenzugriff, APIs und Wiederverwendung räumlicher Daten.

Geodateninfrastruktur Deutschland – Architektur der GDI-DE, Technik, Version 4.1.0
https://wiki.gdi-de.org/spaces/Arch/pages/1476002303/Technik?preview=%2F1476002303%2F1476002326%2Fworddav5673c549eae0f26eebfdb90d591b1aae.png
Aktuelle technische Architekturgrundlage der deutschen Geodateninfrastruktur mit Standards, technischen Komponenten und Qualitätsmonitoring.

Amt für Veröffentlichungen der Europäischen Union – Bewährte Verfahren für hochwertige Datensätze
https://op.europa.eu/en/publication-detail/-/publication/3170ef76-55f8-11ef-acbc-01aa75ed71a1/language-en
Bericht zu technischen, organisatorischen und rechtlichen Erfahrungen bei der Bereitstellung hochwertiger öffentlicher Datensätze.

Sind öffentliche WFS-Dienste grundsätzlich ungeeignet für Unternehmenssoftware?

Nein. Ein WFS kann eine sehr gute Quelle für den automatisierten Datenimport sein. Problematisch wird erst die direkte Laufzeitabhängigkeit. Wenn jede Benutzeraktion unmittelbar einen fremden Dienst benötigt, übernimmt die Anwendung dessen Ausfälle, Antwortzeiten und Änderungen. Sinnvoller ist häufig, Daten regelmäßig zu importieren, zu prüfen und anschließend über eine eigene Datenhaltung bereitzustellen.

Wie oft sollten öffentliche Geodaten aktualisiert werden?

Das hängt vom fachlichen Veränderungstempo der Quelle ab. Ein Straßennetz benötigt einen anderen Rhythmus als kurzfristige Arbeitsstellenmeldungen. Entscheidend ist, dass Aktualisierungen nicht lediglich nach Kalender ausgeführt werden. Jeder neue Datenstand sollte gegen den vorherigen Bestand geprüft werden, damit größere Mengenänderungen, neue Attribute, fehlende Objekte oder auffällige Geometrien vor der produktiven Freigabe erkannt werden.

Was passiert bei einem Ausfall der ursprünglichen Datenquelle?

Bei einer entkoppelten Architektur kann die Anwendung weiterhin den zuletzt erfolgreich geprüften Datenstand verwenden. Der fehlgeschlagene Aktualisierungslauf wird protokolliert und erneut versucht, während der operative Zugriff bestehen bleibt. Wichtig ist dabei, das Alter des verwendeten Datenstands intern zu überwachen, damit aus einem kurzfristigen Ausfall nicht unbemerkt ein dauerhaft veralteter Bestand wird.

Warum genügt ein Cache allein nicht?

Ein Cache speichert Daten, beurteilt sie aber nicht. Für eine produktive Fachanwendung werden zusätzlich Schema-Prüfungen, fachliche Validierungen, Versionierung, Quelleninformationen und definierte Freigaben benötigt. Andernfalls kann auch ein fehlerhafter oder unvollständiger Datenstand sehr effizient gecacht werden. Die entscheidende Ebene liegt deshalb zwischen Import und Veröffentlichung: Erst geprüfte Daten sollten zum produktiven Anwendungsbestand werden.

Wie erkennt man problematische Schemaänderungen?

Dafür wird das erwartete Quellschema technisch beschrieben und bei jedem Import überprüft. Zusätzlich sollten Datentypen, Pflichtattribute, Wertebereiche, Identifier und Geometrietypen kontrolliert werden. Besonders wichtig sind Vergleiche zum vorherigen Datenstand. Wenn plötzlich zahlreiche Werte fehlen oder ein bisher numerisches Stationsfeld ein anderes Format besitzt, sollte der neue Import zunächst nicht automatisch produktiv geschaltet werden.

Welche Rolle spielen Lizenzen bei öffentlichen Geodaten?

Eine frei erreichbare URL bedeutet nicht automatisch, dass jede kommerzielle Weiterverwendung ohne Bedingungen erlaubt ist. Je nach Lizenz können Quellenangaben, Datensatzverweise oder Hinweise auf Bearbeitungen notwendig sein. Deshalb sollten Lizenzinformationen gemeinsam mit der technischen Quelle gepflegt und vor einer produktiven Aktivierung geprüft werden. Bei Daten aus mehreren Bundesländern können sich die jeweiligen Nutzungsbedingungen zudem voneinander unterscheiden.

Warum sind historische Datenstände für Verkehrssicherungsunternehmen relevant?

Ein abgeschlossener Auftrag sollte auch nach einer späteren Änderung des Straßennetzes nachvollziehbar bleiben. Werden Netzknoten, Abschnitte oder Stationierungen fortgeschrieben, kann eine ausschließlich aktuelle Datenhaltung frühere Referenzen verändern. Versionierte Geodaten ermöglichen dagegen, Dokumentationen, Kontrollfahrten und Auftragsinformationen dem Datenstand zuzuordnen, der zum damaligen Zeitpunkt verwendet wurde. Das erleichtert spätere Prüfungen und betriebliche Nachweise erheblich.

Können mehrere Bundesländer in einem gemeinsamen Datenmodell abgebildet werden?

Ja, allerdings sollte das interne Datenmodell nicht einfach das Schema eines einzelnen Bundeslandes übernehmen. Unterschiedliche Quellen können andere Feldnamen, Identifikatoren, Stationierungsmodelle und Aktualisierungsverfahren verwenden. Eine Normalisierung übersetzt diese Unterschiede in ein gemeinsames fachliches Modell. Regionale Besonderheiten bleiben dabei erhalten, während Anwendungen über eine einheitliche interne Schnittstelle auf die benötigten Informationen zugreifen können.

Wann sollte eine Anwendung trotzdem live auf einen Behördendienst zugreifen?

Ein Live-Zugriff kann sinnvoll sein, wenn ausdrücklich der momentan veröffentlichte Ursprungsstand geprüft werden soll oder wenn Daten so kurzfristig wechseln, dass eine lokale Kopie fachlich ungeeignet wäre. Auch dann empfiehlt sich eine Fehlerstrategie. Die Anwendung sollte erkennen, wenn der externe Dienst nicht antwortet, und darf einen fehlgeschlagenen Live-Abruf nicht mit einem fachlich bestätigten Ergebnis verwechseln.

Was ist der wichtigste Unterschied zwischen Open Data und produktionsfähigen Daten?

Open Data beschreibt vor allem die Zugänglichkeit und Wiederverwendbarkeit eines Datenbestands unter den jeweiligen Bedingungen. Produktionsfähigkeit umfasst zusätzliche Anforderungen aus dem Softwarebetrieb: geprüfte Strukturen, definierte Aktualisierung, Versionierung, Fehlerbehandlung, Performance, Monitoring und eine für den Fachprozess geeignete Modellierung. Erst diese Verarbeitung macht aus einer verfügbaren Geodatenquelle einen belastbaren Bestandteil einer betrieblichen Anwendung.