FGSV-Nr. FGSV 002/98
Ort Köln
Datum 19.10.2011
Titel GraphenIntegrationsPlattform (GIP) und OKSTRA: Herausforderungen, Lösungsansätze und Integration
Autoren Mag. Dr. Stefan Kollarits
Kategorien OKSTRA
Einleitung

Stefan Kollarits ist geschäftsführender Gesellschafter der PRISMA solutions EDV-Dienstleistungen GmbH und hat 1999 gemeinsam mit Herrn Dipl.-Ing. Widmann das Unternehmen gegründet. Er verfügt über langjährige umfassende Erfahrung im Umfeld von Verkehrs- und Verkehrsplanungsprojekten (national als auch international) sowie in der Definition und Implementierung von Verkehrsinformationssystemen mit besonderem Schwerpunkt auf Geodateninfrastrukturen sowie eGovernment. Aktuelle Schwerpunkte der Tätigkeit liegen insbesondere im Bereich der Systemkonzeption für GIP (GraphenIntegrationsPlattform) und der Weiterführung dieser Konzepte zur nachhaltigen Pflege und Nutzung in eGovernment-Verfahren.

OKSTRA hat sich als Standard für die Verwaltung von Objekten mit Straßenbezug bewährt und ist in den letzten Jahren sukzessive ausgebaut worden. Der unmittelbare Nutzen für die Verwaltung liegt in der Übersicht über alle relevanten Informationen und in der Nachvollziehbarkeit der relevanten Verwaltungsprozesse – Dokumentationsmöglichkeiten und Analysemöglichkeiten sind damit unter anderem gegeben.

Zunehmende Herausforderungen ergeben sich jedoch an zwei Punkten:

  • Parallele Datenpflege von identen oder zumindest inhaltlich ähnlichen Objekten in anderen Systemen und unter Nutzung anderer Standards (wie GDF, OpenStreetMap oder INSPIRE).
  • Nutzung der Daten durch Dritte, insbesondere für Mobilitätsfragen (Verkehrsmanagement, Routing, …) und für Anwendungen im Bereich der Verkehrstelematik.

Im vorliegenden Beitrag werden diese Herausforderungen als Ausgangslage zusammenfassend vorgestellt und in ihren Konsequenzen / Anforderungen beschrieben. Darauf aufbauend wird der Ansatz der GraphenIntegrationsPlattform GIP erläutert, wie er in österreichischen Verwaltungen in den letzten fünf Jahren als Lösungsansatz für die skizzierten Problemstellungen entwickelt wurde.

In weiterer Folge werden die speziellen Anforderungen und Lösungsansätze für die Nutzung von Verwaltungsdaten für Drittanwendungen und eine mögliche Integration der Ansätze im Sinne der Nutzung von Synergien als Ausblick skizziert.

PDF
Volltext

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

Ausgangslage und Problemstellung

Als Basis für alle Anwendungen im Verkehrsbereich ist ein Netzgraph als eindeutiges Referenzsystem aller Geodaten gemeinsam für den Öffentlichen und Individualverkehr unabdingbar. Dieser Netzgraph muss so aufgebaut sein, dass verkehrsträgerübergreifende Verbindungen von jedem zu jedem Punkt im Netz nach verschiedenen Zielkriterien (z. B. Zeit, Länge, Kosten) berechnet werden können.

Die Modelle zur Abbildung von Netzgraphen können jedoch sehr unterschiedlich aufwändig aufgebaut sein. Wie bei jedem Modell bestimmt der Einsatzzweck die wirtschaftliche Informationsdichte (vgl. auch KOLLARITS 2009).

  • Für die Navigation ist ein vollständiger, gerichteter, beschriebener und bewerteter Graph des benutzbaren Netzes erforderlich. Für das dynamische Routing ist die laufende dynamische Bewertung mit aktuellen Verkehrsdaten erforderlich.
  • Für die Zwecke des Verkehrsmanagements ist ein aktueller, routingfähiger, das heißt ein gerichteter und (mit Reisezeiten, Kapazitäten und Auslastungen) dynamisch bewerteter Graph erforderlich.
  • Für die Zwecke des eGovernments Verkehr ist ein vollständiger, aktueller Graph erforderlich, der auch den Querschnitt der betrachteten Abschnitte und die Abbiegerelationen an den Knoten abbildet.
  • Für die Verkehrsplanung gilt zusätzlich zu den Anforderungen des Verkehrsmanagements, dass der Graph auch Planungen mit enthalten muss, dies möglichst noch in unterschiedlichen Varianten.
  • Für die Kartographie des Verkehrsnetzes und von Navigationsinformationen ist eine klare Strukturierung der Graphenmodelle und die Abbildung von Informationen zur Unterstützung der kartographischen Generalisierung notwendig.
  • Als Verortungsbasis (Verortungsregister) dient der Graph zur eindeutigen Lokalisierung von Informationen mit und über ihren Bezug zum Graph. Dafür ist eine umfassende Abbildung von Bezugssystemen notwendig, die aufeinander abgebildet und damit umgerechnet werden können. Weiters ist für hochgradige Stabilität, also Verlässlichkeit dieses Bezugssystems zu sorgen.

