ÖPNV Bus stop_position

[slhh]

@krza

Ob man die Plattform jetzt noch nach Verkehrsmittel trennen möchte, sei mal dahingestellt (es gibt ja z.B. auch noch railway=platform und highway=platform). Ich persönlich halte es nicht für nötig, da die Elemente ja normalerweise einer Relation angehören und daraus abgeleitet werden kann, ob um was es sich handelt (und es können dadurch sogar Mischnutzungen sein).

Und wenn dann die Linienrelation fehlt, oder ein Bahnsteig ungenutzt (nur bei Betriebstörungen genutzt wird) ist, wird er nicht mehr gerendert oder einheitlich mit Bushaltestellen gerendert?

@krza

Stattdessen kann man den Zusammenhang aber über Relationen darstellen, und genau das wird ja mittels PTv2 getan. Hier können weitläufige Haltestellen zusammengefasst … werden.

Das sollten wir auch beibehalten. Wenn man die Zusammenfassung für Anwendungen für hinreichend wichtig hält, könnte man definieren, dass die Anwendungen über Namensgleichheit zusammen fassen sollen, wenn nicht ein spezielles Tag gesetzt ist, dass gerade dieses unterdrückt, und auch keine Mitgliedschaft in einer Stop-Area-Relation besteht.

@krza

