Analysierte Verbunde

Die Analyseergebnisse mussten ausgelagert werden, da die CPU-Belastung des OSM-Wiki-Servers beim Rendern der vielen großen Tabellen zu hoch wurde. Die Ergebnisse sind eh nur read-only, eine Editierfunktion ist also überflüssig. Die neue Adresse ist u.U. nur temporär und wird möglicherweise demnächst durch eine "aussagekräftigere" Adresse ersetzt.
Die Tabelle hier enthält in der ersten Spalte Links auf die Daten auf der neuen Site.

Name	City/Region	Networks	Discussion	Lines	Edit Lines	History Lines
DE-BY-AVV	Augsburg	Augsburger Verkehrs- und Tarifverbund	Discussion	AVV Lines	Edit	History
DE-BY-DGF	Dingolfing	Dingolfinger Regionalbusnetz	Discussion	DGF Lines	Edit	History
DE-BY-INVG	Ingolstadt	Ingolstädter Verkehrsgesellschaft mbH	Discussion	INGV Lines	Edit	History
DE-BY-LA	Landshut	Landshuter Regionalbusnetz; Landshuter Stadtbusnetz	Discussion	LA Lines	Edit	History
DE-BY-MVV	München	Münchner Verkehrs- und Tarifverbund und weitere	Discussion	MVV Lines	Edit	History
DE-BY-RBO	Ostbayern (Niederbayern, Oberpfalz)	Regionalbus Ostbayern	Discussion	RBO Lines	Edit	History
DE-BY-RVO	Oberbayern	Regionalverkehr Oberbayern	Discussion	RVO Lines	Edit	History
DE-BY-RVV	Regensburg	Regensburger Verkehrsverbund	Discussion	RVV Lines	Edit	History
DE-BY-VGN	Nürnberg	Verkehrsverbund Großraum Nürnberg	Discussion	VGN Lines	Edit	History
DE-BY-VGRI	Pfarrkirchen / Landkreis Rottal-Inn	Verkehrsgemeinschaft Rottal-Inn	Discussion	VGRI Lines	Edit	History
DE-BY-VLC	Cham	Verkehrsgemeinschaft Landkreis Cham	Discussion	VLC Lines	Edit	History
DE-BY-VLD	Deggendorf	Verkehrsgemeinschaft Landkreis Deggendorf	Discussion	VLD Lines	Edit	History
DE-BY-VLK	Kelheim	Verkehrsverbund Landkreis Kelheim	Discussion	VLK Lines	Edit	History
DE-BY-VLMÜ	Mühldorf	Verkehrsgemeinschaft Landkreis Mühldorf	Discussion	VLMÜ Lines	Edit	History
DE-BY-VSL	Straubing	Verkehrsgemeinschaft Straubinger Land	Discussion	VSL Lines	Edit	History
DE-HB-VBN	Bremen / Niedersachsen	Verkehrsverbund Bremen/Niedersachsen	Discussion	VBN Lines	Edit	History
DE-HE-NVV	Kassel / Nordhessen	Nordhessischer VerkehrsVerbund	Discussion	NVV Lines	Edit	History
DE-NW-VRS	Rhein-Sieg	Verkehrsverbund Rhein-Sieg; NRW Regionalverkehr	Discussion	VRS Lines	Edit	History
DE-RP-VRN	Rhein-Neckar	Verkehrsverbund Rhein-Neckar	Discussion	VRN Lines	Edit	History
DE-SN-VMS	Chemnitz / Zwickau	Verkehrsverbund Mittelsachsen	Discussion	VMS Lines	Edit	History

Overpass-API Abfrage

Für die Auswahl der Daten wird das Overpass-API verwendet. Die Abfrage erfolgt außerhalb des eigentlichen Analysetools durch einen wget-Aufruf unter Linux.

Aufbau der Overpass-API-Abfrage

Die Abfrage selber gliedert sich in 7 Teile:

Eingrenzung und Abspeichern des Gebietes

Als (Regierungs-)Bezirk

area[boundary=administrative][admin_level=5][name='Oberbayern']->.O

Als (Land-)Kreis (hier zwei Kreise: Kreisfreie Stadt "Landshut" und "Landkreis Landshut")