Diese Einsatzzwecke haben jedoch durchwegs anwendungsspezifische Anforderungen mit der Konsequenz, dass für die Erstellung von Graphen deutlich differierende Herangehensweisen gewählt wurden. Das hat dazu geführt, dass üblicherweise unterschiedliche Modellierungsansätze für unterschiedliche Anwendungsgebiete verwendet wurden, noch weiter differenziert nach Granularität der Netzauflösung und unterschiedlichen administrativen Ebenen.

  • Datenbestände wurden bislang meist nur innerhalb des unmittelbaren Kompetenzbereichs gepflegt, beispielsweise Landesstraßen versus Gemeindestraßen versus Forststraßen.
  • Datenbestände wurden für unterschiedliche Anwendungen redundant aber inkompatibel gepflegt, beispielsweise Verkehrsnetze für die Verwaltung von Landesstraßen versus Netze für die Verkehrsmodellierung versus Netze für Fahrplanauskunft.
  • Datenbestände wurden von Anwendern übernommen, dann für eigene Zwecke erweitert oder verändert, sodass keine Kompatibilität mehr mit den ursprünglichen Datenbeständen gegeben ist; beispielsweise Ergänzung und Adaptierung von kommerziellen Graphen für Verkehrsmodelle.

Dies zeigt die speziellen Probleme der Öffentlichen Verwaltung beim Aufbau einer umfassenden Geodateninfrastruktur im Bereich Verkehrswege deutlich. So sind die Erhaltungsaufgaben auf mehrere Verwaltungsebenen aufgeteilt, die aber ineinander verzahnt sind. Die Aufgaben der Verkehrsorganisation sind ebenfalls auf mehrere Ebenen verteilt, die Geltungsbereiche unterscheiden sich jedoch von jenen der Erhaltungsaufgaben.

Lösungsansatz GIP

Aus der genannten Problemstellung heraus hat sich in Österreich seit dem Jahr 2006 die Initiative GIP.at entwickelt. Ausgangspunkt waren zwei Forschungsprojekte, in denen die Softwarewerkzeuge zur Graphenintegration geschaffen wurden und die bestehenden Graphen in den beteiligten Ländern integriert wurden. Das Resultat kann beispielhaft anhand von ITS Vienna Region dargestellt werden. Dabei ist aus der ersten Graphik das Zusammenspiel von GIP mit anderen Datengrundlagen (insbesondere: Echtzeitdaten und Modellierungsergebnissen) als Basis für die Informationsservices von ITS Vienna Region ersichtlich. Die zweite Graphik hingegen zeigt die direkten Nutzer der GIP – im Sinne eines Wartungswerkzeugs für die Datenhalter, im Sinne einer konsistenten Datengrundlage und spezieller Funktionalität – wie beispielsweise Kollisionsanalyse für das Baustellenmanagement – für unterschiedliche Anwendergruppen der GIP Informationsgrundlagen.

Abbildung 1: GIP als Integrationsbasis für ITS Services

Abbildung 2: GIP als Schnittstelle von Datenhaltern und Informationsanwendern