Ein Problem stellt sicher dar, dass Änderungen an den verwendeten wys für die Fahrwege schnell zu korrupten Fahrwegen führen können (Stichwort “Zumutung” in Post #128). Okay. Das ist doof. Aber letztlich ist die Reihenfolge und Konsistenz der Haltestellen und deren Zugangspunkten wichtiger.

Wenn wir schon viel Aufwand in das Mappen der Fahrwege stecken, sollten die Daten aber auch korrekt sein. Soweit wir die Beschädigung nicht verhindern können, sollten sie wenigstens einfach behebbar sein. Der Ansatz von Weide bietet hir zwar gewisse Vorteile, ist aber bei weitem noch nicht ausreichend.

@krza

@slhh

Stop-Position und Platform sind nicht miteinander, was dazu führt, dass beide in die Linienrelation müssen. Dies macht die Linienrelationen unnötig kompliziert und fehleranfällig.

Sehe ich nicht so. Was ist daran kompliziert und fehleranfällig?

Vertauschung der Rollenreihenfolge generiert einen zusätzlichen Halt gemäß PTv2. Mehrere Halte in einer Haltestellen kommen aber auch in Realität vor und müssen unterstützt werden.
Kompliziter wird es, da mehr Member in der Relation zu deutlich höherem Sortieraufwand führen und auch die Gefahr besteht, Rollen zwischen den ggf. Namensgleichen stop und platform Elementen zu vertauschen.

@krza

Die Länge eines Bereichs hat in der Organisationsstruktur auch nichts verloren und wird dort auch nicht gebraucht. Das ist Physik und wird von den Elementen selbst vorgehalten, indem eine Plattform zum Beispiel als Way ausgeführt wird. Das ist ja auch üblich.

Die Platform kann viel länger oder auch kürzer (z.B. wegen Brücke/Tunnel, covered unterteilt) sein. Es kann der Teilbereich auch eine besondere Bereichnung haben.
Zur Visualisierung des Fußgänger Routingziels ist es schon sinnvoll, den ganzen Zielbereich darstellen zu können. Die Mitte des Zielbereichs als Routing-Ziel zu verwenden führt ggf. auch zu einer ungünstigen Wegwahl und zu einer schlechten Berechnung von Umsteigezeiten.
Beispiel: ein Bahnsteig mit Zugangstreppen an beiden Enden und in der Mitte. Der Fußgänner nährt sich dem Bahnhof entlang der Strecke. Der Router mag die mittlere treppe wählen, um eionen Zielpunkt in Bahnsteigmitte zu erreichen, wenn er jedoch von einem längeren Zielbereich ausgeht, wäre die zuerst erreichte Treppe an einem der Bahnsteigenden besser, sowohl um den nächstgelegenen Teil des Zuges zu erreichen, als auch im Mittel über alle Wagen des Zuges.

@krza

Theoretisch könnte man das sogar mit Stop-Positionen machen,

Dies ist durchaus möglich, wenn wir die Stop-Position als Linie oder Fläche mappen, die den Node auf dem Fahrweg mit der Platform (und bei Bedarf dem genutzten Bereich der Platformen) verbindet. Dann kann diese Stop-Position in der Art der von Weide vorgeschlagenen Pios in der Routenrelation verwendet werden. Platforms brauchen dann nicht mehr in die Relation, da diese durch gemeinsame Nodes zur Stop-Position auffindbar sind.

@krza

ich persönlich würde aber eher die übliche Fahrzeugmitte als Punkt setzen.

Hier scheint auch wieder einmal eine Definition zu fehlen, wo die Stop-Position zu liegen hat.
Nachträglich definieren oder durch ein Tag bezeichnen?
Bei mittiger Lage der Stop-Position könnte auch ein Tag die Länge des Haltebereichs angeben.
Es fehlt dann nur noch die Verknüpfung zur Platform. Ggf. könnten wir darüber nachdenken, dies in der Stop-Area Relation, z.B. durch eindeutige Zusätze zur Rolle, zu machen. Dann könnten wir auch auf die Platform in den Routen verzichten.

[krza (Kristian)]

@slhh

Und wenn dann die Linienrelation fehlt, oder ein Bahnsteig ungenutzt (nur bei Betriebstörungen genutzt wird) ist, wird er nicht mehr gerendert oder einheitlich mit Bushaltestellen gerendert?

Wenn etwas fehlt, dann ist es ein Fehler. Wir müssen uns von dem Gedanken lösen, alle möglichen Fehler oder Unzulänglichkeiten durch irgendwelche Tagging-Konstruktionen kompensieren zu wollen. Das wird nichts. Das obige Beispiel könnte allerdings ein Argument sein, diese Tags zu behalten, ja, denn die Frage, ob eine Linienrelation fehlt oder einfach nur nicht existiert, entscheidet, ob es ein Fehler ist oder nicht. Auch hier gilt allerdings der Grundsatz, dass wir Daten liefern und keine Renderer-Instruktionen

Mehr Member in einer Relation erhöhen übrigens nicht unbedingt den Sortieraufwand. Es wird vielleicht unübersichtlich, wenn icht alles auf einen Schirm passt, aber kompliziert wird es meines Erachtens erst, wenn es verschiedene Regeln für eine große Anzahl unterschiedlicher Rollentypen gibt. Vielleicht muss man auch den Editor da noch ein bisschen pimpen, aber das kann man ja machen. Der soll sich schließlich an den Bedarfen orientieren und nicht die Tagging-Strategie am Editor.
Ich halte das mit dem Sortieren undso eigentlich für relativ intuitiv, zumal der Editor in JOSM einen dabei ja auch jetzt schon unterstützt. Viel mehr braucht es meines Erachtens auch nicht.

Zur Länge von Plattformen und Stop-Positionen: Das Argument mit der Berechnung der Wegezeit und dergleichen zählt nicht, wenn nicht die Plattform benutzt wird, sondern der PIO. Bisher hat man nur nicht zwischen beiden unterschieden. Den Gedanken, diese dritte Information, die nun hier PIO genannt wird, irgendwie mit aufzunehmen, geistert mir auch schon seit Jahren im Kopf rum. Ich sehe nur (noch) nicht, dass man dafür ein neues Konzept braucht. Wie gesagt, die Stop-Position der Fahrzeuge ist für die meisten Datennutzer ziemlich unerheblich. Und der Rest hat in der Regel weiterführende Informationen zur Verfügung wie Fahrzeuglänge und dergleichen und kann sich mit einer genormten Position (wie z.B. übliche Mitte oder auch der Anfang, der bei Bahnen oft sogar beschildert ist) weiterhelfen. Ob eine Verbindung zur Plattform wirklich nötig ist … ich glaube nicht. Dann müssten wir ja auch eine Line zu jedem Gebäude zeichnen, um ein Routing zur Hausnummer zu ermöglichen. Macht kein Mensch (hoffe ich), weil es nicht nötig ist. Und die Stop-Position wird in den meisten Use-Cases auch nicht vorkommen.

Ich plädiere nochmal dafür, Beispiele zu erzeugen. Vielleicht schaffe ich es ja sogar, selber eins beizusteuern, an dem man sich austoben kann

[Weide]

@krza

Da stimme ich allerdings komplett zu. Ich hatte von Unstimmigkeiten gelesen, aber grundsätzlich sollte es nur 1 “Wahrheit” geben. Will das hier nicht weiter vertiefen, darüber wurden schon Abhandlungen verfasst, glaube ich

Na ja, um so hehre Dinge wie Wahrheit gehts da ja nicht. Nicht mal darum, welche Idee besser wäre. Ich könnte mich ohne Weiteres mit der Idee anfreunden, dass der stop verpflichtend wäre. Damit hätten wir ein Problem weniger.

Nicht anfreunden kann ich mich mit der Behauptung, dass das PTv2 wäre. Denn dadurch haben wir jetzt zu einem Datensatz (Beispielrelation 934910) zwei Interpretationen. Nach einer hat der Bus 28 Haltestellen und nach der anderen 2. Das macht die Daten weitgehend wertlos.

[Weide]

@krza

Ehm, was genau habe ich nicht oder zu flüchtig gelesen? Ich kann mich düster erinnern, etwas über Marker undso in dem Paper auf gafte gelesen zu haben, aber schon damals hatte ich es nicht wirklich verstanden, zumal aussagekräftige Beispiele fehlen. oder gibt es inzwischen welche?

Es gibt welche.

Das liegt an mir. Ich hätte deutlicher machen sollen, dass diese Papiere sehr veränderlich sind. Vor kurzem waren da noch Segmentrelationen statt der Auftrennung durch Marker sowie andere oder keine Beispiele.

Die Segmente sind übrigens wieder rausgeflogen weil sich in Tests (natürlich nicht im OSM-Datenbestand) herausgestellt hat, dass ich mit dem Erfinden von benutzbaren Segmentbezeichnern im praktischen Editierbetrieb überfordert war.

[Weide]

@krza

Übrigens kannst man sich das Auswählen des Weges (leider) sparen, da diese Operation nur auf Knoten wirkt.

Nein. Gerade ausprobiert:
Node 213444181 mit “Datei” “Objekt herunterladen” laden
Den langen Way selektieren.
Alt+Ctrl+D läd jetzt 5 Relationen, die diesen Weg enthalten und vorher nicht da waren.

@krza

Wählst man also die Endpunkte aus, werden auch nur die dort angeschlossenen Wege nachgeladen, nicht aber diejenigen, die zwischen diesen Punkten mit dem Weg verbunden sind.

Ja, das ist Absicht.

@krza

So solltest Du das nicht formulieren, also ohne zu sagen, was eigentlich passiert und warum das Böses verhindern sollte.

OK:

In einer Relation stehen drei Wege hintereinander:
A
B
C
Jetzt spaltet man B auf und da steht
A
B1 (das ist der Teil, der an A grenzt)
B2 (das ist der Teil, der an C grenzt)
C
In einer anderen Relation (z.B. Gegenrichtung) steht
C
B
A
Dann muss in dieser nach dem Aufspalten von “B”
C
B2
B1
A
stehen.

Man kann also nicht einfach “B” überall durch “B1”,“B2” ersetzen, denn es könnte genausogut “B2”,“B1” richtig sein. Man muss in jeder betroffenen Relation nachsehen, welche Nachbarelemente das B hat. JOSM macht das aber nur soweit die Daten schon geladen sind, sie werden also nicht automatisch beschafft.

Alle betroffenen Relationen zum Weg und alle brauchbaren potentiellen Nachbarelemente bekommt man, wenn man den Weg und seine beiden Endpunkte anwählt und Alt+Ctrl+D macht, denn das läd alle referenzierenden Objekte zu den drei gewählten. Nur wenn die Relation an der Stelle sowieso schon kaputt war, wird dann vielleicht falsch eingefügt.

[Weide]

@krza

PS: Weide, das Ctrl+Alt+D taucht in keinem Menü auf, oder habe ich es immer übersehen?

Huch. Ich finde es jetzt auch nicht. Ich habe den Tipp hier aus dem Forum … ist lang her. Ich hatte irgendwann hier geschrieben, dass ich eine “Millimeterumgebung” um die Endpunkte lade und jemand sagte mir dann “Nimm doch Alt+Ctrl+D”. Seitdem ist das meine wichtigste Tastenkombination

[krza (Kristian)]

Hi Weide, danke für die Erwiderungen.

Die “Wahrheit” hatte ich ja bewusst in Geflügelfüße gesetzt. Ich finde auch die Einheitlichkeit am wichtigsten, auch wenn sie natürlich am einfachsten umzusetzen ist, wenn sie der eigenen Vorstellung entspricht

Bei den Beispielen … hatte mir schon gedacht, dass es veränderliche Versionen gibt. Vielleicht wäre eine Wiki dazu besser geeignet, zumindest zum Auslagern von Zwischenständen, Diskussionen und Beispielen. Wikis haben allerdings leider auch das Problem, dass man sie kennen muss. Zufällig kommt man selten auf eine drauf, und die Suche ist auch nicht immer hilfreich.

Zur Tastenkombination: Achso, ich wusste nicht, dass es um das Nachladen von Relationen geht. Ich nahm an, dass es nur die Objekte betrifft. Okay, dafür hatte ich ein ungünstiges Beispiel ausprobiert, das keine enthielt. Unterstreicht aber meinen Einwand mit dem Formulieren Ich werde mir die TK jedenfalls auch merken. Habe sie eben übrigens immerhin in einer JOSM Wiki gefunden, wobei auch hier die Sprache wichtig ist: In der deutschen Version steht da nur “Verweise herunterladen …”, in der englischen immerhin ein verlinktes “Download parent ways and relations”, und dort ein Hinweis auf´s File-Menü … dort hatte ich gar nicht geguckt, aber es ist tatsächlich drin, und das bedeutet, dass man es sich auch als Symbol in die Leiste legen kann*. Und es bedeutet, dass ich es schon genutzt hatte, ohne allerdings die TK zu erkennen Denn genau für die saubere Bearbeitung von Relationen ist das eine unerlässliche Funktion, da kann ich nur zustimmen.

*) Nur das Icon ist etwas unglücklich, weil es dasselbe ist wie zum normalen Daten-Download. Aber man muss es sich ja nicht genau daneben legen und kann notfalls auch die TK ändern.

