| FGSV-Nr. | FGSV 002/138 |
|---|---|
| Ort | Köln |
| Datum | 28.02.2024 |
| Titel | OKSTRA und OkWS in der SIB-Bayern |
| Autoren | Elisabeth Göppl, Christian Stemp |
| Kategorien | OKSTRA |
| Einleitung | Die bayerische Straßenbauverwaltung löst mit der SIB-Bayern die bisherige Straßendatenbank von BAYSIS, dem Bayerischen Straßeninformationssystem, ab. BAYSIS ist die zentrale Auskunftsplattform für das überörtliche Straßennetz des Freistaats Bayern und dient zur Pflege, Visualisierung, Auswertung und Bereitstellung von Straßendaten. Die SIB-Bayern berücksichtigt in ihren Datenstrukturen und Schnittstellen die geläufigen Standards (ASB, OKSTRA®, WMS, WFS) und stützt sich auf Standardsoftwareprodukte der ESRI-Familie. Neben den OGC-konformen WFS und WMS, die das Datenmodell 1:1 wiedergeben, kann die SIB-Bayern auch mittels OKSTRA® und den dazugehörigen OKSTRA®-konformen Webservices (OkWS) angesprochen werden. Um die Daten gemäß OKSTRA® bereitstellen zu können, werden die Daten nächtlich mittels FME-Server aus der SIB-EGDB (ESRI Enterprise Geodatabase) in die OKSTRA®-Datenbank (eine PostgreSQL-Datenbank) migriert. Die OKSTRA®-Datenbank besteht somit als sekundärer Datenbestand neben der SIB-EGDB. Um einen read-only OkWS (OGC WFS 2.0 mit Datenabgabe als OKSTRA®-XML) nach außen bereitzustellen, wird die OKSTRA®-Datenbank über den XtraServer als WFS konfiguriert und publiziert. Der OKSTRA®-Import sowie das OKSTRA®-konforme Netzänderungsprotokoll werden in einem Folgerelease umgesetzt. |
|
|
| Volltext | Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.1 Allgemeine ProjektdatenDie bayerische Straßenbauverwaltung löst mit der SIB-Bayern die bisherige Straßendatenbank von BAYSIS, dem Bayerischen Straßeninformationssystem, ab. BAYSIS ist die zentrale Auskunftsplattform der Bayerischen Straßenbauverwaltung. Mit der Bereitstellung des Straßennetzes und der Bestandsdaten stellt BAYSIS die Grundlagen für zahlreiche andere Fachverfahren, wie das Prüfprogramm Großraum- und Schwertransport, MaViS oder die SIB-Bauwerke, dar. Die SIB-Bayern dient hierbei als zentrales IT-System für die Pflege, die Bereitstellung, die Auswertung und den Austausch der straßennetzbezogenen Daten. Sie berücksichtigt in ihren Datenstrukturen und Schnittstellen die geläufigen Standards (Anweisung Straßeninformationsbank (ASB), OKSTRA®, WMS, WFS) und stützt sich auf Standardsoftwareprodukte der ESRI-Familie – hier vor allem auf die ArcGIS Extension „Roads & Highways“. Die Systemarchitektur ist sehr modular aufgebaut, verfügt über konfigurierbare Einheiten und erlaubt somit umgehend auf neue oder veränderte Anforderungen mit minimalen Anpassungsaufwand zu reagieren. Ein zentraler Bestandteil ist hierbei auch die vollumfängliche Unterstützung des OKSTRA®-Datenformates, was im Altsystem bisher nicht gegeben war. Bild 1: Konzeptionelle Architektur der SIB-Bayern (Ausbaustufe 1) Als Grundgerüst der SIB-Bayern wird für die Netzfortführung und die Datenpflege eine ESRI Enterprise Geodatabase auf einem Microsoft SQL Server verwendet (SIB-EGDB). Die Bedienoberfläche der neuen SIB-Bayern ist in zwei Komponenten aufgeteilt. Die Netzpflege erfolgt mit einer individuell angepassten Netzpflege-Toolbox in ArcGIS Pro. Die Datenpflege und das Auskunftssystem werden über das ESRI-Portal mittels VertiGIS Studio Apps angesprochen. Daneben wird die FME sowohl für die internen Import- und Exportschritte eingesetzt als auch für die Erzeugung des OKSTRA®-Datenformats. Die Bereitstellung des OkWS erfolgt mittels XtraServer und einer separaten OKSTRA®-Datenbank unter SUSE Linux Enterprise Server auf Basis einer PostgreSQL-Datenbank. Bestrebungen, die zentrale Straßeninformationsbank abzulösen und durch ein eigenes modernes und modular erweiterbares Produkt zu ersetzen, existieren bereits seit 2015. Mit Hilfe einer Machbarkeitsstudie wurde damals die Eignung von „Roads & Highways“ geprüft und bestätigt. Projektstart war mit der Vergabe an Eviden (vormals Atos) im Herbst 2021. Eviden tritt hierbei als Generalunternehmer auf. Beteiligt sind außerdem die Firmen con terra (Datenmigration vom Altsystem in die SIB-EGDB sowie Übernahme der Daten in die OKSTRA®-Datenbank), VertiGIS (Entwicklung der Netz- und Datenpflege sowie Auskunftssystem), ESRI (Softwarebereitstellung) und interactive instruments (Erstellung OKSTRA®-Profil, Einrichtung XtraServer und Analyse der Datenqualität des OKSTRA®). Die Produktivnahme ist für das 2. Quartal in 2024 geplant. Nachdem „Die Autobahn GmbH des Bundes“ ebenfalls im Begriff war eine neue SIB auf ESRI-Basis aufzubauen und eine Vergabe an dieselben Firmen erfolgte, wurde beschlossen einen Vertrag zur Überlassung und gemeinsamen Weiterentwicklung zu schließen, um bei der Entwicklung Synergien zu nutzen, Doppelentwicklungen zu vermeiden und wirtschaftlicher zu arbeiten. 2 OKSTRA® im ProjektNeben den OGC-konformen WFS und WMS sowie den ESRI-eigenen Diensten, die das vollständige Datenmodell 1:1 wiedergeben, kann die SIB-Bayern auch mittels OKSTRA® und den dazugehörigen OkWS angesprochen werden. Ziel ist es hierbei, die Straßendaten vollumfänglich gemäß den bundeseinheitlichen Standards zur Verfügung zu stellen sowie später auch importieren und weiterverwenden zu können. So können externe und interne Drittsysteme wie SIB-Bauwerke 2.0, Winterdienst, BISStra (Bundesinformationssystem Straße), VEMAGS (Verfahrensmanagement für Großraum- und Schwertransporte) oder auch potenziell das O2I-Tool (OKSTRA® to INSPIRE) beliefert werden. Der OKSTRA® fungiert somit als offene und dokumentierte Standardschnittstelle zur SIB-Bayern. 2.1 Datenmodell der SIB-BayernDie SIB-Bayern nutzt in Release 1.0 die ASB Version 2.04 als Grundlage (BMVI, 2018). Ein neues Release ist für die Version 2.05 geplant. Daneben gibt es aufgrund landesinterner Anforderungen an zusätzliche Objekte (beispielsweise Zustandserfassungs- und Unfalldaten) sowie Attribute noch weitere landesspezifische Ergänzungen. Ebenso wurden einige Objekte wie beispielsweise die Dokumentenablage um reine OKSTRA®-Attribute erweitert. Hinzu kommen die Spezifikationen des Linearen Referenzierungssystems (LRS) von ESRI „Roads & Highways“. Viele dieser Attribute sind auch für den OKSTRA® interessant, unter anderem die Felder zur zeitlichen Gültigkeit. Bild 2: Das LRS-Datenmodell von ESRI (ESRI, 2023b) Die Erweiterung „Roads & Highways“ verwendet das erweiterte Lineare Referenzierungsmodell (LRS) von ESRI. Dieses LRS-Modell bringt eine festgelegte Datenbankstruktur mit sich, welche als Grundlage für die SIB-EGDB verwendet wurde. Die Erweiterung beinhaltet zudem Standardnetzoperationen und erlaubt die Konfiguration von spezifischen Objektverhalten für jedes Event (Objekt) entsprechend der Netzoperation entlang der Straßenabschnitte. Daneben ist es zeitbezogen und erlaubt eine vollständige Historisierung (ESRI, 2023a). In der SIB-Bayern entspricht eine Route einem Abschnitt oder Ast. Initial besteht diese aus einer Centerline, welche die Geometrie enthält. Sobald Netzänderungen (beispielsweise Kurvenbegradigungen) erfolgen, wird diese Centerline in mehrere aufgeteilt und ermöglicht die Erzeugung der Route je nach Datum des abgerufenen Netzstands und damit des Verlaufs. Dies geschieht über die Centerline Sequence. Über die Kalibrierungspunkte wird die Messlänge eines Abschnitts mitgegeben, was prinzipiell in der Software möglich ist, um auch Punkte entlang eines Abschnitts zu setzen. Dies ist potenziell für starke Steigungen an Abschnitten interessant, um Verzerrungen zu vermeiden (ESRI, 2023b). Das „Roads & Highways“ Datenmodell unterstützt dabei initial keine ASB-spezifischen Objekte wie Netzknoten, BAB-Knoten oder die Straßentabelle. Diese wurden im Rahmen der Entwicklung ergänzt. Die Netzänderungsfunktionalitäten wurden mittels des Server Object Interceptor (SOI) um die notwendigen Attribute und Verhaltensweisen erweitert. Hierbei werden Anfragen und Antworten des Dienstes abgefangen, um diese an die individuellen Bedürfnisse der SIB-Bayern im Zusammenhang mit den fehlenden ASB-Komponenten anzupassen (ESRI, 2023c). 2.2 Die OKSTRA®-DatenbankUm die Daten gemäß OKSTRA® bereitstellen zu können, werden die Daten nächtlich mittels ETL-Prozesses in FME aus der SIB-EGDB in die OKSTRA®-Datenbank (eine PostgreSQL-Datenbank) migriert. Der Datenfluss in den sekundären Datenbestand ist unidirektional, das heißt es erfolgt kein schreibender Zugriff von der OKSTRA®-Datenbank in die SIB-EGDB. Um einen read-only OKSTRA®-konformen Webservice (OGC WFS 2.0 mit Datenabgabe als OKSTRA®-XML) für die Öffentlichkeit anzubieten, wird die OKSTRA®-Datenbank über den XtraServer von interactive instruments als WFS konfiguriert und veröffentlicht. Bild 3: OKSTRA®-Profil Das Datenbankschema entspricht der OKSTRA® Version 2.020. Da der OKSTRA® selbst durchaus umfangreicher ist als der Datenumfang der ASB und in Bayern nicht alle ASB-Objekte geführt werden, wurde ein reduziertes OKSTRA®-Profil erstellt. Dieses enthält den vollen im OKSTRA® darstellbaren Datenumfang der SIB-Bayern. Länder spezifische Wertetabellen wurden im OKSTRA®-Profil der SIB-Bayern ebenso mitberücksichtigt und ergänzt. Auch werden alle für das OKSTRA®-Profil der BISStra notwendigen Daten mitabgedeckt. Das Modell kann bei Bedarf modular erweitert werden. Bild 4: Mapping von der SIB-Bayern in die OKSTRA®-Datenbank am Beispiel der AoA-Daten Im Rahmen des FME-Prozesses werden OKSTRA®-spezifische Attribute erzeugt und bestehende Daten angepasst. So liegen beispielsweise Stationierungswerte in der SIB-Bayern in Metern vor, wohingegen OKSTRA® diese in Kilometern speichert. Die zur Überführung notwendigen Mappingtabellen liegen dazu der OKSTRA®-Datenbank vor. Auch müssen in ArcGIS Punkt- und Linienfeatures in getrennten Feature Classes geführt werden, beispielsweise Durchlässe, die sowohl längs als auch quer zur Straße vorkommen können und in der ASB in einem Objekt zusammengefasst sind. Für den OKSTRA® werden diese wieder in Multigeometrieobjekte zusammengeführt. Im Gegensatz dazu liegen Abschnitte und Äste in ASB und SIB-Bayern in einem Objekt vor, im OKSTRA® sind diese hingegen getrennt. Bild 5: FME-Prozess für Abschnitt und Ast 2.3 OKSTRA®-ExportIm OKSTRA®-Export werden nur Objekte ausgegeben, für welche es eine ASB- bzw. geeignete OKSTRA®-Modellierung gibt. Die übrigen landesinternen Datensätze (beispielsweise für den Großraum- und Schwertransport) werden nur mittels ESRI-Dienste (WFS, WMS, MapServer) ansprechbar sein. Hierbei handelt es sich jedoch um einen sehr geringen Anteil an den Daten, der auch nur für einzelne Fachsysteme von Interesse ist. Daneben bestehen Bestrebungen ASB bzw. OKSTRA® Änderungsanträge zu stellen. Der OkWS wird im Intranet sowie in leicht reduzierter Form im Internet zur Verfügung stehen. Bild 6: Anzeige des OkWS Features „Abschnitt“ in der FME 3 Weitere PlanungAufgrund des Projektumfangs und der Komplexität der Historisierung wird ein Teil der OKSTRA®-Implementierung in Release 1.0 ausgeklammert. Dies ist insofern möglich, da der Import und das Netzänderungsprotokoll nicht essentiell für einen grundlegenden Betrieb des neuen Systems bei vollständiger Ablösung des Altsystems sind und als reine Neuentwicklungen keine Minderung des Funktionsumfangs im Vergleich zum bisherigen System zur Folge haben. 3.1 OKSTRA®-ImportDer OKSTRA®-Import ist für ein folgendes Release nach Einführung der SIB-Bayern geplant. Hierbei wird eine OKSTRA®-XML in das Datenbankmodell der SIB-Bayern umgewandelt. Diese XML-Datei wird über die OKSTRA®-Importschnittstelle eingelesen und mittels FME in das SIB-Bayern Datenmodell überführt. Das Ziel der importierten Daten ist dabei nicht die OKSTRA®-Datenbank, sondern direkt die SIB-EGDB. Damit ist gewährleistet, dass immer der neuste Stand in der SIB-EGDB auch als zentraler Datenbestand vorgehalten wird. Das Schreiben der Daten erfolgt über eine separate Version, die anschließend – nach umfangreichen Prüfroutinen – in den Bestand zurückgeschrieben wird und somit nicht direkt in die Default-Version selbst. Dies hat zur Folge, dass die zu importierenden Daten bei erkannten Fehlern in den Prüfroutinen nochmals überarbeitet und für den Straßenbestand angepasst werden können. Damit wird jederzeit ein konsistenter Netzstand sichergestellt. Besondere Herausforderungen sind hierbei die Abbildung der Historisierung, landesinterne Schlüssel sowie eigene Festlegungen bei der Pflege. So wurde bei der Querschnitts- und Aufbaupflege zwar das ASB-Modell vollständig umgesetzt, jedoch wurden zur Wahrung der Datenkonsistenz eine Vielzahl an Einschränkungen und Plausibilisierungen über die Datenpflegeoberfläche implementiert. Diese Beschränkungen müssen entweder nachgezogen werden oder zu einem Ausschluss des Imports führen, da sonst eine Darstellung und Weiterverwendung in der Pflegeoberfläche nicht möglich ist. 3.2 OKSTRA®-konformes NetzänderungsprotokollEin weiterer offener Punkt zur Realisierung ist das OKSTRA®-konforme Netzänderungsprotokoll wie bereits anfänglich erwähnt. Die Realisierung soll in einem Folgerelease erfolgen. Durch dieses soll die Änderungshistorie an eine andere Datenbank mit demselben Netz übergeben werden können. Daher wurde bereits bei der Entwicklung der Netzoperationen darauf geachtet, dass entsprechende Vorbereitungen hinsichtlich (Netz-) Änderungsverhalten und Logging inkludiert sind. Auch ist es im OKSTRA®-Profil bereits angelegt, um später nicht noch einmal die Netzänderungsoperationen in ArcGIS Pro überarbeiten zu müssen. Schon zu Beginn des Projekts wurde sichtbar, dass das Netzänderungsprotokoll eine besondere Herausforderung darstellt, da bisher ein vollfunktionsfähiges Referenzprojekt fehlt, welches das Änderungsprotokoll sowohl schreiben als auch lesen kann. Eine Entwicklung ohne Referenz ist dabei nicht zielführend, da das OKSTRA®-konforme Netzänderungsprotokoll einen hohen Freiheitsgrad bei der Implementierung erlaubt, was dann möglicherweise zu inkompatiblen Schnittstellen führt. Bisher gibt es zwei grundsätzliche Ansätze für die Modellierung: entweder über identische Netzteile, was von der NW-SIB für die Historisierung genutzt wird, oder die Netzoperationen. Beide Modelle sind bereits in die Jahre gekommen, da bisher keine tatsächliche Umsetzung und Nutzung erfolgt ist, fehlt hier eine Aktualisierung. Zudem erfolgte die Konzipierung der OKSTRA®-Netzänderungsoperationen auf einer rein tabellarischen Struktur, worin geometrische Operationen nur schwer integrierbar sind. So können über das Netzänderungsprotokoll lediglich die Objekte („Sekundärdatenstand“) auf die veränderte Netzsituation angepasst werden, nicht aber das Netz selbst. Hierfür muss der vollständige neue Netzstand im OKSTRA®-Schema mitübergeben werden (OKSTRA® Pflegestelle, 2011). Bild 7: Netzänderungsprotokoll im OKSTRA® Basierend auf diesen Erkenntnissen soll in einem ersten Schritt ein Pilotprojekt mit einem „Konsumenten“ initiiert werden, um direkt ein Netzänderungsprotokoll zu entwickeln, das von bestehenden Produkten problemlos gelesen und umgesetzt werden kann. Des Weiteren soll geprüft werden, ob Anpassungen an der OKSTRA®-Modellierung möglich und notwendig sind. Hierbei sollen auch die identischen Netzteile betrachtet werden, über die ebenfalls die Historisierung abgebildet werden kann. 4 Fazit und AusblickDer OKSTRA® wurde erstmalig mit dem Allgemeinen Rundschreiben Straßenbau Nr. 12/2000 (BMVBW, 2000) eingeführt und seitdem als Voraussetzung für IT-Verfahren des Straßenbaus gefordert. Dennoch erfolgte in den nachfolgenden Jahren nur eine unzureichende Implementierung in diversen Datenbanksystemen und eine Fokussierung auf proprietäre Dienste und Austauschformate. Mit der SIB-Bayern wird diese Lücke daher erstmalig durch eine vollumfängliche und ASB-konforme Bereitstellung von Daten über OKSTRA® geschlossen. Dies ermöglicht Zukunftssicherheit und Kompatibilität mit den derzeit in Aufbau befindlichen und geplanten Fachsystemen sowie den Datenaustausch mit den bestehenden Straßeninformationsbanken anderer Bundesländer, der „Die Autobahn GmbH des Bundes“ und der Bundesanstalt für Straßenwesen (BASt). Allerdings wurde im Projektverlauf noch deutlich, dass der OKSTRA® wie auch die ASB konstant weiterentwickelt und überarbeitet werden müssen. Anzumerken sei hier etwa das Kapitel zur Historienverwaltung im ASB Kernsystem (BMVI, 2018). Die notwendigen ASB-Änderungsanträge werden im Rahmen der Fachgruppe ASB der Dienstbesprechung „Koordinierung der Bund/Länder Fachinformationssysteme im Straßenwesen“ (ITKo) durch Bayern eingebracht. Daneben bestehen im Land Diskussionen inwieweit weitere nicht-ASB Objekte, wie etwa die Unfallauswertung, mittels OKSTRA® abgebildet werden können. Der OKSTRA® weist hierzu bspw. bereits eine Modellierung auf, die jedoch den bayerischen Bedarf nur unzureichend abdeckt. Hier sollen ebenso entsprechende Änderungsanträge ausgearbeitet werden. Auch am OkWS und dem OKSTRA®-Werkzeug wurde Anpassungsbedarf sichtbar. So nutzt der OkWS derzeit noch das HTTP-Protokoll und es treten Probleme mit dem OKSTRA®-Werkzeug auf, da dieses u. a. noch nicht für WFS 2.0 optimiert ist. Hier bestehen aber bereits Analysen und Planungen von Seiten interactive instruments um entsprechende Anpassungen im Jahr 2024 durchzuführen. Im Hinblick auf das Building Information Modeling (BIM) ist die SIB-Bayern mit dem OKSTRA® gut gewappnet. Eine Straßendatenbank stellt bereits einen einfachen Digitalen Zwilling dar, aus welcher – je nach Datenverfügbarkeit – einfache 3D-Modelle abgeleitet werden können. Im Masterplan BIM wird der OKSTRA® neben dem IFC-Format (Industry Foundation Classes) als offenes BIM-geeignetes Datenaustauschformat genannt (BMVI, 2021). Zusätzlich wurde der OKSTRA® in den letzten Jahren um eine Vielzahl an BIM-Anforderungen (bspw. Volumenkörper oder generische Objekte) erweitert, weitere sind in Arbeit (Steyer; Jaud, 2022). Daneben ist eine grundsätzliche Ableitung des IFC-Road Standards aus dem OKSTRA® möglich (Amann; Bormann, 2015). Somit kann davon ausgegangen werden, dass die OKSTRA®-Schnittstelle auch für BIM, vor allem wenn die umfassenden Anpassungen an die Anforderungen weiter umgesetzt werden, ein zukunftssicheres Datenaustauschformat ist. LiteraturverzeichnisAmann, J.; Bormann, A. (2015): Open BIM for Infrastructure – mit OKSTRA® und IFC Alignment zur internationalen Standardisierung des Datenaustauschs. 6. OKSTRA®-Symposium 20./21. 5. 2015, Köln. Bd. FGSV 002/110 BMVBW (2000): Allgemeines Rundschreiben Straßenbau Nr. 12/2000; verfügbar unter https://www.okstra.de/docs/sonstige/okstra-ar.pdf (20.12. 2023) BMVI (2018): Anweisung StraßeninformationsBank – Version 2.04; verfügbar unter https://www.bast.de/DE/Publikationen/Regelwerke/Verkehrstechnik/Unterseiten/V-ASB.html (20.12. 2023) BMVI (2021): Masterplan BIM Bundesfernstraßen – Digitalisierung des Planens, Bauens, Erhaltens und Betreibens im Bundesfernstraßenbau mit der Methode Building Information Modeling (BIM); verfügbar unter https://bmdv.bund.de/SharedDocs/DE/Anlage/StB/bim-rd-masterplan-bundesfernstrassen. pdf? blob=publicationFile (21.12. 2023) ESRI (2023a): Was ist ArcGIS Roads and Highways? verfügbar unter https://pro.arcgis.com/de/pro-app/ latest/help/production/roads-highways/what-is-roads-and-highways.htm (20.12. 2023) ESRI (2023b): LRS-Datenmodell; verfügbar unter https://pro.arcgis.com/de/pro-app/latest/help/production/roads-highways/lrs-data-model.htm (20.12. 2023) ESRI (2023c): What is an SOI; verfügbar unter https://developers.arcgis.com/enterprise-sdk/guide/java/ what-is-soi-java (20.12. 2023) OKSTRA® Pflegestelle (2011): Schema Netzänderungsprotokoll; verfügbar unter https://www.okstra. de/docs/1015/d034-1015.pdf (20.12. 2023) Steyer, R.; Jaud, Št. (2022): OKSTRA® und IFC – Status 2022. 8. OKSTRA®-Symposium am 11./12. 5. 2022, Hamburg. Bd. FGSV 002/132 |