PTv3: Zielsetzung eines modifizierten ÖPNV Modells

Beisielsweise gaukeln fehlende Haltestellen in einer Route einen nicht-vorhandenen Expressverkehr vor. Wir können nicht erwarten, dass ein Mapper komplette Routen beitragen kann.

Schwebt dir da denn schon etwas vor? Ein stumpfes completion= tag wäre, finde ich, eine schlechte Lösung. Aber wie soll ein System sonst erkennen dass eine Route so wie sie erfasst ist vollständig oder nicht ist?
Ein Gedankengang von mir wäre jetzt vielleicht ein Parameter stop_count= welchen man mit der Anzahl erfasster Stops abgleichen könnte...

Insbesondere durch die Vielzahl generierter Varianten Relationen wird die Wartbarkeit der Wege bei PTv2 stark eingeschränkt. Hier ist anzustreben die Anzahl der Relationen an dem jeweiligen Weg zu reduzieren und diese Relationen einfacher reparierbar zu machen.

Gegenüber ptv1 wo alles in die selbe Relation geknüllt wurde sind hier aber wenigstens die Inhalte der einzelnen Routenrelationen relativ übersichtlich. Ich schätze mal du denkst da "wieder" an ein Segmentansatz, aber das könnte im schlimmsten Fall auch wieder beliebig kleinteilig werden.

Ein PTv3, dass sich nur sehr langsam durchsetzt, würde alles nur verkomplizieren anstatt zu vereinfachen. Es ist also wichtig, keine Durchsetzungshindernisse zu schaffen, und der Vorteil von PTv3 muss groß genug sein, damit die Umstellung zügig erfolgt.

Dem ist nur zuzustimmen.

Ich würde gern zwei Punkte der Ziele noch konkretisieren wollen:

Es ist also wichtig, keine Durchsetzungshindernisse zu schaffen, und der Vorteil von PTv3 muss groß genug sein, damit die Umstellung zügig erfolgt.

• Diesen Punkt finde ich richtig. Ich erlebe in meinem Mappinggebiet (Berlin, Brandenburg und Mecklenburg-Vorpommern) auf einigen Routen eine Vermischung verschiedener Mapping- und Taggingansätze. Ich würde mir (aufgrund meiner Erfahrung vor allem mit Regionalbahnen), wünschen, dass sich eine mögliche Umstellung auf ein (potentielles neues) Schema weitgehend automatisieren lässt, alles Andere bindet knappe Ressourcen und verzögert Änderungen um Jahre.

Derzeit ist ÖPNV-Mapping und insbesondere dessen Wartung sehr zeitaufwendig, so dass auch hier Verbesserungen anzustreben sind.

