Abstract:

Geoinformationen bilden einen wesentlichen Teil des vorhandenen Wissens in einer modernen Informations- und Kommunikationsgesellschaft. Sie werden auf allen Ebenen in Verwaltung, Wirtschaft, Wissenschaft und vom Bürger benötigt; sie sind Grundlage des planerischen Handelns und ihre Verfügbarkeit ist maßgebliche Voraussetzung für Standort- und Investitionsentscheidungen. Auf der Grundlage eines bundesweit abgestimmten Vorgehens konnten in den vergangenen Jahren wesentliche Weiterentwicklungen der technischen Grundlagen für Straßeninformationssysteme – die wesentliche Teile der genannten Geoinformationen enthalten – realisiert werden. Ein wichtiger Meilenstein dieser Arbeit waren die Untersuchungen die im Rahmen des Bund-/Länderprojektes „Anforderungsprofil an eine Straßeninformationsbank der Zukunft“ erstellt und im Schlussbericht des dabei entwickelten „XML-Prototypen“ festgehalten wurden.

Aktuelle Aufgabenstellungen beispielsweise aus dem Bereich des Erhaltungsmanagements und Entwicklungen im Rahmen der Realisierung einer bayern-, bundes- bzw. europaweiten Geodateninfrastruktur verlangen, dass an den oben genannten Untersuchungen angeknüpft wird und die erforderlichen Definitionen für dienste-basierte Standards im Bereich von Straßeninformationssystemen getroffen werden.

Bayern erarbeitet dazu Grundlagen einer informationstechnischen Basis, mit deren Hilfe der externe Zugriff auf die Datenhaltung des Bayerischen Straßen-Informationssystems BAYSIS in standardisierter lesender und schreibender Form ermöglicht wird. Damit können dann Anwendungen bereitgestellt werden, die stets auf aktuelle Straßendaten zugreifen und diese ggf. auch bearbeiten. Der Zugriff auf die Datenstrukturen von BAYSIS wird dabei über XML-Web-Services realisiert, die auf dem OKSTRA^®-Standard basieren und den Festlegungen für „Web Feature Services“ genügen.

Der Vortrag berichtet über die strategischen Überlegungen und Hintergründe des Projekts OKSTRA^®-konforme Web-Services.

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

Einführung

Leistungsfähige Verkehrsinfrastrukturen stellen eine zentrale Voraussetzung für einen starken Wirtschaftsstandort dar und bilden gleichzeitig die Basis für die wachsende Mobilität in der Gesellschaft. Nach wie vor spielt bei der Sicherstellung der Mobilität der Verkehrsträger Straße die bedeutsamste Rolle. Das Straßennetz dient hierbei insbesondere der Sicherung der Erreichbarkeit von Einrichtungen der Daseinsvorsorge und der Schaffung möglichst gleichwertiger Standortbedingungen für die Wirtschaft.

Die Aufgabe aller im Bereich des Straßen- und Verkehrswesen Tätigen ist es, das Netz der Infrastruktur Straße so zu bauen, zu erhalten, zu erweitern oder sonst zu verbessern, dass es den gesellschaftlichen und volkswirtschaftlichen Anforderungen möglichst umfassend gerecht wird. Um dieses Ziel auch in einer Zeit beschränkter personeller und finanzieller Ressourcen erreichen zu können, ist ein möglichst umfassendes Wissen über die vorhandenen und die potentiellen Zustände der Netzinfrastruktur Straße erforderlich. Zur Bereitstellung dieses Wissens ist es geradezu zwingende Verpflichtung der Beteiligten, sich aller verfügbarer Hilfsmittel der Informationsbereitstellung zu bedienen. Beispiele dafür sind die Straßeninformationsbanken des Bundes und der Länder (BISStra, TT-SIB, NWSIB). Die Bauwerksdatenbanken (SIB-Bauwerke), die Informationssammlungen für Straßenerhaltungssysteme (Pavement- bzw. Bridge-Management-Systeme), die Liegenschafts- und Gebäude-Managementsysteme, die Unfall-Datenbanken, die Datensammlungen der Verkehrsmengen sowie digitale Geländeinformationen in vielfältigster Art und Weise runden dieses Informationsfeld ab. Die Nutzungsmöglichkeiten dieser Datenquellen im Rahmen von Webanwendungen zeigt exemplarisch nachstehendes Bild.

Bild: BAYSIS-Intranet

