Joachim Schade studierte an der Hochschule Harz Technische Informatik und an der Hochschule Magdeburg Stendal Funkidentifikation und Nahbereichsfunk. Seit 2000 arbeitet er am Institut für Automation und Kommunikation in Magdeburg als Wissenschaftlicher Mitarbeiter im Bereich Verkehrstelematik. Zu seinen Aufgaben zählen unter anderem die Entwicklung von Client-Server-Lösungen in verkehrsrelevanten Anwendungen sowie die systematische Durchführung von Performancetests von Funklösungen aus dem Car-to-Car-Bereich.

Olaf Czogalla absolvierte ein Studium der Technischen Kybernetik und Automatisierungstechnik an der Technischen Hochschule Leipzig mit dem Abschluss als Diplomingenieur im Jahr 1987. Er arbeitete an der Otto-von-Guericke-Universität auf dem Gebiet der Regelungstechnik und Robotersteuerung. Als Mitbegründer des Instituts für Automation und Kommunikation arbeitet er bis heute als Projektleiter auf dem Gebiet der Verkehrssimulation, der Verkehrssteuerung und des Verkehrsmanagements. In gegenwärtigen Forschungsarbeiten beschäftigt er sich mit der Anwendung von Methoden der Geoinformatik im Bereich der intelligenten Verkehrssysteme.

Vor dem Hintergrund eines stetig steigenden Verkehrsaufkommens sind Maßnahmen unerlässlich geworden, die zur Optimierung des Verkehrsflusses und einer besseren Auslastung des Verkehrsnetzes führen. Hierzu zählt besonders eine rechtzeitige Information aller am Verkehrsprozess Beteiligten über die aktuelle Verkehrslage sowie über kurz-, mittel- und langfristige Baumaßnahmen mit Verkehrsbehinderungen. In diesem Zusammenhang ist unter anderem die effiziente Planung und termingerechte Durchführung von Baumaßnahmen im öffentlichen Straßenraum zu beachten, die in erheblichem Maße Einfluss auf den Verkehrsablauf hat.

1 Einführung

Vor dem Hintergrund eines stetig steigenden Verkehrsaufkommens sind Maßnahmen unerlässlich geworden, die zur Optimierung des Verkehrsflusses und einer besseren Auslastung des Verkehrsnetzes führen. Hierzu zählt besonders eine rechtzeitige Information aller am Verkehrsprozess Beteiligten über die aktuelle Verkehrslage sowie über kurz-, mittel- und langfristige Baumaßnahmen mit Verkehrsbehinderungen. In diesem Zusammenhang ist unter anderem die effiziente Planung und termingerechte Durchführung von Baumaßnahmen im öffentlichen Straßenraum zu beachten, die in erheblichem Maße Einfluss auf den Verkehrsablauf hat.

Bereits seit mehreren Jahren entwickelt und betreibt das ifak in Kooperation mit dem Tiefbauamt der Landeshauptstadt Magdeburg eine Informationsplattform zur Darstellung der aktuellen Baustellensituation im Stadtgebiet [1]. Für das Informationsmanagement der Baustellendaten ist ein universell einsetzbares Werkzeug entwickelt worden, mit dessen Hilfe sowohl die Verwaltung der einzelnen Baumaßnahmen als auch die Veröffentlichung und benutzerfreundliche Darstellung der Informationen in unterschiedlichen Medien vorgenommen wird. Ein Effizienzgewinn liegt hierbei in der einmaligen Erfassung der Baustellendaten durch den Sachbearbeiter der zuständigen Straßenverkehrsbehörde und der anschließenden automatischen Aufbereitung, Konvertierung und Verteilung der Informationen an weitere Systeme, wie das auf der TT-SIB basierende landesweite Baustelleninformationssystem SPERRINFO des Landes Sachsen-Anhalt.

Im Zuge der weiteren Konsolidierung, die einen einheitlichen Zugang zu diesen Informationen einer Vielzahl von Berechtigten ermöglichen soll, ist die Schaffung einer standardisierten und langfristig beständigen Schnittstelle für den Datenaustausch notwendig. Ein abgestuftes Rechtemanagement soll einen lesenden Zugriff für alle an den Baustelleninformationen interessierten Benutzern zulassen, bietet aber auch die Möglichkeit einer auf ihre Zuständigkeit bezogenen Datenpflege für institutionelle Nutzer des Systems. Um ein hohes Maß an Flexibilität und Interoperabilität zu erreichen, wird diese Schnittstelle über OKSTRA^®-konforme Web-Services realisiert. Das aus Gründen der Wirtschaftlichkeit und der Effizienz zum überwiegenden Teil unveränderte Datenhaltungssystem wird hierbei um eine Transformationsschicht ergänzt, die den OKSTRA^®-konformen Zugang ausschließlich über eine sichere, verschlüsselte HTTPS- Verbindung sicherstellt.

Während die genutzte OKSTRA^®-Schnittstelle einen Zugriff auf die Baustelleninformationen mit jedem standardkonformen Client gewährleistet, stellt das System ZEBRA (Zentral Baustellen Registrieren und Administrieren) darüber hinaus ein webbasiertes benutzerfreundliches Frontend für die Bearbeitung der Baustellendaten zur Verfügung. In gleicher Konsequenz ist die Kommunikationsschnittstelle dieses Frontends ebenfalls OKSTRA^®-konform ausgeführt. Aufgrund der browserbasierten Realisierung ist zur Benutzung dieses Frontends keine Installation von zusätzlicher Software erforderlich. 

2 Ausgangssituation

2.1 Baustellenverwaltungssoftware ZEBRA

An der Institution der Verfasser wurde mit der Unterstützung durch das Tiefbauamt Magdeburg eine Informationsplattform zur Darstellung der aktuellen Baustellensituation der Landeshauptstadt Magdeburg entwickelt, die sich seit mehreren Jahren im Einsatz befindet. Abbildung 1 zeigt die Benutzeroberfläche der javabasierten Software zur Baustellenverwaltung, wie sie gegenwärtig von der Straßenverkehrsbehörde des Tiefbauamtes in Magdeburg genutzt wird.