• Was diesen Punkt betrifft, sind mit vor Allem die »Metadaten« der PTv2-Relationen ein Dorn im Auge: Momentan ist es so, dass z.B. der Verkehrsverbund in jeder Einzelrelation (nach PTv2-Definition sollen das mindestens zwei sein) und zusätzlich in der Masterrelation gespeichert werden. Ich habe noch keinen Fall gesehen, wo diese Daten in der Realität verschieden sind (Einspruch erwünscht...). Bei Änderungen wird aber manchmal nur eine Relation geändert und es kommt zu einem Widerspruch (Bsp: RE4 Lübeck - Szczecin Główny: https://www.openstreetmap.org/relation/2609914).
Dieser Hinweis trifft genauso auf die Tags »ref«, »ref:Verkehrsverbund«, »operator«, color und »service« zu.
Ich kenne einen Sonderfall, bei dem verschiedene Linienrelationen der selben Linie von verschiedenen Unternehmen bedient wurden (existiert nicht mehr), aber von dem Einzelfall abgesehen, war das bisher für mich nur zusätzlicher Aufwand und eine möglichst zu vermeidende Fehlerquelle.

Abgesehen davon sehe ich relativ wenige Optimierungsmöglichkeiten: Es gibt eine große Vielzahl von Spezialfällen im ÖPNV (die Spanische Lösung wurde schon angesprochen, ansonsten gibt es noch Ringlinien, die nur in einer Richtung bedient werden, saisonale Verbindungen, wechselnde Bahnsteige), die sich momentan nur schwer modellieren lassen. Jeder Sonderfall hat das Potential, eine Relationenstruktur weiter zu vergrößern (etwa durch das Hinzufügen eines zusätzlichen Tags), was als kompliziert wahrgenommen wird.

Ich halte einen Editor für ÖPNV-Mapping für unumgänglich (Gedankengang: Ist die Datenstruktur schon komplex, so soll es zumindest einen einfachen Zugang für Mapper geben). Daran schließt sich natürlich auch ein Validator an, welcher alle Merkmale des Schemas überprüft...

Helmchen42 wrote:

Schwebt dir da denn schon etwas vor? Ein stumpfes completion= tag wäre, finde ich, eine schlechte Lösung. Aber wie soll ein System sonst erkennen dass eine Route so wie sie erfasst ist vollständig oder nicht ist?

Da habe ich schon recht konkrete Vorstellungen. Der Ausgangspunkt sind Überlegungen, wie ein einfach zu bedienendes User-Interface aussehen kann. Wenn der User z.B. eine Bushaltestelle im Editor selektiert hat, sollte er er eine Buslinie hinzufügen können. Zumeist wird man von dem User erwarten können, dass er jeweils aus einem Drop-Down-Menü die vorangegangene oder nachfolgende Haltestelle auswählen kann, damit der Editor die neu hinzugefügte Haltestelle passend in die Relation einbauen kann. Der User muss aber auch die Möglichkeit haben anzugeben, dass ihm dieses unbekannt ist, dass es keine deratige Haltestelle gibt (am Linienanfang bzw. Ende), oder diese Haltestelle noch in der Route fehlt. In letzterem Fall sollte der User um die Angabe der entspechenden Haltestelle nach der Lücke gebeten werden, um die Route passend sortieren zu können.
Die getroffenen Auswahlen müssen natürlich im Editor visualisiert werden und jederzeit nachträglich korrigierbar sein.

Technisch kann diese Information gespeichert werden, indem z.B. der stop Rolle eine Endung mit einem Statuspaar bezogen auf den Vorgänger und Nachfolger hinzugefügt wird.
Beispiele:
stop:gap|none ist der letzte Halt der Linie und davor ist eine Lücke.
stop:ok|ok ist eine innere Haltestelle in der Linie, die in diesem Bereich vollständig und korrekt sortiert ist
stop:unknown|ok ist bezüglich des Vorgängers möglicherweise noch nicht korrekt in die Relation eingeordnet.

Ein Gedankengang von mir wäre jetzt vielleicht ein Parameter stop_count= welchen man mit der Anzahl erfasster Stops abgleichen könnte...

Wir können nicht davon ausgehen, dass der Mapper Wissen über die gesamte Linie hat, und somit die Haltestellenanzahl kennt. Weiterhin fehlt dabei natürlich die Information, wo die Probleme liegen.

Ein stumpfes completion= tag wäre, finde ich, eine schlechte Lösung.

Da stimme ich zu, zumal wir auch hier wieder einen Mapper mit Gesamtwissen über die Linie bräuchten, um beurteilen zu können, dass alles komplett ist.

Abgesehend davon, dass ich den Ansatz begrüße, möchte ich hier nur folgendes kurz einwerfen (auch nicht zum ersten Mal in diesem Forum):

• Ein komplexes System kann nicht auf eine beliebig simple User-Schnittstelle heruntergebrochen werden. Ich beziehe mich damit auf "... ist derzeit die Mehrheit der Mepper von der Public Transport Bearbeitung weitgehend ausgeschlossen.". Ob es jetzt die Mehrheit ist oder nicht ... geschenkt ... je komplexer die Daten, desto weniger Leute können sie bearbeiten. Das ist so, und das wird so bleiben. Man kann nicht alles für jeden editierbar machen. Viel wichtiger ist es, versehentlichen Beschädigungen vorzubeugen – wie auch immer.
Ich sehe auch das Problem, dass eine geringe Anzahl an Bearbeitern auch wenig Fortschritt bedeutet. Daher sollte die Anzahl so hoch wie möglich sein. Ich will nur vor dem Ziel eines "Volks-Editors" warnen, den auch Oma Erna bedienen kann.
• Du hast schon über das Interface hinaus gedacht und überlegt, wie ermittelte Daten abgelegt werden. Das ist sehr wichtig, denn sonst bastelt man eine tolle Oberfläche und stellt dann bei der Implementierung fest, dass man nicht weiß, wohin mit den Informationen. Daneben wäre es aber auch sinnvoll, bei verschiedenen Editoren ein einheitliches Interface bzw. einen einheitlichen Editor bereitzustellen. Bei JOSM wäre es Java-basiert, bei iD weiß ich es nicht.
• Ich persönlich finde PTv2 nicht so schlecht, soweit ich es selbst genutzt habe. Es ist ziemlich klar und strukturiert für "normale" Gegebenheiten einsetzbar, denke ich. Allerdings kenne ich die vielen Sonderfälle natürlich nicht, die damit nicht abzubilden sind. Einige Diskussionen bezüglich dieser Sonderfälle fand ich jedoch auch etwas weit hergeholt, muss ich zugeben. Mit ein bisschen gutem Willen, ließe sich einiges mehr darstellen als auf den ersten Blick erkennbar, glaube ich. Das soll jetzt kein Plädoyer für PTv2 sein, aber den Blick auf ggf. wiederverwendbare Ansätze freihalten.
• Der ÖPNV ist kein deutsches Konstrukt. Ein PTv3 muss genauso im Rest von Europa und im Rest der Welt funktionieren. Auch im Sinne der Akzeptanz sollte man das früh genug mit berücksichtigen und ggf. Leute fragen, die die Gegebenheiten vor Ort kennen. Ich denke da z.B. an die New Yorker Metro, die ein paar Besonderheiten aufweist, die mir in Deutschland zumindest noch nicht begegnet sind. Auch bei den Fahrzeugklassen muss man aufpassen, dass man alles erwischt bis hin zur Pferdekutsche, wenn nötig.
Dieses Forum kann also für eine Vorarbeit sicher gut genutzt werden, zumal es sonst auf der Welt offenbar niemand gibt, der sich massiv um das Thema kümmert (was noch nachzuweisen wäre – quasi wie bei Patentideen). Irgendwann sollte sich das dann aber auf internationale Wikis oder Foren "ausbreiten" (wenn es einen robusten Stand erreicht hat).

Na dann ... auf in den Kampf 😉 Es lohnt sich.

Ich sehe PTV2 als viel zu Aufwändig, nicht Wartbar an. Alle Routenvarianten zu erfassen wird in keinsterweise gemacht... das funktioniert vielleicht in Ballungsräumen noch z.B. München. In Ballungsräumen gibt es aber nicht so viele Varianten.. in den Landkreisen um München sieht es aber dann schon wieder sehr dürftig aus. Es findet sich auch kaum jemand der zu dem Thema Interesse hat, und zweimal schon nicht die PTV2 konform zu machen... und nachzuhalten.

Ich selbst habe auch das Interesse daran verloren, da ich mit manchen Edits die nach mir gemacht wurden unzufrieden bin. Kreisverkehre aufzutrennen oder Linien an stop-positionen aufzuteilen weil hier die Linie endet..usw. manches Tagging usw. finde ich kontraproduktiv und will ich nicht fördern. Diese Auswerter können mich mal 😛 , dann erstelle ich lieber keine Relationen mehr in dieser Richtung.

MfG Miche

krza wrote:

Man kann nicht alles für jeden editierbar machen. Viel wichtiger ist es, versehentlichen Beschädigungen vorzubeugen – wie auch immer.

Leider erfordert die Bearbeitung der Basisinfrastruktur (highway oder railway) oft temporäre Beschädigungen der Routen. Selbst wenn man da z.B. Warnungen generiert, sind diese wenig hilfreich, wenn der Benutzer mangels Editierbarkeit das Problem nicht beseitigen kann. Die Basisinfrastuktur gegen Bearbeitungen zu sperren, erscheint auch nicht wirklich sinnvoll.

Daneben wäre es aber auch sinnvoll, bei verschiedenen Editoren ein einheitliches Interface bzw. einen einheitlichen Editor bereitzustellen. Bei JOSM wäre es Java-basiert, bei iD weiß ich es nicht.

Die Editoren sind konzeptionell zu verschieden. Ein einheitliches Interface für PT wäre da in mindestens einem Editor ein Fremdkörper. iD basiert übrigens auf Java-Script.

Ein PTv3 muss genauso im Rest von Europa und im Rest der Welt funktionieren.
...Ich denke da z.B. an die New Yorker Metro, die ein paar Besonderheiten aufweist, die mir in Deutschland zumindest noch nicht begegnet sind.

Falls etwas bekannt ist, das in PTv2 nicht funktioniert, wäre dies interessant. Funktionale Einschränkungen sollte es in PTv3 gegenüber PTv2 nicht geben, abgesehen vielleicht von der Notwendigkeit, manche Dinge etwas anders zu mappen.

Mein Träume bzgl. PT wären

1. Dass man eines Tages sowas wie Fahrplankarten auf OSM-Basis erzeugen könnte. Als Druckerzeugnis inzwischen wohl mehr oder weniger im Sande verlaufen. Allenfalls Südlicher Oberrhein aus den Kreisen der Erfinder lebt evtl. noch zaghaft ..
Dazu müsste man auch ein wenig durchschnittliche Fahrzeiten und Taktdichten HVZ/NVZ an den Kanten zwischen den Halten taggen. Und (falls noch nicht gemacht) auch Zugarten (RB/RE bswp.) ausreichend unterscheiden. Komplette Fahrpläne natürlich nicht, aber paar Grunddaten, damit man die unterschiedlichen Liniendicken und groben Fahrzeitangaben malen kann.

2. Angaben zur Barrierefreiheit: Bahnsteighöhen *) und Fahrzeughöhen bspw. und vermutlich noch einiges mehr.
Auch damit eines Tages passende Karten entstehen können, wo bspw. ein Farbschema auf einem Blick angibt, wo beides zusammenpasst.

