Dipl.-Ing. (Univ.) Roland Degelmann ist Leiter der Sachgebietes „Gesamtverkehrsplanung, Naturschutz der Staatsbauverwaltung“ der Obersten Baubehörde im Bayerischen Staatsministerium des Innern. In seinen fachlichen Zuständigkeitsbereich fallen unter anderem die grundsätzliche Angelegenheiten der Verkehrs- und Straßenplanung der bayerischen Straßenbauverwaltung und die Steuerung der Tätigkeiten der „Zentralstelle für Informationssysteme“ die das bayerische Straßeninformationssystem BAYSIS betreut. Neben seiner Arbeit als Sachgebietsleiter ist er als Mitglied des Querschnittsausschusses 3 „Grundsatzfragen der Datenverarbeitung“ der Forschungsgesellschaft für Straßen- und Verkehrswesen tätig sowie an der ressortübergreifenden Koordinierung der Geodateninfrastruktur Bayern (GDI Bayern) beteiligt. Ziel seiner Tätigkeit in den vorgenannten Aufgabenfeldern ist die optimierte Bereitstellung von verteilt stehenden Fachinformationen in offenen, standardisierten Systemen.

Der OKSTRA^® ist ein lebender und wachsender Standard, der sich von den kontinuierlich entwickelnden technischen Regelwerken ableitet. Um diese von außen beeinflussten Veränderungen zeitnah in die eigenen Strukturen aufnehmen zu können, wird der OKSTRA^® regelmäßig in Form neuer Gesamtversionen fortgeschrieben – die aktuelle Version trägt die Nummer 1.011. Grundlage dieser Versionierungssystematik war der Ansatz, den OKSTRA^® als Datenaustauschformat zu nutzen und hierfür jeweils durchgängig auf einen einheitlichen Versionsstand zuzugreifen.

Im Rahmen der unmittelbaren Nutzung des OKSTRA^® bei der Strukturierung von Datenhaltungen hat die heute genutzte Art der Versionierung zur Folge, dass bei einer Fortschreibung einzelner Objekte alle anderen Objekte und deren Dateninhalte auch auf die neue Version umzusetzen sind. Im Ergebnis ist dies mit einem hohen Aufwand verbunden, der auch die Einbindung neuer Objekte in vorhandene Datenhaltungen zunehmend behindert.

Im Rahmen des Vortrags erfolgt die Beleuchtung des Problems der OKSTRA^®-Versionierung mit dem Ziel, diese nach dem Vortrag breiter zu diskutieren und ein Meinungsbild zu erhalten, wohin sich der OKSTRA^® in dieser Fragestellung entwickeln soll.

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

Der OKSTRA^® - gestern und heute

Die Entwicklung des OKSTRA^® wurde 1995 mit dem Ziel gestartet, Brücken zu schlagen zwischen verschiedenen Bereichen innerhalb des Straßen- und Verkehrswesens. Inzwischen ist die Notwendigkeit einer Integration nicht nur innerhalb des Straßen- und Verkehrswesens, sondern auch mit benachbarten Bereichen wie der Vermessung oder der Ökologie erkannt worden. Künftig wird darüber hinaus auch die Frage der intermodalen Kommunikation zwischen den verschiedenen Verkehrsträgern weiter an Bedeutung gewinnen.

Bei der Vielzahl der im genannten Zusammenhang abzudeckenden Aufgabenfelder besteht ein dringender Bedarf an einer einheitlichen Systematik für die Beschreibung georeferenzierter Informationen. So entsteht ein durchgängiges Rahmenwerk für zielgruppenspezifische Aufgaben in dessen zentraler Stelle das Straßennetz steht. Hier leistet der OKSTRA^® als ganzheitlicher Standard einen wichtigen Beitrag, da er die Schaffung einer gemeinsamen Plattform für die Bereitstellung von Informationen im Straßen- und Verkehrswesen zum Ziel hat. Dabei werden nach Möglichkeit internationale Standards (derzeit vor allem auch dem ISO/TC 211 oder dem Open Geospatial Consortiums) verwendet. Gleichzeitig sind aber auch die Besonderheiten des Straßen- und Verkehrswesens auf der Basis der gültigen Regelwerke zu berücksichtigen.

Aus den Ausführungen wird deutlich, dass der OKSTRA^® als informationsstrukturierendes Instrumentarium nicht losgelöst von den Entwicklungen in der umgebenden Fach- und IT-Welt entstanden ist und sich auch entsprechend weiter entwickelt. Beobachtungen und Abstimmungen sind permanent erforderlich im Bezug auf

• entstehende, internationale Informationsstandards,
• die Weiterentwicklungen der Informationstechnik und
• die Weiterentwicklung der fachlichen Bereiche