Die Informationstechnik ist in den letzten Jahren eine tragende Säule der modernen Gesellschaft geworden, ohne die eine funktionierende, rasch auf die wechselnden Anforderungen reagierende, kompetent handelnde Verwaltung nicht mehr denkbar ist. Die entstandenen Strukturen und Lösungen der Informationstechnik sind historisch gewachsen und zumeist sehr spezialisiert. An manchen Stellen hat sich in der Vergangenheit ein Wildwuchs gebildet, der dazu führt, dass wertvolle Informationen nicht zielorientiert erreicht und Ressourcen nicht optimal eingesetzt werden. So müssen beispielsweise in großem Umfang Schnittstellen entwickelt und gepflegt werden, um einen Datenaustausch zwischen den unterschiedlichen Lösungen zu ermöglichen. Daher ist es geboten, die IT-Landschaft ständig kritisch zu hinterfragen und sie regelmäßig an die aktuellen Anforderungen anzupassen.

Veranlassung und Projektziel

Die Bayerische Straßenbauverwaltung verfolgt sein längerem das Ziel, den Zugriff auf ihr Straßeninformationssystem BAYSIS umfassend zu öffnen, damit mittelfristig Applikationen entwickelt werden können, die stets auf aktuelle Straßendaten zugreifen und diese auch bearbeiten können. Der Zugriff auf BAYSIS soll dabei über XML-Webservices realisiert werden, die auf dem OKSTRA^®-Standard basieren und den Festlegungen des „Web Feature Servers“ genügen.

Wesentlicher Punkt bei den konzeptionellen Überlegungen für ein derart offen strukturiertes System ist natürlich auch die Frage der Interoperabilität mit vergleichbaren Systemen in anderen Bundesländern, um vor dem Hintergrund künftiger Systeme mit gemeinsamer Nutzung verteilt stehender Daten die bisherigen Beschränkungen bei der Datenbereitstellung zu beseitigen. Gleichzeitig ist darauf zu achten, dass die Fragestellung nicht nur auf eine eng begrenzte Datenmenge und/oder ein abgeschlossenes Aufgabenfeld ausgerichtet wird. Vielmehr steht die Forderung im Raum, allgemeingültige Grundlagen für OKSTRA^®-konforme Web-Services zu definieren. Diese sollen für alle im OKSTRA^® beschriebenen Fachobjekte einen lesenden und schreibenden Zugriff ermöglichen und das für Aufgabenstellungen und Anwendungsumgebungen, die nicht vorab definiert werden.

Dieser Ansatz zwingt zu einem globalen Denken und verhindert Kompromisse im Hinblick auf schnell erreichbare Ergebnisse mit „Halbfertigprodukten“. Er ermöglicht aber die Schaffung eines breiten und stabilen Fundaments, auf dem weitergehende Lösungen künftig schnell und produktiv aufsetzen können.

Die optimale Nutzung wird zudem dadurch gefördert, dass für die Bearbeitung des Projektes im Sinne der agilen Softwareentwicklung ein zwischen Auftraggeber und Auftragnehmer eng abgestimmter Iterationsprozess festgelegt wurde, der die Ansätze der Objekt-orientierten Software-Entwicklung soweit wie möglich nutzt.