3. to be continued

• ) In Karlsruhe gibt es gelegentlich auch zwei Höhen hintereinander (bspw. KA-Durlach 76 cm für S-Bahn RheinNeckar, 55 cm für die Stadtbahnen, am Gottesauer Platz letzteres vor 34 cm für Niederflurtrams), da ist dann das oben schon erwähnte nötig, dass man Bahnsteige teilen kann.
  

Hi,

Zunächst sei erst einmal erwähnt, dass ich erst zu PTv2-Zeiten bei OSM eingestiegen bin.

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

Zum Konkreten:

• Bezüglich der Dopplung von PTv1 und 2 bin ich persönlich der Meinung, dass diejenigen Schlüssel, die durch den public_transport - Schlüssel derzeit gedoppelt werden, ersatzlos wegfallen müssen. Das betrifft im Wesentlichen highway=bus_stop;platform und railway=stop:platform. Diese Schlüssel werden de facto nicht mehr benötigt, um eine Haltestelleninfrastruktur ausreichend zu beschreiben. Ich weiß, dass das vor allem den orm-Mappern wehtun wird, aber eben dafür wurden ja genau Schlüssel wie train=yes eingeführt.
• Um den Railwaymappern entgegen zu kommen schlage ich folgenden neuen Schlüssel vor: platform=railway, um die Widmung als Eisenbahninfrastruktur zweifelsfrei zu kennzeichnen. In einigen Fällen kann es nämlich vorkommen, dass an einem Vollbahn-gewidmeten Bahnsteig auch oder ausschließlich Stadt-oder Straßenbahnfahrzeuge halten. Dieser Schlüssel darf dann aber ausschließlich bei gewidmeten Vollbahnen verwendet werden.
• Der Status des Schlüssels light_rail muss endlich endgültig geklärt werden! Es kann nicht sein, dass hier in Deutschland immer noch an einigen Stellen ein Sonderweg gefahren wird, nur, weil der Schlüssel damals bei der Dokumentation vergessen wurde.
• Es muss ein Tool für JOSM und andere Editoren zu Handhabung von PT-Relationen her. Dieses Muss können: Haltestellen sortieren und hinzufügen und den Linienweg bearbeiten. Dabei sollte ein Befehl auch auf mehrer Relationen gleizeitig oder nacheinander ohne erneutes Auswählen der zu ändernden Relationselemente ausfürhbar sein können, um bei einem ganzen Linienbündel gleichzeitig den Linienweg verlegen zu können. Auch sollte das Tool mit doppelten Relationselementen umgehen können, derzeit ein sehr großer nachteil vom JOSM-Editor, der bei solchen Fällen manchmal abenteuerliche Leistungen hinlegt.
• Es sollte überlegt werden, ob man nicht Relationen als Teil des Linienwegs zulässt. Damit ließen sich gebündelte Linienführungen deutlich einfacher pflegen. Diese neuen Relationen beinhalten ihrerseits den konkreten Fahrweg in der richigen Reihenfolge. Der Nachteil davon ist, dass man somit eine weitere Hürde für Neueinsteiger setzt, aber im Gegenzug wird der Wartungsaufwand erheblich gesenkt, was wiederum auch die Hürde wieder senken kann. Vor allem in Städten mit Bussen als Rückrat des ÖPNV dauert es teilweise eine halbe Ewigkeit, bis man eine einfache Änderung der Hauptachse erfasst hat, vor allem, wenn vorher ünereifrige Mapper für jede einzelne mögliche Endstation eigene Linienrelationen angelegt haben (was wiederum über einfaches Kopieren der Relation sehr einfach ist).