Abbildung 1: Baustellenverwaltungssoftware ZEBRA

2.2 Digitale Karte

Als Grundlage für die Darstellung der Baustellen und Umleitungen wird eine digitale Karte der Firma NAVTEQ verwendet. Die Grundbausteine der Karte setzen sich dabei aus sogenannten Links zusammen, welche eine bestimmte Länge besitzen und in einer bestimmten Richtung gezeichnet sind. Die Positionierung einer Baustelle erfolgt als Stationierung auf einem Link mit Angabe eines Offsets in Prozent, gerechnet vom Beginn des Links an in Zeichnungsrichtung. Die Wirkrichtung der Baustelle kann dabei in oder entgegen der Zeichnungsrichtung des Links angegeben werden. Umleitungen werden ebenfalls als Folge von Links angegeben, wobei die den Links zugehörigen Straßennamen für eine spätere textuelle Beschreibung der Umleitungsroute in einem Zug mit übernommen werden. Dieses Vorgehen stellt die Konsistenz von linkbasierten Umleitungsinformationen bspw. für Navigationsgeräte und textbasierten Umleitungsempfehlungen für Interessenten sicher.

Ein Nachteil bei Verwendung dieser digitalen Karte liegt im Anfallen von Lizenzgebühren bei deren Verwendung, die üblicherweise pro Benutzer erhoben werden. Darüber hinaus können notwendige Aktualisierungen der Karte nur durch den Eigentümer vorgenommen werden, hier fallen wiederum Kosten an. Die Einpflege eigener Erweiterungen ist nicht möglich.

2.3 Verwalten und Publizieren

Die Baustelleninformationen umfassen sowohl textuelle Beschreibungen, wie Ort, Dauer oder Ursache der Maßnahme als auch geografische Positionen für die Anzeige von Baustellensymbolen. Sämtliche Daten werden zunächst lokal vorgehalten und bei jedem Speichervorgang über eine gesicherte HTTPS-Verbindung zum Server übertragen. Konsequenterweise befinden sich keine Daten dauerhaft auf dem lokalen Rechner des Bearbeiters sondern werden einzig und allein auf dem Server gespeichert. Lokal dauerhaft vorgehalten werden nur Programm- und Konfigurationsdateien sowie die digitale Karte. Um dem missbräuchlichen Zugriff auf die Baustellendaten und deren Manipulation vorzubeugen, erfolgt der Zugang zum Server passwortgeschützt.

Die Publizierung der Baustelleninformationen erfolgt ebenfalls von der Baustellenverwaltungssoftware aus. Auf Anforderung werden zugleich HTML-Seiten für die Anzeige im Internet, optimierte Seiten für die Ausstrahlung im Digitalen Rundfunk DAB sowie WML-Seiten für die Anzeige auf WAP-fähigen, meist älteren Mobiltelefonen erzeugt. Die Anzeige im Internet beinhaltet außer der textuellen Beschreibung der Baustellen auch die Anzeige eines Symbols auf einer OSM-basierten Karte.

2.4 Verbindung zum Sperrinformationssystem Sachsen-Anhalt

Über die Publizierung der Baustelleninformationen auf dem eigenen Internetportal http://movi.de hinaus erfolgt auch eine Weiterleitung der entsprechenden Daten an das sachsen-anhaltische landesweite Baustelleninformationssystem SPERRINFO. Zu diesem Zweck wird die für Drittanwender zur Verfügung gestellte WFS-Schnittstelle der Applikation SperrInfoSys zur Einpflege von Baustelleninformationen genutzt. Über einen VPN-Zugang wird die Verbindung zu einem zentralen Server hergestellt, aus Sicherheitsgründen übernimmt dies ein allein für diesen Zweck bereitgestellter virtueller Server, der sich nur temporär für die erforderliche Zeit der Aktualisierung mit dem zentralen Server verbindet. Auf diese Weise erfolgt die Synchronisierung der lokal vorhandenen Baustelleninformationen mit den Sperrinformationen aus dem SperrInfoSys Über die WFS-Schnittstelle. 

3 Lösungsansätze mit OpenSource

Die Entwicklung innovativer Anwendungen ohne das Anfallen kostenintensiver Softwarelizenzgebühren oder die aufwändige Erstellung eigener, proprietärer Lösungen ist mit der Verfügbarkeit und der freien Verwendung entsprechender, OpenSource basierter Frameworks in den letzten Jahren zunehmend einfacher geworden. Als Konsequenz sind in der Regel die mit Hilfe von OpenSource-Lösungen entwickelten Anwendungen der Allgemeinheit wiederum als OpenSource zur Verfügung zu stellen. Gegebenenfalls muss dies bei der Aufstellung eines Geschäftsmodells berücksichtigt werden. Auch die Erweiterung der hier vorgestellten Baustellenverwaltungssoftware hin zu mehr Benutzerfreundlichkeit, Flexibilität und Bedienkomfort profitiert stark vom OpenSource-Gedanken. Nachfolgend sind die hierfür zur Anwendung kommenden OpenSource-Projekte aufgelistet und näher beschrieben.

3.1 Die freie Weltkarte OpenStreetMap

OpenStreetMap (OSM) ist ein Projekt zur Erstellung einer freien, für jedermann zugänglichen und benutzbaren Weltkarte [2]. Jeder, der sich an diesem Projekt beteiligen möchte, kann durch das Einpflegen eigener Kartendaten an der Vervollständigung dieser Karte mitarbeiten.

