Ohne viel Aufwand eine Linie auf der Karte darstellen?
Und es gibt durchaus Linien, wo man auch zwischen den Stationen ein-/aussteigen kann. Im VRS kann man zum Beispiel abends und nachts überall aussteigen und aus Hong Kong kenne ich Linien, die haben nur eine Start- und eine Endhaltestelle.
Beispiel für die Relevanz für den Passagier:
Extrem ist da die Fähre von Juist nach Norddeich Mole. Alle drei Varianten unterscheiden sich nur durch den Weg. Der Weg wird abhängig vom Wasserstand, Schiff und Beladung gewählt. Wenn das Schiff nach dem Verlassen des Juister Hafengebiets nach rechts abbiegt, dann kann man schonmal neue Tickets für den Zug buchen, denn man kommt 40 Minuten später als normal an und der gebuchte Zug ist vermutlich weg.
oder einfach: Wenn links die soundso-Gebäude kommen muss ich auf den Aussteigeknopf drücken.
Beispiel für die Relevanz für Mapper:
Wenn die Linie nicht irgendwo abgeschrieben sondern anhand von tatsächlichen Beobachtungen gemappt wird, dann sind die Routen über längere Zeit unvollständig. Nur anhand der Fahrwege kann man als Mapper sehen, wo vermutlich noch Varianten und fehlende Haltestellen sind.
Ok, danke. Jetzt verstehe ich die Notwendigkeit von Ways in den Relationen.
Ich hatte gehofft, dass wir dem Ziel der Vereinfachung und der einfacheren Wartbarkeit dadurch näher kommen könnten, indem wir die Wege aus den Relationen löschen. Das hat sich damit natürlich erledigt…
Soweit ich es überblicke, haben wir jetzt alle Eigenschaften von PTv2 mit Ausnahme der Stop_area-Relation betrachtet und festgestellt, dass für eine mögliche Vereinfachung nur noch die Einsparung von Linienvarianten und die Reduzierung von Tags in den Routenvarianten (mein Vorschlag) bleibt.
Die Reduzierung von Routenvarianten ist in meinem Mapping-Gebiet (Berlin, Brandenburg, Mecklenburg-Vorpommern) auf einigen Linien gängige Praxis (Beispiele: RE1 Magdeburg - Frankfurt (Oder)/Eisenhüttenstadt/Cottbus https://www.openstreetmap.org/relation/7024716 zwei statt >= 4 Relationen, RE4 Lübeck - Ueckermünde oder Szczecin Główny https://www.openstreetmap.org/relation/2609914 vier statt sechs Relationen). Das könnte man sicherlich noch ausdehnen, insbesondere auf Verstärkerkurse.
Die Reduzierung von Tags ist in meiner Interpretation des Proposals https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport bereits mit PTv2 möglich, denn es heißt z.B. zum Tag »Operator« in der Relation einer Routenvariante:
Die breite Entfernung solcher Tags würde allerdings an fehlender Akzeptanz scheitern (man würde denken, dass es vergessen wurde und nicht aus gutem Grund nicht getaggt) und daran, dass auf der Wiki-Seite dazu nichts steht (s. https://wiki.openstreetmap.org/wiki/Public_transport). Hier heißt es nur »recommended«. Weiß jemand warum das so ist?
Hallo Liebe ÖPNV Interessierte ;),
ich bestelle mir immer wieder Bus-Relationen… dazu hab ich mir nach und nach so eine und andere Sache gebastelt. Vielleicht findet es hier einen oder anderen Interessierten der so ein Tool/Hilfe gute gebrauchen könnte.
Was gibts:
- Was zum Bushaltestellen suchen
- Diese mit einem Online-Routing-Programm routen zu lassen
- Nur das nötigste mit Overpass in JOSM laden…
Dazu hab ich noch ein bisschen was dazu geschieben… damit man vielleicht versteht was ich mir dabei gedacht hab 
http://greymiche.lima-city.de/bus-relation/index.html
mfg Miche101
Also, auf mich macht die Anleitung einen sehr komplizierten Eindruck. Ich habe in letzter Zeit auch viele Bus-Relationen bearbeitet und ich glaube nicht, dass das Problem die Erstellung einer Relation ist. Das geht nämlich relativ zügig: JOSM starten, Bereich herunterladen, neue Relation erstellen (bzw. Kopie einer vorhandenen erstellen), relevante Daten eintragen (bzw. bei einer Kopie anpassen), Haltestellen und Ways zusammenklicken (ggf. heruntergeladenen Bereich erweitern). Fertig.
Das grundsätzliche Problem ist die Komplexität des PT-Schemas, z.B. dass man für unterschiedliche Fahrtverläufe und auch für Hin- und Rückweg eigene Relationen erstellen muss. Dazu kommt, dass man die Relationen mehr oder weniger häufig kontrollieren muss, weil sie z.B. durch unaufmerksame User (vielfach mangels Wissen) beschädigt werden. Und dann sind da noch der jährliche Fahrplanwechsel oder Baustellen, die solange dauern, dass die Relationen angepasst werden müssen.
Es würde schon viel helfen, wenn man unterschiedliche Fahrtverläufe in einer Relation abbilden kann. Mein Vorschlag wäre ein Tag “tourX” (X steht dabei für eine Ziffer), der darstellt, dass Way A nur bei Fahrt X befahren wird. Dieser Tag wird dann auch an den Haltestellen dieser Fahrt notiert (“platform:tourX”). Wenn Ways und Haltestellen für alle Fahrtverläufe gleich sind, entfällt dieser Tag.
(Das ist nur eine Überlegung und ich weiß nicht, ob das möglich oder sinnvoll ist.)
Ich habe da auch so meine Bedenken:
Bei uns ändern sich fast bei jedem Fahrplanwechsel die Routen. Sie werden entweder neu angelegt oder aus zwei anderen Teilen zusammengesetzt oder erhalten nur eine andere Linienbezeichnung.
Ich habe bisher die busstop und die plattform wie in der Vorlagen JOSM (Transport ÖPNV) eingetragen und in description:de die Lineninformationen der Haltestellentafel eingetragen. Dann haben die meisten Haltestellen einen QR-Code, die auf den jeweiligen Haltestellenfahrplan verlinkt - diesen nutze ich als website=*. Da sich dieser fast nicht ändert, sind die Daten aus der Website für diese Haltestelle immer sehr aktuell.
Das Anlegen der Relation und vor allem die Pflege ist damit m.E. nicht notwendig. Ich kann an Hand der aktuellen Haltestellendaten (über die Webseite des Verkehrsunternehmen) jederzeit die Verbindung und Linienführung abrufen.
Eigentlich nicht,… die Anleitung ist nur für den Fall das man nicht weiss was man machen muss. Also geht auch ohne… ich hab sie nur geschrieben für diesen Fall. Wenn man das ganze einmal gemacht hat wird man sagen, ja ist das einfach… das und das wäre noch schön… 
Ja das gibt es mit dem MVV auch aber… Es hat auch Vorteile diese Daten in OSM zu haben… besonders wenn man vielleicht wo ist wo man sich nicht auskennt… und vielleicht nicht mal das Verkehrsunternehmen kennt… hat mir OSM schon geholfen das richtige zu finden… 
Ich treffe immer wieder auf total veraltete solche description oder andere Tags mit Linieninfos als Inhalt. Halte ich sehr wenig von weil
- Ist das nicht maschinell auslesbar, da nicht standardisiert. Also machst du dir hier nen Haufen Arbeit für die Katz.
- Ist description=* dafür gedacht, andere Infos zu konkretisieren, wenn sie sonst nicht konkret genug dargestellt werden können. Bestes Beispiel: wheelchair=limited. Das sehe ich hier nicht, man kann ausreichend genau darstellen, welcher Bus wo hält.
Mache ich auch wo möglich. Aber:
Das passiert doch häufiger als man denkt. Im Köln-Bonner Raum sind z.B. alle alten Links inzwischen für die Katz, da der VRS vor einiger Zeit die Websitearchitektur umgebaut hat. Das passiert im Endkundenbereich selbst bei solch trägen Unternehmen ab und an, da man sehr auf einen Benutzerfreundlichen Auftritt angewiesen ist.
Viele Grüße