Viele Grüße,
hsimpson

hsimpson wrote:

(...) Bezüglich der Dopplung von PTv1 und 2 bin ich persönlich der Meinung, dass diejenigen Schlüssel, die durch den public_transport - Schlüssel derzeit gedoppelt werden, ersatzlos wegfallen müssen. Das betrifft im Wesentlichen highway=bus_stop;platform und railway=stop:platform. Diese Schlüssel werden de facto nicht mehr benötigt, um eine Haltestelleninfrastruktur ausreichend zu beschreiben.

highway=bus_stop ist einer der ältesten Tags. Den kann man nicht "wegfallen lassen". Der wird auch noch in zehn Jahren benutzt werden, weil es zig User gibt, die nach ihrer Anfängerzeit nie wieder in ein Wiki schauen oder in Foren/Mailing-Listen was von neueren Entwicklungen mitbekommen. OSM ist ein weltweites Projekt, und wenn hier in D genug ÖPNV-Mapper da sind, um irgendwelche hochkomplizierten PTvX-Schemen umzusetzen, sieht das schon in Polen ganz anders aus... da kann man froh sein, wenn abseits der Großstädte bus_stop da ist. Und ob jemand, der in Afrika rendert, mitbekommt, dass Haltestellen in D mit bus_stop nicht zu finden sind? Bitte immer schön die Abwärtskompatibilität beachten!