Die Verwendung von OSM für die Baustellenverwaltung bringt einige Vorteile mit sich. In erster Linie ist sicherlich die freie Verwendung und damit das Wegfallen von Lizenzgebühren zu nennen, zudem können Vervollständigungen und Berichtigungen der Karte leicht selbst vorgenommen werden, wobei die Daten direkt in die Basis eingepflegt werden und somit auch wieder der Allgemeinheit zur Verfügung stehen. Über frei im Internet verfügbare WMS-Server können auf OSM basierende Karten in Form von Bildkacheln abgerufen und zur Anzeige in die eigene Webanwendung eingebunden werden. Die Erstellung eigener Kartenlayer, die über das Basislayer der OSM-Karte gelegt und wahlweise ein- und ausgeblendet werden können, ermöglicht die flexible Darstellung eigener Karteninhalte. Um unabhängig von internetbasierten Fremdanbietern zu sein, besteht darüber hinaus die Möglichkeit, aus den vorhandenen OSM-Daten und mit Hilfe eines eigenen WMS-Servers selbst eine Karte nach individuellen Anforderungen zu erzeugen und für die Darstellung zu verwenden.

3.2 Das Framework OpenLayers

Das OpenSource basierte JavaScript-Framework OpenLayers ermöglicht die Darstellung geografischer Karten in Websites sowie die komfortable und benutzerfreundliche Interaktion mit ihnen [3]. Hierzu zählen unter anderem Zoomfunktion, Verschieben der Karte, das Einblenden eigener dynamischer Inhalte in die Karte oder die Darstellung eigener, über die Basiskarte überlagerter Kartenlayer. Die von aktuellen kartenbasierten Anwendungen wie Google Maps bekannte und von den Anwendern mittlerweile erwartete Funktionalität und Bedienerfreundlichkeit  diente auch als Anforderungsmaßstab für die hier vorgestellte Baustellenverwaltungssoftware. Eine komfortable Bearbeitung der Baustellen inklusive Platzieren und Verschieben von Baustellensymbolen und Zeichnen und Bearbeiten von Umleitungen direkt auf der Karte stehen ebenso im Focus wie eine ansprechende Darstellung für die Bürgerinformation. Die durchgehende Verwendung von auf OSM basierenden Karten und OpenLayers sowohl bei der administrativen Verwaltung der Baustellen als auch bei der Darstellung der generierten und der Öffentlichkeit bereitgestellten Baustelleninformationen garantiert somit Konsistenz zwischen den eingegebenen Daten und den publizierten Informationen. Eine aufwändige Konvertierung in andere Bildformate oder ein Mapping auf andere Kartenformate entfällt hierdurch.

3.3 Framework basierte Entwicklung von Webapplikationen

Die Entwicklung moderner und ansprechender Websites ist mit dem Aufkommen JavaScript- basierter Frameworks zunehmend einfacher geworden. Das Google Web Toolkit (GWT) [4] erlaubt die Erstellung anspruchsvoller Webapplikationen, sogenannter Rich Internet Application (RIA) in der Programmiersprache Java. Nach einem Compilerdurchlauf wird hierbei aus dem Java-Code browserunabhängiger JavaScript-Code erzeugt (s. Abbildung 2), die Anwendungen sind danach direkt im Browser lauffähig. Ext GWT [5] erweitert GWT noch um zusätzliche Features und ermöglicht die Entwicklung browserbasierter Webapplikationen, die in Aussehen und Funktionsumfang Desktop-Anwendungen ähneln und zugleich den Vorteil besitzen, keine Installation mit eventuell notwendigen Administratorrechten zu benötigen.

Abbildung 2: Erstellung einer Webapplikation mit GWT

Für die Erstellung einer Webapplikation mit dem Charakter einer Desktop-Anwendung, wie sie für Verwaltungssoftware in Betracht kommt, sind framework-basierte Toolkits wie Ext GWT, welche kurze Entwicklungszeiten bei einem hohen Grad an Funktionalität bieten, gut geeignet. Der große Vorteil gegenüber einer reinen Desktopanwendung besteht bei den hier vorgestellten Applikationen aber in der nahtlosen Integration der auf OpenLayers basierenden Kartendarstellung in die Webanwendung. Serverseitig kommt ebenfalls Java zur Anwendung, so dass die einheitliche Entwicklung dieser verteilten Anwendung in einer Programmiersprache gewährleistet ist. Die Kommunikation zwischen Front End (Webanwendung) und Back End (Application Server) erfolgt dabei über eine gesicherte HTTPS-Verbindung. 

4 Referenzierung von Punkt- und Linienobjekten

Der Nutzwert von Baustelleninformationen wird erheblich gesteigert, wenn über die Darstellungen von Baustellen und Umleitungen auf der Karte zur reinen Bürgerinformation hinaus auch eine Referenzierung der geografischen Objekte erfolgt. Dies ist Voraussetzung für die weitere Verarbeitung und Nutzbarmachung dieser Informationen durch andere Systeme und ermöglicht bspw. Navigationsgeräten erst ein intelligentes Routing unter Beachtung der Baustellensituation. Unter dem Begriff der Referenzierung wird im Folgenden die Herstellung des Bezugs eines gegebenen Objektes zu einer bekannten und verfügbaren Netzgrundlage verstanden. Eine konkrete Netzgrundlage stellt eine digitale Karte dar, die als Graph eine Knoten- und Kantentopologie besitzt und auf die mittels eines Geodatenbanksystems oder eines geografischen Informationssystems zugegriffen werden kann. Beispiele hierfür sind die Straßeninformationsdatenbanken der Länder in Gestalt von TT-SIB oder NW-SIB, ferner die für Navigationszwecke genutzten Straßenkarten wie NAVTEQ oder Straßendatenbanken, die zur kommunalen Bestandsdokumentation ebenfalls nach dem Standard der „Anweisung Straßendatenbank“ (ASB) aufgebaut und kontinuierlich fortgeschrieben werden.

