OSM und der öffentliche Verkehr

Ich habe mich in den letzten Tagen intensiv mit Open Street Map und mit Offenen Daten den öffentlichen Verkehr betreffend beschäftigt. Folgendes mag ich mir merken:

JOSM ist der Editor der Wahl, wenn es um die Bearbeitung von Open Street Map geht. Es arbeitet sowohl mit Java7 als auch mit Java8. Richtig vollständig ist es aber nur, wenn man es zusammen mit Overpass-Turbo.eu verwendet, denn JOSM selbst kann zwar OSM-Daten Laden, dann aber nur den vollen Datensatz der entsprechenden Region. Und da es bei den öffentlichen Verkehren die ich betrachtet habe um recht lange Strecken ging, hat das den Server vollständig überfordert.

Letztendlich bin ich so vorgegangen:

  1. Für den öffentlichen Verkehr sind die sogenannten Relations relevant, weshalb nur jene heruntergeladen werden. In Overpass-Turbo.eu folgende Abfrage (mit Chrome, Safari wollte nicht exportieren) durchgeführt, jeweils mit oder ohne Tagabfrage zur Linie die mich interessiert:
    <osm-script output="xml" timeout="25"> <query type="relation">
    <has-kv k="route" v="bus"/>
    <has-kv k="ref" v="190"/><!-- Hier Linie eingeben, bzw. Tag weglassen -->
    <bbox-query {{bbox}}/>
    </query>
    <print mode="meta"/>
    <recurse type="down"/>
    <print mode="meta" order="quadtile"/>
    </osm-script>
  2. JOSM starten und in den Einstellungen die Remote-Funktion aktivieren. So einstellen, dass Remote-Daten in ein neues Layer gespeichert werden. Ohne war ziemlich doof.
  3. in overpass-turbo.eu auf Export klicken, dort auf Direkt mit JOSM
  4. Die Daten werden in ein neues Layer in JOSM importiert und können dort editiert werden. Das Programm sieht etwas kryptisch aus (ist Java) funktioniert aber tadellos. Links unten kann man entscheiden, welche Paletten rechts auftauchen. Ich brauchte Relationen, Merkmale/Mitgliedschaften und Ebenen. Später kommen noch Prüfergebnisse dazu.
  5. Relationen basieren immer auf einer vorhandenen Geometrie, die aber, sofern eine Linie bereits vorhanden ist, schon passend von JOSM dazu geladen wurden.
  6. Legt man eine neue Linie an (wie ich die Linie 192), so braucht man die Straßengeometrien, die mir overpass-turbo.eu unter „Wizard“ unter dem Schlagwort „Straßennetz“ zur Verfügung stellt. Auch diese Daten wieder Direkt an JOSM schicken.
  7. Manche der Straßen über die mein Bus rollert, sind nicht als relevante Straße verschlagwortet, wodurch sie nicht über die Abfrage kommen. An jenen Stellen müssen Daten nachgeladen werden. An dieser Stelle habe ich direkt JOSM bemüht. Wichtig: Ein Müllllayer anlegen und aktivieren, dann auf das Icon zum herunterladen klicken. Relevanten Bereich wählen (sollte sehr klein sein, der Server meckert sonst!) und die Daten hereinladen. Anschließend die für die Lückenschließung relevanten Geometrien auswählen, kopieren (Cmd+C), das Layer wechseln und dort die Daten einfügen.
  8. Wie man Relationen editiert schreibe ich hier nicht rein, dazu gibt es bereits hinreichende Anleitungen. Einzig der Hinweis auf das neue Schema sei gestattet: link
  9. Nach diesem neuen Schema gibt es sowas wie Alternativrouten innerhalb einer Relation nicht mehr (das gab es vorher), sondern jede Fahrvariante, soll als neue Relation angelegt werden. Bei meinem Testfall, der Linie 192 bedeutet das, dass ich bei 7 Fahrten am Tag, 7 verschiedene Relationen anlegen musste.
  10. Anschließend wird versucht die neue Relation hochzuladen, woran uns aber die validation hindert. Alle (oder die meisten) Fehler sollte man ausräumen. Das dauert eine gewisse Zeit, insb. wenn man eine 46km lang Busroute als ersten Editierungsversuch neu anlegt ^^. Ist es hochgeladen wird es beinahe sofort auf den obenstreetmap-Servern (bzw. www.öpnvkarte.de) sichtbar.