[slhh]

@Weide

Nicht anfreunden kann ich mich mit der Behauptung, dass das PTv2 wäre. Denn dadurch haben wir jetzt zu einem Datensatz (Beispielrelation 934910) zwei Interpretationen. Nach einer hat der Bus 28 Haltestellen und nach der anderen 2. Das macht die Daten weitgehend wertlos.

Die Behauptung, dass das PTv2 wäre, erscheint mir noch das kleinste Problem zu sein, da die PT-Version nicht zwingend getagt wird.
Das eigentliche Problem ist, das man eine Änderung gemacht hat, die zu einer falschen Interpretation vorhandener Daten führt. Dass die Änderung dann auch noch nur in einer Sprache dokumentiert ist, beschränkt zwar die Ausbreitung des Problems regional, ist ansonsten aber besonders destruktiv.

Hätte man für weitere platforms eine “+platform”-Rolle oder ähnliches verwendet, wäre das zwar auch formal wohl kein PTv2 mehr, ein wesentliches Problem hätten wir aber nicht.

[Weide]

@krza

Ich erinnere mich an Diskussionen, ob Relations zum Gruppieren genutzt werden sollen oder nicht. Ich sage ganz klar: Ja, denn es sind auch Relationen, die damit beschrieben werden. Meine private und vor allem auch berufliche Erfahrung sagt mir aber auch, dass eine Gruppierung auf der Basis von individuellen Namen eine Katastrophe wäre. Das geht gar nicht. Genau mit sowas erzeugt man Fehler ohne Ende, und bei OSM kommt noch hinzu, dass es sich überhaupt nicht richtig warten lässt. Hier gibt es für mich nur eins: Relationen. Die sind robust und einfach zu handhaben.