Punktobjekte stellen zum Beispiel einzelne Baustellen im innerstädtischen Bereich mit einer geringen geografischen Ausdehnung dar. Linienobjekte werden zur Darstellung von Baustellen im Außerortsbereich, insbesondere auf den Bundesautobahnen genutzt. Auf ähnliche Weise werden verschiedene Kartengrundlagen durch die wechselseitige Referenzierung ihrer Linienobjekte miteinander in Bezug gesetzt. In den folgenden Unterabschnitten werden diese Aspekte ausführlicher beschrieben.

4.1 Referenzierung von Baustellen als Punktobjekt

Für die Darstellung von innerstädtischen Baustellen über dem Hintergrund einer Stadtgrundkarte ist in der Regel ein Punktobjekt hinreichend, dessen Koordinaten bei der Erfassung bestimmt und als geografische Eigenschaft des Baustellenobjektes für die Weiterverarbeitung gespeichert werden (siehe Abbildung 3).

Abbildung 3: Innerstädtische Baustellen mit Punktkoordinaten

Die Koordinaten stehen dabei entweder als geographische Weltkoordinaten in Länge und Breite (z.B. WGS84) oder in Form eines bekannten Koordinatensystems (z.B. Gauß-Krüger) zur Verfügung. Die Weiterverarbeitung der Baustellenobjekte erfolgt im Rahmen des landesweiten Baustelleninformationssystems Sachsen-Anhalt zur einheitlichen Darstellung aller im Land verfügbaren Sperrinformationen in einem einheitlichen Auskunftssystem. Hierfür werden die von den zuständigen Behörden in den Landkreisen, kreisfreien Städten und auf den Bundesautobahnen landesweit erfassten Sperrinformationen in einer Geodatenbank zunächst zwischengespeichert.

Zur Ermittlung der durch die Sperrung oder Einschränkungen verursachten verkehrlichen Auswirkungen ist es erforderlich, deren Referenzierung auf die verwendete Netzgrundlage herzustellen. Für das überörtliche Straßennetz im Land Sachsen-Anhalt, bestehend aus den Bundesautobahnen, den Bundes-, Landes und Kreisstraßen existiert eine umfangreiche Bestandsdokumentation im Rahmen einer der Anweisung Straßendatenbank (ASB) konformen Straßeninformationsdatenbank (TT-SIB). Das hier als Landesnetz bezeichnete Straßennetz beinhaltet neben den räumlichen Informationen über die geografische Lage der Straßenabschnitte sämtliche für die den Betrieb und Unterhaltung erforderlichen Sachdaten. Das darin verwendete Bezugssystem ist das Netzknoten-/Stationierungssystem. Ein Netzknoten ist als Kreuzungspunkt von Verkehrswegen im Landesnetz definiert. Die eindeutige Bezeichnung der Netzknoten wird dabei aus der Nummerierung des Planquadrates der TK25-Grundkarte abgeleitet. Zwei benachbarte Netzknoten werden durch einen Abschnitt verbunden, dessen eindeutige Bezeichnung aus der Straßenbezeichnung und einer fortlaufenden Abschnittsnummer gebildet wird. Jeder Abschnitt ist durch eine Stationierungsrichtung bestimmt. Die Stationierung dient der Referierung von punkt- oder linienförmigen Objekten entlang des Abschnittes und wird in Metern angegeben. Sie beginnt im Startknoten des Abschnitts und endet im Endknoten mit der Länge des Abschnitts.

Eine Referenzierung von Punkt- oder Linienobjekten kann somit im Bezugssystem der TT-SIB durch die Angabe der Abschnittsnummer und der Stationierung eindeutig erfolgen. Im Landesnetz können die Sperrinformationen entweder bei ihrer Erfassung oder in einem nachträglichen, automatisierten Bearbeitungsschritt auf die Netzgrundlage bezogen werden. Für die innerörtlichen Baustellen in den kreisfreien Städten hingegen, die nicht auf einem Abschnitt des Landesnetzes liegen, ist die Verwendung einer weiteren Kartengrundlage erforderlich. Der automatisch ausgeführte Bearbeitungsschritt zur Herstellung der Referenz auf die jeweils verwendete Kartengrundlage besteht in der Anwendung geografischer Verarbeitungsfunktionen innerhalb der Geodatenbank (PostGIS) zur Zwischenspeicherung der Sperrinformationen und des Verkehrsnetzes als Kartengrundlage. Das Grundprinzip der Referenzierung ist in der Abbildung 4 dargestellt.

Abbildung 4: Prinzip der Referenzierung

Anhand der gegebenen Koordinaten eines Punktes aPoint liefert die Suche nach dem nächsten Nachbar das Linienobjekt Nearest_Neighbor aus der Ebene des Straßennetzes. Dieses Linienobjekt repräsentiert einen Straßenabschnitt zwischen den Punkten from und to. Beide Endpunkte sind Knoten des Netzes und haben weitere Kanten mit der Möglichkeit zur Aufteilung von Verkehrsströmen. Die in der Geodatenbank anzuwendende Funktion ST_locate_point zur linearen Referenzierung liefert die Station des Punktes mit der geringsten Entfernung zu aPoint entlang des Abschnittes und in Richtung der Netzkante. Die Station bzw. Offset wird im Intervall (0,1) zurückgeliefert und kann anhand der bekannten Länge des Links auch als absoluter Wert angegeben werden. Mit dem netzweit eindeutigen Bezeichner des Abschnitts Nearest_Neighbor und der Angabe der Station ist die lineare Referenzierung über die geografischen Eigenschaften der Objekte gegeben. Für einen beliebigen Netzabschnitt eines kommunalen Straßennetzes kann nunmehr eine eindeutige Referenz anhand des Straßenabschnittes und der Stationierung angegeben werden. Damit ist die Möglichkeit des Austausches von Sperrinformationen anhand einer gemeinsamen Kartengrundlage möglich, auf die von verschiedenen Instanzen der Verarbeitung aus Bezug genommen werden kann.

