387 Routing und Visualisierung im individuellen ÖPNV Daniel MAIER Zusammenfassung Im vorliegenden Beitrag wird die Entwicklung eines webbasierten Informationssystems für den ÖPNV beschrieben. Dazu wird ein Überblick gegeben, wie Methoden der Geoinformatik, Softwarebausteine und frei verfügbare Daten im Bereich des Personennahverkehrs genutzt werden können, um eine Visualisierung des Transportnetzes auf Grundlage von Google Maps zu erstellen. Ziel dieser Applikation ist es, die Attraktivität des Nahverkehrs zu steigern sowie den Nutzer bei der Wegoptimierung zu unterstützen, indem ihm ein komfortabler Zugriff auf die Fahrplandaten zur Verfügung gestellt wird. Abgerundet wird der Beitrag durch eine Performanzuntersuchung, die in einer frühen Phase der Entwicklung Aufschlüsse über das Zeit-Antwort-Verhalten der Applikation geben soll. 1 Einleitung 1.1 GIS im Verkehrsbereich Mit der fast allgegenwärtigen Nutzbarkeit des Internets, der wachsenden Leistungsfähigkeit von mobilen Endgeräten oder der Verfügbarkeit von freier Software und Geodaten ergeben sich viele interessante Möglichkeiten für die Entwicklung von webbasierten GIS- Applikationen. Für das Transport- und Verkehrswesen gibt es bereits eine Vielzahl von GIS-Anwendungen (BILL 2010). Die Unterstützung der Navigation von Fahrzeugen, die Bereitstellung von digitalen und analogen Karten zur Verkehrsführung, das Flottenmanagement, die Einsatzplanung und Einsatzkontrolle in Notdiensten sind als Beispiele zu nennen (ZAGEL 2000). Ziel der Verkehrstelematik (Telematik = Telekommunikation und Informatik) ist die Effizienzsteigerung von Verkehrs- und Transportprozessen, die Erhöhung der Sicherheit und des Reisekomforts sowie die Reduktion der Umweltbelastungen durch Einsatz intelligenter Technik. 1.2 Eine Anwendung zu Routing und Visualisierung im ÖPNV Im Folgenden wird die Konzeption und Umsetzung einer internetbasierten Anwendung für den Öffentlichen Personennahverkehr (ÖPNV) beschrieben. Auf Basis von Google Maps und unter Verwendung von Daten aus dem OpenStreetMap-Projekt wurde eine Visualisierung der Fahrplandaten für das Straßenbahnnetz der Rostocker Straßenbahn AG (RSAG) erstellt. Über einen Browser kann sich der Nutzer die aktuellen Positionen der Straßenbahnen laut Fahrplan sowie die Haltestellen mit den dazugehörigen Abfahrtstafeln auf einer Google Map anzeigen lassen. Neben der Benutzeroberfläche wurde ein Datenmodell konzipiert und umgesetzt, in dem Informationen zu den Haltestellen, Streckenabschnitten zwischen den Haltestellen, Ab- Strobl, J., Blaschke, T. & Griesebner, G. (Hrsg.) (2011): Angewandte Geoinformatik 2011. Herbert Wichmann Verlag, VDE VERLAG GMBH, Berlin/Offenbach. ISBN 978-3-87907-508-9. Dieser Beitrag ist ein Open-Access-Beitrag, der unter den Bedingungen und unter den Auflagen der Creative Commons Attribution Lizenz verteilt wird (http://creativecommons.org/licenses/by/3.0/).
388 D. Maier fahrtszeiten und Linieninformationen gespeichert werden. Das Datenmodell bildet die Topologie des ÖPNV-Netzes in einem Knoten-Kanten-Modell als Grundlage für Routingberechnungen ab. Um die dafür notwendige Erfassung von Fahrplandaten zu erleichtern, wurde eine Schnittstelle erarbeitet, die das Einfügen von Abfahrtszeiten in die Datenbank ermöglicht. Abschließend wurde die Anwendung hinsichtlich der Performanz untersucht. 2 Softwarekomponenten, Daten und Systemarchitektur 2.1 Softwarekomponenten und Daten Praktischerweise gibt es für fast jedes Teilproblem der Aufgabenstellung freie Software und Schnittstellen, die für das Projekt genutzt werden können. So wird für die Datenhaltung die Datenbank PostgreSQL eingebunden, die Visualisierung erfolgt über die Google Maps API, die Routingfunktionalität übernimmt die PostgreSQL-Erweiterung pgrouting und selbst die Sachdaten müssen nicht selbst erhoben werden sie können aus OpenStreetMap sowie den Fahrplänen der RSAG entnommen werden. Dem Entwickler eröffnet sich so die Möglichkeit, sich auf die Optimierung der Komponenten zu konzentrieren und das Zusammenspiel der Bestandteile zu organisieren. 2.2 Client-Server-Architektur Das Informationssystem wurde nach der Client-Server-Architektur (KORDUAN & ZEHNER 2008) konzipiert. Zum einen werden auf dem Server die Webapplikationen gespeichert, außerdem befindet sich die Datenbank mit den programmrelevanten Daten auf dem Server. Der Vorteil dieses Konzepts ist, dass die Informationen zentral verwaltet werden, d. h. Änderungen müssen nur einmal bearbeitet werden, überdies ist der Speicherbedarf geringer, als wenn die Daten auf jedem Client hinterlegt werden. Gerade auf mobilen Endgeräten mit beschränkten Ressourcen und bei großen Datenmengen ist eine Speicherung des kompletten Modells auf der Clientseite nicht umsetzbar. Ein weiterer Aspekt dieser Technologie ist, dass viele Clients gleichzeitig über ein Netzwerk auf einen Server zugreifen können. 2.3 Recherche zu ähnlichen Anwendungen Bei der Seite swisstrains.ch handelt es sich um ein auf Google Maps basiertes Mashup. Es entstand durch enge Zusammenarbeit von Google Maps mit der Schweizerischen Bundesbahn (SBB), des Zürcher Verkehrsverbundes (ZVV) und den Verkehrsbetrieben Zürich (VBZ). Diese Applikation zeigt die Positionen sämtlicher Personenzüge des öffentlichen Verkehrsnetzes der Schweizerischen Bundesbahn (SBB) an und stellt diese auf einer Karte dar. Die Visualisierung der Verkehrsmittel und somit ihrer Positionen basieren zurzeit auf den Daten der Fahrpläne, d. h. die Applikation zeigt also nicht, wo ein Zug tatsächlich ist (keine Echtzeitdarstellung), sondern das System errechnet lediglich die Lage, wo die Bahn sich gemäß Fahrplan befinden müsste. Durch Klicks auf die Züge bzw. auf das Zugsymbol können zusätzliche Informationen über die Route und Geschwindigkeit des Zuges abgefragt werden. Das Projekt Route4you ist eine internetbasierte Routingsoftware, die besonders auf die Bedürfnisse von Blinden und Rollstuhlfahrern ohne Ortskenntnis ausgerichtet ist (PRESSL &
Routing und Visualisierung im individuellen ÖPNV 389 WIESER 2010). Die Nutzer können sich Touren unter Verwendung von Fahrplandaten generieren lassen. Dabei ist es möglich ein Benutzerprofil zu erstellen, das bei der Routenplanung und Optimierung der Route berücksichtigt wird. Das Profil enthält unter anderem Angaben über Hindernisse, die für die Person von Belang sind. Die im Beitrag beschriebene Anwendung soll wie swisstrains allen Nutzern des ÖPNV zur Verfügung stehen und wird nicht für eine spezielle Anwendergruppe konzipiert. Dabei wird die Visualisierung mit der Routingfunktionalität verknüpft. Ein Hauptaugenmerk liegt auf der Erweiterbarkeit der Anwendung. Neue Funktionalitäten, wie Hausnummernkoordinaten oder eine 3D-Darstellung von Routen, müssen sich ohne wesentliche Änderungen am Konzept hinzufügen lassen. 3 Modellierung, Implementierung und Performanzuntersuchungen 3.1 Modellierung und Abbildung der Topologie des ÖPNV-Netzes Zur Vorbereitung der Routingberechnungen wurde ein Datenmodell (Abb. 1) entwickelt, das neben den Fahrplandaten auch die Topologie des Verkehrsnetzes mithilfe eines gerichteten Graphen abbilden kann (Knoten-Kanten-Modell). Das Datenmodell wurde auf einer PostgreSQL-Datenbank auf dem Server umgesetzt. In der vorgestellten Applikation bilden die Gewichte der Kanten die Fahrzeit zwischen den Haltestellen ab. Die Relation departures enthält die Knoten und die Relation edges die Kanten des Graphen. Die Relation edges soll aus den Tabellen stations, station2line und departures automatisch generiert werden. Zusätzlich wurden einige Beschränkungen umgesetzt, die sicherstellen, dass die erhobenen Daten korrekt übernommen werden. Beispielsweise darf sich an einem durch die Latitude und Longitude eindeutig bestimmten Punkt nur eine Haltestelle befinden. Außerdem wird geprüft, dass die Abfahrtszeit einer Linie an einer Station nur einmal vorhanden ist, oder dass eine Haltestelle immer einen positiven zeitlichen Abstand von der dazugehörigen Starthaltestelle hat. Abb. 1: Klassen des Datenmodells
390 D. Maier 3.2 Implementierung In einem ersten Schritt wurde begonnen, die Webanwendung auf die Portalsoftware Liferay zu portieren. Liferay ist ein Portalserver, der die Möglichkeit bietet, eine Webseite aus einzelnen Kacheln zu erstellen. In diesen Kacheln werden Applikationen ausgeführt die Portlets. Sie geben die Sicht auf der Portalseite vor, während auf dem Server ein dazugehöriges Programm (z. B. ein Java-Programm) ausgeführt wird. So wird dem Entwickler eine Möglichkeit eröffnet, clientseitige Programmierung mit Ajax, HTML und JavaScript mit komplexer serverseitiger Programmierung in Java zu kombinieren. Portlets sind durch die Java Portlet Specification (JSR 168) standardisiert (KUSSMAUL 2005). Für den ersten Prototyp wurden zwei Portlets erstellt: Das Erste enthält die Kartendarstellung über die Google Maps API sowie Eingabemöglichkeiten, das Zweite realisiert die Schnittstelle zur Datenbank. Die Erfassungsschnittstelle für das Auskunftssystem berechnet automatisiert die Abfahrtszeiten an den Stationen einer Linie entsprechend der ersten Abfahrtszeit und fügt diese in die Datenbank ein. Die Abfahrtstafeln für eine Haltestelle können von Nutzer über einen Klick auf ein Haltestellensymbol auf der Karte geöffnet werden. Die Informationen, welche Bahnen an der Haltestelle als Nächstes abfahren, werden durch per SQL-Anfrage ermittelt. Die Ergebnisse der Anfrage werden innerhalb eines Infofensters als Tabelle angezeigt. Abb. 2: Darstellung einer Abfahrtstafel 3.3 Performanzuntersuchungen Die Performanz wird im Zuge der vorliegenden Arbeit durch zwei verschiedene Messverfahren untersucht. Zuerst werden Einzelanfragen durchgeführt, anschließend wird ermittelt wie viel Zeit für die Bearbeitung auf der Serverseite bzw. wie viel Zeit clientseitig benötigt wurde. Für das zweite Verfahren wurde ein Java-Programm geschrieben, das mehrere pa-
Routing und Visualisierung im individuellen ÖPNV 391 rallele Threads erzeugt und so gleichzeitige Zugriffe auf die Daten simuliert. Die Prozesse werden dabei über eine sogenannte CyclicBarrier synchronisiert. 3.3.1 Einzelanfragen Um die Laufzeit einer Anfrage auf der Server- und Clientseite zu ermitteln, wurde das Firefox-Plug-in Firebug benutzt. Das Plug-in unterteilt das Laden der Daten in DNS- Lookup, Verbinden, Blockieren, Senden sowie serverseitig in Warten und Empfangen. Bei der untersuchten Anfrage handelt es sich um die Berechnung der nächsten 6 Abfahrten an der Station Friedensforum. Tabelle 1: Laufzeiten von Einzelanfragen DNS-Lookup Verbinden Blockieren Senden Warten Empfangen 3 ms 41 ms 1 ms 0 ms 85 ms 0 ms 2 ms 74 ms 2 ms 0 ms 136 ms 0 ms 1 ms 245 ms 1 ms 0 ms 226 ms 0 ms 1 ms 41 ms 1 ms 0 ms 85 ms 0 ms 1 ms 44 ms 1 ms 0 ms 82 ms 0 ms 1 ms 40 ms 0 ms 0 ms 87 ms 0 ms 4 ms 99 ms 1 ms 0 ms 208 ms 0 ms 10 ms 48 ms 1 ms 0 ms 88 ms 0 ms 6 ms 126 ms 0 ms 0 ms 202 ms 0 ms 2 ms 46 ms 1 ms 0 ms 83 ms 0 ms 3,1 ms 80,4 ms 0,9 ms 0 ms 128,2 ms 0 ms Eine durchschnittliche Einzelanfrage benötigte 212,6 ms von Absetzen der Anfrage bis zum Abschluss der Übertragung. Dabei wurden 84,4 ms vom Client benötigt, um die Anfrage an den Server abzusetzen, sowie im Mittel 128,2 ms auf der Serverseite, um die Ergebnisse zum Browser zu senden. Der Bearbeitungszeitraum war serverseitig also um den Faktor 1,52 größer. 3.3.2 Parallele Anfragen Das entwickelte Java-Programm simuliert parallele Zugriffe auf den Server. Insgesamt wurden 35 Messungen durchgeführt, bei denen die durchschnittliche Laufzeit der Threads vom Start an der CyclicBarrier bis zum erfolgreichen Übertragungsende gemessen wurde. Jeder Prozess erstellt seine eigene Verbindung zum Server und ruft über diese eine PHP- Seite ab, die wiederum eine Datenbankanfrage durchführt. Das berechnete Ergebnis der Abfrage stellt die sechs nächsten Abfahrtszeiten am Mittwoch um 10:00 Uhr an einer Haltestelle dar. Das für die Messungen benutzte Datenbankmanagementsystem ist so konfiguriert, dass bis zu 100 Verbindungen gleichzeitig angenommen werden können. Tabelle 2 zeigt die Ergebnisse des beschriebenen Testprogramms. Man erkennt, dass die Laufzeiten der Prozesse mit steigender Anzahl paralleler Anfragen größer werden. Die Kurve deutet auf ein lineares Wachstum hin. Ein positives Ergebnis der Messungen ist, dass auch bei 30 parallelen Prozessen die durchschnittliche Abfragedauer unter einer Sekunde lag und die Performanz somit in dieser Größenordnung sehr gut ist.
392 D. Maier Tabelle 2: Laufzeitverhalten paralleler Anfragen Anzahl Messung 1 Messung 2 Messung 3 Messung 4 Messung 5 Durchschnitt Threads 1 90 ms 82 ms 162 ms 87 ms 363 ms 156,8 ms 5 191 ms 308 ms 607 ms 189 ms 191 ms 297,2 ms 10 300 ms 318 ms 323 ms 273 ms 292 ms 301,2 ms 15 476 ms 396 ms 461 ms 543 ms 384 ms 452 ms 20 506 ms 576 ms 506 ms 488 ms 519 ms 519 ms 25 680 ms 659 ms 672 ms 869 ms 801 ms 736,2 ms 30 847 ms 1.016 ms 846 ms 909 ms 848 ms 893,2 ms 4 Fazit Im vorliegenden Prototyp des Fahrplanauskunftssystems wurde ein Datenbankmodell entworfen, auf dem ein Routing durch das Verkehrsnetz möglich ist. Die Eingabeschnittstelle des Systems stellt dem Nutzer ein Tool zur Verfügung, mit dem das Einfügen der Abfahrtszeiten erleichtert wird. Mit der vorliegenden Kartendarstellung, auf der die Positionen der Fahrzeuge sowie Abfahrtstafeln dargestellt werden, wird dem Nutzer des Auskunftssystems eine einfache und schnelle Zugriffsmöglichkeit auf Fahrplaninformationen zur Verfügung gestellt. Die Performanzuntersuchung zeigte, dass die Hauptlast beim Server liegt. Im Moment gibt es trotz paralleler Anfragen noch keine Performanzprobleme. Allerdings deutet sich bei den serverseitigen Berechnungen ein zukünftiger Flaschenhals an. Die Applikation bietet außerdem eine Vielzahl von Erweiterungsmöglichkeiten. Beispielsweise kann die vorhandene Kartendarstellung um Points of Interest ergänzt werden, wie Taxistände, Parkplätze und Fahrradstationen, oder es kann eine 3D-Visualisierung entwickelt werden. Auch seitens der Eingabeschnittstelle sollen weitere Importmöglichkeiten umgesetzt werden, die im Moment noch manuell eingefügt werden (z. B. automatischer Import des Linienverlaufs). Literatur BILL, R. (2010): Grundlagen der Geo-Informationssysteme. 5. Aufl. Wichmann Verlag, Berlin/Offenbach. 809 S. KORDUAN, P. & ZEHNER, M. L. (2008): Geoinformation im Internet. Technologien zur Nutzung raumbezogener Informationen im WWW. Wichmann Verlag, Heidelberg. 314 S. KUSSMAUL, T. (2005): Die Java-Portlet-Spezifikation. JavaSpektrum, 3, S. 39-43. PRESSL, B. & WIESER, M. (2010): Datenmodellierung und Routenplanung für behinderte Personen auf der Basis von Fahrplänen. In: STROBL, J. et al. (Hrsg.): Angewandte Geoinformatik 2010. Wichmann Verlag, Berlin/Offenbach, S. 262-270. ZAGEL, B. (Hrsg.) (2000): GIS in Verkehr und Transport. Wichmann Verlag, Heidelberg, 244 S.