Motivation
Erste Diskussionen fanden auf einem Münchner Stammtisch im Februar 2017 statt.
Ausgelöst wurde die ganze Diskussion durch unbeabsichtigtes Löschen von Bus-Relationen im Münchener Umfeld (es wurden aber neue Relationen erstellt). Dadurch waren viele Links auf der Seite München/Transportation nicht mehr aktuell. Allerdings muss man auch sagen, dass die Seite in der Vergangenheit eh nicht gut gepflegt war, z.T. gar nicht bekannt war. Die Qualität und Aktualität der Seite scheint also ein generelles Problem zu sein.
Problem: es hapert mit der Qualität der München/Transportation Seite:
- Vollständigkeit:
- wir wissen nicht, ob wir alle existierenden Buslinien des MVV auf der Seite aufgelistet haben
- wir wissen nicht, ob wir Artefakte, d.h. Buslinien gemapped haben die bereits (wieder) eingestellt oder umnummeriert worden sind
- S-Bahn, U-Bahn und Tram sind in ihrer Anzahl überschaubar, da besteht die Chance, dass wir vollständig sind
- PTv2:
- wir wissen nicht, welche der Linien schon auf "Public-Transport Version 2" umgestellt sind.
- DE:Public_transport. Den originalen Wortlaut des Proposals findet man unter Approved Feature Public Transport (approved Version 625726)
- Korrektheit:
- wir wissen nicht, ob die auf PTv2 umgestellten Linien durchgängig und sortiert sind
- d.h. ob die Ways komplett, in der richtigen Reihenfolge, ohne Lücken, ohne Fortsätze und bei Kreisverkehren korrekt erfasst sind
- ob die "stop" und "platform" Member komplett und in der richtigen Reihenfolge erfasst sind
- Einheitlichkeit:
- wir wissen nicht, ob alle Relationen mit ihren Tags komplett und korrekt sind
- d.h. mit vorhanden, korrekten und gegebenenfalls einheitlichen "network", "operator", "public_transport:version", "name", "ref", "from", "to" (und "via"), ...
- Übersichtlichkeit:
- wir haben keine Seite, auf der uns all das, vor allem aber die Probleme damit, übersichtlich angezeigt wird
- Automatisierbarkeit:
- wir haben keine Möglichkeit eine solche Übersichtsseite automatisiert zu erstellen (wöchentlich, ...)
Ursachen gibt es viele:
- Vollständigkeit:
- woher sollen wir die Informationen bekommen? Wir erhalten u.U. vom MVV eine Liste (CSV, ...)
- PTv2:
- einige Linien haben weder "Version" 1 noch 2 als Tag: vergessen, Unkenntnis der Existenz ...
- Korrektheit:
- das ist eine mühsame Kleinarbeit, die immer wieder und wieder angestoßen werden muss, da Relationen schnell mal (unbeabsichtigt) mit Lücken "versehen werden", ...
- Einheitlichkeit:
- was ist denn der Standard? network=MVV oder network="Münchner Verkehrs- und Tarif-Verbund" und so weiter? München/Transportation Vorschlag_für_vereinheitliches_Tagging
- Übersichtlichkeit:
- Teile der Seite sind schon übersichtlicher gestaltet, wie könnte eine übersichtlichere Seite aussehen (Layout?)
- Automatisierbarkeit:
- da gibt es nichts
Ein nicht repräsentativer Blick auf Berlin, Hamburg und Aachen zeigt, dass andere Städte u.U. das gleiche Problem haben.
Überblick
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Die Web-site
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Auswertungen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
- Name
- City/Region
- Verkehrsverbund
- Auswertung
- Letzte Änderung
- Diskussion
- Linien
Statistiken
Statistiken ... Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Die zum Verkehrsverbund gehörigen Linien
Wichtig: Beachte das Copyright © des Verkehrsverbundes bzw. die Herkunft der Daten!
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beachte: Die Liste wird unter der GPL 3 veröffentlicht.
Die Public Transport Analyse
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beschreibung der erwarteten Linien
Wichtig: Beachte das Copyright © des Verkehrsverbundes bzw. die Herkunft der Daten!
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beachte: Die Liste wird unter der GPL 3 veröffentlicht.
Beispiel: Linien des Münchner Verkehrs- und Tarifverbund im OSM Wiki
Download der Daten aus OSM
Für den Download der Daten wird das Overpass-API verwendet.
Die Abfrage erfolgt außerhalb des eigentlichen Analysetools durch einen wget-Aufruf unter Linux.
Definition des Suchgebietes
- Namen der Kreise oder/und Landkreise
Beispiel: boundary=administrative und admin_level=6 und name~'(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)' - Name des Regierungsbezirks
Beispiel: boundary=administrative und admin_level=5 und name='Oberbayern' - Name des Verkehrsverbundes, sofern es dazu einen Relation gibt
Beispiel: boundary=public_transport und name='Verkehrsverbund Rhein-Sieg' - Oder die Liste von Geokoordinaten eines umschließenden Polygons
Beispiel, einfaches Rechteck: poly:'48.0770 11.6378 48.0436 11.6378 48.0436 11.7024 48.0770 11.7024'
- er ist eindeutig, denn z.b. einen Landkreis: admin_level=6 mit name="Coburg" mag es weltweit mehrfach geben.
- eine Relation mit type=boundary kann Lücken enthalten, es werden dann keine Daten runter geladen.
Auswahl und Abspeichern aller relevanten Route und deren Route-Master Relationen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Ausgabe der relevanten Informationen
Siehe: OSM Wiki
Beispiel: Overpass-API query für Münchner Verkehrs- und Tarifverbund
Definition von Auswertungsoptionen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beispiel: Optionen für Münchner Verkehrs- und Tarifverbund
Analyse der Daten
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Datum der Daten
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beispiel: Münchner Verkehrs- und Tarifverbund
Überblick über die ÖPNV-Linien ...
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beispiel: Münchner Verkehrs- und Tarifverbund
Nicht eindeutig zugeordnete Linien
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Beispiel: Verkehrsverbund Mittelsachsen
Andere ÖPNV-Linien
Übrig bleiben die Linien, die
- den network-Tag Kriterien entsprechen und
- eben nicht in der Liste (CSV-Datei) "Beschreibung der erwarteten Linien" vorkommen.
Taucht in dieser Liste ("Andere ÖPNV-Linien") z.B. eine Linie 724 auf, und
- das 'network' tag ist gesetzt und passt zum analysierten Verkehrsverbund?
- Die Linie wurde u.U. eingestellt - denn sonst würde sie bei der Liste "Überblick über die ÖPNV-Linien ... " auftauchen.
- Die Linie existiert tatsächlich und fehlt in der Liste (CSV-Datei) "Beschreibung der erwarteten Linien".
- das 'network' tag ist nicht gesetzt und müsste eigentlich zum analysierten Verkehrsverbund passen?
- Die Linie wurde u.U. eingestellt - denn sonst würde sie bei der Liste "Überblick über die ÖPNV-Linien ... " auftauchen.
- Die Linie existiert tatsächlich und fehlt in der Liste (CSV-Datei) "Beschreibung der erwarteten Linien".
- das 'network' tag ist nicht gesetzt und müsste eigentlich zu einem anderen Verkehrsverbund passen?
- Das 'network' tag mit dem korrekten Wert des anderen Verkehrsverbundes zu belegen lässt die Linie aus der Auswertung verschwinden.
Beispiel: Regionalverkehr Oberbayern
ÖPNV-Linien ohne 'ref'
Hierzu zählen alle Linien, die
- keinen ref-Tag haben
- egal, ob sie den network-Tag Kriterien entsprechen oder nicht
Beispiel: Verkehrsverbund Ems-Jade
Weitere Relationen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Dieser Abschnitt enthält weitere Relationen aus dem Umfeld der Linien:
- 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 streng genommen Fehler, da Relationen keinen Sammlungen darstellen sollen: Relationen sind keine Kategorien
- Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Die Darstellung erfolgt in diesem Abschnitt lediglich mit der Relation-ID und markanten Tags.
Beispiel: Verkehrsverbund Rhein-Sieg (VRS)
Details zu 'network'-Werten
Das 'network' Tag wird nach den folgenden Werten durchsucht:
- "langer" Name des Verkehrsverbundes
- "kurzer" Name des Verkehrsverbundes
- 'network' ist nicht gesetzt
Berücksichtigte 'network' Werte
Dieser Abschnitt listet die 'network'-Werte auf, die berücksichtigt wurden, d.h. einen der oben genannten Werte enthält.
Beispiel: Verkehrsverbund Mittelsachsen (VMS)
Nicht berücksichtigte 'network' Werte
Dieser Abschnitt listet die 'network'-Werte auf, die nicht berücksichtigt wurden. Darunter können auch Tippfehler in ansonsten zu berücksichtigenden Werten sein.
Beispiel: Verkehrsverbund Mittelsachsen (VMS)
Prüfungen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Verwendetes Schema
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: OSM Wiki
Abweichungen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: OSM Wiki
Besonderheiten
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: OSM Wiki
Vorgehensweise
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: OSM Wiki
Auswertungsoptionen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
| Option | Standardwert | Beschreibung | Bild |
|---|---|---|---|
| allow-coach | OFF | Erlaube 'route_master' = 'coach' und 'route' = 'coach' (auch wenn diese eher inoffiziell sind). | |
| check-access | OFF | Es werden Wege benutzt welche explizit oder implizit ('construction', 'access', ...) nicht genutzt werden können und wo 'bus' = 'yes', 'bus' = 'designated', 'bus' = 'official', 'psv' =' yes', ... nicht gesetzt ist. Das gilt auch für 'barrier'. | |
| check-against-gtfs | OFF | OFF|tags|csv|csv,tags Prüfe OSM route_master/route Daten gegen GTFS feed Daten. OFF: keine Prüfung csv: prüfe gegen die Daten des GTFS feed, definiert in CSV Eintrag in der Routes Datei tags: prüfe gegen die Daten des GTFS feed, definiert in 'gtfs:*' tags in den route_master und route Relationen csv,tags: prüfe gegen 'csv' und 'tags'. |
|
| check-bus-stop | OFF | 'highway' = 'bus_stop' ist nur auf Nodes erlaubt, nicht auf Ways oder Areas. | |
| check-dates | OFF | Prüfung, ob Datumsangaben dem ISO-Format entsprechen: JJJJ-MM-TT | |
| check-from-to | OFF | Check that 'from' and 'to' match with corresponding platform 'name' values. | |
| check-gtfs | OFF | Prüfung, ob 'gtfs:*' Tags korrekt, ... sind. | |
| check-motorway-link | OFF | Prüfung, ob Autobahnauf- oder abfahrten benutzt werden ohne nachher oder vorher eine Autobahn/Schnellstraße zu nutzen. | |
| check-name | OFF | Prüfung, ob 'name = '... ref: from => to' beziehungsweise 'name' = '...ref: from => via ... => to' entspricht. | |
| check-name-relaxed | OFF | Mehr entspanntere Prüfung, ob 'name' = '...: A => B' entspricht, wo 'A' Teil von 'from' und 'B' Teil von 'to' sein müssen. | |
| check-osm-separator | OFF | Prüfe die Werte von 'network', ... ob das Aufzählungstrennzeichen tatsächlich das Semikolon ';' (ohne Blanks) ist. | |
| check-platform | OFF | Prüfe, ob zum Beispiel 'bus' = 'yes' bei einer PTv2 Bushaltestelle existiert, wo 'public_transport' = 'platform' gesetzt ist. PTv2 fordert dieses allerdings nicht. | |
| check-roundabouts | OFF | Prüfung von Kreisverkehren, ob sie partiell (in Segmente aufgeteilt) oder komplett (aber nicht in Segmente aufgeteilt) in der Relation enthalten sind. | |
| check-route-ref | OFF | Prüfung, ob das Tag 'route_ref' an Haltestellen den Wert der Tags 'ref' der Route enthält (vorausgesetzt 'route_ref' existiert). Prüfung, ob das Tag 'ref' der Haltestelle zufällig den Wert des Tags 'ref' der Route enthält. Prüfung, ob die Tags 'bus_lines', 'bus_routes', 'lines' oder 'routes' an Haltestellen gesetzt sind. Sie sollten durch das Tag 'route_ref' ersetzt werden. |
|
| check-sequence | OFF | Prüfung der Reihenfolge der befahrenen Wege, existieren Lücken? | |
| check-service-type | OFF | Prüfe den Wert des 'service' Tags für 'highway' = 'service'. Verdächtige Werte: 'drive-through', driveway', 'emergency_access', 'parking_aisle' |
|
| check-stop-position | OFF | Prüfe, ob zum Beispiel 'bus' = 'yes' bei einer PTv2 Bushaltestelle existiert, wo 'public_transport' = 'stop_position' gesetzt ist. | |
| check-version | OFF | Prüfung von 'public_transport:version' = '...' bei Route-Master und Route. | |
| check-via | OFF | Check that 'via' matches with corresponding platform 'name' values. | |
| check-way-type | OFF | Prüfung, ob die befahrenen Wege passend zum Fahrzeugtyp sind ('train' nutzt 'railway' = 'rail', 'tram' nutzt 'railway' = 'tram', 'bus' nutzt 'highway' = '...', ...). | |
| coloured-sketchline | OFF | SketchLine (Overpass-API Skript) berücksichtigt den Wert von 'colour' = '...' des Route-Master oder der Route. | |
| expect-network-long | OFF | Der Wert von 'network' = '...' wird in der Langform erwartet (siehe: network-long-regex). | |
| expect-network-long-as | Der Wert von 'network' = '...' wird in der Langform erwartet, so wie hier angegeben. | ||
| expect-network-long-for | Der Wert von 'network' = '...' wird in der Langform erwartet statt der hier angegebenen Kurzform. | ||
| expect-network-short | OFF | Der Wert von 'network' = '...' wird in der Kurzform erwartet (siehe: network-short-regex). | |
| expect-network-short-as | Der Wert von 'network' = '...' wird in der Kurzform erwartet, so wie hier angegeben. | ||
| expect-network-short-for | Der Wert von 'network' = '...' wird in der Kurzform erwartet statt der hier angegebenen Langform. | ||
| gtfs-feed | Verwende diesen Wert als GTFS-Feed für die Option 'link-gtfs' wenn die Relation keinen der Tags 'gtfs:feed', 'operator:guid' oder 'network:guid' enthält. | ||
| language | en | Legt die Ausgabesprache fest. | |
| link-gtfs | OFF | Erzeuge Links zur GTFS-Analyse für 'gtfs:route_id' oder 'gtfs:trip_id' Tags. | |
| max-error | Begrenzt die Anzahl der Ausgabe identischer Fehler und Anmerkungen für eine Relation. | ||
| multiple-ref-type-entries | analyze | allow|analyze|no Definiert, wie das mehrfache Auftreten der Kombination von "ref;type" (z.B. "N8;bus") in den CSV-Daten behandelt werden soll. PTNA nimmt an, dass es sich um separate Linien mit identischen 'ref' und 'type' in unterschiedlichen Städten/Gemeinden handelt und dass diese sich durch 'operator', 'from' und 'to' unterscheiden. allow: erlaube weitere Vorkommen dieses Eintrags, keine Überprüfung von 'operator', 'from' und 'to' analyze: prüfe, ob 'operator', 'from' und 'to' in den CSV-Daten mit den Werte der Relation übereinstimmen no: ignoriere weitere Vorkommen dieses Eintrags, keine Überprüfung von 'operator', 'from' und 'to'. |
|
| network-long-regex | Der Wert von 'network' = '...' bei der Route-Master und Route Relation muss dem regulären Ausdruck als Langform entsprechen oder kann leer sein (nicht gesetzt). | ||
| network-short-regex | Der Wert von 'network' = '...' bei der Route-Master und Route Relation muss dem regulären Ausdruck als Kurzform entsprechen oder kann leer sein (nicht gesetzt). | ||
| no-additional-navigation | OFF | Es werden keinen zusätzlichen Navigationshilfen oberhalb der Tabellen ausgegeben. | no-additional-navigation |
| operator-regex | Der Wert von 'operator' = '...' bei der Route-Master und Route Relation muss dem regulären Ausdruck entsprechen oder kann leer sein (nicht gesetzt). | ||
| or-separator | | | Diese Option setzt den ODER-Separator für das 'ref' Feld in der CSV-Liste der Routen. Beispiel: '250|250a|250b' : definiert, dass hier Routen mit 'ref' = '250' und 'ref' = '250a' und 'ref' = '250b' erlaubt sind. |
|
| positive-notes | OFF | Zeige auch 'network:short' = '...', 'network:guid' = '...' und andere Tags und Werte. | |
| ptv1-compatibility | no | allow|no|show 'highway' = 'bus_stop' für einen Punkt neben der Straße wird wie 'public_transport' = 'platform' behandelt, wenn 'role' = 'platform'. allow: die Kompatibilität mit alten bus-stops (aka: PTv1) wird stillschweigend angenommen no: keine Kompatibilität mit alten bus-stops (aka: PTv1) show: die Kompatibilität mit alten bus-stops (aka: PTv1) wird angenommen und angezeigt. Siehe auch: OSM-Wiki: Kompatibilität mit bekannten Tags. |
|
| ref-separator | / | Diese Option setzt den 'network-ref'-Separator für das 'ref' Feld in der CSV-Liste der Routen. Beispiel: '605/50' : definiert, dass hier 'ref' von zwei 'network' erwartet werden. Es wird geprüft, ob 'ref:network1 '= '605' und 'ref:network2' = '50' existieren. |
|
| relaxed-begin-end-for | Entspannte Prüfung für den Anfang und das Ende der Fahrstrecke bezüglich Haltestellen (zB. für 'train', 'tram', 'light_rail'). | ||
| roundtrip-distance | 50 | Erachte eine Route, die mit 'roundtrip='yes' getagged ist als OK wenn der Abstand zwischen erster und letzter Platform den definierten Wert nicht überschreitet. | |
| separator | ; | Diese Option setzt der Feld-Separator für die CSV-Liste der Routen. | |
| show-gtfs | OFF | Analog zur Option '--positive-notes': zeige die Namen und Werte von 'gtfs*' Tags in der Spalte 'Amerkungen'. | |
| strict-network | OFF | Route-Master und Route Relationen mit leerem 'network' werden nicht berücksichtigt. | |
| strict-operator | OFF | Route-Master und Route Relationen mit leerem 'operator' werden nicht berücksichtigt. | |
| table-show-also | Zeige auch die Werte für diese Tags in der Tabelle der Liste der 'positiven' Routen. Beispiel: --table-show-also=from,via,to |
Meldungen
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
PTNA bei 'taginfo'
PTNA und die von PTNA ausgewerteten 'tags' sind bei 'taginfo-projects' als Projekt gelistet.
Die GTFS Analyse
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Der Code
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
ptna
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: ptna auf GitHub
ptna-networks
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: ptna-networks auf GitHub
ptna-www
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: ptna-www auf GitHub
gtfs
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: gtfs auf GitHub
gtfs-feeds
Lorem ipsum dolor sit amet, consectetur adipisici elit, …
Siehe: gtfs-feeds auf GitHub








