Diskussion über Public Transport Version 2.1

ref_name wird dafür schon ziemlich lang benutzt. http://openptmap.org/ wertet es z.B. aus. Normalerweise kann man einen Inhalt finden, der für die Bahn und die lokalen Unternehmen geeignet ist. “Lüneburg, Ernst-Braune-Straße” funktioniert mit beiden Anbietern.

Weide

Okay. Ist es konsensual, wenn ich den Wikieintrag zu http://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform um die Zeile

ergänze?

Dieser Text steht übrigens hier in dem Abschnitt Halte Postion, nicht aber unter *Bushaltestelle *. Ist das Absicht?

Gegen den Text ist nichts einzuwenden. Nur das Beispiel sollte gut überlegt sein. Internetfahrplanauskunft ist nicht gleich Deutsche Bahn! Die meisten Verkehrsverbünde stellen den Ortsnamen vorne an. Auch bei vielen Busbetrieben habe ich das so gesehen. Warum die DB als Standard genau das andere favorisiert weiß ich nicht.
Edit: Vielleicht ist es damit die Ergebnisse schneller gefunden werden. Denn unter Berl würde man sonst erstmal tausende Beliner Haltestellen finden. Und der Kunde kennt in der Regel auch das was auf dem Schild steht und nicht zu welchem Ortsteil Gemeinde oder was auch sonst noch vorangestellt die Haltestelle gehört.

Mir gefällt es wenn Haltestellen per Dorf/Stadt bei einander sortiert werden. Man kann immer suchen auf Internet. Hier in Belgien gab es einigen die der Name der Gemeinde wohl benutzt haben, anderen nicht. So haben wir entscheiden um die ‘überall’ hin zu fügen. Ausnahme: Antwerpen und Brüssel. Für Brüssel gefällt mir das, weil da alles in 2 Sprachen gemacht werden muss und dann kann es wirklich lang werden:

Berchem Sainte-Agathe - Sint-Agatha-Berchem Avenue Reine Élisabeth - Konining Elisabethlaan

Die hinten dran schreiben haben wir nie überwogen.

Die Komma müsste ich nochmal vorlegen auf talk-be. Im Moment trennen wir das nicht mit Komma und es ist eigentlich vollig klar was Name und was Gemeinde/Ort ist

Für mich wäre es am saubersten die Gemeinde/Ort in einen separaten Tag zu setzen, und dann name formatters benutzen um die neben einander dar zu stellen. Das funkzioniert dann aber nur in JOSM und dennoch nur für die Leute die den Preset geladen haben welche diese Name Formatters enthalten.

Jo

Die OpenPTMap greift ja auf DB-Daten zu. Gibt es eine Karte, die z.B. auf Daten des Verkehrsverbund Berlin-Brandenburg zugreift, um unterschiedliche Anwendungsfälle zu testen?

Sven

Eine solche Karte kenne ich noch nicht.
Aber du kannst es ja mal mit den URL Parametern Input versuchen:
http://fahrinfo.vbb.de/bin/stboard.exe/dn?time=19:08&input=S%20Wartenberg%20%28Berlin%29&boardType=dep&

Gibt es eigentlich eine Referenzanwendung, die PTv2 in einer Karte auswertet und so den Mehrwert der einzelnen Elemente anschaulich macht?

(Doppelposting)

Es gibt zumindest hier eine Liste aller Deutschen Bahnhöfe, deren Verwendung für OSM vom VRR autorisiert ist… Stand 10/2014.
Ob die noch benötigt wird oder alle deutschen Bahnhöfe eh schon damit getagged sind, weiß ich nicht… komme eher aus der Bus-Welt :wink:
http://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit#Materialsammlung_.28angefangen_vor_dem_Treffen.29

Gruß
Achim

Mir ist da noch eine Idee gekommen…

Wir haben ja derzeit die Situation, dass die unabsichtlichen Beschädigungen an PTv2-Routen durch das Auftrennen von Wegen in ganz anderen Zusammenhängen (meist Lane-Edits und Fußgängerinseln und meist in JOSM) zu einigen Stunden Reparaturarbeiten pro Tag allein in NRW führen. Diese Reparaturen sind gewöhnlich ziemlich leicht durchführbar, aber sie kosten auch mit viel Routine viel Zeit und sie bringen keinen Fortschritt sondern beseitigen nur Rückschritte. Die Verursacher bekommen von der ganzen Angelegenheit nichts mit, da die von ihnen verarbeiteten Objekte nicht geändert werden müssen. Wir arbeiten also mit Datenstrukturen, die sehr ungüstige Zusammenhänge schaffen.