Pfad-Finder wrote:

highway=bus_stop ist einer der ältesten Tags. Den kann man nicht "wegfallen lassen". Der wird auch noch in zehn Jahren benutzt werden, weil es zig User gibt, die nach ihrer Anfängerzeit nie wieder in ein Wiki schauen oder in Foren/Mailing-Listen was von neueren Entwicklungen mitbekommen. OSM ist ein weltweites Projekt, und wenn hier in D genug ÖPNV-Mapper da sind, um irgendwelche hochkomplizierten PTvX-Schemen umzusetzen, sieht das schon in Polen ganz anders aus... da kann man froh sein, wenn abseits der Großstädte bus_stop da ist. Und ob jemand, der in Afrika rendert, mitbekommt, dass Haltestellen in D mit bus_stop nicht zu finden sind? Bitte immer schön die Abwärtskompatibilität beachten!

Sry, aber das kann kein Grund sein! Mit der Begründung könnte man jede Neuerung im Keim ersticken und man müsste auf alle Ewigkeiten mit den jetzigen Tags leben!

Übrigens bin ich grade darum der Meinung, dass man von Anfang an alle relevanten Renderer im Boot haben muss. Erst, wenn auch dem letzten auffält, dass highway=bus_stop nicht mehr auf der Karte vorkommt, wird er vieleicht merken, dass sich etwas getan hat!

Und dein letztes Argument mit der Komplexität ist ja eben genau das, worum es sich hier drehen soll: Wie kann man mehr Mapper überhaupt in die Lage versetzen, mit ausreichender Sicherheit ein ÖPNV-System zu pflegen? Wenn PTv1 darauf eine Lösung wäre und das dann auch noch den Anforderungen der Vielseitigkeit des Öffentlichen Verkehrs genügen würde, würden wir diese Diskussion hier gar nicht führen. Aber so fahren wir hier grade zwei Systeme parrallel, was defninitiv keine Dauerlösung darstellen kann (es aber schon viel zu lange ist).

Grüße

Ich habe übrigens noch zwei weitere Probleme, für die man eine Lösung finden sollte:

• Es gibt immer mehr Anruftaxen, die von einer bestimmten Haltestelle ein ganzes Bendiengebiet erschließen. Ein Beispiel dafür sind die Anruf-Sammel-Taxen in Köln: https://www.kvb.koeln/service/ast_und_taxibus.html Solche Fälle können bisher gar nicht erfasst werden.
• Es gibt Fälle, in denen der Überlandbus über die Umgehungsstraße fährt, außer jemand drückt voher an der Haltestelle im Dorf eine Taste. Damit wird ein Signal vor der Abfahrt zum Dorf geschaltet, welches dem Busfahrer signalisiert, dass dort Fahrgäste warten. Nach meiner Kenntnis wird dieses System in Skandinavien bereits eingesetzt, allerdings weiß ich nicht genau wo.

Viele Grüße

hsimpson wrote:

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. Das Haltestellenmapping sollte niemals abgelöst werden. Es sollte nur ergänzbar werden und das ist passiert.

Leider wird auch da ergänzt, wo es sachlich garnicht nötig ist, weil es dieses unausrottbare falsche Gerücht gibt, dass highway=bus_stop durch PTv2 abgelöst wurde und die ganze Welt mit public_transport=* zugeschüttet werden muss.

Weide wrote:

Das tun wir doch garnicht. PTv2 sollte die Routenrelationen aus PTv1 ablösen und das ist passiert. Es gibt fast keine PTv1-Routen mehr. Das Haltestellenmapping sollte niemals abgelöst werden. Es sollte nur ergänzbar werden und das ist passiert.
.

Ist das so? Ich habe in den randgebieten des AVVs oft mit Routenrelationen zu tun die zwar kein PTv1 sind aber näher an PTv1 als an PTv2 in dem Sinne, dass es z.B. nur eine Rountenrelation für alle Fahrvarianten gibt.