area[boundary=administrative][admin_level=6][name~'Landshut']->.O

Als Liste von (Land-)Kreisen

area[boundary=administrative][admin_level=6][name~'(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)']->.O

Als Geimeindegebiet

area[boundary=administrative][admin_level=8][name='Ottobrunn']->.O

Als Gebiet eines Verkehsverbundes

area[boundary=public_transport][name='Verkehrsverbund Rhein-Sieg']->.O

Via Polygon

(poly:'48.0770 11.6378 48.0436 11.6378 48.0436 11.7024 48.0770 11.7024')

Auswahl und Abspeichern der Routen innerhalb des Gebietes

Es erfolgt eine unscharfe Auswahl durch Verwendung von '~'. Das stellt sicher, dass auch "verdächtige" Relationen mit z.B. route='suspended_bus' gefunden werden.
Es wird absichtlich nach 'route' und nicht nach 'route_master' gesucht, da PTv1 keine Route-Master kennt und wir eine Bestandsaufnahme aller ÖPNV Linien anstreben.
Nur Busse

rel(area.O)[route~'bus']->.R

Busse und Bahnen

rel(area.O)[route~'(bus|train)']->.R

Alle bekannten ÖPNV Typen

rel(area.O)[route~'(bus|tram|train|subway|light_rail|trolleybus|ferry|monorail|aerialway|share_taxi|funicular)']->.R

Suche und Ausgabe der zugehörigen Route-Master (Eltern-Relationen)

Die Tags der Eltern-Relationen sowie die IDs der Member der Eltern-Relationen

rel(br.R); out

Suche und Ausgabe der eigentlichen Routen

Die Tags der Relationen und IDs der Member der Relationen

rel.R; out

Suche und Ausgabe der Member der Routen, die wiederum Relationen sind

MP-Platforms, ... und deren Tags sowie die IDs ihrer Member (nicht die Tags der Member)

rel(r.R); out

Suche und Ausgabe der Member der Routen, die Ways sind

Straßen, Platforms, ... und deren Tags sowie die IDs ihrer Nodes (nicht die Tags der Nodes)

way(r.R); out

Suche und Ausgabe der Member der Routen, die Nodes sind

Stop-Positions, Platforms, ... und deren Tags

node(r.R); out

Die Overpass-API-Abfrage liefert

Die Overpass-API Abfrage liefert alle Routen für ÖPNV sowie deren Route-Master für den angegebenen Ort (die angegebene Region).
Zusätzlich liefert die Abfrage noch alle Ways und Nodes der Routen (d.h. Member der Relationen mit ihren Details, sowie die Ids aller Nodes der Ways).

Die Overpass-API-Abfrage liefert nicht

Die Suche erfolgt absichtlich nicht nach "route_master"-Relationen und deren Mitgliedern.
- PTv1 relation haben keinen Route-Master, sie würden nicht gefunden werden, eine Bestandsaufnahme wäre somit unvollständig,
- Route-Master haben keine physischen Objekte, die Suche in einem Gebiet scheitert und liefert keine Daten.
Route-Master ohne Routen (leere Route-Master) werden hiermit nicht gefunden.
"stop_area"-Relationen werden nicht gesucht und somit auch nicht analysiert.
- sie haben keine Bedeutung für Linien des ÖPNV.
- dafür und für die Analyse von 'stop_position" und 'platform" Objekten könnte
  - evtl ein weiteres Tool geschrieben werden oder
  - das selbe Tool eine zweite Output-Datei erzeugen
  - oder schaut mal bei Ilya Zveriks Subway Validator vorbei. Blog.

Die Overpass-API-Abfrage erlaubt

Diese Abfrage erlaubt eine Analyse der ÖPNV-Linien dahingehend, dass auch die Wegstrecke auf Vollständigkeit geprüft werden kann. Nodes, Ways und Relationen (Stops und Platforms) und deren Tags können nun auch gegen deren Rolle 'role' in der Relation geprüft werden. Die Abfrage liefert XML-Daten zwischen 1.1 MB und ~65 MB, ja nach Göße des Gebietes und des Vekehrsverbundes (Gemeinde Ottobrunn: 1.1 MB, Verkehrsverbund Großraum Nürnberg: ~65 MB).