Die Graphenintegrationsplattform – kurz GIP – bildet ein österreichweit einheitliches, intermodales Verkehrsbezugssystem. Die GIP führt die verschiedenen Datenbanken und Geoinformationssysteme zusammen, mit denen im öffentlichen Sektor Verkehrsinfrastruktur erfasst und verwaltet wird. Sie ist für verschiedene Zwecke nutzbar: Verwaltung von Straßen und Wegen, Referenzbasis für das Unfalldatenmanagement, Datenbasis für die Verkehrsauskunft und für Modellrechnungen, Grundlage für Kartographie und vieles andere. Auch die Verpflichtungen aus EU-Richtlinien wie INSPIRE oder die neue IVS-Richtlinie können mit den Daten der GIP erfüllt werden.

Die GIP ist ein Graph für alle Verkehrsmittel. Derzeit sind der Straßenverkehr, die besonderen Wege und Einrichtungen für Radfahrer und Fußgänger und die Schnittstelle zum öffentlichen Verkehr abgedeckt. Wenn von „Straßen“ gesprochen wird, sind nicht bloß Straßen im engeren Sinn – für Kfz – gemeint, sondern allgemein Verkehrswege (also auch Radwege, Wanderwege, Schienenwege, Wasserwege, usw.), da es sich um vergleichbare linienhafte Strukturen handelt. Die GIP ist intermodal konzipiert, eine allgemeine, verkehrsträgerübergreifend gültige Begriffswelt muss jedoch erst aufgebaut werden.

Die zentrale Zielsetzung der GIP kann als „Entwicklung und konsistente qualitätsgesicherte Pflege des vollständigen und intermodalen Amtlichen Graphen für Österreich durch die Verwaltung“ beschrieben werden.

Die GIP als Resultat bietet daher

  • Eine „Philosophie“ im Sinne des genannten zentralen Ziels
  • Ein Konzept zur Datenintegration mit einem definierten Datenmodell
  • Eine konkrete Datenbankstruktur
  • Einen kompletten Application Server für die Graphenintegration („Business Logic“)
  • Mehrere Client Werkzeuge (ArcView, Web-GIS) für verschiedene Nutzergruppen GIP wird genutzt
  • Als Werkzeug für die Wartung bestehender Verkehrsgraphen für die Verwaltung und andere Nutzergruppen
  • Als Bezugssystem für die Referenzierung auf das Verkehrsnetz
  • Als Austauschplattform

Grundzüge der GIP Architektur

Aus der taxativen Auflistung der Zielanwendungen, die durch die GIP unterstützt werden sollen, ergeben sich einige technische Anforderungen bzw. Herausforderungen, die in der GIP als Werkzeug gelöst wurden:

  • Durch langlebige Identifikations-Nummern, die primär von den baulichen Gegebenheiten und nicht von der Verkehrsorganisation abhängen, wird es externen Anwendungen ermöglicht, den Graphen als Referenzgraphen zu verwenden.
  • Infrastrukturbetreiber (z.B. Gemeinden) können Subgraphen dezentral warten. Die Anbindung der Subgraphen an den Hauptgraphen (z.B. Landesstraßennetz) bricht den Hauptgraphen nicht auf, die IDs und Attributierungen im Hauptgraphen bleiben erhalten.
  • Der Graph ist vollständig historisiert, um als Referenzsystem für rechtswirksame Abläufe dienen zu können.
  • Die lückenlose Historisierung ist auch Basis, um ein Verkehrsdatenarchiv als Grundlage für die Verkehrsplanung und das strategische Verkehrsmanagement aufzubauen.
  • Der Graph enthält alle Verkehrsmittel (MIV, ÖV, NMV) sowie die Übergangspunkte und Konfliktpunkte zwischen den Verkehrsmitteln (Garagen, Park & Ride, Bike & Ride, etc.) im Sinne eines vollständigen und umfassenden Datenmodells.
  • Für die GIP ist ein hochgradig detailliertes Rechte- und Rollenmodell implementiert. Dies erlaubt eine rollenspezifische Zuweisung von Kombinationen von Objektarten des Datenmodells, Subnetzen und Funktionsgruppen. So kann die Bearbeitungserlaubnis beispielsweise eingeschränkt werden auf Objekteigenschaften von Radwegen entlang von Landesstraßen.
  • Der Graph enthält mehrere Referenzsysteme und Stationierungen. Die Verarbeitung oder Bereitstellung von Meldungen in Fremdreferenzsystemen (z.B. RDSTMC) ist dadurch möglich.