Ich habe jetzt vielleicht eine Möglichkeit gefunden, die Routen einer ÖPV-Linie so zu formulieren, dass sie unempfindlich gegen anderweitige Editieroperationen werden (und leichter auf die trotzdem noch anfallenden Restschäden hin überprüfbar werden).

Dazu werden die von vielen Mappen ja ohnehin gewünschten Segmente eingesetzt. (Diese geben gemeinsame Routenstücke von mehreren Varianten an und vermeiden so vielfache Angaben derselben Sache.) Wenn nun die Routen gar keine Fahrwege mehr enthalten und also nur noch aus Segmenten zusammengesetzt werden, dann ist diese Segmentreihenfolge unabhängig von anderen Editieraktivitäten. Verlangt man nun von den Segmenten, dass sie nur ein eindeutiges Wegstück beschreiben (verzweigte Wegenetze wären da ohnehin wenig sinnvoll), dann kann man in den Segmenten ohne Reihenfolgeinformation arbeiten und sie so ebenfalls unabhängig von anderen Editieraktivitäten machen. Sie wären dann eine Art PTv1-Routen ohne Haltestellen (mit “forward”, “backward” und “bidir”) – ergäben aber immer einen eindeutigen Weg. Das beträfe nur die Fahrwege, die Halte wären nach wie vor in der Route selbst.

Weide

Du beschreibst nur eine Seite. Viele Mapper achten darauf, mit ihren Änderungen keinen Schaden an den ÖPNV-Relationen zu verursachen. Die einen passen die Relationen selbst an und brauchen dafür sehr viel Zeit, weil sie ungeübt sind und viel nachlesen müssen, die anderen verzichten darauf, solche Straßen zu bearbeiten. Die Verursacher, also die Ersteller der ÖPNV-Relationen, bekommen von der ganzen Angelegenheit nichts mit, da man den erstellten Changesets die Mehrarbeit nicht ansieht und die nicht erstellten Changesets gar nicht sichtbar sind.

Ja!

Das wäre schon ein Fortschritt. Allerdings fügt man damit dem ÖPNV-Schema eine weitere Abstraktionsebene hinzu und macht die Kontrolle der Relationen abhängig vom Editor komplizierter.

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.
Damit würde man sowohl den Mappern, die ÖPNV-Relationen erstellen und pflegen, als auch jenen, die die Straßen editieren, viel Arbeit abnehmen.
Die Datenstrukturen wären zudem weniger anfällig gegen unabsichtliche Zerstörung.

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen? Auftrennen macht doch nur Abbiegeverbote und destination_signs kaputt. Das Zusammenführen ist in meinen Augen das Problem. Das ist eine der riskantesten Aktionen in OSM (und eine rein kosmetische), wobei die neueren JOSM-Versionen wenigstens mit dem mehrfachen Vorkommen in einer Relation klar kommen. Wie es sich da mit anderen Editoren verhält weiß ich ja nicht.

Aber davon ab fände ich es schade, wenn man Segmente auf eine noch höhere PT-Version verschieben müsste. Ich habe hier Buslinien, die aus insgesamt 10 Einzelvarianten bestehen mit eigentlich nur einer handvoll Variationen, wenn man Bausteine nehmen würde. Wenn dann jemand einen Baustein beschädigt, müsste man auch nicht gleich alle Relationen fixen, sondern nur den einen Baustein. Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Ich habe Segmente für ÖPNV-Stammlinien (Innenstadt, Busbahnhof) verwendet und darin keine Schwierigkeiten gesehen.
Es gibt allerdings Anwendungen, die mit geschachtelten Relationen nicht zurechtkommen.

Ich meine eher, dass man selbst den Überblick verliert, ob die Segmente überhaupt (noch) aneinanderpassen und dadurch auch, ob die Reihenfolge stimmt. In JOSM könnte ich mir das aufklappbar im Routeneditor vorstellen träum

Der OSM Relation Analyzer http://ra.osmsurround.org/ kann die Zusammenhängigkeit auch bei geschachtelten Relationen darstellen (konnte es zumindest damals).
Im JOSM-Relationen-Editor wäre das Feature natürlich viel effizienter angesiedelt.