Nachdem ich also herausgefunden hatte wie man OSM-Daten editiert (ist nicht so schwer, braucht aber halt etwas Zeit, primär weil man ziemlich viel nachschlagen muss, wie die Elemente nun zu attributieren sind), machte ich mich daran herauszufinden, was man denn mit so einer ÖV-Route anfangen kann. Ich dachte mir, dass schon irgendwer aus den OSM-Daten irgendwas Verkehrssimulationsmäßiges gemacht hat, aber soweit ich das überblicken kann, ist die Lage da eher solala. Entscheidend scheint zu sein, dass man an sogenannte GTFS-Daten kommt. GTFS ist ein Austauschformat das seit ein paar Jahren anerkannter offener Standard ist. Der Nachteil: In Deutschland ist das noch nicht angekommen. Zum einen, weil wir dank der Deutschen Bahn ein wunderbar funktionierendes und zentralisiertes Auskunftssystem haben. Es braucht garkeine Informatikpunks, die etwas alternatives aufbauen. Außerdem haben wir Verkehrsverbünde, wieder zentralisierte Einheiten, die die Netzplanung machen. Die brauchen die Daten und die haben die Daten. Es gibt bereits etablierte Schnittstellen der ÖV-Betriebe die genutzt werden (aber an die Privatleute nicht dran kommen).

GTFS-Daten. Vom NVV sind die nicht zu bekommen. Einerseits weil sie sie selbst nicht haben und Andererseits weil die hessischen Verkehrsverbünde viel mit Politik zu tun haben…

Also hilft für den Moment nur: Selber machen.

Es gibt verschiedene Ansätze:

  • osm2gtfs.js – ist eine Javascript-Bibliothek die ich nicht verstanden habe.
  • osm2gtfs ist eine Visual-Studio-Applikation für Windows, die lediglich rudimentär funktioniert. Ich habe zwar die Haltestellen als gtfs mit dieser Software bekommen, alles andere hat aber nicht funktioniert. (UPDATE: Das Locale hat es wohl kaputt gemacht: Punkt vs. Komma… Microsoft…)
  • GTFS-OSM-Sync ist eine Java-Applikation um GTFS-Daten mit OSM-Daten zu vergleichen und bei Änderungen in einem der Datensätze dem Benutzer Hinweise zu geben, was zu ändern ist.
  • gtfs-edit ist eine Java-Applikation mit Web-GUI. Sehr solide Oberfläche, aber noch mit rudimentärem Funktionsumfang. Zum Beispiel kann es keine Geometrien importieren und somit bekomme ich die OSM-Daten da nicht so ohne weiteres rein. Der Editor kann lediglich GTFS-Daten importieren. Aber die habe ich ja noch nicht ^^. Ich habe mich aber mal an den Code gewagt: Die GUI besteht primär aus JavaScript wodurch ich in der Lage sein sollte, das selbstständig zu erweitern. Besonders positiv ist mir aufgefallen, dass sie für das Setzen der Geometrien (a.k.a. Haltestellen) Leaflet.js und Leaflet.draw.js verwenden, d.h. ich kann sicher auf Leaflet.osm.js dazu nutzen um die Haltestellen zu setzen. gtfs-edit unterstützt leider bisher nicht die shapes.txt der GTFS-Datenstruktur, so dass die Mehrzahl der OSM-Daten in Bezug auf GTFS verworfen werden, aber an anderer Stelle kann man diese Daten sicher noch sinnvoll nutzen.
  • UPDATE: Es gibt auch noch GTFS-Maker das auf OSM-Daten zu basieren scheint. Da die Dokumentation aber ausschließlich auf italienisch (esperanto?) ist, bin ich etwas unschlüssig was es tut… Hm. Sieht ziemlich gut aus, wenn man den „fixes“ Branch wählt… braucht aber noch Arbeit, ist noch ziemlich im Entwicklungszustand (seit einem Jahr stalled…).

Das OK Lab Ulm hat eine Livemap des Ulmer ÖPNV gebastelt und via Github veröffentlicht. Hätte man GTFS-Daten, könnte man diese Software (auch JavaScript) hervorragend auf Nordhessen umbauen und von da aus wer weiß was machen. Im Moment träume ich ja von einem Partizipationsbaukasten auf Basis dieser Software. Dynamisch die GTFS-Daten anpassen lassen und so Umsteigezeiten optimieren, etc. Und da das alles JavaScript ist, muss man noch nicht mal einen Leistungsfähigen Server haben. Das ist alles im Browser machbar. 🙂 Aber das ist alles sehr viel Arbeit. Und ich habe noch nicht mal GTFS-Daten…

 

Leave a Reply

Your email address will not be published. Required fields are marked *