Die Erfüllung der zuletzt genannten Anforderung – der Unterstützung unterschiedlicher Referenzsysteme – ermöglicht die Verwendung des Graphen als Kommunikationsschnittstelle zwischen unterschiedlichen Partnern und deren unterschiedlichen Referenzsystemen (Verortungssystemen). Damit ist eine Überführung von Informationen, die über Kilometrierung erfasst wurden, auf Teleatlas-IDs, TMC Codes oder andere Referenzsysteme in beiden Richtungen möglich.

Das Datenmodell wurde so konzipiert, dass alle genannten thematischen Anforderungen erfüllt werden können und über spezielle Mechanismen die Konsistenz des Graphen an den Übergangsstellen zwischen unterschiedlichen Datenhaltungskompetenzen gewährleistet wird. Das Datenmodell orientiert sich dabei sehr stark an den Ergebnissen des EuroRoads Projekts, das weitestgehend als Basis für die INSPIRE Implementierungsvorgabe für Verkehrsnetze im Straßenbereich diente (INSPIRE data specification on Transport networks – guidelines V3.0.1). Die Anforderungen der Echtzeitmodellierung und der intermodalen Routenauskunft werden über entsprechende Aufbereitungsroutinen und standardisierte Schnittstellen (GIS Routing, INTREST Schnittstelle) unterstützt. Die nachfolgende Grafik zeigt vereinfacht jenes Modell, das als Konsens für die genannten Anwendungen auf Bundes-, Länder- wie Gemeindeebene ausgearbeitet wurde.

Abbildung 3: Vereinfachte Skizze des Datenmodells GIP – konzeptive Ebene

Die Systemarchitektur wurde so definiert, dass eine klare Trennung zwischen Presentation und Business Layer vorliegt. Damit können unterschiedliche Benutzeroberflächen (Clients) auf die gleiche Basisfunktionalität zugreifen. So können Anwender einen ArcGIS Client und mehrere WebClients nutzen, womit die Anwendungsanforderungen unterschiedlicher Benutzergruppen unterstützt werden. Das Konzept der einheitlichen Business Logik mit unterschiedlichen spezifischen Clients erscheint zentral für die weitere Nutzung des GIP Konzepts. So können unterschiedliche Anwendungen mit sehr unterschiedlichen und anwenderspezifischen Benutzeroberflächen über die definierten Entwicklerschnittstellen direkt die GIP Kernfunktionalität nutzen. Über diese ist die Datenkonsistenz, die Historisierung und der einheitliche konfliktfreie Datenzugriff gewährleistet. Beispiele für derartige Anwendungen sind AWIS (Alpines Wegeinformationssystem, in dem die alpinen Vereine Wegeinformation auf Basis der GIP einpflegen) oder das in Entwicklung befindliche Wiener Baustellenmanagementsystem, das umfassende eGovernment Verfahren nutzt und über Textbausteine Verortungsinformationen in der GIP definiert.

Auf der Datenebene wurde ein Ansatz gewählt, der durch einen objektrelationalen Mapping- Mechanismus (auf der Basis von Hibernate) weitgehend unabhängig von der verwendeten Datenbank ist, wobei diese als Voraussetzung native Unterstützung von Geodaten bieten muss. Zu diesem Zweck dient in der ersten Version Oracle (spatial locator), sodass unterschiedliche GIS Clients auf die gleiche Datenbasis zugreifen können.

Technisch sind mit der GIP nun erstmals Werkzeuge vorhanden, die eine vollständige Pflege von multimodalen Graphen in dezentraler Form erlauben. Damit alle angestrebten Anwendungsgebiete gleichwertig unterstützt werden können, sind aber auch auf technischer Ebene weitere Entwicklungen notwendig, womit einerseits Produktivität und Qualität des Managements erhöht werden sollen und andererseits zusätzliche Partner für die Aufgaben der GIP-Pflege und -Nutzung gewonnen werden sollen.

Abbildung 4: Detailabbildung von Querschnitten (Beispiel: Wiener Ringstrasse)

Organisatorischer Rahmen für die GIP Implementierung