Wie sich aus den gezeigten Zusammenhängen ergibt, sind die Veränderungen der verwendeten Werkzeuge bei der Beschreibung der Strukturen nicht entscheidend. Entscheidend ist aber die einheitliche Vorgehensweise, z.B. die gleiche Art der Codierung der Daten oder die gleiche Art der Modellierung von Geometrie und Topologie.

Als durchgängiges Rahmenwerk für Informationen im Straßen- und Verkehrswesen bietet der OKSTRA^® ganz besonders beim übergreifenden Zusammenwirken verschiedener Informationsbereiche ein hohes Nutzenpotential. Dies gilt vor allem in Fällen, bei denen Angaben aus verschiedenen Informationssystemen mit Straßennetzbezug zusammenkommen. Gerade hier ist es von wesentlicher Bedeutung, dass alle Systeme eine gemeinsame „Sprache“ sprechen – eben OKSTRA^®.

Ist-Zustand der OKSTRA^®-Versionierung

Der OKSTRA^® wird gegenwärtig in Form regelmäßiger neuer Gesamtversionen fortgeschrieben – aktuelle Version ist 1.011. Für die jeweils neue OKSTRA^®-Version wird faktisch ein eigenes Datenmodell geschaffen, das formal völlig unabhängig von den Modellen der Vorgängerversionen ist. Grundlage für die bisher gewählte Art der Versionierung war wohl der Ansatz, den OKSTRA^® vorrangig als Datenaustauschformat zu nutzen und dabei jeweils durchgängig auf einen einheitlichen Versionsstand zuzugreifen.

Im Rahmen der unmittelbaren Nutzung des OKSTRA^® bei der Strukturierung von Datenhaltungen im Bereich des Straßen- und Verkehrswesens hat diese Art der Versionierung zur Folge, dass bei einer Fortschreibung einzelner Objekte alle vorhandenen Daten auf die neue Version umzusetzen sind. Im Ergebnis ist dies mit einem hohen Aufwand verbunden, der auch die Einbindung neuer Objekte in vorhandene Datenhaltungen zunehmend behindert.

Wenn eine Schnittstelle (und ggf. auch die dahinter stehende Datenhaltung) ein Feature einer neuen OKSTRA^®- Version nutzen will, muss ein komplettes Upgrade auf die neue Version erfolgen. Dies bedeutet, dass sämtliche zwischen den beiden Versionen existierenden Änderungen umgesetzt werden müssen, die in den Bereich der in der Schnittstelle abgebildeten Objektarten fallen – auch solche, die im konkreten Fall gar nicht notwendig sind. Letztlich führt die Gesamtversionierung des OKSTRA^® damit zu erhöhten Umstellungsaufwänden.

Zur Beseitigung der genannten Defizite hat die bayerische Straßenbauverwaltung einen OKSTRA^®- Änderungsantrag mit dem Ziel gestellt, von der Gesamtversionierung des OKSTRA^® zu einer objektspezifischen Versionierung überzugehen. Dabei sollte die Versionsnummer so an das Objekt binden, dass auch eine Verbindung von Objekten unterschiedlicher Versionsstufen ermöglicht wird. Damit bestünde eine größere Flexibilität bei der Anpassung von OKSTRA^®-Schnittstellen an neue OKSTRA^®-Versionen; es könnten gezielt nur diejenigen Änderungen realisiert werden, die tatsächlich erforderlich sind.

Es wird nicht verkannt, dass bei einer alleinigen Versionierung der Objektinstanz der OKSTRA^® im Bereich des Datenaustausches eine Verschlechterung gegenüber dem Ist-Stand erfahren würde. Auf Grund dieser Tatsache muss bei einer künftigen Lösung erreicht werden, dass alle Anwendungsmöglichkeiten im möglichst großen Umfang bei ihrer Aufgabenstellung unterstützt werden.

Stand der Diskussion

Der Änderungsantrag des Freistaats Bayern wurde von der Pflegestelle im Rahmen der üblichen Abstimmungsregelungen kommentiert und auf den OKSTRA^®-Webseiten veröffentlicht.

Die ersten Diskussionen zu diesem Thema zeigten Ansätze, die es sinnvoll erscheinen ließen, den Vorschlag zunächst durch eine weiterführende Analyse der Thematik zu konkretisieren. Dazu sollten insbesondere die folgenden Fragestellungen geklärt werden:

• Wenn Objekte aus verschiedenen Versionen zusammen verwendet werden, müsste die Möglichkeit geschaffenwerden, Objekte versionsübergreifend durch Relationen zu verbinden. Es müsste somit fachlich festgelegt werden, wo solche „Interversions-Relationen“ erlaubt sein sollen und wo nicht.