4.2 Bildung einer Knoten/Kanten-Topologie für OpenStreetMap

Für die Herstellung eines eindeutigen Netzbezuges, der neben dem überörtlichen Netz auch im Bereiche der kommunalen Straßennetze umfasst, wird eine alternative Netzgrundlage vorgeschlagen, die sowohl landesweit als auch bundesweit eingesetzt werden kann und frei von Lizenzrechten Dritter ist. Die bereits beschriebene weltweite digitale Straßenkarte OpenStreetMap wird von einer großen dezentral agierenden Nutzergemeinschaft erstellt und weitergeführt. Sie weist im Vergleich zu kommerziell verfügbaren Karten aufgrund der kontinuierlichen dezentralen Pflege einen höheren Aktualisierungsgrad auf.

Der Erfassungsprozess stützt sich auf die Nutzung von handelsüblichen GPS-Empfängern, mit denen Straßenverläufe und die Position von Knotenpunkten als Straßenkreuzungen mit ausreichender Genauigkeit vermessen werden. Die Vergabe von Bezeichnern für jeden Knotenpunkt erfolgt dabei permanent, das heißt eine einmal vergebene Identifikationsnummer wird beibehalten, solange dieser Knotenpunkt in der Realität existiert. Die Technik der Erfassung bringt es mit sich, dass die Netzdefinition von OpenStreetMap so gewählt wurde, dass ein lineares Netzelement zur Darstellung von Wegeverbindungen und Straßen über mehrere Knotenpunkte hinweg führen kann. Das hat zur Folge, dass die Repräsentation dieses Netzes keine Knoten/Kanten-Topologie aufweist, wie sie zur Identifikation eines einzelnen Abschnittes entlang eines Straßenzuges, oder für ein Routingverfahren erforderlich ist. Für die Schaffung einer allgemein nutzbaren Netzgrundlage zur Referenzierung von Punkt- oder Linienobjekten im bisher beschriebenen Sinn ist daher eine Auftrennung aller Linienobjekte erforderlich, die über mehr als zwei benachbarte Knotenpunkte hinausgehen. Die Umformung des Netzes ist mit Hilfe der Funktionalität des genutzten Geodatenbanksystems PostGIS möglich.

Daher wurde für das Land Sachsen-Anhalt diese zu kommerziellen Anbietern alternative Netzgrundlage erarbeitet, die insbesondere im Bereich kommunaler Straßensysteme die vorhandene Referenzierung auf Basis des überörtlichen Netzes ergänzen kann.

Entscheidend für die öffentliche Nutzung einer durch private Nutzer aktualisierten Datengrundlage ist die Vergabe von permanenten und eindeutigen Bezeichnern für alle Netzknoten als Verzweigung von Verkehrsbeziehungen. Das bedeutet, dass eine eineindeutige Referenz eines beliebigen Objektes zu erstellen ist, die mit Bezug auf die genutzte Karte einem ebenfalls eindeutigen geografischen Ort zugeordnet werden kann.

Abbildung 5: Innerstädtischer Ausschnitt aus OpenStreetMap mit permanent bezeichneten Straßenabschnitten und Angabe der Stationierungsrichtung

Die eindeutige Identifikation eines Abschnittes erfolgt über die Nutzung der ebenfalls eindeutigen und permanenten Bezeichner der jeweils benachbarten Knotenpunkte. Ein Ausschnitt aus der so aufbereiteten Kartengrundlage ist in der Abbildung 5 dargestellt, die auch die Vergabe der eindeutigen, permanenten Abschnittsbezeichnungen zeigt. Die Bezeichner von Start- und Endknoten bilden in verknüpfter Form für jeden Abschnitt eine neue Bezeichnung, die für die Kartengrundlage OpenStreetMap eindeutig und permanent ist und deshalb ebenfalls zur allgemeinen Referenzierung vorgeschlagen werden kann.

Anhand dieses Beispiels wird die Vorgehensweise deutlich, mit der für das Gebiet von Sachsen- Anhalt eine vollständige digitale Karte aus dem System von OpenStreetMap extrahiert und einschließlich ihrer geografischen Information gespeichert wurde. Im Ergebnis steht das gesamte Straßennetz als Menge von Netzkanten zur Verfügung, die über eine eindeutige und permanente Identifikation verfügen, die aus den Knotenbezeichnungen abgeleitet wurden.

4.3 Zuordnung von TT-SIB-Abschnitten zu OpenStreetMap-Kartensegmenten

Für die Schaffung einer wechselseitigen Referenz zwischen unterschiedlichen digitalen Karten bestehen verschiedene grundlegende Ansätze. Im Rahmen von europäischen Forschungsprojekten, siehe [6] und [7], wurde das Verfahren AGORA bzw. AGORA-C zur Referenzierung von raumbezogenen Daten auf unterschiedliche Kartengrundlagen entwickelt. Mit diesem Verfahren können, unter der Voraussetzung, dass für die zu nutzenden digitalen Karten Encoder- und Decodersoftware zur Verfügung stehen, in denen das Referenzierungsverfahren implementiert ist, raumbezogene Daten ohne Zwischenspeicherung oder Nutzung von Übersetzungstabellen, das heißt „on-the-fly“, ausgetauscht werden. Das Verfahren AGORA wurde in der Nachfolge der Forschungsprojekte patentiert und standardisiert [8]. Die Anwendung dieses lizensierten Standards verzögerte sich bisher aufgrund der Unsicherheit über die Verbindlichkeit der Nutzung durch die marktführenden Hersteller und Anbieter digitaler Karten und Navigationssysteme. Weiterhin behindern eine unvorhersehbare Lizenz- und Nutzungskonzeption die weitere Anwendung dieses Verfahrens. Um die so entstandene Situation aufzulösen, wurde von der Firma TomTom International B.V. die Entwicklung eines weiteren Verfahrens zur Kodierung, Übertragung und Dekodierung raumbezogener Referenzen angeregt und in der Folge unter dem offenen Standard OpenLR veröffentlicht, siehe [9]. Die Lizenzsituation gestattet eine freie Anwendung des Verfahrens zur wechselseitigen Referenzierung zwischen verschiedenen Kartengrundlagen, erfordert aber ebenfalls den Entwurf und die Implementation von Decoder- und Encodersoftware für den beabsichtigten Datenaustausch ohne Zwischenschritt oder tabellarischen Bezug, der als „on-the-fly“ bezeichnet wird. Die ist insbesondere dann erforderlich, wenn der Datenaustausch zwischen mehreren verschiedenen Kartengrundlagen und Versionen zu erfolgen hat.