Eine Reihe von Herausforderungen entsteht aber nicht im technischen, sondern im organisatorischen Bereich. Zentrale Herausforderung der Entwicklung eines intermodalen Graphen ist die Erstellung eines (Daten-)Organisationsmodells, das alle organisatorischen und inhaltlichen Anforderungen abbildet und dabei dennoch einen performanten Zugang zu den Daten gewährleistet. Detailfragen dabei sind insbesondere auch:

  • Wie kann eine grenzüberschreitende Datenorganisation gewährleistet werden, wobei die Datenhaltungskompetenz teils horizontal (beispielsweise Bundesländergrenzen), teils vertikal (beispielsweise Gemeinde- versus Landesstraßennetz) definiert ist?
  • Wie kann eine zeitnahe und konsistente Aktualisierung der Daten erfolgen?
  • Wie können Anwender mit unterschiedlichem Basiswissen, Systemvoraussetzungen und sehr unterschiedlicher Bedienhäufigkeit die Wartung eines homogenen Gesamtgraphen durchführen?
  • Wie können die Anforderungen der Echtzeitmodellierung und der intermodalen Auskunft mit jenen von eGovernment Prozessen in Einklang gebracht werden?
  • Wie können Daten unterschiedlichster Datenquellen zu einem homogenen Gesamtgraphen zusammengeführt werden?

Organisatorisch werden diese Herausforderungen insbesondere durch die intensive Abstimmung im Zuge der österreichweiten Initiativen von GIP.at und GIP.gv.at (Kooperationsprojekte unter Kofinanzierung des Klima- und Energiefonds mit Einbindung der österreichischen Bundesländer, des BMVIT sowie von ASFINAG und ÖBB). Dabei dient GIP.at den Prozessen und Werkzeugen zur Pflege des Verkehrsnetzes im engeren Sinn, während in GIP.gv.at darauf aufsetzende Prozeduren des eGovernment im Verkehrsbereich unterstützt werden (wie beispielsweise die Definition von temporären und/oder permanenten verkehrlichen Maßnahmen).

Eine darüberhinausgehende internationale Abstimmung erfolgt insbesondere über laufende Interreg Projekte wie Alpcheck2 (Alpenraum), TrIM (Österreich - Italien), SETA (Südosteuropaprogramm) oder das 2011 eingereichte Projekt EDITS (Central).

In einer Arbeitsgruppe von GIP.at wurde 2011 ein Standard zur Erfassung und Pflege von GIP- Daten entworfen. Dieser soll die Nutzung der verfügbaren GIP-Werkzeuge klar regeln. Die Zielsetzungen der Standardisierung können der Einleitung zum Standardentwurf selbst entnommen werden (s. RVS 05.01.14 im Entwurf):

„Diese Richtlinie regelt den Aufbau und die Wartung des österreichweiten, intermodalen elektronischen Verkehrsbezugssystems GIP (Graphenintegrationsplattform). Die GIP bildet die Grundlage für neue elektronische Verwaltungsabläufe im Verkehr (eGovernment) und sie dient als Basis einer österreichweiten intermodalen Verkehrsinformationsplattform.

Die Standardbeschreibung GIP trifft Festlegungen, welche die Konsistenz der Teilgraphen sicherstellen und die für den österreichweiten Austausch von Verkehrsreferenzen nötig sind. Die Standardbeschreibung GIP definiert einen Standard und einen Mindeststandard. Der Mindeststandard stellt sicher, dass das Routing, die kartographischen Darstellungen und grundlegende länderübergreifende eGovernment-Anwendungen (Unfalldatenverortung, Austausch von Straßenbezeichnungen und Kilometrierungsangaben) österreichweit einheitlich funktionieren. Der darüber hinausgehende Aufbau der GIP hat standardkonform zu erfolgen.

Der Standard legt fest, wie die Daten zu erfassen sind. Der Mindeststandard legt fest, welche Daten mindestens zu erfassen sind.“

In der GIP.at- sowie der GIP.gv.at-Gruppe werden nach erfolgter Formulierung des Datenstandards aktuell insbesondere organisatorische Problemstellungen diskutiert. Das beinhaltet unter anderem die Definition eines Betreibermodells für die GIP, die Erstellung von klaren Richtlinien zur Datenweitergabe an und Nutzung durch Dritte (Auflagen, Rahmenbedingungen, Konditionen) sowie die Einbindung von neuen Anwenderkreisen (insbesondere: Gemeinden).