Beispiele

Suche nach dem (Land-)Kreis

Als Beispiel wird Landshut verwendet Es werden alle Busse analysiert, die durch das Gebiet fahren.

der Landkreis Landshut (name="Landkreis Landshut") hat den "admin_level" 6 und existiert weltweit als Kreis mit diesem Namen nur ein einziges mal - das ist zu beachten!
die Kreisfreise Stadt Landshut (name="Landshut") hat den "admin_level" 6 und existiert weltweit als Kreis mit diesem Namen nur ein einziges mal - das ist zu beachten!

Da hier beide Kreise erfasst werden sollen wird die unscharfe Suche nach "Landshut" verwendet.

https://overpass-api.de/api/interpreter?data=area[boundary=administrative][admin_level=6][name~'Landshut']->.O; rel(area.O)[route~'bus']->.R; rel(br.R); out; rel.R; out; rel(r.R); out; way(r.R); out; node(r.R); out;

Suche nach der Gemeinde

Als Beispiel wird hier die Gemeinde Ottobrunn südöstlich am Stadtrand von München verwendet. Es werden alle Busse und Züge (S-Bahn) analysiert, die durch das Gemeindegebiet fahren.

Die Gemeinde Ottobrunn hat den "admin_level" 8 und existiert weltweit als Gemeinde mit diesem Namen nur ein einziges mal - das ist zu beachten!

https://overpass-api.de/api/interpreter?data=area[boundary=administrative][admin_level=8][name='Ottobrunn']->.O; rel(area.O)[route~'(bus|train)']->.R; rel(br.R); out; rel.R; out; rel(r.R); out; way(r.R); out; node(r.R); out;

Suche per Polygon

Als Beispiel hier eine Gegend um Augsburg herum definiert. Die Definition erfolgt per Polygon. Es werden alle Busse und Züge (S-Bahn) analysiert, die durch das Gebiet fahren.
Hier wurde der Einfachheit halber ein Rechteck gewählt mit: oben links, unten links, unten rechts, oben rechts. Es sind jedoch beliebige Polygone realisierbar - durch Hinzufügen von weiteren Breitengrad/Längengrad-Paaren. Siehe auch: Overpass-API Abfrage für Augsburger Verkehrs- und Tarifverbund

https://overpass-api.de/api/interpreter?data=rel(poly:'48.0770 11.6378 48.0436 11.6378 48.0436 11.7024 48.0770 11.7024')[route~'(bus|train)']->.R; rel(br.R); out; rel.R; out; rel(r.R); out; way(r.R); out; node(r.R); out;

Suche per Verkehrsverbund

Als Beispiel wird hier ein Verkehrsverbund, für den es eine boundary=public_transport Relation gibt. Es werden alle ÖPNV-Transportmittel analysiert, die durch das Gebiet fahren.
Hier werden die Grenzen des VRS, Verkehrsverbund Rhein-Sieg, benutzt.

https://overpass-api.de/api/interpreter?data=area[boundary=public_transport][name='Verkehrsverbund Rhein-Sieg']->.O; rel(area.O)[route~'(bus|tram|train|subway|light_rail|trolleybus|ferry|monorail|aerialway|share_taxi|funicular)']->.R; rel(br.R); out; rel.R; out; rel(r.R); out; way(r.R); out; node(r.R); out;

Das Analyse-Tool

Filter nach network

Aus den Daten der Overpass-API Abfrage werden alle Routen und Route-Master herausgefiltert/entnommen, die gewissen Kriterien entsprechen:

der network-Tag ist nicht vorhanden oder
der network-Tag enhält 'MVV' (short) oder
der network-Tag enthält 'Münchner Verkehrs- und Tarifverbund' (long).

Test Linien

Im nächsten Schritt werden die entnommenen Linien mit einer Liste verglichen. Diese Liste (CSV-Datei^*) enthält einige Linien des MVV. Die Liste ist ein Teil der Liste der MVV-Linien, diese haben wir zum überwiegenden Teil direkt vom MVV bekommen. Die Einträge in der CSV-Datei enthalten u.A. Informationen über die Liniennummer ('ref') und den Type des Verkehrsmittels ('route'='bus', ...). Die in OSM gefundenen Linien müssen dabei sowohl

