Früher hatten wir wenigstens noch bunte Striche und bunte Pfeile. Die Pfeile galten für die Streckenstücke, die nur in einer Richtung durchfahren wurden. Ich fand das damals sehr hilfreich – die Streckenpläne waren so wie sie sein sollten.
Mit der Einführung von PTv2 sind die Pfeile “verstorben”:
1.: für die PTv2-Routen ist es schwer rauszukriegen. Man muss quer über alle Varianten anhand des Kontextes analysieren. (Wenn die Route nicht komplett und fehlerfrei ist, kann das richtig kompliziert werden.)
2.: für die PTv1-Routen wurde durch Verwechslung mit PTv2-Eigenschaften der Datenbestand entwertet. Eigentlich sind PTv1-Routen Linienpläne. Es gibt nur eine Relation pro Linie und jede Straße taucht nur einmal auf. Dann musste man nur die Straße in der Relation finden und hatte:
Rolle “forward”: Linie mit Pfeil in OSM-Richtung des Wegs
Rolle “backward”: Linie mit Pfeil gegen die OSM-Richtung des Wegs
Rolle “”: Linie ohne Pfeil (Bus fährt von links nach rechts und von rechts nach links)
Richtige PTv1-Routen sind sehr selten geworden.
Das ist im Grunde PTv1. Eine Straßenliste mit Durchfahrrichtungsergänzungen(den Rollen “forward”, “backward” und “” für bidirektional)
PTv2 kam, weil einige Sachen nicht aus dem Streckenplan hervorgehen. Auf dem Plan kann es so aussehen, als ob der Bus von A-Dorf nach B-Dorf fährt. Tatsächlich gibt es aber nur die Varianten “ohne die beiden Dörfer”, “über A-Dorf” und “über B-Dorf”, aber eben nicht “über beide”. Oder etwa Sprungbusse (bin ich in Schweden mal drauf reingefallen), die auf derselben Strecke die meisten Haltestellen auslassen.
Es ging mir aber nicht darum, dass man etwas Arbeit spart weil man auf weniger Relationen Rücksicht nehmen muss. Ich will die ganze Rücksichtnahme-auf-ÖPV-Arbeit beim Splitten beseitigen. Derartige Segmente würden ohne Reihenfolgeinformation funktionieren und daher müsste man beim Splitten keine Rücksicht auf sie nehmen.
Wir können uns hier ja auf einen Vorschlag einigen und diesen mit allen Pro- und Kontraargumenten, die im Laufe der Zeit aufgetaucht sind, anschließend international zur Diskussion stellen.
Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.
ich hab vor kurzem auch nach einem Tag für Anzeigetafeln gesucht und bin auf departures_board=“” gestoßen. Dabei hab ich die folgenden Werte benutzt:
realtime → Anzeige der Abfahrtszeit in Minuten (“in 1 min” typisch bei Straßenbahnen und Bussen)
delay → Anzeige von Verspätungen (“heute ca. 5min später”, typisch für kleinere Bahnhöfe und Haltepunkte der DB)
timetable → Anzeige der fahrplanmäßigen Abfahrtszeit (“10:00” wenn keine Informationen zu Verspätungen angezeigt werden)
delay;timetable → Anzeige sowohl der planmäßigen Abfahrtszeit als auch von Verspätungen (typisch für größere Bahnhöfe)
Ich hab meistens direkt die Stelle, an der die Anzeigetafel steht, getaggt, zusätzlich mit public_transport=departures_board.
Ich denke man könnte hier analog zu bin=yes, shelter=yes, amenity=waste_basket und amenity=shelter vorgehen und es sowohl an den Bahnsteig als auch an die konkrete Position taggen.
Ich wollte das Schema eigentlich schon länger mal dokumentieren, bin aber bisher noch nicht dazugekommen.
Einige so getaggte Anzeigetafeln findet ihr in diesem Bereich.
Die könnte man vielleicht als Basis für eine weitere Diskussion verwenden.
Toll…da hat sich im Juli 2014 jemand einfach etwas neues ausgedacht. Ich habe seit Januar 2014 “passenger_information_system” genutzt. Vor allem, weil es systemoffen ist und man mehr sinnvolle Kombinationen als nur yes/no hinzufügen kann.
passenger_information_systen:timetable=yes (gedruckter Fahrplan)
passenger_information_system:display_board=yes (elektronische Abfahrtsübersicht)
passenger_information_system:sound=yes (Lautsprecheransagen möglich)
passenger_information_system:personal=yes (persönliche Auskunft)
passenger_information_system:robot=yes (zukünftiges Auskunftssystem per Roboter)
passenger_information_system:electronic_information=yes (einzeiliges Informationssystem z.B. an kleineren Bahnhöfen)
passenger_information_system:departure_board=yes (Mehrzeilige Abfahrtsanzeige an Bahnsteigen)
Hallo erstmal,
Wie macht ihr das, um die Busrouten für http://overpass-api.de anzupassen? Es gibt hier das Problem, dass die Abfrage der Overpass-API nicht richtig funktioniert, wenn man sowohl eine Platform, als auch eine stop position hat. Somit passt da das Overpass nicht mit dem p_t:v2, oder umgekehrt, zusammen. Gibt es irgend eine Seite, auf der Vorschläge für bessere Formatierungen vorschlagen kann?
Hier geht das richtig und auf manche Stellen mappe ich beide platform und stop_position. Platform aber immer (auf Nodes), stop_position nicht immer. Es sind dann auch die Platform nodes die alle Details enthalten. Das ist in Deutschland und Österreich ganz anders gemacht/evoluiert.
Roland hat viel Hokus Pokus einbauen mussen, um das alles so richtig wie möglich zu interpretieren.
Ich habe nämlich die Buslinien in Wien so angepasst (platform immer und mit Linie in Relation/ stop positions gar nicht oder halt ohne relation). Jetzt funktioniert die Abfrage für alle Linien in Wien (1A-99B network=VOR) aber ein andere User stößt sich daran, da der es strikt nach der Wiki machen will (aber so die Overpass-Kompatibilität wieder kaputt macht…) Das Proposal p_t:v2 ist da leider etwas misslich . Also ist die Formatierung auch Auslegungssache . Danke für die Antwort!
Na ja, Du hast ja auch richtig gemappte Informationen gelöscht.
PTv2 sagt dazu ganz klar:
Each direction/variant relation contains all available stop_positions, platforms and ways.
sowie
Each stop is included with two elements (if available): first the stop_position tagged with
role stop and immediately followed by the corresponding platform tagged with role platform.
The stops (stop_positions and platforms) should be inserted beginning with the initial
stop_position/platform and ending with the terminal stop_position/platform.
Die zwischen den Wegen liegende linienförmige Platform (bei der der Name “Stephansplatz” fehlt), müsste auch oben mit eingeordnet werden. Auch die Wege müssten in sich noch geordnet werden.
After all the stops all the used ways should be inserted into the relation with an
empty role. The ways should be inserted beginning with the way at the initial stop position
and ending with the way at the terminal stop position.
Wenn die Overpass-Abfrage das nicht richtig darstellt, dann liegt dort das Problem. Das sollte man nicht in den Daten lösen.
werden sollte?:
. Also ist die Formatierung auch Auslegungssache 
. Danke für die Antwort!