Trockennasenaffe wrote:

Ich habe in den randgebieten des AVVs oft mit Routenrelationen zu tun die zwar kein PTv1 sind aber näher an PTv1 als an PTv2 in dem Sinne, dass es z.B. nur eine Rountenrelation für alle Fahrvarianten gibt.

Ich hab auch genügend gemacht pro Fahrrichtung.. Relationen aber mit alles Varianten... oder einzelne Varianten aber nicht alle.. oder alles in einer... mir wäre nicht bekannt das sich da mal die Mühe gemacht hätte diese auf PTV2 zu ändern..

Ich hab immer noch >50 Hinweise platziert... wo noch Bushaltestellen komplett fehlen.. welche erst vor Ort aufgenommen werden müssen. Also da stimme ich zu das wir da zu "durch PTV2 abgelöst" noch sehr weit entfernt sind.

Auf dem Land sind Bushaltestellen bisher so gut wie gar nicht gemappt, da braucht man ans Public-Transport-Mapping noch gar nicht zu denken. Noch dazu sind die Fahrpläne dort eine einzige Katastrophe nur weil man der Meinung ist, die Schulbusse müssten auch für "Auswärtige" zugänglich sein und damit im Fahrplan eingetragen werden.

Wer ein "Schreckensbeispiel" sehen will: bitteschön. Versuch das mal jemand in PTv2 darzustellen.

Ich sehe das Konzept der Routeneintragung als überholt an. Es müllt die Datenbank zu.. und erschweit die Bearbeitung. 🤔 Man könnte heute die Route durch eine Routingsoftware berechnen lassen mit wenigen Wegpunkten... und z.B. als GPX ablegen und diese bei Bedarf neu berechnen.

M.E. wäre es sehr wichtig, die Bushaltestellen mit dem Link zum Onlinefahrplan zu versehen - heute meist als qr-Code mit angegeben. Dort sind dann auch Routenänderungen automatisch - z.B. bei Baustellen - mit enthalten.

http://www.openstreetmap.org/node/3740880925
Hier ist z.B. noch nicht die Routenänderung der Linie C - bisher Bannewitz - jetzt Bahnhof Hainsberg enthalten. Könnte also als description:de und auch als Relation (Route) entfallen, da über

http://www.vvo-online.de/de/fahrplan/ak … d=33001141

ersichtlich, wohin und wann ein Bus fährt.

Prince Kassad wrote:

Noch dazu sind die Fahrpläne dort eine einzige Katastrophe nur weil man der Meinung ist, die Schulbusse müssten auch für "Auswärtige" zugänglich sein und damit im Fahrplan eingetragen werden.

Bei uns musst man teilweise "Schulbus" nutzen um in die "Dörfer" zu kommen.

Ja. Es gibt eine Menge Probleme. Aber diese Probleme kommen nicht daher, dass PTv2 bei der Ablösung von PTv1 nicht brutal genug war.

Ich weiß natürlich nicht, was die Ziele von PTv3 sind. Für mich stellt sich immer die Frage, welchen Nutzen hat das Ganze. Ich war gestern beim Wandern in einer fremden Gegend und habe auf der OSM-Karte eine Bushaltestelle gesucht und glücklicherweise gefunden. Auf der Karte habe ich dann auch gesehen, auf welcher Straßenseite die Haltestelle ist und damit auch in welche Richtung der Bus fährt und dies wohl deshalb, weil das von vielen verpönte "highway=bus_stop" vorhanden war. Der Mapper-Kollege hat hier einfach nicht gegen den Renderer gearbeitet und ihm die Chance gegeben, die Haltestelle auf der Karte darzustellen. Ich fordere also, dass ich auf der Karte erkennen kann, wo eine Bushaltestelle ist und auch auf welcher Straßenseite. Wie dies umgesetzt wird, ist mir egal. Der Renderer muss jedenfalls eine Möglichkeit habe, dies darstellen zu können.

geri-oc wrote:

M.E. wäre es sehr wichtig, die Bushaltestellen mit dem Link zum Onlinefahrplan zu versehen - heute meist als qr-Code mit angegeben. Dort sind dann auch Routenänderungen automatisch - z.B. bei Baustellen - mit enthalten.

Was man auch nicht übersehen darf ist die Angabe einer Referenz wie in deinem Beispiel, oder allgemein ref:IFOPT. Damit werden die Daten noch viel nützlicher weil beispielsweise Vergleiche oder Verknüpfungen zu Schnittstellen möglich werden.

Diese Dinge haben aber nicht viel direkt mit PTv* zu tun, es ist allgemein wichtig so etwas zu mappen, hier geht es aber wahrscheinlich eher weniger darum.