Das Auftrennen ist ein Problem, wenn nicht genügend Mitglieder der Relation geladen sind. Im Folgenden gehe ich von JOSM aus. Angenommen, der Editor hat von einer Relation nur eine Way geladen. Wenn man nun diesen Way aufsplittet, woher soll der Editor dann wissen, dass er Teil 1 vor Teil 2 oder Teil 2 vor Teil 1 in die Relation einsortieren soll? Wenn die angrenzenden Member (also das erste vor und nach dem zu teilenden Way) geladen sind, dann kann er das selbst ermitteln (außer die Relation ist so kaputt, dass die gerade an der Stelle ein Loch hat).

Bei iD kann ich mir vorstellen, dass Teil 2 des gesplitteten Ways einfach hinten am Relationsende angehängt oder hinter Teil 1 einsortiert wird. Wer möchte, darf gerne mal Versuche machen und die Erkenntnisse hier posten.

Einen großen Teil der Routen-Fehler, die durch Aufsplitten der Ways entstehen, dürfte man verhindern können, wenn JOSM einfach das Aufsplitten solcher Ways nur erlauben würde, wenn der Vorgänger und Nachfolger in der Routenrelation geladen sind. Eine Fehlermeldung im Stil “Der Way kann nicht geteilt werden, weil er Mitglied einer Relation ist und noch nicht genügend Mitglieder der Relation geladen sind. [fehlende Ways nachladen] [Way nicht aufteilen]” ([Buttonbeschriftung]) dürfte JOSM-Nutzer nicht verstören (die sind ja, um es im iD-Sprech auszudrücken, verstörende Popus gewohnt). Im Falle von iD wäre es egal, wenn der Editor sich schnell im Hintergrund den Vorgänger und Nachfolger von der API holt, da das Onlineeditor ist. (In JOSM braucht man einen Netzwerkverbindung nur zum Down- und Upload)

Das Wiedereinführen von Segmenten ist halt ein tiefer Eingriff in die Datenstruktur. Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :slight_smile:

Die Reihenfolge der Wege in der Relation gibt die Durchfahrrichtung indirekt an. Steht da
Weg A
Weg B
Weg C
dann fährt der Bus erst durch A, dann durch B und dann durch C. Jetzt trennen wir B auf und erhalten die Teile X und Y. Nehmen wir an, dass X das Stück von B ist, dass zuerst durchfahren wurde. Die richtige Reihenfolge ist dann also
Weg A
Weg X
Weg Y
Weg C

Beim Bus in der Gegenrichtung stand da
Weg C
Weg B
Weg A
und jetzt muss da
Weg C
Weg Y
Weg X
Weg A
stehen.

Es muss also einmal das B durch XY und einmal durch YX erstetzt werden.

Das macht der JOSM nur dann richtig, wenn er zum Zeitpunkt des Auftrennens A und C und die Relation schon geladen hatte. Sonst ersetzt er B beide Male durch XY und damit ist eine der beiden Relationen falsch, Scotty muss den Bus zweimal beamen und er fährt in den Daten ein kleines Stückchen von Süd nach Nord statt wie in der Realität von Nord nach Süd.

Das kann man verhindern, wenn man vor jedem Auftrennen (“p”) den zu trennenden Weg und seine beiden Endpunkte anwählt und Alt-Ctrl-D macht.

Da das sehr häufig bei großen Straßen (wegen der lanes) passiert und da notorisch auch viele Busse fahren, kann man ganz leicht ein Dutzend Relationen beschädigen ohne was zu merken.

Weide

Hab ich gemacht. Der ID hat alles richtig gemacht. Diesen Fehler hab ich bei meinen Reparaturarbeiten auch fast nur im Zusammenhang mit JOSM gefunden.

Weide

Edit: PS: Beim Längssplitten (Fußgängerinseln vor Kreuzungen. Aus einem Weg werden zwei benachbarte Oneways) muss man es in jedem Editor per Hand korrigieren und das geht im ID m.W. einfach nicht.

Ein Router kann die Strecke nur raten, reagiert empfindlich auf Baustellen etc. und ist bei teilweise erfassten Routen schlechter als nichts. Da würde ich eher komplett auf den Fahrweg verzichten. Wenn mehrere Mapper mal hier und mal da was beitragen, dann geht das ohne Fahrwege nur ganz schlecht, weil man keinen Überblick über den Erfassungszustand bekommt. Man sieht nicht, ob der Bus an dieser Abbiegung einfach durchfährt oder ob er noch einen Schlenker durch A-Dorf macht und da nur noch keiner Haltestellen erfasst hat.

Weide

Sollten wir dann mal für 3 extra was aufmachen?

Weide