Abbildung 5: Detailabbildung des Verkehrsnetzes mit Querschnittsinformation am Beispiel der Wiener Ringstraße

Mobilität und Verkehrstelematik als Anwendungsbereich

Viele Verkehrsmanagementapplikationen leiden unter Qualitätsproblemen insbesondere im Bereich der Routing-Daten (Aktualität, Vollständigkeit, Inkonsistenzen bis hin zu Abweichungen von der StVO). Dieses Problem der langfristig konsistenten Datenwartung ist dabei allen komplexen (Geo)dateninfrastrukturen bekannt. Die notwendigen Informationen werden (zumindest inhaltlich) zwar ursächlich alle in Verwaltungsprozessen generiert, die Prozesse selbst werden aber zum Großteil nicht mit Bezug zu digitalen Graphen abgearbeitet.

Hier können Ansätze wie GIP und OKSTRA zu Verbesserungen der Ausgangslage führen. Auch bei einer Pflege dieser Informationen aus der Sicht der Verwaltungsanforderungen, kann jedoch nicht direkt von einer Nutzung für Verkehrsmanagement / Routing ausgegangen werden.

Dies liegt einerseits an Unterschieden im Hinblick auf Qualitätsanforderungen – aus Sicht der Verwaltung ist die Routingfähigkeit eine nachgeordnete Eigenschaft. Aber auch die strukturelle Abbildung der Informationen selbst unterscheidet sich erheblich. Dies kann anhand der verkehrlichen Maßnahmen für „Geschwindigkeitsbeschränkungen“ beispielhaft veranschaulicht werden:

  • Aus der Sicht der Verwaltung sind Geschwindigkeitsbeschränkungen so definiert, dass sich problemlos mehrere unterschiedliche Typen von Maßnahmen überlagern dürfen – Zonenbeschränkung im Ortsgebiet und linienhafte Geschwindigkeitsbeschränkung innerhalb einer Zonenbeschränkung.
  • Aus der Sicht des Routings ist die aktuelle Sicht eines spezifischen Verkehrsteilnehmers maßgebend: Diese ist orts- und zeitabhängig, aber jedenfalls immer eindeutig (zumindest im Falle einer StVO konformen Maßnahmendefinition). Zunehmende Komplexität ergibt sich durch die Abhängigkeit von Tätigkeit und Rolle des Verkehrsteilnehmers, aber auch von Wetterumständen etc.

Ansätze zur Lösung dieses Problems liegen einerseits in speziellen Maßnahmen zur Qualitätssicherung, andererseits in der verstärkten Einbindung von eGovernment-Verfahren in der direkten und indirekten Datenpflege. Dies kann am Beispiel der Ansätze von GIP.gv.at gezeigt werden und analog auf den OKSTRA übertragen werden.

Der überwiegende Teil von Informationen im Verkehrsbereich ist Bestandteil von Verwaltungsprozessen. Eine Abbildung dieser Prozesse als eGovernment-Prozesse und eine Nutzung dieser Prozesse zur Generierung von Daten (quasi nebenbei) liegt damit auf der Hand. Der mögliche Nutzen einer derartigen Vorgangsweise ist auf mehreren Ebenen zu sehen:

  • Verfügbarkeit von digitalen Daten mit entsprechenden Möglichkeiten zur Weiterverwertung der Daten (beispielsweise für kartographische Darstellungen);
  • Arbeitsvereinfachungen durch die Digitalisierung des Aktenlaufes und der Dokumentverwaltung (beispielweise Workflow-Management für die Verordnungserstellung);
  • Benutzerunterstützung in bestehenden Arbeitsprozessen (beispielsweise durch die kartographische Orientierung und die Prüfung von Benutzereingaben bei der Erstellung von Verordnungen);
  • Rechtssicherheit, durch die verbesserte Verwaltung der Akten und damit der Zuordenbarkeit von Verordnungsdokument und Verkehrszeichen und durch die Unterstützung sowie automatische Plausibilisierung im Prozess der Verordnungserstellung selbst;
  • Zugriff auf zusätzliche Daten über die kooperierenden Behörden, die eine Verstärkung der oben genannten Nutzereffekte zur Folge haben.