mit ref als auch mit route_master bzw. route in der Liste vorkommen

Beispiel: '210;bus': Linie 210 muss als Bus-Linie erscheinen (d.h. 'ref' = 210 und ('route_master' = 'bus' oder 'route' = 'bus)).
Als Tram oder U-Bahn wird sie nicht berücksichtigt und erscheint auf der nächsten Liste ("Other Public Transport Lines").

(*): Die CSV-Datei ist keine reine CSV-Datei mehr. Lediglich die Linieneinträge passen noch zum Format von CSV.

Andere ÖPNV Linien

Übrig bleiben die Linien, die

den network-Tag Kriterien entsprechen und
eben nicht in der Liste (CSV-Datei) vorkommen.

Taucht in dieser Liste ("Andere ÖPNV Linien") z.B. eine MVV Linie 724 auf, so ist das ein Indiz, dass es diese Linie nicht mehr gibt - sie wurde u.U. eingestellt (denn sonst würde sie bei der Liste "Test Linien" auftauchen).

ÖPNV Linien ohne 'ref'

Hierzu zählen alle Linien, die

keinen ref-Tag haben
- egal, ob sie den network-Tag Kriterien entsprechen oder nicht

Verdächtige Relationen

Dieser Abschnitt enthält alle Relationen, die verdächtig sind:

evtl. falsche 'route' oder 'route_master' Werte?
- z.B. 'route' = "suspended_bus" statt 'route' = "bus"
aber auch 'type' = 'network' oder 'route' = "network", d.h. eine Sammlung aller zum 'network' gehörenden Route und Route-Master.
- solche Sammlungen sind Fehler, da Relationen keinen Sammlungen darstellen sollen: Relationen sind keine Kategorien

Die Darstellung erfolgt in diesem Abschnitt lediglich mit der Relation-ID und markanten Tags.

Nicht berücksichtigte 'network' Werte

tbd.

Prüfungen

Verwendetes Schema

Die Daten durchlaufen mehrere Prüfungen, wobei der Fokus auf dem Schema: Public Transport Version 2 liegt. Dieses Schema wird beschrieben unter:

wobei ich mich vornehmlich auf das Approved Feature Public Transport beziehe, da die einzelnen Tags dort weitaus besser beschrieben sind.

Abweichungen

Die Abweichungen betreffen im Wesentlichen eine striktere Auslegung der im Approved Feature Public Transport definierten Vorgehensweise:

"recommended" wird bei den folgenden Tags als "mandatory" gesehen
- public_transport:version
  - public_transport:version=2 ist wichtig um die PTv2 Analyse für eine Route zu starten
- network
  - ist wichtig um nach dem zu analysierenden Verkehrsverbund zu filtern
- ref
  - ist wichtig um die einzelnen Teillinien einander zuordnen zu können (das wird nicht über einen evtl. vorhanden Route-Master gemacht, den gibt es bei PTv1 ja auch nicht)
- name
  - sollte gesetzt werden, damit man die Teillinien auseinander halten kann
  - Einfache Linie
    - name="Bus 210: Neuperlach Süd => Brunnthal, Zusestraße" Hinfahrt
    - name="Bus 210: Brunnthal, Zusestraße => Neuperlach Süd" Rückfahrt
  - Linie mit unterschiedlichen Wegen
    - name="Bus 221: Unterhaching (S) => Waldheimplatz" Hinfahrt am Wochenende
    - name="Bus 221: Unterhaching (S) => Siemensstraße => Waldheimplatz" Hinfahrt werktags (durchs Gewerbegebiet)
    - name="Bus 221: Waldheimplatz => Unterhaching (S)" Rückfahrt am Wochenende
    - name="Bus 221: Waldheimplatz => Siemensstraße => Unterhaching (S)" Rückfahrt werktags (durchs Gewerbegebiet)
- public_transport=stop_position oder =platform
  - sollte gesetzt sein, damit die Funktion des Objektes eindeutig ist
  - es erleichtert die Analyse ob die stop_position in der richtigen Reihenfolge sind, ...

Besonderheiten

Die folgenden Besonderheiten beziehen sich immer auf einen einzelne Relation (type=route) in der PTv2-Notation (public_transport:version=2). Hierbei stellt eine solche Relation immer eine von (in der Regel) mehreren Teillinien dar.

Kreisverkehre
- Hier ist das Tool nicht puristisch und erwartet nicht, dass der Fahrweg in der Relation (in der Regel: des Busses) nur die Teile eines Kreisverkehrs enthält, die auch tatsächlich durchfahren werden
  - das entspricht dem Verhalten von JOSM
  - es wird aber u.U. eine Anmerkung ausgegeben, wenn der Kreis nicht komplett durchfahren wird, das hat aber keinen Einfluss auf die weitere Analyse
  - der Kreis kann aber aufgeteilt, d.h. in mehrere Segmente geteilt werden (Kreisverkehr-Puristen mögen hier stöhnen)
  - wendet der Bus im Kreisverkehr und ist Einfahrt gleich Ausfahrt (ohne Verkehrsinsel), so wird der komplette Kreisverkehr eingebunden (aber nur dann)
  - kommt der Bus auf seinem Weg ein weiteres Mal zum selben Kreisverkehr, so benutzt er in der Regel ein anderes Segment des Kreises

Durchfahrt eines Weges in beide Richtungen bzw. erneut in der selben Richtungen
- Fährt das Verkehrsmittel (hier in der Regel: der Bus, aber auch Züge die in Kopfbahnhöfen einen Zwischenhalt einlegen) einen Weg mehrfach, so ist der OSM-Way auch mehrfach in die Relation aufzunehmen (an der richtigen Stelle natürlich)
  - ohne: 'forward' oder 'backward', einfach nur so
  - JOSM wird auf das doppelte Vorhandensein hinweisen, aber das kann hier ignoriert werden

Anzahl Stops
- Es wird erwartet, dass mindestens 2 Stops existieren
  - Derzeit werden mindestens 2 Nodes erwartet, egal ob Stop oder Platform

Anzahl Wege
- es wird erwartet, dass mindestens zwei Wege/Straßen/Schienenstücke/... existieren
  - Eine Ausnahme bilden Fähren und Seilbahnen.

Beginn und Ende des Fahrweges
- der erste Node im ersten Way muss eine Stop-Position sein: Rolle = 'stop' oder 'stop_entry_only'
  - eventuelle Schienen- oder Straßenstücke davor gehören nicht zum Fahrweg, denn es werden hier noch keine Personen befördert
  - Eine entspanntere Version dieser Prüfung (--relaxed-begin-end-for=...) erwartet lediglich, dass eine Stop-Position zum ersten Way gehört (aber nicht gleichzeitig auch zum zweiten Way)
- der letzte Node im letzten Way muss eine Stop-Position sein: Rolle = 'stop' oder 'stop_exit_only'
  - eventuelle Schienen- oder Straßenstücke danach gehören nicht zum Fahrweg, denn es werden hier keine Personen mehr befördert
  - Eine entspanntere Version dieser Prüfung (--relaxed-begin-end-for=...) erwartet lediglich, dass eine Stop-Position zum letztenWay gehört (aber nicht gleichzeitig auch zum vorletzten Way)

Sortierung mehrerer Routen (type=route) im Route-Master (type=route_master)
- 'sort_name=' als Tag der Route wird zum Sortieren verwendet, wenn vorhanden
  - Z.B.:
    - sort_name="Hinfahrt: 1,5,7,9"
    - sort_name="Hinfahrt: 2,3,4,6,8"
    - sort_name="Rückfahrt: 1,2,3,4"
    - sort_name="Rückfahrt: 5,6,7,8,9"
- 'name=' wird verwendet, wenn 'sort_name' nicht existiert
- wenn 'name=' nicht gesetzt ist wird die ID der Relation genommen
- alternativ: es wird die Reihenfolge der Member im Route-Master genommen.
  - noch zu diskutieren, bzw. in in einer späteren Version des Tools (Re-Design)
- eigentlich keine Besonderheit, aber nicht ohne Grund:
  - Sortierung dient dazu, zufällige Reihenfolgen auf der Wiki-Seite zu vermeiden, was unnötige "deltas" im Wiki erzeugen würde

Vorgehensweise