Eine weitere Möglichkeit des Austauschs räumlicher Daten ohne Nutzung von Decodern und Encodern erweist sich als geeignet, wenn diese Daten nur zwischen zwei verschiedenen digitalen Karten vermittelt werden müssen. Hierzu wird eine Referenztabelle erstellt, die für jedes Segment bzw. Netzkante einer in der Granularität übergeordneten Karte alle Segmente der feiner aufgelösten Karte beinhaltet, die vom gleichen Start- zum gleichen Zielpunkt führen.

Auf diese Weise können zum Beispiel raumbezogene Daten, die im Netzknoten-/ Stationierungssystem der TT-SIB in Form von Abschnittsnummer und Station angegeben werden, unmittelbar in einer weiteren digitalen Karte referenziert werden.

Zur Ermittlung dieser Referenztabelle wird ein Verfahren der Kurzwegsuche angewandt, das um einen Optimierungsschritt derart ergänzt wird, dass nur die jeweils kürzeste Verbindung zwischen zwei gegebenen Punkten als Ergebnismenge geliefert wird.

Abbildung 6: Referenzierung von Netzsegmenten in der OpenStreetMap -Karte (rot) zwischen den benachbarten Netzknoten eines Abschnitts der TT-SIB (grün)

Das Verfahren wurde unter Nutzung der verfügbaren Funktionalität des Geodatenbanksystems PostGIS mit Hilfe der Datenbanksprache SQL implementiert. Den Ausgangspunkt bilden die geografischen Koordinaten der benachbarten Netzknoten eines Abschnittes der TT-SIB, die in der Abbildung 7 mit VonNK und NachNK bezeichnet sind. Mit diesen Koordinaten werden die Start und Zielpunkte einer Schar von Segmenten des zu referenzierenden Netzes (hier: OpenStreetMap) ermittelt. Mit Hilfe des in PostGIS verfügbaren Suchalgorithmus‘ shortest_path werden die Segmente ID#1, ID#2 und ID#3 gefunden und als Ergebnis mit Link- und Knotenbezeichnern der OpenStreetMap-Karte (siehe Abbildung 6) sowie der zugehörigen Netzknotennummer aus der TT-SIB-Karte als Tabelle gespeichert. Insbesondere im Bereich von komplexen Knotenpunkten von Autobahnkreuzen oder -anschlüssen besteht die Möglichkeit, dass der Suchalgorithmus im ersten Lauf nicht die kürzeste Verbindung zwischen Start- und Zielpunkt in dem zu referenzierenden Netz liefert, weil zunächst nähergelegene Start- und Zielpunkte von Segmenten (z.B. Brücke, Zubringer o.ä.) ermittelt werden, die nicht Bestandteil der gesuchten Kurzroute sind. Um diese Fälle auszuschließen, werden sämtliche Routen von drei verschiedenen Startpunkten bis zu drei verschiedenen Endpunkten, die sich in unmittelbarer Nähe der gegebenen Start und Endpunkte befinden, gesucht und entsprechend ihrer Länge geordnet. Als Ergebnis wird nur die kürzeste Route in Form einer Liste von Einträgen in die Tabelle nach Abbildung 7 zurückgeliefert.

Abbildung 7: Ausschnitt aus der Ergebnistabelle als Referenz zwischen Netzknoten der TT-SIB (nnk, vnk) und Segmenten derOpenStreetMap-Karte (edge_id, s, t) in Gestalt einer 1:n-Beziehung

Mit dieser für das gesamte Land Sachsen-Anhalt aufbereiteten Ergebnistabelle ist eine schnelle Referenzierung zwischen den unterschiedlichen Karten möglich, die vor allem für den direkten Austausch von Sperrinformationen zwischen den beschriebenen Kartengrundlagen im inner- und außerörtlichen Bereichen benötigt wird. 

5 OKSTRA^®-konforme Datenschnittstelle

5.1 Systemarchitektur

Um einer Vielzahl von Bedarfsträgern einen einheitlichen Zugang zu den Informationen des Baustelleninformationssystems zu ermöglichen, ist die Schaffung einer standardisierten und langfristig beständigen Schnittstelle für den Datenaustausch notwendig. Ein abgestuftes Rechtemanagement ermöglicht lesenden Zugriff für alle an den Baustelleninformationen interessierten Benutzern, bietet aber auch die Möglichkeit, Daten in das System einzutragen, zu ändern und zu löschen.

Um ein Höchstmaß an Flexibilität und Interoperabilität zu erreichen, wird diese Schnittstelle über OKSTRA^®-konforme Web-Services realisiert. Aus Gründen der Wirtschaftlichkeit und der Effizienz wird das vorhandene Datenhaltungssystem in weiten Teilen unverändert belassen. Abbildung 8 zeigt die Systemarchitektur des Gesamtsystems.

5.2 Datenhaltung

