PTv3: Zielsetzung eines modifizierten ÖPNV Modells

Weide · 2017-12-14T13:53:55.000Z

hsimpson:

Weide:

hsimpson:

Aber so fahren wir hier grade zwei Systeme parrallel, was defninitiv keine Dauerlösung darstellen kann (es aber schon viel zu lange ist).

Das tun wir doch garnicht. PTv2 sollte die Routenrelationen aus PTv1 ablösen und das ist passiert. Es gibt fast keine PTv1-Routen mehr.

Da muss ich dir wiedersprechen. Siehe: https://wiki.openstreetmap.org/wiki/VRS/Analyse

Da wird von nur einer PTv1-Buslinie gesprochen – das sieht für mich nach “fast keine” aus. (Und PTv1-Buslinien sind auch kein Problem, wenn public_transport:version=1 dransteht)

hsimpson:

Die Schienen-Routen mögen inzwischen meist PTv2 sein, aber bei den Bus-Routen herrscht noch ein wildes durcheinander. Die Analyse haben wir vor kurzem gestartet und bisher war ich alleine mit der Pflege der Relationen, die bereits PTv2 waren, voll ausgelastet.

Ja. PTv2 ist zu pflegeintensiv. Insbesondere ist es zu empfindlich gegen eigentlich ganz normale Arbeiten von Mappern, die garnichts am ÖPNV ändern wollen. Das muss in einem PTv3 anders sein. Aber ein Problem des Übergangs von PTv1 nach PTv2 sehe ich da nicht.

hsimpson:

Was soll das railway=tram_stop? gilt das auch für light_rail strecken und routen?

Es gibt light_rail-Strecken. Es gibt keine light_rail-Routen. Das steht nur im Proposal, weil jemand nach der Abstimmung den Abstimmungstext gefälscht hat. Das sind Züge und sie haben route=train in PTv2. Es war richtig, dass light_rail da nicht vor kam. Genauso ist es mit route=bus. Das kommt auch dann dahin, wenn diese Buslinie durch Taxen oder Reisebusse oder von mir aus Pferdefuhrwerke bedient wird. Es geht um den Charakter der Linie und nicht um die Beschreibung der Fahrzeuge oder der Betriebsordnung.

hsimpson:

Oder muss man hier mit railway=station …

railway=station ist der Zentralnode eines Bahnhofs und wird nach den von den Bahnleuten spezifizierten Regeln gepflegt. PTv2 arbeitet nicht mit Zentralnodes und sie kommen nie in PTv2-Relationen vor.(Wenn der Zentralnode auch noch zufällig der stop-Node ist, dann kommt er natürlich in PTv2 vor.)

hsimpson:

Was passiert, wenn Bus und Tram an einer platform halten, muss man dann ein tram_stop und ein bus_stop setzen, beides in die selbe Node,…

Auf jeden Fall müssen PTv2-stops in den Fahrweg des betreffenden Verkehrsmittels. Wenn das derselbe way ist, dann sehe ich erstmal keinen Grund, zwei verschiedene Nodes dafür zu nehmen.

hsimpson:

… oder für den bus_stop eine eigene platform-Node, da die Tram einen railway=platform gemalt bekommen hat?

Wenn diese Platform von den Busbenutzern benutzt wird, dann muss sie in die Route. Und natürlich darf keine zweite Platform gemappt werden, wenn nur eine da ist.

hsimpson:

Die Beibehaltung der alten Tags mag damals vieleicht logisch und sinnvoll erschienen sein, aber wenn wir jetzt eine neue Reform haben wollen, dann sollten wir uns für ein einziges einheitliches und in sich schlüssiges Schema entscheiden, was dazu flexibel genug ist, weitere Neuerungen aufzunehmen. Das Schema sollte vol allem konsequent logisch aufgebaut werden, um Interpretierungsschwierigkeiten von vornherein zu unterbinden! Und das sehe ich bisher nur bei den public_transport Schlüsseln.

Finde ich auch. Nur sollte dabei public_transport=* auch abgelöst werden.

