ÖPNV Bus stop_position

Warum wird die “stop_position” bei Bushaltestellen auf der Straße getaggt?
Für mich nur verständlich als vereinfachte Version, wenn man nicht pro Richtung eine Haltestelle (“platform”) neben der Straße einzeichnen möchte.
Es ist damit keine zusätzliche Information vorhanden, mit Bus-Routen hat man doppelte Arbeit, um sowohl “stop_position” als auch “platform” einzusortieren und in der Public-Transport Sketch-Line tauchen die Haltestellen doppelt auf.

Damit Router wissen wo die Bushaltestelle ist. Das kann der nicht wissen wenn sich der Node neben der Straße befindet, weil er dann irgendeine Heuristik bräuchte um festzustellen welche Straße dem Node am nächsten ist und da kann es gerade in städtischen Gebieten viele false positives geben, oder auch das Gegenteil der Router merkt gar nicht dass er schon längst an der Bushaltestelle vorbei ist.

stop_position ist die Halteposition des Busses (auf der Straße), platform ist dort wo der Fahrgast z.B. wartet (neben der Straße).
Beides ergänzt sich also und beschreibt zwei verschiedene Dinge.

Die Sketchline müsste so geändert werden, dass wenn beides vorhanden ist, die Haltestelle trotzdem nur einmal auftaucht.

Welcher Router arbeitet denn mit Bushaltestellen?

Dieses ist für mich nur ein virtueller Punkt, der von der Position der platform abhängig ist und somit keine zusätzliche Information.

Zum Beispiel die Anzeigen in den Bussen, die sagen, welche Haltestelle die nächste ist. Es ist nicht undenkbar, dass solche Anwendungen heute oder auch in Zukunft auf OSM-Basis arbeiten werden.

Die Public-Transport Sketch-Line ist einfach kaputt. Es wird behauptet, dass sie Public-Transport v2 kann, tut sie aber nicht und dass schon seit einer Ewigkeit.

Die Stopposition liefert in einigen Fällen durchaus zusätzliche Informationen. Bus- und Bahnsteige können recht lang sein und manchmal kann vorne oder hinten gehalten werden oder auf beiden Seiten. Es ist zudem nicht zwingend erforderlich, sowohl plattform als auch stop-position zu mappen um PTv2 kompatibel zu sein. Es reicht eins von beiden und kann bei sehr einfachen Verhältnissen auch sinnvoll sein.

Das aktuelle “public-transport”-Schema wurde meines Wissens nach mit dem Ziel entwickelt, weitergehende Routingfähigkeit für Verkehrsunternehmen und Verbindungsauskunftsanwendungen zu bieten, was bisher nur mit zusätzlichen, meist proprietären Daten möglich ist. Soweit ich weis wird davon allerdings noch nirgendwo in nennenswertem Umfang gemacht und es ist auch unklar, ob das Schema dafür besonders geeignet ist, da sich noch kein Verkehrsunternehmen oder Anwender dazu geäußert hat. Falls ich da falsch liege bitte korrigieren.

Ohne deine Route jetzt im Detail zu kennen, klingt es für mich danach, dass du “highway=bus_stop” und “public_transport=platform” an einem und dem selben Node getaggt hast. Das mag das Line Diagram leider nicht, da er als erstes alle “highway=bus_stop” intern zu einem “stop” übersetzt.


Nur Node "pt=stop_position" => OK
Nur Node "pt=platform" => OK
Node "pt=stop_position" und Node "pt=platform" => OK
Node "pt=stop_position+ hw=bus_stop" und Node "pt=platform" => OK
Node "pt=stop_position" und Node "pt=platform + hw=bus_stop" => FEHLER

So wird es sein. Das ist gängige Praxis und zulässig, solange es nur ein highway=bus_stop pro platform/stop_position-Paar gibt. Wenn es beides gibt, gehört das dann optionale highway=bus_stop sogar an die platform-Node. Wenn die Software damit nicht klar kommt, ist sie fehlerhaft.

Ja. Da ist viel überflüssig. Das ist geschichtlich gewachsen und es haben sich Missverständnisse etabliert.

Es gab damals nur den “highway=bus_stop”-Node. Wenn der nur für eine Richtung war, dann haben einige Mapper ihn damals neben die Straße gelegt und andere haben ihn mit einem “direction=NW” oder “dir=NW” drauf gelassen. Außerdem kamen Mapper auf die Idee, die Objekte neben der Straße als Linie oder Fläche zu mappen, was mit den damaligen Routen einfach nicht ging weil alle Haltestellen da Nodes sein mussten. Also hat man beim Neuentwurf daraus zwei Objektarten gemacht: “stop” und “platform”. Diejenigen, die Objekte neben die Straße legen wollten, konnten sie mit der Rolle “platform” in die neuen Routen eintragen und diejenigen, die sie auf die Straße legen wollten, konnten sie mit der Rolle “stop” eintragen. Wenn jemand das jeweils andere Objekt ergänzen wollte, dann konnte er ja nicht ein zweites highway=bus_stop nehmen. Deshalb wurde zusätzlich public_transport=platform bzw. stop_position definiert. In die alten Routen kam aber immer nur der highway=bus_stop-Node mit keiner Rolle oder der Rolle “stop”.