• Bisher wird für jede OKSTRA^®-Version eine eigene Referenzmodellierung erstellt; Verbindungen zwischenverschiedenen Versionen sind auf dieser Ebene bislang nicht vorgesehen. Es müsste daher ein Konzept entwickelt werden, wie die Interversions-Relationen formal beschrieben werden können.

• Es sollte geklärt werden, ob – und wenn ja, wie – die gemeinsame Verwendung von Objekten ausverschiedenen Versionen in den OKSTRA^®- Datenformaten CTE und XML möglich ist.

• Es sollte untersucht werden, was ein Versions-Mix für die OKSTRA^®-Export- und Import-Schnittstellen bedeutet (insbesondere: Wie viele Varianten aus Objekten unterschiedlicher Versionen muss eine Import- Schnittstelle unterstützen?).

Nützlich erscheint es in diesem Zusammenhang, nicht nur die Änderung des Versionierungsverfahrens zu behandeln, sondern allgemein Methoden zu diskutieren, mit denen OKSTRA^®-Objekte aus verschiedenen Versionen miteinander kombiniert werden können, um so eine größere Flexibilität bei der Anpassung von Schnittstellen an neue OKSTRA^®-Versionen (oder Teile davon) zu erzielen. Die Diskussion wurde thematisch entsprechend erweitert.

Auf dem aktuellen Stand der Diskussion lassen sich folgende generelle Aussagen treffen:

• Eine größere Flexibilität im Datenexport bedeutet möglicherweise einen größeren Aufwand im Datenimport,speziell dann, wenn Daten aus verschiedenen Quellen bezogen werden sollen, die aufgrund dieser Flexibilität Daten in verschiedenen Varianten liefern können.

• Ein wesentliches Problem bei der Kombination von OKSTRA^®-Objekten aus verschiedenen Versionen sind dieRelationen zwischen den Objektarten, da in diesem Fall versionsübergreifende Relationen erforderlich werden, die bisher aufgrund der strikten Trennung der Modelle der einzelnen Versionen nicht vorgesehen sind. Relationen über Versionsgrenzen hinweg müssten daher sowohl auf der technischen Ebene ermöglicht als auch unter fachlichen Gesichtspunkten betrachtet werden, d.h. es müsste fachlich begründet festgelegt werden, wo eine Relation über eine Versionsgrenze hinweg erlaubt ist und wo nicht, um einen standardisierten und vollständig definierten Datenaustausch zu gewährleisten.

Möglichkeiten der OKSTRA^®-Versionierung

Unabhängig von den genannten grundsätzlichen Überlegungen wurden auch mögliche Versionierungsmethoden in die Diskussion eingeführt. Nach dem Stand der Diskussion sind folgende Alternativen zur Erzielung von mehr Flexibilität bei der Anpassung an neue OKSTRA^®-Versionen vorstellbar:

1. Mischen von Objekten aus verschiedenen Versionen in den Datenformaten

Bei dieser Variante gibt es weiterhin verschiedene Gesamtversionen des OKSTRA^® mit formal getrennten Datenmodellen. OKSTRA^®-Objekte aus verschiedenen Versionen können aber in einer OKSTRA^®-CTE-Datei oder einem OKSTRA^®-XML-Dokument zusammen verwendet, d.h. „gemischt“ werden. Dazu müsste jedes einzelne Objekt eine eigene Versionsinformation tragen. Es müsste darüber hinaus in Ergänzung zu den Referenzmodellierungen der einzelnen OKSTRA^®-Versionen festgelegt werden, wo die bestehenden Relationen zwischen Objekten welche Versionsgrenzen überschreiten können. Außerdem wäre zu prüfen, inwieweit die OKSTRA^®-Formate CTE und XML dieses Verfahren unterstützen. Beim OKSTRA^®-XML müsste z.B. geklärt werden, gegen welches XML Schema ein XML-Dokument mit Objekten aus verschiedenen OKSTRA^®-Versionen validiert werden soll und ob man es zulassen möchte, Objekte mit GML-Geometrien aus verschiedenen GML-Versionen zu mischen.

2. Objektbezogene Versionierung innerhalb eines einzigen Datenmodells