hsimpson · 2017-12-14T15:04:46.000Z

Weide:

hsimpson:

Weide:

Das tun wir doch garnicht. PTv2 sollte die Routenrelationen aus PTv1 ablösen und das ist passiert. Es gibt fast keine PTv1-Routen mehr.

Da muss ich dir wiedersprechen. Siehe: https://wiki.openstreetmap.org/wiki/VRS/Analyse

Da wird von nur einer PTv1-Buslinie gesprochen – das sieht für mich nach “fast keine” aus. (Und PTv1-Buslinien sind auch kein Problem, wenn public_transport:version=1 dransteht)

Ich sehe da deutlich mehr, viele auch noch komplett ohne public_transport:version=1. Vor allem im Ländlichen Bereich, also bei den Buslinien, die nicht im 100er und 600er Bereich sind.
PTv1-Linien möglen technisch vieleicht kein Problem darstellen, aber alleine ihre Existenz ist eine immense Einstiegshürde für PT-unerfahrene Mapper. Und da schließt sich dann auch der Kreis, denn PTv1-Linien kommen vor allem da vor, wo es eben keine aktiven PT-Mapper gibt.

Weide:

Es gibt light_rail-Strecken. Es gibt keine light_rail-Routen. Das steht nur im Proposal, weil jemand nach der Abstimmung den Abstimmungstext gefälscht hat. Das sind Züge und sie haben route=train in PTv2. Es war richtig, dass light_rail da nicht vor kam. Genauso ist es mit route=bus. Das kommt auch dann dahin, wenn diese Buslinie durch Taxen oder Reisebusse oder von mir aus Pferdefuhrwerke bedient wird. Es geht um den Charakter der Linie und nicht um die Beschreibung der Fahrzeuge oder der Betriebsordnung.

Was macht man dann mit den Stadtbahnen im Rhein-Ruhr-Bereich? Es ist nicht ohne Grund der Fall, dass hier immer noch keine Einheitliches Linien-Tagging vorherrscht. Die sind nämlich von Charakter her weder tram noch subway. Die Stuttgarter haben daher ihr Netz korrekter Weise auf light_rail umgestellt, auch wenn es das offiziell gar nicht gibt.

Und ein rechtlicher Rahmen gibt auch immer mindestens anteilig den Charakter vor. So ist es kein Zufall, dass auf allen Stadtbahnsystemen deutlich kürzere und schmalere Züge fahren als auf den Voll-U-Bahnen, das wird nämlich von der BoStrab so vorgegeben.

Weide:

PTv2 arbeitet nicht mit Zentralnodes und sie kommen nie in PTv2-Relationen vor.

Die sind aber in jedem Bahnhof in der stop_area drin, auch, wenn JOSM das immer anmeckert.

Weide:

hsimpson:

Was passiert, wenn Bus und Tram an einer platform halten, muss man dann ein tram_stop und ein bus_stop setzen, beides in die selbe Node,…

Auf jeden Fall müssen PTv2-stops in den Fahrweg des betreffenden Verkehrsmittels. Wenn das derselbe way ist, dann sehe ich erstmal keinen Grund, zwei verschiedene Nodes dafür zu nehmen.

hsimpson:

… oder für den bus_stop eine eigene platform-Node, da die Tram einen railway=platform gemalt bekommen hat?

Wenn diese Platform von den Busbenutzern benutzt wird, dann muss sie in die Route. Und natürlich darf keine zweite Platform gemappt werden, wenn nur eine da ist.

Ich stimme dir da voll zu. Aber ich will hier gar keine Diskussion über die korrekte Anwendung von PTv2 führen. Ich will dir aufzeigen, dass die Leute damit einfach nicht klar kommen! Deswegen muss das ganze deutlich vereinfacht werden!

Weide:

Nur sollte dabei public_transport=* auch abgelöst werden.

Warum? Warum unbedingt nochmal einen neuen Schlüssel erfinden, wenn wir schon einen haben, der das alles kann? Ich habe bisher noch kein Argument gehört, warum public_transpot=* nicht funktioniert!