Bild: OOSE-Iterationsmodell (aus: http://www.oose.de)

Serviceorientierte Architektur

Das Thema „Serviceorientierte Architektur“ zeichnet sich heute vielfach durch Modewörter, inkompatible Technologien und Architekturen sowie allerlei Hindernisse aus. Es gibt keinen durchgängig formulierten, einheitlichen Ansatz, geschweige denn eine universale „Lösung“. So bleibt die Frage, was genau „Serviceorientierte Architektur“ eigentlich ist, und welche Chancen diese Architektur birgt.

Der Gedanke der serviceorientierten Architektur ist nicht neu. Mit Technologien wie CORBA und DCOM wurden bereits in den 1990er-Jahren serviceorientierte Architekturansätze verfolgt. Beide Protokolle waren jedoch äußerst komplex. Außerdem waren die Services, die auf den Protokollen basierten, lieferantenabhängig und daher nicht miteinander kompatibel. Dank XML- und Web-Services basiert der heutige Ansatz für die Entwicklung von Services jedoch auf echten Standards, d. h. die Services können von verschiedenen Arten von Anwendungen genutzt werden

– unabhängig von den Technologien, die für die Anwendungsentwicklung verwendet wurden.

Zur Beschreibung des Gedankens der serviceorientierten Architektur wird heute häufig die Metapher eines Lego-Baukastens verwendet. Um die einzelnen (Software-)Bausteine zu etwas Ganzem zusammenfügen zu können, braucht man einen Ansatz, wie dieses Zusammenfügen erfolgen kann, eine Art Lego-Brett, also die Lego-Grundplatte, auf der die Lego-Bausteine einrasten. Die Lego-Bausteine wiederum haben eine „standardisierte Schnittstelle“, damit sie miteinander verbunden werden können. Die serviceorientierte Architektur beschreibt somit einen möglichst optimalen Entwurf, wie ein Lego-Brett und Lego-Bausteine aussehen sollen. Wie im Lego-System können Dienste (Lego-Bausteine) in unterschiedlichen Anwendungskontexten (Spielesituationen) wiederverwendet werden. Neue Dienste und Produkte können so schneller eingeführt und existierende Dienste schneller an neue Anforderungen angepasst werden. Kosten und Entwicklungszeiten sinken. Diese Flexibilität kann aber nur genutzt werden, wenn ausreichend regulatorische Rahmenbedingungen erfüllt werden.

Gewählte technische Randbedingungen

Für die Realisierung des Projekts „OKSTRA^®-konforme Web-Services“ wurden für den Bereich der bayerischen Straßenbauverwaltung nachfolgende Rahmenbedingungen festgelegt:

• Es wird (gegenwärtig) ausschließlich OKSTRA^® in Version 1.011 unterstützt.
• Die BAYSIS-Datenbank läuft unter MS-SQL-Server 2005. Es wird ausschließlich die neueste Datenbankversionvon BAYSIS unterstützt.
• Der geographische Teil der BAYSIS besteht aus MapInfo-Relationen bis Version 8.5.
• Der Austausch der Requests und der Responses erfolgt mit SOAP über https (V.1.1).
• Die Web Feature Service Definition (WFS) V.1.1.0 dient als Grundlage der Datenbereitstellung.
• Es werden ausschließlich die von OKSTRA^® verwendeten Elemente von GML 3.1 unterstützt.
• Die Serverapplikation (Datenbereitstellungsschicht, etc.) läuft unter Windows Server 2003 und dem MS Internet Information Server 6.0.
• Die Serverapplikation bedient sich des Net-Frameworks V 2.0.
• Die Serverapplikation wird mit Visual Studio 2005 unter der Verwendung der Programmiersprache C# erstellt.
• Die Dokumentation der Abläufe, der Umgebung und der Klassenstrukturen erfolgt – soweit zielführend – gemäß UML 2.0. Die UML-Diagramme werden in das Pflichtenheft bzw. die Dokumentation eingebunden und zusätzlich digital im XMI-Format (XML Metadata Interchange Format) bereitgestellt. Zur Erstellung der UML-Diagramme wird StarUML verwendet.
• Der erstellte Quellcode wird mit Hilfe von CVS verwaltert.

Die genannten Festlegungen gelten ausschließlich für die konkrete Umsetzung der bayerischen Straßenbauverwaltung. Sie sind im informationstechnischen Umfeld eines anderen Anbieters oder Nutzers nicht zwingend identisch, aber auf diese übertragbar. Es ist im Rahmen serviceorientierter Architekturen ohne Einschränkungen möglich, die geschilderten Lösungsansätze auch mit anderen technischen Systemkomponenten zu realisieren. Die in Bayern gewählte Lösung hat sich im Laufe der bisherigen Realisierung aber als höchst effektiv und wirtschaftlich erwiesen.

Der Freistaat Bayern hat im Rahmen der Erstellung für das System volle Leseberechtigung auf alle erzeugten und benutzten Dokumente. Nach Fertigstellung stehen dem Freistaat Bayern alle erarbeiteten Unterlagen (einschließlich Quellcode) zur Verfügung. Es ist beabsichtigt, die Unterlagen zu veröffentlichen und in die Diskussion der Bund-/Länder-Dienstbesprechung der IT-Koordinierung und der OKSTRA^®-Pflege einzubringen.

Systembeschreibung

Ziel bei der Realisierung des Projektvorhabens war es zunächst, eine Serverapplikation zu realisieren, mit der der Anwender bzw. das vom Anwender benutzte Programm über das Internet auf die Daten der BAYSIS-Datenbank zugreifen kann. Die übermittelten Daten müssen dabei dem OKSTRA^®-Standard genügen. Da die BAYSIS-Datenhaltung in der aktuellen Form unmittelbar keine OKSTRA^®-Objekte anbietet, musste im Rahmen des Projekts eine Serverapplikation erstellt werden, die folgende Aufgaben übernimmt:

• Annahme von Anfragen (Requests) nach OKSTRA^®-Objekten gemäß Web Feature Server Spezifikationen, dievon einem Anwender oder einem Programm über das Internet gestellt Interpretation der Anfragen und Abfrage der entsprechenden BAYSIS-Datensätze bzw. Geometriedaten (MapInfo-Relationen).
• Transformation der Abfrageergebnisse in OKSTRA^®-Objekte.
• Rückgabe der OKSTRA^®-Objekte an die anfragende Stelle über das Internet gemäß Web Feature Server-Spezifikationen.
• Annahme von OKSTRA^®-Objekten gemäß Web Feature Server Spezifikationen, die von einem Anwender odereinem Programm über das Internet gestellt wurden und die in die Datenbank (bzw. die MapInfo-Relationen) übernommen werden („Neue Daten“) oder vorhandene Daten überschreiben („Daten bearbeiten“).
• Bereitstellen von Diensten gemäß Web Feature Server Spezifikationen zum Löschen von Dateien.

Die Serverapplikation besteht aus verschiedenen Komponenten, die über Schnittstellen (Interfaces) kommunizieren (Abbildung). Durch diesen Aufbau wird eine hohe Modularität und Skalierbarkeit sichergestellt.

Weiterhin werden auch weitergehende Lösungen realisiert, welche nicht direkt der Datenbereitstellungsschicht zuzuordnen sind. Exemplarisch hierfür können folgende Lösungen genannt werden:

• Serverseitiges Bereitstellen der komplexen Operationen Längenstatistik, Streckenband und Netzoperationen

• Erstellung eines browserbasierten Netzeditors

Datenbereitstellung

Die Datenbereitstellungsschicht nimmt die Anfragen des Clients entgegen, überprüft, ob diese korrekt und ausführbar sind und kontrolliert, ob der anfragende Client berechtigt ist, die angefragten Informationen zu erhalten. Ist die Anfrage legitim, werden im Falle eines Requests auf Basis des OKSTRA^®-Objektmodells erstellt und an die OKSTRA^®-SIB-Mappingschicht weitergeleitet. Sendet der Client OKSTRA^®-Objekte (z. B. Im Rahmen einer Transaktion) werden diese überprüft und an die Mappingschicht zur weiteren Bearbeitung weitergeleitet. Die Antworten der Mappingschicht sind u. a. OKSTRA^®-Objekte. Diese werden von der Datenbereitstellungsschicht validiert und über Web Feature Services in Form eines Responses an den Client gesendet.

Die folgende Abbildung enthält das Anwendungsfalldiagramm der Datenbereitstellungsschicht.

Bild: Anwendungsfalldiagramm der Datenbereitstellungsschicht

OKSTRA^®-SIB-Mapping

Eine wesentliche Herausforderung für die Kommunikation zwischen der Datenbereitstellungsschicht und der BAYSIS-Datenbank besteht in der Transformationen von OKSTRA^®-Objekten in BAYSIS-Daten und umgekehrt. Diese Transformation war aus fachlicher Sicht der komplexeste Punkt im Rahmen der Projektrealisierung. Es wurde detailliert untersucht, wie die Objekte umzusetzen sind bzw. ob sie überhaupt uni- bzw. bidirektional umgesetzt werden können und welche Einschränkungen hinzunehmen sind. Das Ergebnis der Untersuchungen ist eine Matrix der Objekte und ihrer Möglichkeiten („Capabilities“), die über „getCapabilities“ abgefragt werden können.

Bild: OKSTRA^®-SIB-Mapping

Die OKSTRA^®-SIB-Mappingschicht, in der das O/R-Mapping zwischen OKSTRA^® und BAYSIS realisiert wird, ist vollständig unabhängig von der Datenbereitstellungsschicht, die die WFS und das OKSTRA^®-Objektmodell implementiert. Einige der wichtigsten Anforderungen an die Mappingschicht sind:

• Substituierbarkeit
  Der Austausch von Teilen des Mappings soll mit möglichst wenig Aufwand verbunden sein, so dass bei Änderungen im OKSTRA^® oder BAYSIS flexibel, schnell und kostengünstig reagiert werden kann. Die gleiche Anforderung hinsichtlich Flexibilität ergibt sich auch für die Nutzung mit Datenhaltungen anderer Straßeninformationsbanken, wie sie beispielsweise in anderen Bundesländern zum Einsatz kommen.

• Skalierbarkeit
  Werden neue oder geänderte Objekte unterstützt, sollte eine Erweiterung möglichst einfach sein.

• Offenheit
  „Was“ die Mappingschicht „wie“ mappt, muss für Entwickler und Anwender frei zugänglich und klar dokumentiert sein.

Nach diversen Technologierecherchen wurde folgende Verfahrensweise für das Mapping als sinnvollste Lösung erachtet und entsprechend im Rahmen der Projektrealisierung verwendet. Bei Abfrage eines Objekts wird mit Hilfe von XSLT eine Datenbankabfrage generiert, in welcher sämtliche gesetzten Filter berücksichtigt sind. Für jedes Objekt existiert ein spezielles XSLT-Transformationsskript, das aus den Vorgaben der Mappingbeschreibung erstellt wird. Die Datenbankabfrage wird dabei so formuliert, dass ihre Antwort so weit wie möglich den OKSTRA^®-Strukturen entspricht. Bei der Abfrage wird zudem der Zusatz „FOR XML AUTO“ verwendet, so dass das Abfrageergebnis ein XML-Dokument ist. Das XML-Dokument als Ergebnis der Datenbankabfrage wird anschließend mit einem weiteren für jedes Objekt speziell entwickelten XSLT-Skript soweit transformiert, dass es gültiges OKSTRA^®-XML wird, welches im Bedarfsfall gegen die XML-Schemata des OKSTRA^® validiert werden kann.

Web Feature Services (WFS)

Die Kommunikation zwischen Clientapplikation und der Datenbereitstellungsschicht erfolgt auf Basis der Web Feature Server Spezifikationen. Die dort definierten Operationen werden dabei um die Netzoperationen erweitert und bilden damit die „Baysis Web Services“, kurz „baysisws“. Komplexe Operationen wie Längenstatistik und Streckenband sind nicht Bestandteil der „baysisws“.

Abbildung: Objektdiagramm „baysisws“

Die Web Feature Service Spezifikationen erweitern die OGC Web Services mit einer Reihe von Methoden zum bilateralen Datenzugriff. Die Web Feature Service Spezifikationen werden wiederum durch die Netzoperationen und komplexen Operationen erweitert. Alle Methoden zusammen bilden die Baysis-Web-Services. Als Kommunikationsbasis zwischen den Clients und der Datenbereitstellungsschicht ist ausschließlich „https“ zu verwenden. Zwischen der http-Anwendungsschicht und der TCP-Transportschicht ist eine SSL-Verschlüsselung zwischenzuschalten, so dass die Daten im Internet sicher sind vor unberechtigten Zugriffen (so genanntes „https“).

Die Datenbereitstellungsschicht bietet ihre Dienste in Form von Webservices an. Für den Austausch der Daten zwischen den Systemen, d.h. die Nutzung der angebotenen Webservices, wird ausschließlich das SOAP-Protokoll zu verwendet. Der Datenaustausch erfolgt, in dem der Client Anfragen („Requests“) an die Datenbereitstellungsschicht sendet. Diese verarbeitet den Request und liefert die Antwort („Response“) zurück an den Client. Der Datenaustausch über SOAP besteht demnach aus dem Request und dem Response.

Web Service Beschreibung (WSDL)

Die Webservices, die von der Datenbereitstellungsschicht angeboten werden, sind durch ein WSDL-Dokument eindeutig beschrieben. Ruft der Client die entsprechende URL auf dem Server auf, so wird das WSDL-Dokument dynamisch (und damit stets aktuell) übermittelt.

Die im nachstehenden WSDL-Dokument (Auszug) beschriebenen Webservices entsprechen den Implementierungsspezifikationen des Web Feature Service (WFS), mit deren Hilfe OKSTRA-Objekte angefordert, geändert, hinzugefügt oder gelöscht werden können.

Bild: WSDL-Dokument (Auszug)

SOAP

Für die Übertragung von WFS-Requests und -Responses wird ausschließlich SOAP verwendet. Die nachstehende Abbildung zeigt einen SOAP-Envelope für „getFeature“.

Bild: SOAP-Envelope

Wie aus dem Beispiel erkennbar wird, wird im Header des Envelope die Benutzerberechtigung mit übergeben. Die Ursache für diese Rechteverwaltung liegt darin begründet, dass die Definitionen des Web-Feature-Servers keine „eigene Rechteverwaltung“ kennt und diese deshalb im „Umschlag“ für das Datenpaket geliefert werden muss. Der mögliche Nachteil bei diesem Ansatz ermöglicht aber die effektive Verrechnung der Serveranfragen im Rahmen eines Bezahlsystems für Datennutzungen. Der Server liest dabei die Berechtigung der eingehenden SOAP-Nachricht und leitet diese parallel zum Beantwortungsweg an eine Verarbeitung weiter, die in Abhängigkeit der Anfrage eine Kostenermittlung und -verrechnung durchführen.

Komplexe Services

Zur effizienten Nutzung einer Straßeninformationsbank ist es notwendig, Dienste bereitzustellen, die über die Spezifikationen des Web Feature Servers hinausgehen. Mit den Web Feature Services können OKSTRA^®-Objekte abgefragt und verändert werden. Für einige Anwendungen ist es jedoch erforderlich, sehr viele Daten in komplexer Weise abzufragen, zu verändern oder neu hinzuzufügen, so dass hier eine Vielzahl von Webservices ausgeführt und große Datenmengen ausgetauscht werden müssten. Dies belastet seitens der Clientapplikation den Entwicklungsaufwand und die Ausführungsgeschwindigkeit negativ. Es werden daher mehrere so genannte „komplexe Services“ serverseitig implementiert und bereitgestellt, die eine Vielzahl von Einzeloperationen automatisch und performant abarbeiten.

Komplexe Services, die im Rahmen des aktuellen Projektes implementiert werden, sind folgende:

• Längenstatistik
  Serverseitig wird ein Dienst implementiert, der auf Anfrage eine Längenstatistik unter Beachtung der vom Client spezifizierten Kriterien erstellt.
• Streckenband
  Serverseitig wird ein Dienst implementiert, der auf Anfrage ein (noch in Absprache mit dem AG zu spezifizierendes) Streckenband als SVG-Grafik erstellt, auf welchem verschiedene Fachobjekte visualisiert sind.

Zusammenfassung und Ausblick

Ziel des Projekts OKSTRA^®-konforme Web-Services ist die Einführung einer offenen Datenbereitstellungsschicht für das Bayerische Straßen-Informationssystem BAYSIS unter Berücksichtigung vorhandener Standards sowie die Erzeugung von Anwendungen, die auf dieser Technik aufbauend eine optimierte Arbeitsunterstützung für unterschiedlichste Fragestellungen bereitstellen. Für die Erarbeitung der OKSTRA^®-konformen Web-Services in dem geschilderten Umfeld wurde der komplette Lösungsansatz und damit die notwendigen Grundlagen zur Implementierung der Datenbereitstellungsschicht mit vollständiger Lese- und Schreibefunktionalität für sämtliche OKSTRA^®-Objekte in einem Feinkonzept beschrieben und dieses technisch umgesetzt. Soweit die Standards nicht konkret oder differenziert genug beschrieben waren, wurden entsprechende Vertiefungen durchgeführt.

Die erzielten Ergebnisse belegen die Richtigkeit des gewählten Ansatzes und werden die erwarteten Synergieerfolge zeitnah freisetzen. Die möglichen Potentiale zeigten sich bereits in einem Parallelprojekt, das zum Ziel hat, BAYSIS-Daten auf mobile Endgeräte (Handy-PDAs) zu bringen. Ohne großen Mehraufwand war es dabei möglich, die im Rahmen der OKSTRA^®-konformen Web-Services angebotenen Datenzugriffsmöglichkeiten unmittelbar auch im Umfeld mobiler Endgeräte zu nutzen.

Bild: OKSTRA-konforme-Web-Services in BAYSISmobil

Auch wenn die gezeigten Beschreibungen OKSTRA^®-konformer Web-Services die „bayerische Lösung“ der Aufgabenstellung wiedergeben, so können alle dargestellten Elemente vollständig und mit geringem Anpassungsaufwand auch auf andere Straßeninformationssysteme übertragen werden. Um diese Umsetzung zu unterstützen, werden die Ergebnisse des bayerischen Projektansatzes in nächster Zeit den verschiednen Fachgremien (z. B. OKSTRA^®-Pflegestelle, Bund/Länder-Dienstbesprechung IT-Koordinierung Straßenwesen) zugeleitet und mit diesen diskutiert werden.