Diskussion über Public Transport Version 2.1

Das was da schon vorher stand ist falsch und wurde vom Autor in der englischen Fassung nur eingetragen, weil er es – auf meine Anfrage nach seiner eigenen Aussage – nicht verstanden hat. Ich hatte angenommen, dass er es danach geändert hat…

Da es weggelassen werden kann, wenn eine stop_area existiert, gehört in die Stop-Positions und die Platforms genau der in der stop_area anzugebende Name. Also der Name der Haltestelle. “Bahnsteig C” gehört da nicht rein – auch nicht als Bestandteil.

Weide

Mal dazu, worum es in diesem Thread ursprünglich ging…

Dafür (on_demand=yes habe ich schon an eins, zwei Stellen verwendet).

Dafür. Für Busse bräuchte es noch service=school, für Linien die nur aus ein paar Fahrten an Schultagen bestehen. Diese könnten auf Karten z. B. gestrichelt dargestellt werden. Außerdem peak und night.

Open PT Map stellt Linien mit state=alternate, sprich seltener bediente Linienvarianten, gestrichelt dar (keine Ahnung, wo der Tag herkommt…), wäre gut wenn es künftig was offizielles gäbe.

Im Proposal vom 21.04.2011 steht für name von platform:

name 	Individual name 	The name by which the platform is known. 	recommended if no public_transport=stop_area exists, else optional

Die Infos von Weide eingarbeitet habe ich jetzt folgendes im deutschen public_transport=platform:

name 	Haltestellenname 	Der Haltestellenname. Gleis-/Platformnummer(n) werden mit ref erfasst. 	sehr empfohlen, wenn kein public_transport=stop_area existiert, sonst optional 

Ist das so mehrheitsfähig?

Danke!

“ref” als Steignummer ist etwas problematisch. Da “ref” ja eine ganz allgemeine Referenznummer ist, kann sich das mit anderen Nummern beißen. Für die meisten Sachen gibt es deshalb spezifische "ref"s wie “uic_ref” oder “route_ref”. Wenn man in “ref” etwas nicht identifizierbares findet, kann man es nicht einfach überschreiben. Da “local_ref” durch den NAPTAN-Kram ziemlich eindeutig auf Haltestellennummer festgelegt ist und teilweise sogar in der Normalkarte als solche angezeigt wird, bietet es sich als Haltestellennummer an. (Man darf natürlich nicht so tun, als ob das eine PTv2-Regel wäre … in PTv2 steht leider nichts zum Thema Steignummern.)

Weide

BTW: Gibt es eine abgesprochene Regel, wie wir mit abweichenden Haltestellen-Namen im Verkehrsverbund umgehen?
Im HVV wird z.B. - um die Eindeutigkeit des Namens zu ermöglichen - dem Haltestellennamen die jeweilige Stadt/Gemeinde vorangestellt “Lüneburg, Am Sande” (HVV-Name) vs. “Am Sande” (KVG-Name)

Du nimmst als name für die Haltestelle am besten was vor Ort am Schild steht.
Alles weitere kannst du mit name:HVV und name:KVG erfassen.

Danke. Dann schlage ich vor, den Wikieintrag zu platform um einen Eintrag name:=* zu ergänzen.

Und dann bliebe da noch die Fahrplanauskunft der Bahn. Bei der HVV heißt die Haltestelle “Ernst-Braune-Straße” so: “Lüneburg, Ernst-Braune-Straße”, Bei der Fahrplanauskunft der Bahn heißt sie “Ernst-Braune-Straße, Lüneburg”. Sollte ich also auch name:Bahn erfassen? Oder überlasse ich das dem Geschick der Auswertungsprogramme?
Ist die IBNR, die (auch) die Bahn verwendet (z.B. http://reiseauskunft.bahn.de/bin/bhftafel.exe?input=618353)) proprietär oder “offen”. Ich meine hier(?) mal gelesen zu haben, dass sie proprietär sei.

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.