u. a. im Bereich Ennepetal wurden jüngst durch einen User viele highway=bus_stop entfernt. Die Haltestellen wurden auf PTV 2 “umgestellt” und es wurden viele Busrouten ergänzt, was natürlich vorteilhaft ist. Jedoch halte ich highway=bus_stop für die Rückwärtskompatibilität immer noch relevant. Es geht ja nicht nur um die Darstellung auf Carto, sondern z. B. auch um die in der Verkehrskarte oder in OSMAnd.
Ich hatte versucht, dem User in https://www.openstreetmap.org/changeset/80448633 zu erklären, dass highway=bus_stop sich als Node eig. ganz gut mit public_transport=platform verträgt, zugegeben sollte man ihm vielleicht Zeit zum Lesen lassen. Allerdings ist mir aufgefallen, dass er auf ältere Kommentare anderer User nicht reagiert hat.
Sollte man highway=bus_stop auf den Nodes wieder ergänzen?
Auf alle Fälle ja, damit arbeiten noch viele Karten.
https://wiki.openstreetmap.org/wiki/DE:Key:public_transport
highway=bus_stop (Dieses ältere Tag ist trotzdem notwendig, da sonst die Bushaltestelle momentan nicht auf der Hauptseite gerendert wird.)
EDIT: Habe ihn (lmk) hierher eingeladen.
“Umstellen auf PTv2” gibt es bei Routen aber nicht bei Haltestellen, da alle alten Haltestellen voll und ganz und ohne jede Ergänzung durch “public_transport=…” zu PTv2 gehören. “highway=bus_stop” ist nicht PTv1 – es ist PTv1 und PTv2.
Wenn damit allerdings gemeint ist, dass ein Way mit “public_transport=platform” einen Node mit “highway=bus_stop” enthält, dann ist das falsch. PTv2 sagt sehr klar, dass beide PTv2-Platforms sind und dass alle gemappten Stops und Platforms in die Routen müssen. Dann würde das Fahrzeug dort aber zweimal halten. Man darf in PTv2 Platforms nicht doppelt mappen.
Das ist vollkommen richtig, passiert aber leider auch noch viel zu häufig.
Ansonsten danke für euer Feedback und danke an geri-oc für die Einladung des Users hierher. Ich werde evtl. noch ein paar Tage abwarten und würde dann ansonsten mit Verweis hierauf mit dem Wieder-ergänzen beginnen.
platform ist nicht notwendigerweise der Bereich wo das Fahrzeug hält sondern der Bereich wo die Fahrgäste warten.
Abgesehen davon sehe ich es auch so, highway=bus_stop ist für Bushaltestellen das etablierte tagging und wird es vermutlich auch bleiben, also bitte nicht löschen.
Aber zum Thema highway=bus_stop und pt=platform und Deiner Aussage:
highway=bus_stop und pt=platform auf ein und demselben node ist erlaubt und auch für PTv2 problemlos.
pt=platform auf way und highway=bus_stop auf einem dessen nodes ist zwar semantisch zwei Taggings für ein und dasselbe Objekt und so gesehen unschön, aber:
Ich verstehe nicht, warum doppelt gemappte platforms (highway=bus_stop auf node und pt=platform auf way) unbedingt auch doppelt in die Relation eingetragen werden müssen.
Warum kann dort nicht die pt=platform in die Relation und der highway=bus_stop unabhängig für den Renderer bleiben?
Für die Auswertung der Route von PTv2 ist das dann doch eindeutig!
Klar, es müssen alle gemappten stop und platform in die Route, damit sie von der Route erkannt werden - aber das bedeutet doch nur, dass die Platform als Objekt in die Route muss - nicht aber zwingend alle Ihrer Tagging-Varianten.
Problematisch ist es doch nur für einen Renderer (bzw. den Betrachter), wenn er irgendwann sowohl highway=bus_stop als auch pt=platform rendern wird …
Genauso wäre es natürlich auch möglich, highway=bus_stop auf einem way zuzulassen - und der Renderer müsste dann eben sehen, wo er das Symbol hinpackt …
Und (wegen PTNA) mal die QS/QA-Brille aufgesetzt: Ich bevorzuge bei ‘role’ = ‘platform’ einen Node, da wir bereits und in Zukunft vermehrt CSV/GTFS-Daten bzgl. der Positionen von Haltestellenschildern bekommen (werden).
Ein ‘role’ = ‘platform’ Node erlaubt dann einen genaueren Abgleich zwischen ‘unserer’ und ‘deren’ Haltestelle was die Abweichgung in Metern angeht.
der Erklärt die Probleme die dabei gibt ganz vielfälltig… möchte fast sagen das Ganze pt=* ist für die Tonne, weil schlecht auswertbar und völliges durcheinander, mapper kommen damit nicht zurecht, jeder taggt anders. Außerdem sollte highway=bus_stop nie ersetzt werden Einfach mal lesen…
Es geht schon mal los bei der Plazierung des Symbol… die einen wollen es auf der Straße die andern nicht. Wobei ich bei den Entwicklern bin und es auch nicht auf der Straße haben möchte.
Sinnvoll wäre ein Kompromiss zu finden… und ptv2 in der jetzigen Form sterben zu lassen Aber die Fronten sind so verhärtet das dass mit dem rendern in den nächsten (x)-Jahren nix wird
Also wenn unser Ziel ist dass mit OSM Linienbusse geroutet werden sollen dann brauchen wir alle Elemente von PTv2, auch die stop_positions. Denn ein Bus kann ohne stop_position nicht wissen ob er die Haltestelle schon erreicht hat. Es reicht nicht einfach zu schauen, wie nahe man an einem highway=bus_stop dran ist denn der kann im Einzelfall (sehr breite Straßen, Busbuchten etc.) recht weit von der Straße so wie sie im OSM-Datenmodell erfasst ist entfernt sein und dann muss der Router im Zweifelfall davon ausgehen dass die Bushaltestelle nie erreicht wird.
Gleiches mit den stop_areas. Zusammenhängende Haltestellen können im Einzelfall sehr weit voneinander entfernt sein (z. B. Hanau Kastanienallee), andererseits gibt es Haltstellen die genau gleich heißen, aber nichts miteinander zu tun haben (in Birstein gibt es die Haltestellen Friedhof (in der Kernstadt) und Friedhof (in Fischborn), ein Router wüsste ohne stop_area nicht dass das zwei verschiedene Haltestellen sind zumal die Buslinien dort beide Haltestellen in einer Fahrt bedienen).
Each direction/variant relation contains all available
stop_positions, platforms and ways.
Each stop is included with two elements (if available): first the stop_position tagged with role stop
and immediately followed by the corresponding platform tagged with role platform.
Hintergrund ist jedoch: Diese Regeln stellen sicher, dass man zu jedem Halteobjekt die zugehörigen Linien einfach in der Datenbank direkt nachschlagen kann. Das doppelt Mappen von Platforms macht eine wichtige Datenbankeigenschaft kaputt.
Stop_positions verpflichtend zu machen widerspricht PTv2. Ich sehe auch keinen Grund, Linienbusse zu routen. Die Fahrer fahren nach den Vorgaben des Verkehrsunternehmens und da werden viele Dinge berücksichtigt, die nichts mit OSM zu tun haben. Wir sollten nicht das Ziel haben, Linienbusse oder Züge etc. zu routen. Das für OSM-ÖPV interessante Routing ist das Routing der Passagiere (Fuß, Rollstuhl, Rad, Auto(bei Fähren), …) beim Umsteigen.
Die PTv2-Idee war ja, bei stop_areas den Namen nur einmal zu rendern und die Einzelteile nur als einfache Symbole/Nummern ohne Namen darzustellen. Aber das hat nicht wirklich funktioniert.
PTv2 hat da Kompromisse gemacht, die sich nicht durchsetzen werden. Es sollten damals nicht sowohl Halte als auch Routen austauscht werden. Daher wurden nur die Routen ausgetauscht und die Haltestellen nur ergänzt. (Lustig: die Gerüchteküche hat genau das Gegenteil angenommen) (Wenn die Route geändert werden muss weil die Haltestelle geändert wurde und die Haltestelle geändert werden muss weil die Route geändert wurde, dann löst man eine OSM-weite Änderungslawine aus)
Ich denke, dass wir an einem PTv4 (PTv3 gibt es ja schon und ich bin dagegen) arbeiten sollten und dabei in den saueren Apfel der Komplettumstellung beißen müssen. Die Änderungslawine muss man dann durch Markieren der ersetzten alten Objekte (“gilt nicht mit PTv4”) verhindern.
-Wer physisch vorhandenes mapped, sollte nicht durch ÖPV-Regeln eingeschränkt werden. Vor allem für die Nichtspezialisten sollte es einfacher werden: Wenn jemand ein Bauwerk Bussteig sieht, dann sollte er es einfach mappen können. Jetzt geht das nicht. PTv2 kann keine mehrteiligen Platforms, die z.B. durch Tunnel, Brücken oder unterschiedliche Höhen gerechtfertigt sind. In Jönköping gibt es physisch klar vorhandene Bussteige an denen aber niemals ein Passagier wartet.
-Es gibt immer mehr just-in-time Bahnsteigzuweisungen. Das würde zu einer unerträglichen Vervielfältigung der Routen führen.
-Manchmal werden zwei Steige gleichzeitig benutzt. Bei Veranstaltungen der Arena/Messe in Düsseldorf gibt es manchmal beidseitigen Ausstieg. In Japan gibt es IFAIK Einstiege von einer Seite und Ausstiege auf der anderen mit gegeneinander versetzten Türen.
-Es gibt unterschiedliche Steige für unterschiedliche Passagierarten. Bei manchen Fähren (z.B. Langeoog) warten Radfahrer woanders als Fußgänger. Bei Autofähren ist es auch so.
-PTv2 kann fehlende Stücke am Anfang und Ende nicht von kürzeren Routen unterscheiden.
-Man kann es schaffen, dass jeder Splittingfehler bei Wegen zu einer Fehlermeldung führt. Das ist jetzt nicht so.
-für eine Brauchbarkeit im Zusammenhang mit Reiseauskünften brauchen wir die Möglichkeit, Teilbahnsteige anzugeben. Wer wissen will, wie lang er in Duisburg Hbf zur U-Bahn braucht, dem nützen Platform und Gleisnummer einfach garnichts (weil die Doppelstockzüge und Triebwagen viel viel kürzer sind als die Bahnsteige und nicht unbedingt in der Mitte halten.)
Vielleicht ist ein radikaler Bruch einfacher zu vermitteln als viele Regeln “das bleibt so” aber “das ist anders”. Zumindest hab ich nach den Erfahrungen mit PTv2 diese Hoffnung.
Ptv2 ist auch nicht das gelbe vom Ei 
