Seh ich auch so… dazu sind diese Fahrzeuge zu flexibel… um da immer aktuell zu bleiben. 
Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen 
Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss…
public_transport (Öffentlicher Verkehr) ist eben nicht mit railway in ein Schema gebracht worden. Die Bahnsteige und Fahrwege sind nur meist die gleichen.
Mit PTv1 und PTv2 kann man ganz gut umgehen. Ich sehe zwar Vereinfachungsmöglichkeiten, aber keine Notwendigkeit etwas Neues aufzutellen.
Zur eigentlichen Forumsfrage, der Notwendigkeit der stop_position:
Der Ein- Ausstiegpunkt für eine Fußgängernavigation wird durch ein Lot von der stop_position auf die nächstgelegen platform-Linie gebildet. Der Fußpunkt oder das Linienende ist dieser Ein- Ausstiegspunkt und wäre für mich auch die Position für das Haltestellensymbol.
Leider wird auf der Mapnik Karte kein Symbol für PTv2 - Haltestellen gerendert. Die Hintergründe sind viel diskutiert, die fehlende Umsetzung ist nicht begreifbar.
Gruß Axel
PTv3 könnte etwas in diese Richtung gehen. Wir könnten für den Fahrweg atomare Segmente anlegen, die wir aber in der Regel nicht in die Linienrelation aufnehmen. Diese atomaren Segmente würden in der Regel von den Stop-Positionen einer Haltestelle zu denen der nächsten Haltestelle führen. Die Linienrelation würde dann in der Regel nur Haltestellen (vermutlich in Form von Stop-Positionen) auflisten. Die Auswertung hat dann die zu den genutzen Stop-Positionen jeweils aufeinanderfolgender Haltestellen passende atomare Segment zu verwenden, die über die Miglidschaft der Stop Position als from oder to node des atomaren Segments einfach aufzufinden sind. Der Editor könnte ggf. die zu einer Linienrelation fehlenden atomaren Fahrwegsegmente nach Benutzeraufforderung durch Autorouting automatisch erstellen. Für die meisten Segmente wird das korrekte Ergebnisse liefern und in den anderen Fällen kann dann der Benutzer nachkorrigieren.
Ein Ausnahmefall ist, wenn es zwischen einem Paar von Stop-Positionen mehrere verschiedene tatsächlich genutzte Fahrwege gibt, was sehr selten sein dürfte. In diesem Fall wäre zusätzlich ein Via-Node oder das betreffende Fahrwegsegment explizit in die Linienrelation aufzunehmen.
Gibt es Linien die eine Haltestelle ohne Halt durchfahren, sollte diese Haltestelle in der Regel in die Linienrelation mit aufgenommen werden und nur durch eine Rolle als durchfahren gekennzeichnet werden. Dies vermeidet zusätzlich benötigte Fahrwegsegmente und bringt somit eine wichtige Entlastung der Highway-Elemente von übermäßig vielen Relationen.
Die atomaren Segmente müssen nicht unbedingt linear sein, sondern können am Anfang und Ende zu mehreren From- bzw. To-Nodes verzweigt sein. Anhand der in der Linienrelation verwendeten Stop-Positionen, können die aus dem Fahrweg Segment tatsächlich benötigten Ways herausgefiltert werden.
Für Karten-Renderer die ohnehin den lokal vollständigen Datensatz vorliegen haben, sollten kein Problem mit den nötigen Auswertungen haben. Um Linien auf Basis einer Overpass Abfrage darstellen zu können, braucht man entweder eine Browsers-seitige Nachbearbeitung oder eine Erweiterung der Overpass-API um PT-spezifische Ausgangsfilter.
Ein großes Probem von PTv2 ist die bei konsequenter Umsetzung durch Varianten erzeugte Datenflut, die für eine manuelle Pflege ungeeignet ist. Bezüglich Varianten ist PTv2 strukturell zu einfach definiert, was durch die enorme Datenmenge ausgeglichen werden muss und damit zumindest für Menschen die Komplexität deutlich erhöht.
PTv3 sollte daher in der Lage sein, zumindest kleine Variationen innerhalb der Relationen abzubilden, um nicht für jede Untervariante eine separate Routenrelation zu benötigen.
Ein Beispiel wie sowas bei einem Segment aussehen kann:
pio A-Dorf
pio:-B_Gl2 B-Dorf an Gleis 1
+pio:-B_Gl2,-KZ B-Dorf Bahnsteigverlängerung an Gleis 1
alt-pio:+B_Gl2 B-Dorf an Gleis 2
pio C-Dorf
B_Gl2 und KZ sind dabei beliebige Bezeichner für eine Variation, die aktiv ist, wenn sie in der Rolle der Migligschaft des Segments in der Tour aufgeführt sind. Ein minus vor diesem Bezeichner in der Memberrolle deaktiviert den Member wenn die Variation aktiv ist. Ein plus vor diesem Bezeichner in der Memberrolle deaktiviert den Member wenn die Variation inaktiv ist.
Wird ein pio deaktiviert, so wird aus einem unmittelbar nachfolgenden +pio oder alt-pio ein pio.
Wird ein alt-pio deaktiviert, so wird aus einem unmittelbar nachfolgenden +pio ein alt-pio.
Für einen Kurzzug der in B-Dorf auf Gleis 1 fährt wäre diese Rolle dann:
segment:KZ
Damit wird aus obiger Membersequenz:
pio A-Dorf
pio B-Dorf an Gleis 1
pio C-Dorf
Für einen Zug der in B-Dorf auf Gleis 2 fährt wäre diese Rolle dann:
segment:B_Gl2
pio A-Dorf
pio B-Dorf an Gleis 2
pio C-Dorf
Natürlich können auch mehrere Variationen gleichzeitig wirken:
segment:KZ,B_Gl2
Dies hat für den Beispielfall aber das gleiche Ergebnis wie zuletzt.
Sowas ist nur brauchbar, wenn alles andere fehlerfrei und vollständig ist.
Da muss nur jemand bei einem Stück Fahrweg einen kleinen Fehler machen und schon hat man eine Karte mit richtig gut und plausibel aussehendem Unsinn statt einer anständigen Fehlermeldung.
Auch für teilweise erfasste Linien ist so etwas sehr ungünstig.
Und dann gibt es noch Linien, die sich damit überhaupt nicht sinnvoll erfassen lassen wie z.B. die Fährverbindung zwischen Norddeich Mole und Juist. Ob man da 40 Minuten länger fährt oder nicht macht den Unterschied zwischen “alles klar” und “Zug verpasst und ich brauche eine neue Fahrkarte” aus.
Ich seh immernoch die Zukunft… dass man mit einem Routingprogramm eine Strecke generieren kann die vielleicht noch mit Via-Punkten korrigieren und dann dass Ergebnis als z.B. Relation statisch abspeichert. 
Würde auch viele potenzielle Fehler vermeiden…
Nach dem lesen dieser Beiträge:
Das ist sicher für Spezialisten interessant und richtig dies auch zu diskutieren.
Für einen einfachen unbedarften Dateneinträger sollte eine Haltestelle “einfach” einzutragen sein, meinetwegen mit ergänzenden Schlüsseln wie Bahnsteignummer, Liniennummer, Name, Referenz, … (neuerdings bei uns mit QR-Code zu Fahrplan/-änderungen). Und bis dahin sollte das “Fußgängerrouting” führen.
Die daraus abzuleitende Relation (Fahrpläne?) sind schon spezieller. Einige werden sicher diese Aufgabe übernehmen. Dort darf aber eine Änderung an einer Haltestelle nicht zum “Chaos” führen.
Ob ein Zug auf Gleis 1 oder 1a oder 2 hält ist oft auch situationsbedingt - genauso die Bushalte. Diese müssten einfach die “Haltestellen” abfragen.
Endlich eine Verwendung für die Stop-Position? Würde es nicht genauso funktionieren, wenn die atomaren Segmente den Weg von einer Platform zur nächsten beschreiben würden?
Egal ob Stop oder Platform, an jeder Haltestelle müßten die ways aufgetrennt werden.
Grundsätzliche Frage: Wo sollte die Schnittstelle zwischen OSM-Daten und Fahrplandaten sein?
Ich könnte mir vorstellen, sofern es denn einmal freie Fahrplandaten mit eindeutig zuordnenden Haltepunkten (IFOPT?) gibt, es ausreichen sollte, die Haltestellen und die Fahrwege zwischen den Haltestellen (atomare Segmente) zu taggen.
Ich sehe keinen Sinn darin, dutzende Fahrweg-Relationen in den OSM-Daten zu haben, ohne zu wissen, wann diese bedient werden. Im Eisenbahnbereich kommt es auch immer wieder aus betrieblichen Gründen zu Gleis- und damit auch zu Bahnsteig-wechseln.
Du gehst da von Vorstellungen aus, die nicht PTv2 sind.
In PTv2 gehört zu einem stop nicht unbedingt eine platform. Es können aber auch mehrere dazu gehören.
In PTv2 gehört zu einer platform nicht unbedingt ein stop. Es können aber auch mehrere dazu gehören.
Ob eine platform “nächstgelegen” ist, ist völlig egal.
In dem Bild wird dargestellt, dass die Busse nur nach Norden fahren. Das kann man aus der Haltestellenbeschreibung nicht schließen. Man kann es nicht einmal nach Analyse aller gemappten Routen schließen.
Fast genau das habe im P3-Vorschlag versucht. Die real vorhandenen Objekte sollen einfach als solche gemappt werden – ohne jede Rücksicht auf ÖPV-Routen. Die ÖPV-Routen dagegen stützen sich nur auf die Punkte des Fußgängerrouting (PIO). Oft fallen diese beiden Sachen zusammen, aber das muss nicht so sein.
Ich habe auch den Eindruck, dass seit ungefähr Oxomoa der Versuch unternommen wurde, den gesamten ÖPNV vom Ruftaxi bis zum ICE mit einem allmächtigen System zu beschreiben. Das wurde dann notwendigerweise so umfangreich, dass der Normalmapper nicht mehr überblickt, wie er relativ primitive Sachen eintragen kann und es lieber ganz bleiben lässt.
Ich plädiere dafür, das Ganze in mindestens zwei Gruppen aufzuteilen:
a) Alles was “on the ground” sichtbar ist und einfach zuzuordnen ist, wie Haltestellen (an Hand der Schilder), Bahnsteige, Gleise.
b) Alle Besonderheiten und komplizierteren Objekte wie Busbahnhöfe, U-Bahn-Ausgänge, kombinierte Strecken in einer Abteilung “für Experten”, für die es natürlich einer viel ausführlicheren Beschreibung und Festlegung bedarf.
a) ist natürlich eine Teilmenge von b).
Mit a) und primitiven Relationen, die nur die Reihenfolge der Haltestellen enthalten, kann man z.B. schon einen Netzplan und eine kombinierte Fußgänger-ÖPNV-Navigation erzeugen. Es wäre eine Überlegung wert, ob es sich lohnt, die Linie(n) als (später redundanten) Tag in das Haltestellen-Objekt einzutragen. Das Erzeugen der Linien-Relation wird dadurch jedenfalls erleichtert.
Anders als z.B. bei Wander- oder Fahrradrouten hat beim ÖPNV der exakte Routenverlauf eine geringere Priorität für den Nutzer. Man braucht ihn eigentlich nur für die Darstellung auf der Karte.
Der Vorschlag Haltestellen in (einfache) Routenrelation zubringen, finde ich gut. Dann kann man für die Linie 333 eine Route mit Haltestellen A, B, C, … anzeigen.
Wichtig wäre schon, wo die Route 333 verläuft - damit kann ich Haltestellen “ohne umsteigen” finden bzw. wo ich auf eine andere Route wechseln muss, wenn ich nach Z möchte.
Einen richtigen Top-Down Ansatz. 
Es wäre für den Auswertung einfacher die atomaren Segmenten in der Relation auf zu nehmen. Damit weiss man a) das der Segment noch benuzt wird, b) haben Overpass und andere Auswerter weiniger Probleme der Fahrweg zu identifizieren/an zu zeigen und c) kann man nicht-haltende Fahrwege machen indem man nicht der Halt aber doch die Segmenten in der Relation mit aufnimmt.
Ein Problem löst es nicht: es ist noch immer nötig für jede Variante eine Relation zu erstellen. Ich weiss auch nicht ob es weniger aufwand ist die Relationen so an zu legen.
Was sind “atomaren Segmente”
atomar → kleines Teilchen… bzw. Atom das kleinst überhaupt… bei OSM wäre das eine Node ohne Eigenschaften…
Segment → ein Teilstück… bei OSM… ein Teilstück eine Weges?
Ein Weg mit 2 Nodes ohne Eigenschaften??? Das hört sich toll an aber Sinn gibt das nicht… 
Varianten kann man aus dem “verlinkte Fahrplan” lesen.
M.E. würde schon ein Routenverlauf aus der Abfolge der Haltestellen ausreichen. Wenn z.B. der “Eilbus” zwei, drei Haltestellen nicht anfährt, ist das aus dem “Fahrplan” ersichtlich.
Die jetztigen Daten… bringen höchstens die Idee wie man es fahren könnte und welche Linien so möglich wären. Aber ohne Fahrplan mit Zeiten und Häufigkeit… würd ich mit dem OSM Plan nirgends versuchen… über 2 Linien irgendwo hinzukommen… außer ich hätte keine andere Wahl.
Ich würde es viel praktischer find wenn eine Link zur Online-Auskunft des Verkehrsbetriebes hinterlegt wäre… würd mir meist mehr helfen… als zu raten wo es da vielleicht hingeht…
http://www.openstreetmap.org/node/3740880925#map=17/51.01448/13.63736&layers=T
Außerdem haben unsere Haltestellen den Link in einem QR_Code (bzw. der Link in OSM ist der QR-Code).
EDIT: Link
Wie ich es verstanden hab: Teilstücke (Relations) die von einen bis der nächsten Halt gehen. Diese definieren dann den Laufweg.
Also: Linie 1 hat Halte A, B und C.
Dann gibt es Relationen fur den laufweg A->B und B->C, diese kommen in der Busrelation zusammen mit die Halte.
Stimmt. Es werden eigentlich nur die Segmenten zwischen die Halten gebraucht. Aber dafür soll man sie dan in der Relation mit einbinden. Wenn der laufweg herausgefunden werden muss an hand von stop_position1 => stop_position3 und es Segmenten
stop_position1 => stop_position2, stop_position2 => stop_position3, stop_position1 => stop_position5, stop_position5 => stop_position3, kann der Laufweg nicht identifiziert werden.
Sowas ist ist sogar Haltestellenscharf…
Aber des wäre schon mal cool wenn man mit OSMand mit dem Handy auf eine Bushaltestelle klickt… dann, wenn vorhanden, zur Online Auskunft des jeweiligen Verkehrbetriebes komme… bzw. direkt zum Fahrplan dieser Linie… Abfahrsmonitor… zur App, Ticketshop usw. was auch immer…
Aso der Weg zwischen zwei Haltestelle… diese Relation könnte man dann für mehrere Linien verwenden die zwischen den gleichen Haltestellen fahren.
Aber die Bezeichnung ist trotzdem irreführend…