Es ist bisher nur leider so, dass es durch die ganzen Dopplungen von vielen als Überflüssig oder als Hilfstag wahrgenommen wird. Aber die Gründe dafür liegen definitiv wo anders.

Viele Grüße

Weide · 2017-12-14T16:41:35.000Z

hsimpson:

Die sind aber in jedem Bahnhof in der stop_area drin, auch, wenn JOSM das immer anmeckert.

Ja. Aber public_transport=station darf rein. Dass public_transport=station etwas völlig anderes ist als railway=station ist den Leuten egal. public_transport=station wird einfach umdefiniert, damit man formal begründen kann, dass der Zentralnode in der stop_area auftaucht.

hsimpson:

Ich habe bisher noch kein Argument gehört, warum public_transpot=* nicht funktioniert!

Nehmen wir mal nur public_transport=stop_position und public_transport=platform: Jeder der beiden muss in die Route, wenn er gemappt ist. Jeder der beiden ist optional, aber einer muss da sein, sonst ist da keine Haltestelle. Die Zusammengehörigkeit eines stops zu einer platform (egal, ob mit oder ohne public_transport-tag) ist nur aus den Routen zu entnehmen. Zu einer Platform können mehrere Stops gehören und zu einem Stop können mehrere Platforms gehören. Wenn man jetzt eine Karte erstellt und wissen will, ob an diesem gerade verarbeiteten Node ein Haltestellensymbol auf die Karte soll, dann kann man ohne komplette Analyse der Routen nichts entscheiden. Selbst mit Routenanalyse gibt es Fälle, in denen man nicht entscheiden kann ob da ein “H” auf die Karte soll oder nicht. Man kann natürlich mehrere “H” für einen Halt machen … aber es will doch nun wirklich keiner eine mit “H” zugepflasterte Karte.

Deshalb sollte jede Bushaltestelle genau ein highway=bus_stop haben und das sollten die Kartenhersteller nutzen.

simon04 · 2017-12-16T22:31:00.000Z

Beim OSM-Samstag auf der heurigen FOSSGIS in Passau gab es eine Diskussion zum ÖPNV-Mapping. Ein Kurzprotokoll habe ich damals unter https://wiki.openstreetmap.org/wiki/FOSSGIS_2017/OSM-Events/%C3%96PNV-Mapping zusammengeschrieben

Nakaner · 2017-12-18T17:25:05.000Z

Hallo hsimpson,

hsimpson:

Ich finde, es ist am wichtigsten, dass PTv3 endlich klarheit bezüglich der zu verwendenen Schlüssel schafft. Dass PTv2 quasi parrallel zu PTv1 gebaut wurde hat sicherlich sehr viel zur allgemeinen Verwirrung beigetragen.

Die Probleme bei PTv2 sind in meinen Augen:

Das Proposal ist zwar angenommen, aber die Wikiseiten, die sich mit ÖPNV beschäftigen, sind erst Jahre später aktualisiert worden. Solche Widersprüche fördern Missverständnisse und stiften Verwirrung. Auch ich bin diesen eine Zeit lang aufgesessen.
Ein Taggingschema, das mehr macht, als nur ein paar Tags zu erfinden, wird ohne eine Musterimplementierung nur beschränkten Erfolg haben. Für ein x-beliebiges neues Tag foo=bar, erfordert es nur Änderungen am Kartenstil. Neue Relationstypen erfordern jedoch Support durch die Werkzeuge, die aus diesen Relationen normale Simple-Feature-Geometrien (Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon) erzeugen, wie sie von den üblichen GIS-Werkzeugen verwendet werden. Aus diesem Grund hat die site-Relation auch nur eine geringe Relevanz. Wer also möchte, dass ein von ihm vorangetriebenes Mappingschema auch unterstützt wird, muss, so hart es leider auch klingen mag, selber Software programmieren.
Das Problem mit den schwer wartbaren Routen ist wirklich ein Problem. Ich meine damit das Schulbusproblem und die Segmentfrage. Ich kann mit Segmenten leben.