Das war eigentlich nicht schlecht, es kam aber zu Missverständnissen. Manche meinten, dass man das alte Tag durch die neuen ersetzen müsste oder dass überall die neuen Tags zusätzlich dran müssten oder dass überall beide Angaben zu einer Haltestelle gemappt sein müssten oder dass das highway=bus_stop nur noch das Haltestellensymbol aber keine Haltestelle definiert. Das ist alles falsch! Insbesondere ist highway=bus_stop immer ein Node und kann als “stop” oder als “platform” benutzt werden.

Diese Missverständnisse haben zu vielen überflüssigen Einträgen geführt. Sehr oft haben wir zwei stop_positions, zwei platforms und eine zusammenfassende stop_area-Relation, die insgesamt kein bischen mehr sagen als ein einfacher Node auf der Straße, der nur highway=bus_stop und name=xxx hat.

Weide

Es gibt tatsächlich auch noch den exotischen Fall, dass er ausnahmsweise nicht dahin gehört. Wenn zwei Platforms sich denselben stop teilen und eine platform kein Punkt ist, dann kann das highway=bus_stop nur an den stop-Node. Dann kann er aber für die Gegenrichtung nicht mehr an den platform-Node.

Weide

Diese Missverständnisse sind ja hauptsächlich dadurch entstanden, dass dies so nirgendwo verständlich dokumentiert war. Deshalb habe ich in diesem Bereich viele Fehler gemacht (und mache sie wahrscheinlich immer noch).
Mir war bisher nicht klar, dass “highway=bus_stop” und platform als doppelte Haltestelle erscheinen, wenn wenn platform als way und bus_stop in diesem way als node eingetragen ist.

Dieses Durcheinander lässt mich eigentlich nur wieder dafür plädieren, auf bus_stop ganz zu verzichten und sich nur noch auf ptv2 zu konzentrieren oder aber sich wirklich mal dran zu setzen und eine pt-Version zu konzipieren, die alles andere ersetzt und zukunftsfähig ist.

Wenn ich mich recht erinnere, hattest Du mal an einem ptv3 gearbeitet. Davon hört man leider gar nichts mehr. Grund ist wohl auch, dass man versucht auf v1 und v2 Rücksicht zu nehmen, statt vollkommen NEU zu konzipieren, statt sie über längere Zeit parallel lassen zu können. Ja, das gäbe bei älteren Auswertungstools sicherlich Probleme, aber ein langfristiger sukzessiver Austausch von v1 und v2 mit v3 oder v4 wäre sicherlich möglich.

Bin auch der Meinung, wenn etwas bei ÖPNV passieren soll (Aktualität) dann sollte ein “System” anwendungsbereit dokumentiert werden. Somit würden auch schnell alle ptv1 aktualisiert werden. Gibt es überhaupt Nutzer von ptv1?

Das ist echt schwierig: Man steht dann als dann als Kartenersteller auf dem Schlauch. Die Haltestelle sollte dargestellt werden. Es kann nur ein stop da sein, es kann nur eine platform da sein, es können aber auch beide da sein. Die Pärchen sind aber nur in den Routen erkennbar. Vor Ort können auch zu einem stop zwei platforms gehören oder umgekehrt. Sogar 1:3- und 1:4 - Beziehungen können vorkommen. Da ist es viel einfacher, das Symbol an das highway=bus_stop zu machen.

Ja. Seit unserem Treffen in Dortmund vor zwei Jahren damals habe ich es aber deutlich vereinfacht (hoffe ich jedenfalls :slight_smile: ). Es liegt auf http://gafte.de/

Im Prinzip werden dabei die alten Sachen komplett neu hinzugefügt und die alten Sachen werden als ersetzt markiert, so dass das Neue von Anfang an angezeigt werden kann ohne dass irgendwas doppelt dargestellt oder doppelt ausgewertet wird.

Reaktionen habe ich gar keine – weder positiv noch negativ – was mich vermuten lässt, dass ich mal wieder nicht ausreichend verständlich formuliert habe :frowning:

Nicht viele, aber es gibt sie. Wir haben mancherorts Altbestände und aus ein bischen Wissen über die Buslinie (“Der fährt hier durch und biegt da hinten recht ab”) kann man einigermaßen leicht eine PTv1-Relation machen oder ergänzen. Bei PTv2 sind “Informationsschnipsel” schwer zu verarbeiten. Manche Leute haben aber auch einfach die Nase voll von der ganzen Verwirrung und nehmen deshalb das alte Schema.