Ja, ich habe selbst ein Problem damit, die stop_area und die stop_area_group rauszunehmen und würde gern die Tags “operator” und “network” durch Relationen ersetzen und “vrr:wabe” und ähnliche durch Flächen.

Aber die stop_areas werden zwar gut angelegt aber gehen bei der Pflege (oder Nicht-Pflege) oft kaputt. Eine unzutreffende stop_area ist aber für die Auswertung meist schlechter als garkeine. Die Renderer neigen garnicht dazu, sie zu benutzen. Man lastet den nicht an ÖPV interessierten Mappern zusätzlich zum Mappen der Haltestelle jedesmal die Pflege einer Relation auf. Die kleinen Namensabweichungen, die die Zusammenfassung bei Network und Operator so schwer machen, treten aber bei der Zusammenfassung von Einzelhaltestellen seltener auf, da schon vorhandene Namen aus der Umgebung oft in den Editoren zu den Vorschlägen beim Eintragen gehören.

Ich bin da bei der Gesamtabwägung zum Ergebnis gekommen, dass zwei zusätzliche Relationstypen zu wenig bringen und habe sie wieder rausgeworfen. Man könnte sie aber wieder reinnehmen.

[Weide]

@krza

• die Positionen, an der ein Fahrzeug hält (stop_position)
• die Position, an der Fahrgäste warten (platform)
• die Position, an der Fahrgäste das Fahrzeug bzw. den dafür vorgesehenen Zubringerweg betreten (pio)