d3d9 wrote:

Was man auch nicht übersehen darf ist die Angabe einer Referenz wie in deinem Beispiel, oder allgemein ref:IFOPT.

Ich hätte ref:IFOPT schon längst bei von mir gemappten Bushaltestellen eingetragen, kenne dafür aber keine Quelle. Gibt es die Nummern überhaupt flächendeckend?

Prince Kassad wrote:

Ich hätte ref:IFOPT schon längst bei von mir gemappten Bushaltestellen eingetragen, kenne dafür aber keine Quelle. Gibt es die Nummern überhaupt flächendeckend?

Ich weiß nicht ob es die flächendeckend gibt, ich vermute ja; hier ist eine Übersicht (keine Ahnung ob komplett): https://zhv.wvigmbh.de/

Quellen gibt es viele, welche erlaubten es in deinem Raum gibt weiß ich nicht. In NRW darf man die Inhalte der VRR-EFA in verschiedenen Varianten benutzen.

Prince Kassad wrote:

Ich hätte ref:IFOPT schon längst bei von mir gemappten Bushaltestellen eingetragen, kenne dafür aber keine Quelle.

In der Regel der örtliche Verkehrsverbund. Dieser vergibt die ref entsprechend der DIN EN 28701:2012

Prince Kassad wrote:

Gibt es die Nummern überhaupt flächendeckend?

Ich habe zumindest bisher nichts mitbekommen, dass sich da ein Verbund aktiv gegen entschieden hätte.

Es gibt sogar einen Eintrag im Wiki dazu: https://wiki.openstreetmap.org/wiki/DE:Key:ref:IFOPT
Die Liste der Verbünde in D ist aber definitiv nicht up to date. In Bayern nutzen Sowohl der VGN als auch der MVV definitiv die IFOTP!

Grüße

Weide wrote:

hsimpson wrote:

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

Weide wrote:

Das Haltestellenmapping sollte niemals abgelöst werden. Es sollte nur ergänzbar werden und das ist passiert.

Eben das halte ich für einen der größten Fehler, da es uns viele Unsicherheiten und spezialdefinitionen beschert hat, die kaum einer wirklich durchblickt und jeder anders interpretiert:

• Was soll das railway=tram_stop? gilt das auch für light_rail strecken und routen? Oder muss man hier mit railway=station und station=subway arbeiten? Und überhaupt, wieso werden zwei Sytsteme, die beide unter BoStraB laufen, mal nach dem Railwayschema gemappt und mal nicht? Und darf man railway=tram_stop auch sysnonym zu railway=station setzen, wie es tausendfach praktitiziert wird oder nicht? In Düsseldorf hat letztlich wer ne Reihe von tram_stops durch railway=stop ersetzt, da die Haltestellen Teil von oberirdischen Hochflur-Linien waren. Diese sind in dem Bereich aber nur ein besonderer und kein eigenständiger Bahnkörper und daher der Definition nach eine Straßenbahn. Die entsprechenden Kommentare muss ich noch verfassen, da hatte ich bisher keine Zeit zu. In Düsseldorf haben wir übrigens auch die Besonderheit, dass ein und die selbe Linie auf Düsseldorfer Seite an tram_stop und auf Duisurger Seite an station=subway hält...
• 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, oder für den bus_stop eine eigene platform-Node, da die Tram einen railway=platform gemalt bekommen hat? Alles schon gesehen! Was passiert, wenn eine light_rail oder tram auf einer EBO-Infrastruktur fährt? In Köln ists derzeit noch die Tram, da die Linien noch nicht auf light_rail umgestellt wurden, weil noch bis vor kurzem einige S-Bahn-Linien als light_rail gemappt waren. Bisher sind die Stationen daher mit tram_stop gemappt, aber rein juristisch gesehen sind das stations und halts.

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.

Viele Grüße

hsimpson wrote:

Hi,
Es muss ein Tool für JOSM und andere Editoren zu Handhabung von PT-Relationen her. Dieses Muss können: Haltestellen sortieren und hinzufügen und den Linienweg bearbeiten. Dabei sollte ein Befehl auch auf mehrer Relationen gleizeitig oder nacheinander ohne erneutes Auswählen der zu ändernden Relationselemente ausfürhbar sein können, um bei einem ganzen Linienbündel gleichzeitig den Linienweg verlegen zu können. Auch sollte das Tool mit doppelten Relationselementen umgehen können, derzeit ein sehr großer nachteil vom JOSM-Editor, der bei solchen Fällen manchmal abenteuerliche Leistungen hinlegt.