Ja. Aber das ist – für mich jedenfalls – ein echt frustrierendes Thema. Es tauchen ständig mit PTv2 unvereinbare Dinge in den Wikis als PTv2-Eigenschaften auf. Da wird nachträglich der Abstimmungstext von PTv2 geändert, bei railway=station steht drin, man könnte da public_transport=station hinzufügen, im public transport wiki steht “Stops sind Pflicht”. Ich mache da nichts mehr und mappe auch nicht mehr in Gegenden und Bereichen, in denen es Konflikte gibt.

Weide

Gibt es denn derzeit eine Wiki, die einen “korrekten” PTv2-Ansatz beschreibt? Hier kann man sicher darüber streiten, was “korrekt” ist, aber es muss ja mal eine Basis-Idee gegeben haben. Ich selbst hatte damals ein paar Buslinen in Köln auf PTv2 umgestellt, die ich teilweise Jahre zuvor mit vermutlich PTv1 oder sonstwie getaggt hatte. Dafür nutzte ich eine entsprechende Wiki, die ich für ziemlich eingängig und simpel und damit gut umsetzbar hielt.

Die ganzen oben genanngen Konflikte zwischen den Nodes undso kann ich ehrlich gesagt auch kaum nachvollziehen. Allerdings muss ich zugeben, dass ich bewusst oder unbewusst offenbar auch beides gemacht habe: highway=bus_stop und public_transport=stop_position. Letztlich halte ich ersteres aber auch für überflüssig.

In dem Zusammenhang kann ich auch dem Argument mit dem Schlauch unter dem Kartenhersteller nicht ganz beipflichten, denn wenn Halte- oder Wartepunkte teilweise über hunderte Meter verstreut liegen und trotzdem zur selben Haltestelle gehören, wird es ohnehin schwierig mit einem Symbol. Solange semantisch sauber gemappt wird, kann man als Renderer (was ich jetzt mal mit dem Kartenhersteller gleichsetze) auch eine bestmögliche Lösung herausholen. Diese kann aber nicht besser sein als das Mapping. Und wenn man relationen braucht, dann muss man die halt auch nutzen, und zwar auf der Mapperseite und auf der Auswerterseite. Dazu sind sie da, auch wenn sie einmalig etwas Mühe machen können. Dass sowas funktioniert, sieht man ja jetzt schon auf einigen Karten.

Naja, und irgendwann kommt halt der Punkt, an dem ein Renderer auch mal eine überkommene Konvention über Bord wirft. Dann wird PTv1 eben nicht mehr unterstützt. Na und? Man wird es merken und sich ranmachen, um es datenseitig auf Stand zu bringen. Ist doch in Ordnung. Das passiert doch alle Nas lang, und davon lebt OSM ja auch ein Stück weit.

Ich kenne nur http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726
Die Wikis verändern sich recht häufig…

Da sollen ja auch mehrere Symbole hin. Nehmen wir eine Kreuzung mit vier Eine-Richtung-Haltestellen an den vier abgehenden Straßen. In manchen Maßstäben sollten dann vier Symbole auftauchen. Dabei können aber durchaus zwei der Halte als “stop” und “platform” und einer nur als “stop” und einer nur als “platform” angegeben sein. Da sind dann insgesamt drei “stop”-Angaben und drei “platform”-Angaben und daraus müssen vier Symbole werden. Das ist schon ein Problem. Da ist es viel einfacher, die vier Nodes mit highway=bus_stop darzustellen.

Das mit dem STOP-Area hat immer ein ganz hohes Konfliktpotenzial. Gerade dann, wenn zwei gegenüberliegende Haltestellen weit auseinander liegen. Im VRR gibt’s dann manchmal sogar 2-3 Stop-Areas für die gleiche Haltestelle, ich halte davon nix. Die Router sind inzwischen intelligent genug, von einem Haltestellenmasten oder eine Plattform den korrekten Punkt auf der Straße zu ermitteln (das wird mit den Gebäuden ja genauso gemacht).

Leider wurden im Rahmen der Mentz-Datenverarbeitung (hehe, was ein Wortspiel) ein Großteil der Masten z.B. bei uns ein Dortmund vernichtet. Kein Kommentar.

Nach meiner Erfahrung ist das ziemlich selten. Ich hab so einen Fall mal vor längerer Zeit in Wuppertal-Oberbarmen gesehen. Gibt es Gegenden wo das oft vorkommt?

Den Zusammenhang mit den stop_areas verstehe ich nicht.

Ich kenne kein Tag für Masten.