Stop_positions verpflichtend zu machen widerspricht PTv2. Ich sehe auch keinen Grund, Linienbusse zu routen. Die Fahrer fahren nach den Vorgaben des Verkehrsunternehmens und da werden viele Dinge berücksichtigt, die nichts mit OSM zu tun haben. Wir sollten nicht das Ziel haben, Linienbusse oder Züge etc. zu routen. Das für OSM-ÖPV interessante Routing ist das Routing der Passagiere (Fuß, Rollstuhl, Rad, Auto(bei Fähren), …) beim Umsteigen.
Die PTv2-Idee war ja, bei stop_areas den Namen nur einmal zu rendern und die Einzelteile nur als einfache Symbole/Nummern ohne Namen darzustellen. Aber das hat nicht wirklich funktioniert.
PTv2 hat da Kompromisse gemacht, die sich nicht durchsetzen werden. Es sollten damals nicht sowohl Halte als auch Routen austauscht werden. Daher wurden nur die Routen ausgetauscht und die Haltestellen nur ergänzt. (Lustig: die Gerüchteküche hat genau das Gegenteil angenommen) (Wenn die Route geändert werden muss weil die Haltestelle geändert wurde und die Haltestelle geändert werden muss weil die Route geändert wurde, dann löst man eine OSM-weite Änderungslawine aus)
Ich denke, dass wir an einem PTv4 (PTv3 gibt es ja schon und ich bin dagegen) arbeiten sollten und dabei in den saueren Apfel der Komplettumstellung beißen müssen. Die Änderungslawine muss man dann durch Markieren der ersetzten alten Objekte (“gilt nicht mit PTv4”) verhindern.
Was sind die Anforderungen an ein neues Schema, was soll mit PTvX realisierbar sein?
Die Editoren und Renderer von Anfang an mit einbeziehen?
Wo sind Unklarheiten in PTv2, Lücken (u.A. Bus, der eine Fähre benutzt)?
Was muss nicht realisierbar sein?
Ist auch schon wieder recht kompliziert geraten.
aber das Ergebniss sollte sehr einfach zu handhaben und zu mappen sein.
Wird jemand zufällig auf der FOSSGIS 2020 in Freiburg sein, ich bin von Mittwoch bis Samstag dort.
Was mir so auf Anhieb einfällt:
-Wer physisch vorhandenes mapped, sollte nicht durch ÖPV-Regeln eingeschränkt werden. Vor allem für die Nichtspezialisten sollte es einfacher werden: Wenn jemand ein Bauwerk Bussteig sieht, dann sollte er es einfach mappen können. Jetzt geht das nicht. PTv2 kann keine mehrteiligen Platforms, die z.B. durch Tunnel, Brücken oder unterschiedliche Höhen gerechtfertigt sind. In Jönköping gibt es physisch klar vorhandene Bussteige an denen aber niemals ein Passagier wartet.
-Es gibt immer mehr just-in-time Bahnsteigzuweisungen. Das würde zu einer unerträglichen Vervielfältigung der Routen führen.
-Manchmal werden zwei Steige gleichzeitig benutzt. Bei Veranstaltungen der Arena/Messe in Düsseldorf gibt es manchmal beidseitigen Ausstieg. In Japan gibt es IFAIK Einstiege von einer Seite und Ausstiege auf der anderen mit gegeneinander versetzten Türen.
-Es gibt unterschiedliche Steige für unterschiedliche Passagierarten. Bei manchen Fähren (z.B. Langeoog) warten Radfahrer woanders als Fußgänger. Bei Autofähren ist es auch so.
-PTv2 kann fehlende Stücke am Anfang und Ende nicht von kürzeren Routen unterscheiden.
-Man kann es schaffen, dass jeder Splittingfehler bei Wegen zu einer Fehlermeldung führt. Das ist jetzt nicht so.
-für eine Brauchbarkeit im Zusammenhang mit Reiseauskünften brauchen wir die Möglichkeit, Teilbahnsteige anzugeben. Wer wissen will, wie lang er in Duisburg Hbf zur U-Bahn braucht, dem nützen Platform und Gleisnummer einfach garnichts (weil die Doppelstockzüge und Triebwagen viel viel kürzer sind als die Bahnsteige und nicht unbedingt in der Mitte halten.)
Vielleicht ist ein radikaler Bruch einfacher zu vermitteln als viele Regeln “das bleibt so” aber “das ist anders”. Zumindest hab ich nach den Erfahrungen mit PTv2 diese Hoffnung. 
+1
Ich bin am Samstag da.
Ich verstehe nicht warum wir bei einer solch einfachen Frage immer über OT ptv4 oder den Sinn von ptv2 diskutieren müssen. Einfach anwenden und fertig !
Das soll ja angeblich in Frankreich schon seit Jahren die Regel sein, dass dort Menschenmassen panisch quer durch die Bahnhöfe rennen, weil sie erst wenige Sekunden vor Ankunft des Zuges erfahren, wo der Zug denn hält. In OSM ist das pragmatisch gelöst - es sind einfach sämtliche Gleise und Bahnhöfe des gesamten Bahnhofs (z. B. Paris Gare de l’Est) in der PTv2-Relation.
Und damit kommen wir zum Thema “Sinn und Unsinn von ÖPNV-Mapping in OSM”. Über das Thema könnte man sicher eine Magisterarbeit schreiben. Google Maps verzichtet ja generell auf das Mapping von ÖPNV-Routen und beschränkt sich darauf, die Infrastruktur (Bushaltestellen, Bahnhöfe) mit den GTFS-Daten querzuverlinken. Ob es sinnvoll ist, Fahrten darzustellen, die schlimmstenfalls nur einmal am Tag von einem Schulbus bedient werden, auf der Karte aber so dargestellt werden als sei das eine regelmäßige Busverbindung, das dürfte auch dem Außenstehenden sehr fraglich vorkommen.
Offensichtlich ist die Anwendung von PTv2 abschreckend. Ich stimme dir zu, ja: anwenden und fertig. Ich gehe da ziemlich nach Schema-F vor und gut is.
Aber ich lese auch immer wieder resignierende Kommentare von Leuten, die aufgegeben haben.
Und wenn ich dann an eine Linie mit > 40 Varianten denke … baut sich auch bei mir eine gewisse Abneigung auf.
Irgendwie versuche ich hier noch eine Brücke zu bauen, von Informationen der Verbünde (GTFS, Fahrpläne, CSV, …) zu Hilfsmitteln, die das Erstellen/Warten von Relationen vereinfachen.
Ja, auch das darf/muss Teil einer Debatte über ÖPNV in OSM sein: was ist sinnvoll, was nicht.
Aber es zeigt auf einer Karte doch so schön wie dicht unser ÖPNV-Netz ist - theroretisch (s.u.).
Nur OSM ist ja bekanntlich mehr als eine Karte.
NB: weil mir der Spruch (Autor ist mir nicht bekannt) wieder mal einfällt:
“In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis, in der Praxis schon.”
Das wäre keine pragmatische Lösung sondern Vandalismus. Die dortigen Relationen sind aber PTv1 und da ist das völlig in Ordnung.
Ja auf jedenfall… die müssen mit dem Tagging arbeiten können ( siehe #12 ). Auch der Mapper sollte damit gut arbeiten können.
Dann steht dem ganzen noch im Weg… das man bestehendes Tagging auf Grund von Tools, Editoren,… usw. nicht ändern sollte, weil sonst alles angepasst werden müsste z.B. auch Potlatch 
. Also das einzig benutzbare Tagging das es schon ewig gibt… und auch klar ist was damit gemeint ist, ist highway=bus_stop. Bei pt=* ist das nicht so klar …
Somit wird highway=bus_stop bleiben… als Node… mit allen Infos zur Bushaltestelle die es gibt an der Stelle an dem der Busnutzer hin muss um den Bus nutzen zu können. Wer dann noch möblieren will soll kann das mit extra Nodes, Ways, Relationen tun. Der Haupttag bleibt die Node mit highway=bus_stop.
Ja das ist die Zukunft… des vielleicht smarten Öpnv im Umland und Stadt… Optimierungen im Nutzer verhalten/Wunsch… dem kann man, meiner Meinung nur mit Routing den Wegverlaufes entgegnen… um sich das eintragen aller Wegstücke in die Relation zu ersparen, was die meiste Arbeit macht. Das man nur noch die Haltestellen (nur Platform ) einträgt… und ggf. Korrekturdaten wenn das Routing nicht funktioniert.
Gruß Miche
In einigen Landkreisen gibt es ja schon Ruftaxi-Systeme ohne festen Fahrweg die einfach zwischen zwei beliebige Haltestellen fahren und den optimalen Fahrtweg z. B. bei mehreren Fahrgästen spontan berechnen. Spätestens dann stoßen wir mit unserem Fahrweg-Tagging an unsere Grenzen…
Ja sowas kann man fast gar nicht darstellen 
Beim MVV 8000, 8200, 8300, 8400, 8500, 8800 der Fall das theoretisch mehrere Haltestellen gleichzeitig angefahren werden, kommt aber praktisch nicht vor 
Aber alleine die vorhandenen Linie, wo man den genauen Fahrweg bestimmen kann, gibt es jetzt schon so viele Varianten 
bis zu >40 Varianten bei einer Linie sind heute schon drin
Richtungsbandbetrieb heißt das bei den Planern…
Auch ein AnrufSammelTaxi, wo man an (idealerweise allen) Haltestellen einsteigen und vor der Haustür aussteigen kann innerhalb der Stadtgrenze, oder von überall im Stadtteil zum Bahnhof und zurück, ist noch nicht gut zu mappen.
das kenne ich auch noch von früher, nachts konnte man anrufen und dann in der Innenstadt von bestimmten Bushaltestellen sonst von der Haustür zur Haustür fahren, mit Monatskarte für nur 1 DM, sonst 4 oder so. Manchmal stand man im Winter bei Minusgraden 40 minuten bis das SAM kam, selten kam es auch gar nicht
Bei so einem System gibt es nicht viel zu mappen abgesehen von den innerstädtischen Sammelpunkten.
Stop_positionen wäre vielleicht sinnvoll um das Routing zu verbessern… 
z.B. wenn die Plattform nahe einer Kreuzung ist… da macht der Router machmal fehler und biegt kurze Stücke ab und wendet, um dem Ziel möglichst nahe zu kommen. Um zu zeigen wie gut das eigentlich geht nur anhand der Plattformen und Stop-Positionen zu Routen. hab ich mal gebastelt: 
Hier mache ich aus einer Ptv2 Relation ein Gpx-Datei:
https://greymiche.lima-city.de/bus-relation/ptv2_platform_to_rte/index.html?relation=9767722
Fast perfekt, bis auf das wenden in der Ulrich-Pucher-Straße… aber das ist auch in der Relation nicht richtig 
bzw. nur wenige Busfahrer machen das so. Von daher könnte man sich das “Shape” für die Busroute auch so erstellen. Um des noch perfekt zu machen könnte ich mir ein Relationsrolle “via” vorstellen die die wenigen Punkte noch gibt die man braucht. Aber alles nicht so aufwendig wie jetzt hier alle Wege in eine Relation einzutragen… 
Gruß Miche
PS: Orginal-Relation:
https://www.openstreetmap.org/relation/9767722
Oh ich hab da so eine (leider noch nicht PTv2-kompatible) Relation, mit der ich das gerne ausprobieren würde. Die Buslinie ist auch in der Realität ziemlich schlimm, der Bus wendet in drei Dörfern, in zwei von ihnen sogar unter Einsatz des Rückwärtsgangs (kann der Router das?).
Wichtig sind die Bushaltestellen und von wo da ein Bus wohin fährt → Link zum online Fahrplan der Haltstellee meist auch per QU-RCode abrufbar
Wie und ob etwa rückwärts oder sonst wie ist m.E. für OSM nicht relevant. Die Routen(-vielfalt) ist mittlerweile zu umfangreich. Bei uns wird aus der Linie C eine Linie E und am Busbahnhof daraus eine Linie A. Manchmal fährt die F über die Linie E (Schülerverkehr) oder aus der D wird in Bannewitz eine Regionallinie.
Ich werde einmal ein Foto einstellen dann kann man ja aus einer Linie 12-15 Routen erstellen und dann fährt ein Teil der Route als andere Linie und mit verschiedenen Endhaltestellen. Und das bei nur 4 Linien an unserer Haltestelle in eine Richtung.
Sehe ich auch so. Ich verstehe diese Diskussion nicht. Der Fahrweg von Buslinien wird vom Busunternehmen festgelegt und daran hat sich der Fahrer zu halten. Da gibt es kein Routing der Busse mit Hilfe von OSM. Oft kann man abends und nachts … manchmal nur als Frau … auf der Route zwischen den Haltestellen aussteigen. Wenn irgendwo ein Stück des Fahrwegs gesperrt wird, dann wird nicht über einen Router vom Fahrer eine andere Strecke gewählt. Da setzt sich jemand vom Verkehrsunternehmen hin und beschließt Ersatzhaltestellen und/oder gestrichene Haltestellen und einen neuen Fahrweg. In irgendwelchen Karten bei Sperrungen in so einem Fall berechnete Routen anzuzeigen wäre sehr oft irreführend, denn man sieht eine plausibel aussehende Route die mit der Realität nichts zu tun hat.
Das für OSM relevante Routing beim ÖPV ist das Routing der Passagiere beim Umsteigen und zwar hauptsächlich für Programme, die Fahrplanauskünfte und Umsteigeanweisungen geben. Da liegt zur Zeit manches im Argen, dass man mit OSM-Daten verbessern könnte und es hat einen riesigen Einfluss, denn aus sowas ergeben sich oft völlig andere Verbindungen mit anderen Umsteigeorten je nach Eigenschaften des Passagiers.
Nein des kann glaub ich kein Router… wenden verursacht halt einfach Kosten in der Routenberechnung. Ich hab keinen eigenen Router programmiert sondern nutze die bestehenden: graphhopper.com, openrouteservice.org, brouter.de. Openrouteservice hätte ein Routingprofil Bus, aber das funktioniert leider nicht Brouter kann man aber dafür überreden
https://greymiche.lima-city.de/bus-relation/GPX2Routing-request2/index.html