Nicht störenden Unschönheiten sind:

Masterrouten. Mir leuchtet noch nicht ein, wozu die erforderlich sind. Das mag aus Mapperperspektive auf dem Papier schön aussehen (“dann ist da eine Relation, die die anderen Relationen zusammenfasst”). Das Konzept hat aber das oben erwähnte Problem, dass es von wenigen Anwendungen unterstützt wird und in den mir bekannten Fällen nur Informationen dupliziert. Versteht mich nicht falsch! Ich bin nicht streng gegen Duplizierung, aber wenn Duplizierung, dann bitte so, dass beide Varianten ähnlich gut für Datennutzer zugänglich sind.
Geteilte Bahnsteige (siehe Beitrag #1 von sllh)

hsimpson:

Es ist sicherlich keine verkehrte Idee, Schlüssel wie public_transport beizubehalten, aber hier sollte es bei der Einführung vermieden werden, auf die alten PTv2 und 1 zu verweisen. Es muss ganz klar sein, dass es ab dem Zeitpunkt nur noch PTv3 gibt und nichts anderes. Auch ist es sehr wichtig, alle relevanten Renderer von anfang an im Boot zu haben. Diese sollten in einer Übergangsfrist beide Schematas unterstützen, aber nach maximal 6-12 Monaten darf es keinen Renderer mehr geben, der PTv3 nicht unterstützt.

Dem Renderer sind die Daten egal. Du meinst vermutlich “Kartenstil”, oder?

Wenn zu mir als Kartenstilautor jemand sagen würde, du musst das neue Tag foo=bar unterstützen, weil es dazu ein akzeptiertes Proposal gibt, würde ich ihm freundlich mitteilen, dass ich gerne abwarten würde, bis es angenommen ist. Der beste Weg, etwas voranzubringen, ist Dinge selber zu machen. So funktioniert Open Source.

Viele Grüße

Michael

hsimpson · 2017-12-18T21:45:35.000Z

Ein bisschen OT, aber warum existiert diese Wiki-Seite noch: https://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema
Ist es nicht Sinnvoll, diese Seite zu löschen und stattdessen eine Weiterleitung zur Public-Transport-Seite zu installieren?

Meiner Ansicht nach schafft diese Siete mehr Verwirrung, als sie ausräumt, da sie bei weitem nicht vollständig ist und keinerlei Verweise auf aktuelle Seiten zum Thema ÖPNV aufweist (außer zu ein-zwei Key/Value-Seiten).

Grüße

hsimpson · 2017-12-18T21:57:56.000Z

Nakaner:

Dem Renderer sind die Daten egal. Du meinst vermutlich “Kartenstil”, oder?

Wenn zu mir als Kartenstilautor jemand sagen würde, du musst das neue Tag foo=bar unterstützen, weil es dazu ein akzeptiertes Proposal gibt, würde ich ihm freundlich mitteilen, dass ich gerne abwarten würde, bis es angenommen ist. Der beste Weg, etwas voranzubringen, ist Dinge selber zu machen. So funktioniert Open Source.

Viele Grüße

Michael

Genau hier beißt sich doch wieder die Katze in den Schwanz…

Es gibt nunmal leider viele Mapper hier, die nur das mappen, was auch auf der Karte gezeigt wird. So bin ich immer noch der Meinung, dass die Berliner und Hamburger S-Bahnen sehr schnell auf route=train + service=commuter umgestellt werden würden, wenn die gängigen ÖPNV-Karten route=light_rail nicht mehr grün rendern würden. Diese tun das aber immer noch, mit Verweis auf die aktuelle Nutzung dieser Tags. Im speziellen Fall der ÖPNV-Karte ist ein Umstellen auf die korrekte Tagging-Variante sogar kontraproduktiv, da diese service=commuter gar nicht rendert. Blöderweise ist das auch eine der bekanntesten Karten in dem Bereich.

Und genau deshalb muss man die großen Renderer unbedingt von Anfang an mitnehmen, damit man eben nicht erst am Ende zu ihnen kommt und denen ein neues Schema vor die Füße wirft. Sonst würde ich auch sagen, dass man mir doch bitte erst mal ein paar Beweise bringen soll, dass das tatsächlich relevant ist, das jetzt anders zu rendern.

Anderes Beispiel: Wenn Carto highway=platform nicht mehr rendern würde, wäre dieser Tag schon lange ausgestorben…

Viele Grüße

Trockennasenaffe · 2017-12-19T08:42:39.000Z

Mal zu etwas ganz anderem. Wenn es ein neues Pt Schema gibt, bietet sich die Chance, den weltweit stark verbreiteten, und auch in Deutschland extrem auf dem Vormarsch befindlichen Bedarfs-ÖPNV zu berücksichtigen. Alleine im Aachner Verkersverbund gibt es da diverse Varianten:

Da ist z.B. die konservativste Variante das Anruf-Linientaxi. Hierbei handelt es sich um klassischen Linienverkehr nach Fahrplan, der allerdings nur auf Bestellung fährt. Meist kommt das bei Linien zum Einsatz die zur Hauptzeit normal bedient werden.

Nächste Variante ist das ASEAG-Sammelauto. Das kann man zu festen Zeiten zu bestimmten Bushaltestellen bestellen, das Ziel allerdings innerhalb eines Gebietes frei wählen.

Eine weitere Variante ist der Netliner oder Multibus, bei dem Start und Ziel eine beliebige Haltestelle innerhalb eines Gebietes sein müssen, aber die Zeiten relativ frei gewählt werden können.

In Afrika und Asien gibt es vielfach Sammelbusse, die feste Routen fahren, aber nicht nach Fahrplan fahren, sondern dann, wenn genug Fahrgäste eingestiegen sind.

Ich würde daher einführen, dass Linienrelaionen nicht nur Routen sondern alternativ eine Liste von Start- und Endhaltestellen oder alternativ Start- und Endgebieten beinhalten können. Dazu sollen an alle Linien noch folgende Informationen getaggt werden können: generelle Bedienzeittraum, Fährt nur auf Bestellung, fährt nach festem Fahrplan oder zeitlich varabel.

Polyglot · 2017-12-21T12:31:15.000Z

Hier habt ihr meine Ideen für was wichtig ist wenn wir eines Tages umschalten auf ein anderes Schema:

http://www.openstreetmap.org/user/Polyglot/diary/42995

Wo wir einverstanden sind, ist das so ein neues Schema einfacher sein muss, als was wir jetzt haben.

Jo

thal1982 · 2017-12-24T13:34:42.000Z

Moin,

also für mich ist immer entscheidend, das das mappen nicht weiter verkompliziert oder gar erschwert wird.
Bei Buslinien die verschiedene Routen auf einer Linie haben (z.b. Bus fährt von a nach c aber b wird gelegentlich bedient), sollte einfach nur die Linie hinzugefügt werden, über die gesamten Fahrtroute-Varianten.
Und nicht extra aufspalten in Bedienungszeitraum-Linien
(Aus einer Linie können urplötzlich mehrere vorhanden sein, pflegeintensiver und wartungsintensiver zugleich).
Mittels Routing-Funktion kann virtuell doch dann der Bus diese Linie befahren, und bei den Abzw. die richtige Linienführung finden wegen der nächsten logischen Haltestelle.

Wie sieht eigentlich das Tag für Draisinenbahnen aus oder für Museumsbahnen?

Gruß

Thal

Polyglot · 2017-12-24T15:30:32.000Z

Da bin ich völlig einverstanden. Wenn eine Linie diese Haltestellen bedient:

A B C D E F G H

dann macht es nicht viel Zweck auch Routenrelationen zu erfassen für die Varianten die nur

C D E F

bedienen. Bei C und F würde ich dann wohl public_transport=stop_position/bus=yes auf dem Weg mappen und die Wege dort trennen.

Polyglot

miche101 · 2017-12-24T16:04:07.000Z

Polyglot:

dann macht es nicht viel Zweck auch Routenrelationen zu erfassen für die Varianten die nur

C D E F

bedienen.

kommt immer darauf an was man mit den Daten machen möchte… zum Rendern einer Karte stimme ich zu, weil deckungsgleich… Wäre ich der Busfahrer… dann möchte ich vielleicht nur das Schnipsel

Gibts es eigentlich auch die Möglichkeit sich aus so einer Routenrelation sich eine gpx… bzw. kml-Datei oder ähnliches sich zu generieren zu lassen… um das z.B. nachzufahren? Weil im Wander/Tracking/MTBFahrrad Bereich ist sowas ja dass Format…

miche101 · 2017-12-24T16:09:39.000Z

Polyglot:

Bei C und F würde ich dann wohl public_transport=stop_position/bus=yes auf dem Weg mappen und die Wege dort trennen.

Das Trennen von Wegstücken empfinde ich auch als sehr großen Nachteil der jetzigen Vorgehensweise…

Hier so eine Negativbeispiel:
http://www.openstreetmap.org/#map=19/48.30312/11.91214

Da wäre es mir lieber wenn Routing-Ergebnisse, also z.B. Gpx-Dateien auf eine Karten gerendert werden würden

PS: Natürlich könnte man sagen… ja das ist Aufgabe des Renderers die Wege wieder zusammenzufügen die man wegen der Routen-Relationen zerteilt hat… Naja sehe ich nicht so… was soll der Renderer noch alles machen…

30303020 · 2017-12-27T23:51:26.000Z

Meiner Erfahrung nach sind mehrere Routenvarianten für eine Richtung ein verhältnismäßig kleiner Mehraufwand. Wenn ich die Lücken von Linien schließen möchte, gehe ich mit JOSM wie folgt vor:

längste Routenrelation heraussuchen

mit Strg+A alle Elemente auswählen und dann mit JOSM-Sortierfunktion (vor-)sortieren

Plausibilitätscheck für der sortierten Einträge

prüfen, ob noch immer Lücken vorhanden (evtl. Ways ergänzen)

gucken, welche Linienabschnitte sich überschneiden und diesen Teil aus nicht reparierten Relationen löschen

Überschneidungen aus reparierter Relation mit Strg+Ziehen in die andere(n) Relationen kopieren

Anpassungen an verschiedenen Linienästen (entfällt bei Verstärker-Relationen)

(in blau die zusätzlichen Schritte: einfaches Kopieren)

Momentan frage ich mich allerdings, was überhaupt der Vorteil darin ist, dass man die Ways in den Relationen ablegt. Was interessiert es den Nutzer, über welche Straße/welches Gleis man fährt? Wozu braucht man diese Info?

Polyglot · 2017-12-28T00:11:52.000Z

30303020:

Momentan frage ich mich allerdings, was überhaupt der Vorteil darin ist, dass man die Ways in den Relationen ablegt. Was interessiert es den Nutzer, über welche Straße/welches Gleis man fährt? Wozu braucht man diese Info?

Ohne viel Aufwand eine Linie auf der Karte darstellen?

TZorn · 2017-12-28T05:59:00.000Z

Polyglot:

30303020:

Momentan frage ich mich allerdings, was überhaupt der Vorteil darin ist, dass man die Ways in den Relationen ablegt. Was interessiert es den Nutzer, über welche Straße/welches Gleis man fährt? Wozu braucht man diese Info?

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.

Weide · 2017-12-28T12:51:38.000Z

30303020:

Momentan frage ich mich allerdings, was überhaupt der Vorteil darin ist, dass man die Ways in den Relationen ablegt. Was interessiert es den Nutzer, über welche Straße/welches Gleis man fährt? Wozu braucht man diese Info?

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.

30303020 · 2017-12-28T18:40:54.000Z

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:

recommended if no route_master=* exists, else optional

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?

miche101 · 2018-01-19T15:35:18.000Z

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

aixbrick · 2018-01-19T17:14:13.000Z

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.)