Eines der Hauptziele bei der Erarbeitung des OKSTRA^®-Standards [10] ist die Schaffung eines standardisierten Datenaustauschs zwischen heterogenen Systemlandschaften ohne die Erfordernis einer grundlegenden Umstrukturierung der jeweiligen Datenhaltungssysteme. So wurde auch die Datenhaltung für die Speicherung aller für die Baustellenverwaltung ZEBRA relevanten Daten in weiten Teilen belassen. Aus Gründen der besseren Verständlichkeit sind im Modell, das in Abbildung 8 dargestellt ist, auch jene Systeme aufgeführt, die nicht Bestandteil der hier vorgestellten Baustellenverwaltung sind, aber über Schnittstellen Daten mit dieser austauschen.

Abbildung 8: Schichtenmodell des Gesamtsystems

Daten für das System der Baustellenverwaltung werden in teils unterschiedlichen Formaten gespeichert. Während bspw. für die Speicherung der Baustellendaten relationale Datenbankmanagementsysteme (MySQL und PostGreSQL) verwendet werden, sind die für das Rechtemanagement benötigten Benutzer und ihre Rollen in entsprechenden Konfigurationsdateien gespeichert. Die als Grundlage für das automatische Routing von Umleitungsstrecken notwendige OSM-Karte liegt ebenfalls als Datei vor und wird durch den Applikationsserver bei dessen Start eingelesen. Der Zugriff auf das System zur Datenhaltung erfolgt ausnahmslos über den Applikationsserver über die Protokolle der jeweiligen Schnittstellen und ist somit vollständig vom öffentlichen Zugriff entkoppelt, wodurch eine weitgehende Beibehaltung der bestehenden Datenhaltungssysteme gewährleistet ist.

Obwohl nicht Bestandteil des hier vorgestellten Baustellenverwaltungssystems, ist im engeren Sinn auch das Sperrinformationssystem des Landes Sachsen-Anhalt zur Ebene der Datenhaltung zu zählen und ist aus diesem Grund auch in Abbildung 8 als grau dargestelltes Symbol mit aufgeführt. Die Datenhaltung erfolgt hier durch zentrale Server des Landesrechenzentrums Sachsen-Anhalt, die Synchronisierung mit dem Baustellenverwaltungssystem erfolgt über das HTTP-Protokoll und ein gesichertes VPN (siehe Abschnitt 2.4).

5.3 Datenbereitstellung

Als öffentliche Schnittstelle für den Zugriff auf das Baustellenverwaltungssystem stellt die Datenbereitstellungsschicht standardkonforme Methoden für Lese- und Schreiboperationen zur Verfügung. Ein Applikationsserver (Apache Tomcat) als zentrale Serverkomponente übernimmt die Verbindung mit der Basisschicht Datenhaltung und ermöglicht höheren Schichten die Kommunikation über eine standardisierte OKSTRA^®-WFS-Schnittstelle. Diese Schnittstelle können sowohl Informationsportale für die Bürgerauskunft als auch Clientapplikationen für die Verwaltung der Baustellen nutzen. Zum Schutz vor Manipulation und unberechtigtem Abhören der übermittelten Daten erfolgt die Kommunikation bei schreibenden Operationen über eine gesicherte und verschlüsselte HTTPS-Verbindung. Clients die lediglich lesenden Zugriff für die Aufbereitung und Darstellung der Baustelleninformationen benötigen, können die HTTP-Schnittstelle verwenden.

In der Datenbereitstellung erfolgt auch die Prüfung der Zugriffsrechte des aktuellen Benutzers. Hierzu muss sich ein Anwender zu Beginn mit gültigem Benutzernamen und Passwort einloggen. Die Erlaubnis für das Ausführen einer bestimmten Operation wird nur erteilt, wenn die zugewiesene Rolle des Benutzers mit den entsprechenden Rechten versehen wurde. Beim Zugriff ohne Angabe einer Benutzerkennung oder bei Nutzung der ungesicherten HTTP-Schnittstelle erfolgt die Zuweisung eines Standardbenutzers, dessen Rolle nur lesenden Zugriff für ausgewählte Inhalte erlaubt.

Um die Mechanismen der Authentifizierung von den OKSTRA^®-WFS zu trennen, wurde auf eine Integration von Benutzerdaten in die zu übertragenden OKSTRA^®-Daten verzichtet. Zur Anwendung kommt stattdessen HTTP-Authentifizierung, bei der die entsprechenden Benutzerdaten im HTTP-Header übertragen werden. Hierdurch entfällt die Mitführung der Benutzerkennungen in den zu übertragenen OKSTRA^®-Daten, darüber hinaus benötigen browserbasierte Clientapplikationen keine zusätzlichen Mechanismen für das Login und die Speicherung von Benutzerdaten, da dies vollständig vom Webbrowser übernommen wird. Die Implementierung von Benutzerverwaltung und Authentifizierung erfolgt demnach ausschließlich auf dem Server. Bei der Entwicklung eigener, nicht browserbasierter Clientapplikationen ist darauf zu achten, dass die entsprechende Benutzer-Passwort-Kombination im HTTP-Header mitgeführt wird.

Abbildung 9: Entkopplung von OKSTRA^®-WFS und Authentifizierung

Eine weitere Komponente, welcher der Datenbereitstellungsschicht zugeordnet werden kann, ist der WMS-Server, welcher die Bilder (Kacheln) für die Kartendarstellung der Basiskarte in der Präsentationsschicht liefert. Der WMS-Server selbst ist nicht Bestandteil des hier vorgestellten Systems. Vielmehr wird hierfür einer der über das Internet frei verfügbaren WMS-Server in Anspruch genommen. Im Gegensatz zur gesicherten HTTPS-Verbindung für die Übermittlung der OKSTRA^®-Daten kommt hier eine ungesicherte HTTP-Verbindung zur Anwendung, was aber angesichts der Tatsache, dass nur Daten abgefragt werden, von untergeordneter Bedeutung ist.

5.4 Präsentation