Diese sicher unvollständige Auflistung zeigt deutlich die Zielrichtung von eGovernment-Verkehr für den Geoinformationsbereich auf. Es steht nicht die Schaffung neuer Datenbanken oder die Verteilung bestehender Daten auf möglichst viele Stellen im Vordergrund, sondern die Unterstützung aller verkehrsbezogenen Aufgaben auf einer digitalen Basis durch die Abbildung und Optimierung der jeweiligen Arbeitsprozesse mit ihren Abläufen, Interaktionen und allen zugehörigen Dokumenten.

Der Nutzen von konkreten Lösungsansätzen kann beispielhaft anhand eines Pilotprojektes des Landes Kärnten gezeigt werden (vgl. auch KOLLARITS & MANDL-MAIR 2003). In diesem Pilotprojekt wurden behördliche Arbeitsabläufe mit GIS abgebildet, insbesondere die Verwaltung von Verkehrszeichen und Bodenmarkierungen, die automatisierte Erstellung und StVO- Überprüfung von verkehrlichen Maßnahmen sowie die Sanierung der bestehenden Verkehrsregelung (wie sie durch Verkehrszeichen und Bodenmarkierungen real kundgemacht sind) mit Unterstützung durch „Verkehrslogik“.

Im Pilotprojekt wurde aufbauend auf einer Behördenkooperation zwischen Land Kärnten, Bezirkshauptmannschaft, Gemeinde und Straßenmeisterei versucht, die Arbeitsabläufe bezüglich Verordnungen zu beschreiben und in einem Workflow umzusetzen. Aus den Textbausteinen für die Maßnahme, Verortung und Kundmachungshinweisen wird ein einheitliches Verordnungsdokument automatisiert erstellt. Dies führt in weiterer Folge zu einem landesweiten gültigen Formulierungsstandard, was sowohl die Verständlichkeit und Nachvollziehbarkeit als auch die Rechtssicherheit verbessern soll.

Die automatisierte Unterstützung der Maßnahmendefinition steht an zentraler Stelle in der Umsetzung, da damit einerseits die genannten Aspekte der Rechtssicherheit verbunden sind, andererseits nur so langfristig eine konsistente Aktualisierung des Naturbestandes (Verkehrszeichen) gewährleistet werden kann. Mit dem gewählten Lösungsansatz werden im Zuge eines bestehenden Arbeitsvorgangs – der Erstellung und Umsetzung der Verordnung – automatisiert die notwendigen Datenbestände erzeugt und stehen so in der Datenbank und (karto-)graphisch bereits zur Verfügung. Damit können die integrierten Informationen über das Verkehrsnetz und die bestehenden Nutzungsregelungen (über die Verkehrszeichen und Bodenmarkierungen) verwendet werden, um direkt in graphischer Form die aus einer Verordnung resultierende Verkehrsorganisation zu kennzeichnen. Besonders hervorzuheben ist jedoch, dass die im Zuge des GIS-gestützten Verordnungsprozesses gewonnenen Daten direkt auf den Graphen Bezug haben. Damit erfolgt – quasi als „Abfallprodukt“ des Verordnungsprozesses – eine Aktualisierung von vielen routingrelevanten Informationen im digitalen Verkehrsnetz. Abbiegege- und -verbote, Einbahnregelungen, Fahrverbote und Geschwindigkeitsbeschränkungen können so zeitnah mit ihrer gesamten Detaildefinition („Gültigkeit“) aktuell gehalten werden.

Abbildung 6: GIP Basisobjekte im Kontext unterschiedlicher Anwendungen

Die Graphik oben zeigt die zentralen Aufgaben der GIP im Kontext unterschiedlicher Systeme zur Verwaltung von (Straßen-)netzrelevanten Informationen. So dient die GIP primär zur eindeutigen und nachhaltigen Verwaltung aller netzbezogenen Ortsinformationen sowie zur Bereitstellung eines vollständig routingfähigen Graphen (= Wirkung von Maßnahmen mitsamt Gültigkeiten, wie beispielsweise „Geschwindigkeitsbeschränkung 80 km/h bei Schnee oder Regen“). Diese Basisebene wird genutzt von einer spezialisierten Fachapplikation zur Integration von verkehrlichen Maßnahmen („Maßnahmenassistent“), der das Regelwerk zur Abbildung von Maßnahmen und zur Ableitung der Routinginformationen aus den Maßnahmen darstellt. Umfassende Fachapplikationen bieten detaillierte Verwaltungsinformationen für Infrastrukturobjekte (wie in Straßendatenbanken) oder komplexe Workflows in eGovernment- Verfahren (wie Verordnungen permanenter Maßnahmen oder das Management geplanter Behinderungen).