Viele Grüße,
hsimpson

Der PT_Assistant plugin für JOSM macht schon viel von was du willst. HS sortieren entlang den Fahrtweg ist diesen Sommer hinzugefüft worden.
Hinzufügen von HS am Route aber (noch) nicht. Technisch ist das nicht all zu schwierig. Die manuel hinzufügen ist aber auch nicht so schwierig und nimmt weniger Zeit als falsche Positive löschen.

Gleichzeitig ändern von mehrere Routen ist nicht drinn, weil das relativ "gefährlich" ist. Was wohl drinn ist, ist Unterstutzung om Routen zu reparieren basiert auf andere Routen die schon kontinuerlich sind.

Das Tool kann mit doppelten Elemente umgehen. Obwohl mein Vorschlag für ein PTv3 gerade sein würde HS mit 1 zentrales Element darzustellen. Preferenziell eine Node, der alle Details hat, neben dem Weg dargestellt. Vielleicht brauchen wir ein neues Tag wie:

public_transport=pole
oder
public_transport=passenger_stop
oder
public_transport=passenger_area

oder
public_transport=halt
(ich kann kein besseres Wort finden auf English das nicht 'stop' ist)

anstatt
highway=bus_stop (nicht wirklich ein highway)
public_transport=platform (nicht immer ein Platform da)
bus=yes

oder
railway=tram_stop (keine Schiene neben die Schiene wo die Leute stehen)
public_transport=platform
tram=yes

Wenn ein Plattform vorhanden ist, ist es natürlich kein Problem das als Way oder Area dar zu stellen, das soll aber nicht die Details duplizieren und es sollte auch nicht in die Routenrelationen hin. (meine Meinung)

Jedenfalls ist PT_Assistant zo gemacht daß es mit mehrere Mappingstyle umgehen kann und daß es helfen kann bei die Umstellung von v1 auf v2.

Es ist auch fertig für wenn wir einen Tag mal Routesegmente benutzen können, um Linienteile zu bundlen. Das würde die Wartung erleichtern, es würde aber auch die komplexität etwas höher machen. Editor support ist dann sicher notwendig, weil manuell die Kontinuität überprüfen dann nicht mehr möglich sein wird.

Polyglot

PS: es war natürlich immer so gemeint daß public_transport highway=bus_stop und railway=tram_stop ersetzen würde. Nur ist das von die Leute die die Standard Rendering machen nie so ausgeführt. Erst angeblich um technischen Gründe, die letzten Jahre aber weil sie kein added value drin sehen. Ich habe keine Gründe zu glauben daß es ein PTv3 anders vergehen würde. Also machen wir das mit 'double tagging'. Ich habe es schon einigen Jahren her aufgegeben das zu ändern versuchen. Ein Tag mehr oder weniger ist auch nicht wirklich ein Problem. Details duplizieren, oder mehrere Objekten an Routerelationen hinzufügen müssen, is schlimmer. m.E.

hsimpson wrote:

Weide wrote:

hsimpson wrote:

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 wrote:

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 wrote:

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 wrote:

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 wrote:

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 wrote:

... 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 wrote:

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.

Weide wrote:

hsimpson wrote:

Weide wrote:

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 wrote:

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 wrote:

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 wrote:

hsimpson wrote:

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 wrote:

... 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 wrote:

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

hsimpson wrote:

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 wrote:

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.

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/FOS … NV-Mapping zusammengeschrieben

Hallo hsimpson,

hsimpson wrote:

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 wrote:

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

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

Nakaner wrote:

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

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.

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

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

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

Polyglot wrote:

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

Polyglot wrote:

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

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?

30303020 wrote:

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?

Polyglot wrote:

30303020 wrote:

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.

30303020 wrote:

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.

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/Pro … _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?

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.

aixbrick wrote:

Also, auf mich macht die Anleitung einen sehr komplizierten Eindruck.

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

geri-oc wrote:

(über die Webseite des Verkehrsunternehmen)

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

geri-oc wrote:

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.

Ich treffe immer wieder auf total veraltete solche description oder andere Tags mit Linieninfos als Inhalt. Halte ich sehr wenig von weil

1. Ist das nicht maschinell auslesbar, da nicht standardisiert. Also machst du dir hier nen Haufen Arbeit für die Katz.
2. 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.

geri-oc wrote:

Dann haben die meisten Haltestellen einen QR-Code, die auf den jeweiligen Haltestellenfahrplan verlinkt - diesen nutze ich als website=*.

Mache ich auch wo möglich. Aber:

geri-oc wrote:

Da sich dieser fast nicht ändert, sind die Daten aus der Website für diese Haltestelle immer sehr aktuell.

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