Wie in Abbildung 8 zu sehen, erfolgt zwischen den beiden Schichten Datenaufbereitung und Präsentation keine strikte Trennung. Da die im Rahmen der Baustellenverwaltung zum Einsatz kommenden Clientapplikationen die Zuständigkeiten beider Schichten in sich vereinen, erfolgt hier die Zusammenfassung zu einer gemeinsamen Ansicht. Je nach Verwendungszweck (Werkzeug für die Baustellenadministrierung, Webseiten für die Bürgerauskunft) besitzen die Clientapplikationen dabei unterschiedliche Implementierungen.

Als Basis für die Darstellung der Baustellen dient eine digitale Karte auf der Basis von OSM, welche über einen externen WMS-Server bezogen und dargestellt wird. Über die Wahl des Anbieters kann auch eine unterschiedliche Kartendarstellung erreicht werden. Optional besteht auch die Möglichkeit, über das Aufsetzen eines eigenen WMS-Servers eine völlige Unabhängigkeit von externen Anbietern zu erreichen. Die Verbindung zum WMS-Server und die Darstellung der Karte übernimmt die JavaScript-Bibliothek OpenLayers, welche auch Funktionen für die Dynamisierung, wie Zoomfunktion oder Verschieben des Kartenausschnitts zur Verfügung stellt. Baustellen und Umleitungen werden als eigenständiger, dynamischer Layer der Basiskarte überlagert und bieten aufgrund der clientseitigen Implementierung die Möglichkeiten der Interaktion des Benutzers (Anzeigen von Tooltips, Mouse-Events, farbliche Hervorhebung) ohne für jede Interaktion eine Verbindung zum Server aufbauen zu müssen. Abbildung 10 zeigt die Darstellung einer Baustelle mit empfohlener Umleitung, bspw. für die Anzeige bei der Bürgerauskunft.

Abbildung 10: Baustelle mit angezeigter Umleitung

Die Implementierung der OKSTRA^®-WFS-Schnittstelle für das Lesen und Schreiben der Baustellendaten auf Seiten der Clientapplikation erfolgt mit Hilfe einer auf JavaScript basierenden Schnittstelle – die als OKWFS Client API bezeichnet wird. Dieses, unter Benutzung von Ajax (Asynchronous JavaScript and XML) zu entwickelnde JavaScript-Framework erlaubt die Kommunikation und den Datenaustausch mit dem Server ohne dabei die Webseite fortwährend neu laden zu müssen und stellt das Gegenstück zum OKSTRA^®-WFS des Applikationsservers dar. Clientapplikationen, sowohl für den Einsatz zur Administrierung der Baustellen als auch Informationsseiten für die Darstellung der Baustelleninformationen können diese API für ihre Zwecke nutzen und einbinden. Der in Abbildung 8 eingezeichnete gestrichelte Pfeil steht für die Generierung der Informationsseiten für die Bürgerauskunft, die durch den Sachbearbeiter über die Baustellenverwaltung vorgenommen werden kann. Hierbei werden sämtliche Informationen zum Zeitpunkt der Erzeugung in den Webseiten kodiert, so dass in diesem Fall keine Verbindung zum Applikationsserver nötig wird.

6 Zusammenfassung

Die Erweiterung der seit vielen Jahren im Einsatz befindlichen Baustellenverwaltung ZEBRA um eine standardisierte Schnittstelle in Form OKSTRA^®-konformer Web-Services ist ein wichtiger Meilenstein auf dem Weg hin zur Öffnung der Baustelleninformationen der Landeshauptstadt Magdeburg für weitere Nutzergruppen und leistet dadurch insgesamt einen Beitrag zur besseren Informationsverbreitung über die Baustellensituation in der Region. Die Entwicklung browserbasierter, benutzerfreundlicher Bedienungsoberflächen ermöglichen eine komfortable und effiziente Verwaltung der Baustellendaten ohne die Notwendigkeit der Installation entsprechender Verwaltungssoftware. Verhältnismäßig kurze Entwicklungszeiten und ein hohes Maß an Effizienz bei der Erstellung anspruchsvoller Clientapplikationen sind durch den konsequenten Einsatz freier OpenSource-Bibliotheken und Frameworks möglich geworden. Eigene Entwicklungen oder Anpassungen der Clientapplikationen können durch Verwendung der zur Verfügung stehenden OKWFS Client API mit überschaubarem Aufwand selbst erstellt werden. Mit der vorgeschlagenen Nutzung aufbereiteter Abschnitte der OpenStreetMap-Karte könnte deutschlandweit auch im Bereich kommunale Straßennetze eine einheitliche und permanent nutzbare Referenzierungsgrundlage geschaffen werden.

Literatur

1. Mobilitäts- und Verkehrsinformationen für die Region Magdeburg, http://www.movi.de
2. OpenStreetMap: Die freie Wiki-Weltkarte, http://www.openstreetmap.de/
3. JavaScript Framework OpenLayers, http://openlayers.org/
4. Google Web Toolkit, http://code.google.com/intl/de-DE/webtoolkit/
5. Internet Application Framework Ext GWT, http://www.sencha.com/products/extgwt/
6. Heßling, M.; Duckeck, R.: Location referencing integration and implementation guidelines. Deliverable 3, Implementation of global location referencing approach, AGORA IST-20457, Work package report, http://www.ertico.com/agora-website-2/.
7. Wevers, K.; Hendriks, T.: AGORA-C on-the-fly location referencing. 12^th World Congress on Intelligent Transport Systems, San Francisco, November 6-10, 2005, Proceedings.
8. ISO Standard 17572-3 Intelligent Transport System (ITS)-Location Referencing for Geographic Databases-Part 3: Dynamic Location References
9. OpenLR^TM White Paper. Version 1.4, An open standard for encoding, transmitting and decoding location references in digital maps, http://www.openlr.org.
10. OKSTRA Objektkatalog für das Straßen- und Verkehrswesen, http://www.okstra.de/