GIP und OKSTRA – Integration?

Ein Vergleich von GIP und OKSTRA hinsichtlich der Modellierungs- und Pflegeansätze zeigt, dass die ursprünglichen Zielsetzungen klar komplementär sind

  • GIP als Pflege- und Integrationskonzept für Netzgraphen zur Unterstützung der Datenanforderungen der Verwaltung, des Verkehrsmanagements und der Verkehrsplanung.
  • OKSTRA als Objektkatalog und Pflegekonzept für die Verwaltung von straßenbezogenen Informationen, mit einer sehr breiten Abdeckung von Infrastrukturobjekten aus der Sicht des Straßenerhalters.

Die jüngsten Entwicklungen, insbesondere auch verdeutlicht durch die Fragestellungen dieser Konferenz, zeigen, dass eine Verbreiterung der Anwendungen von OKSTRA Daten zunehmend diskutiert wird. Dabei kann auf positive Erfahrungen aus dem GIP Bereich verwiesen werden, wo sich gezeigt hat, dass jeder zusätzliche Nutzer (insbesondere im Sinne von zusätzlichem Anwendungsbereich) zu einer Verbreiterung der Akzeptanz des Konzepts und der Werkzeuge der GIP geführt haben.

In diesem Sinne erscheint eine Analyse möglicher Synergieeffekte zwischen den Ansätzen von GIP und OKSTRA sinnvoll. Auf der Basis einer ersten ad-hoc-Analyse können technische Synergien auf mehreren Ebenen aufgezeigt werden, wobei diese hiernach zunehmenden Grad an Koppelungsintensität angeführt sind:

  • Austausch und wechselseitige Integration / Adaptierung von Konzepten è geringe / keine Koppelung mit wechselseitiger Nutzung von Erfahrungen und Konzeptentwicklungen
  • Datenaustausch è lose Koppelung auf der Basis einer Datenintegration über die jeweils definierten Schnittstellen (unter Nutzung der definierten Datenschnittstellen der GIP oder der definierten Serviceschnittstellen von OKSTRA)
  • Nutzung der GIP als Referenznetzbasis für OKSTRA, mit Synchronisationsmechanismen, Datenintegrationsmechanismen und Qualitätsmanagementfunktionen è enge Koppelung auf technischer Basis

Eine Nutzung der Synergien erscheint insbesondere auf Basis klar definierter Referenzierungsmechanismen, wie im Bericht zur „Analyse der Regelwerke und Ordnungssysteme/Ortsreferenzierungssysteme der Bereiche Straßeninformationssysteme und Verkehrssysteme“ (BAST 2011) beschrieben, möglich. 

Literatur

BAST BUNDESANSTALT FÜR STRASSENWESEN (2011): Analyse der Regelwerke und Ordnungssysteme/Ortsreferenzierungssysteme der Bereiche Straßeninformationssysteme und Verkehrssysteme.

KOLLARITS, S. (2009), Geoinformationsinfrastrukturen im Verkehrsbereich – Anwendersichten und Integration. In: KAREL KRIZ, WOLFGANG KAINZ und ANDREAS RIEDL (HRSG.)

Geokommunikation im Umfeld der Geographie, Tagungsband zum Deutschen Geographentag 2009 in Wien, 140-147.

KOLLARITS, S. (2010): GIP roadmap: Perspektiven der Entwicklung bis 2012. In: AGIT 2010 Tagungsband. – Salzburg.

KOLLARITS S., MANDL-MAIR I. (2003), e-Government in der Straßenverwaltung. Behördenübergreifende workflow Unterstützung für die Verordnungsgebung und Steigerung der Verkehrssicherheit mit GIS-Unterstützung. In: Proc. European ESRI User Conf., 2003, Innsbruck.

RVS 05.01.14 Entwurf (2011): Intermodaler Verkehrsgraph Österreich – Standardbeschreibung GIP (GraphenIntegrationsPlattform).