Bei dieser Variante werden sämtliche Versionen aller OKSTRA^®-Objekte in einem einzigen Datenmodell beschrieben. Damit kann im Modell selbst explizit festgelegt werden, zwischen welchen Objektarten verschiedener Versionen Relationen möglich sein können und zwischen welchen nicht. Das Konzept einer einheitlichen „aktuellen“ OKSTRA^®-Version würde aufgegeben werden, da man eine einzelne Objektart nur noch bei einer konkreten Änderung an dem Objekt selbst versionieren würde. Wie in Variante 1 müsste jedes OKSTRA^®-Objekt mit einer Versionsinformation ausgestattet werden. Der Preis für die einheitliche Beschreibung aller Kombinationsmöglichkeiten von Objektversionen in einem einzigen Modell wäre, dass dieses erheblich komplexer würde als die bisher verwendeten Modelle. Sofern weiterhin EXPRESS als Modellierungssprache verwendet würde, müssten die verschiedenen Versionen einer Objektart im Modell unterschiedlich bezeichnet werden. Außerdem müsste man formal getrennte Relationen zu allen gewünschten Versionen einer Objektart aufbauen. Dies würde nicht nur zu einer erheblich größeren Zahl von Relationen führen, sondern auch dazu, dass bereits existierende Objektversionen bei der Versionierung ihrer Relationspartner neue Relationen hinzubekämen. Sinnvoll wäre bei dieser Variante daher die Suche nach einer Modellierungssprache, die diese Form der Versionierung in einem Modell besser unterstützt als EXPRESS. Damit ergäbe sich auch die Frage nach der weiteren Unterstützung des OKSTRA^®-CTE-Formates. Für das OKSTRA®-XML hätte dieses Verfahren die Konsequenz, dass ein Umstieg auf eine neuere GML-Version oder eine Änderung der XML-Ableitungsregeln stets für sämtliche Objektversionen (also auch für bereits lange existierende) gelten und damit unter Umständen dazu führen würde, dass sämtliche bereits existierenden OKSTRA®-XML-Daten in ein neues Format konvertiert werden müssten.

3. Getrennte Versionierung einzelner Bereiche des OKSTRA^®

Bei dieser Variante wird der OKSTRA^® in Teilmodelle untergliedert, die unabhängig voneinander versioniert werden können. Denkbar wäre z.B. die Aufteilung in einen „Kernbereich“ mit dem Straßennetz und weiteren zentralen Objektarten sowie verschiedenen Fachdatenbereichen, die optimalerweise möglichst unabhängig voneinander sind. Auch bei dieser Variante müssten die einzelnen Objekte über eine eigene Versionsinformation verfügen. Sofern Relationen über Teilmodellgrenzen (und damit ggf. auch über Versionsgrenzen) hinweg nötig werden, ergibt sich die bei den generellen Aussagen erläuterte Relationsproblematik. Sofern Objektarten aus mehreren Teilmodellen von einer Schnittstelle zur Verfügung gestellt werden sollen, treten außerdem die bei der Variante 1 beschriebenen Fragestellungen hinsichtlich des Mischens von Objektarten verschiedener Versionen in einem Datenformat auf.

4. Getrennte Schnittstellen

Verschiedene Teile einer Datenhaltung werden mit verschiedenen Schnittstellen (bzw. Web-Services) ausgestattet, die jeweils nur Objektarten aus einer einzigen OKSTRA^®-Version verwenden. Der Vorteil dieser Konstruktion wäre, dass die einzelnen Schnittstellen unabhängig voneinander und damit je nach Bedarf an neue OKSTRA^®-Versionen angepasst werden könnten. Diese Methode ist außerdem ohne Änderung des derzeitigen OKSTRA^®-Versionierungsverfahrens einsetzbar (sie könnte aber auch mit anderen Versionierungsverfahren zusammen verwendet werden, beispielsweise mit dem in der Variante 3 beschriebenen Verfahren). Probleme ergeben sich dann, wenn Objekte aus verschiedenen Schnittstellen, die auf unterschiedlichen OKSTRA^®-Versionen basieren, aufeinander verweisen sollen. Dies ist zwar technisch möglich – generell über symbolische Verweise, beim OKSTRA^®-XML sogar für sämtliche Relationen über externe xlink:href-Verweise – führt aber zur Notwendigkeit einer externen fachlichen Festlegung erlaubter Relationen über Versionsgrenzen hinweg.

Weiteres Vorgehen

Der Änderungsantrag der bayerischen Straaßenbauverwaltung wurde von der OKSTRA^®-Pflegestelle kommentiert und auf den OKSTRA^®-Webseiten veröffentlicht. Die Pflegestelle erstellte ein Diskussionspapier, in dem die Gesamtproblematik beschrieben sowie mögliche Lösungsansätze und die sich daraus ergebenden Konsequenzen aufgezeigt und bewertet wurden. Die Thematik soll in einer Expertengruppe weiter diskutiert werden, in die insbesondere die im Bestandsdaten- und Entwurfsbereich aktiven Firmen einzubeziehen sind. Um dieser Expertengruppe vorab ein möglichst breites „Stimmungsbild“ mitzugeben wird die Fragestellung auch im OKSTRA^®- Symposium 2007 thematisiert und diskutiert.