Letzteres finde ich etwas irreführend. Ich würde eher sagen
• die Position, zu der die Fahrgäste zum Einsteigen oder ab dem Aussteigen geroutet werden sollten

Dabei wird (für mich jedenfalls) deutlicher, dass es fast immer mit einem der beiden anderen zusammenfällt und es nicht um Zubringerwege geht.

[Trockennasenaffe]

Ich habe mich mit den Ptv3 Linien auseinander gesetzt. Leider verstehe ich die nicht ganz glaube ich. Im Grunde wie Ptv2 aber da werden irgendwie Nodes als Marker eingefügt, und dann ist die Relation auch ohne Sortierung eindeutig? Wie genau müssen die Marker gewählt werden?

[Weide]

@Trockennasenaffe

Im Grunde wie Ptv2 aber da werden irgendwie Nodes als Marker eingefügt, und dann ist die Relation auch ohne Sortierung eindeutig?

Ja.

@Trockennasenaffe

Wie genau müssen die Marker gewählt werden?

(Erstmal einer vorn und einer hinten damit man auch unbekannte Stücke am Anfang oder Ende darstellen kann. Das ging in PTv2 nicht.)

Die anderen braucht man die Marken zum Trennen der Abschnitte. Ein Abschnitt ist entweder ganz leer (er fehlt also) oder er bildet einfache Linie zwischen den Marken, die sich selbst nicht berührt und in der nichts fehlt.

Bei vielen Buslinien hat man nur einen Abschnitt.

Wenn eine Schleife drin ist, dann kommt eine Marke in die Schleife, dann enthält keiner der beiden Abschnitte eine Mehrdeutigkeit in der Reihenfolge.

So kann immer innerhalb jedes Abschnitts automatisch sortiert werden. Splitten einer Linie an einem Punkt ist kein Problem mehr. Längssplitten einer Linie in zwei parallele oneways fällt sofort auf. Verkürzen einer Linie oder Zusammenfassen mit bisher nicht dazu gehörenden fällt ebenfalls sofort auf. Falsche Einbahnstraßenbenutzung ebenfalls.

[Trockennasenaffe]

@Weide

Wenn eine Schleife drin ist, dann kommt eine Marke in die Schleife, dann enthält keiner der beiden Abschnitte eine Mehrdeutigkeit in der Reihenfolge.

So kann immer innerhalb jedes Abschnitts automatisch sortiert werden. Splitten einer Linie an einem Punkt ist kein Problem mehr. Längssplitten einer Linie in zwei parallele oneways fällt sofort auf. Verkürzen einer Linie oder Zusammenfassen mit bisher nicht dazu gehörenden fällt ebenfalls sofort auf. Falsche Einbahnstraßenbenutzung ebenfalls.

Ok hier war mein Denkfehler: Die Wege und Knoten müssen weiterhin sotiert sein. Nur wenn zwischen zwei Knoten etwas durcheunander gerät, kann es so wieder automatisch sortiert werden. Man kann aber nicht die knoten und wege beliebig durcheianderwürfeln.

[krza (Kristian)]

Das ist mir zu hoch Jedenfalls so in Textform.

[Weide]

@krza

Das ist mir zu hoch wink Jedenfalls so in Textform.

In Punkt 1.4 der Intro ist ein Beispiel. Das ist allerdings zugegebenermaßen mit heißer Nadel gestrickt, weil ich die neue Fassung ohne Segmentrelationen nicht ohne Beispiele machen wollte. Da ist bestimmt noch Luft für Verbesserungen…

[Weide]

@Weide

Da ist bestimmt noch Luft für Verbesserungen…

Ein paar Verbesserungen (hoffe ich jedenfalls) habe ich gerade auf gafte.de hochgeladen. Die “-in” und “-out” suffixe für "pio"s sind auch drin (allerdings nicht in der Intro).

[Trockennasenaffe]

Eine gute Erläuterung ist essentiell für die Akzeptanz. Wenn es ernster wird am besten auch noch auf deutsch.

[miche101]

@Trockennasenaffe

Eine gute Erläuterung ist essentiell für die Akzeptanz.

…nicht nur das, aber auch wichtig!

Man braucht auch Anwendungen dazu, wo man sieht was man damit alles tolles machen kann. So fantastische Dinge Wo man sagt: “Ja, cool… was da alles geht… das will ich auch!”

Daran mangelt es… für das was heute geht genügt PTv1 ein Netzplan…

[Trockennasenaffe]

Ich habe mich in letzter Zeit viel mit freien Verkehrsdaten beschäftigt. Ich stelle mir da die Frage, nach dem Zusammenspiel mit PTv3. Auf der einben Seite geben immer mehr Unternehmen ihre Daten frei. Auf der anderen Seite wissen wir, dass Erfassung und Pflege von ÖPNV Daten in OSM sehr aufwendig ist und daher nur von wenigen gemacht wird. Ich denke daher, dass der Erfolg vom PTv3 auch entscheident davon abhängen wird, in wieweit man die Freien Daten dazu nutzen kann. Dazu müssten die Konzepte zusammenpasst. Bei Bushaltestellen gibt es meist Daten zu Haltestellenmasten. Das sind die Schilder die die Halteposition markieren. Davon gibt es meistens mehrere pro Haltestelle. Die haben in der Regel Koordinaten und diverse globale und lokale Referenznummern. Das ließ sich mit PTv2 als public_transport=Platform als node moderiere. Bei aussteigen mit mehreren Masten oder räumlich sehr ausgedehnten gab es da aber schon ein Problem. Wie sieht das mit PTv3 aus?

Zu den anderen freien Daten schreibe ich ein andermal etwas.

[krza (Kristian)]

Wie schon oben gesagt: Die Masten halte ich persönlich für völlig überflüssig. Die Positionsinformation stellt keinen Mehrwert für die Haltestelle selbst dar. Wenn man die Masten aus irgendeinem Grunde taggen möchte, dann sollte man ein Tag verwenden, das explizit einen Mast bezeichnet. Mit Plattformen, Ausstiegen, Haltepositionen haben die Dinger aber für gewöhnlich nichts zu tun. Dann stünden sie in vielen Fällen auch ziemlich im Weg. Meine kleine Meinung. Aber ich stimme TNA insofern zu, dass kompatible und konsistente Systeme entstehen müssen.

Bezüglich Akzeptanz und Beispielen … ich habe die Beispiele in Revision 1984* der Introduction nochmal ganz kurz überflogen. Im Zusammenspiel mit den Texten von weiter oben dämmert es mir langsam. Ob ich den Aufwand-Nutzen-Vorteil schon sehe … hm. mal gucken. Spontan macht es die Sache für mich unnötig komplizierter, wenn es nur um das Sortieren geht. Man muss nämlich noch mehr aufpassen und nicht weniger.

*) uuh … was will uns der Autor damit sagen …