vor der Frage kurz zum Hintergrund: Habe bisher nur gelegentlich ein paar Wege ergänzt und korrigiert. Da das Busnetz in meiner Gegend in OSM nicht auf dem aktuellen Stand ist (Haltestellen fehlen, Routen sind falsch), möchte ich mich nun in einer größeren Aktion dem Busnetz widmen. Da spielt auch GTFS rein, was ja gerade einen Schub in PTNA bekommen hat. Alles sehr interessant. Hier aber erstmal nur eine einfache Frage für das manuelle Mappen von Bushalten.
Problem: Für Bushalte gibt es sehr unterschiedliche Mapping-Varianten, insbesondere wenn ein Bussteig vorhanden ist und als Linie mitgemapt werden soll. Wohin mit dem highway=bus_stop, das im Standard-Rendering von OSM das blaue Bushaltsymbol erzeugt?
Variante 1: An die Stopp-Position auf der Straße. Ist unschön, weil dann das Haltsymbol mittig auf der Straße liegt und nicht ersichtlich ist, auf welcher Straßenseite der Halt liegt.
Variante 2: An die Bussteig-Linie. Ist unschön, weil dann kein Haltsymbol gerendert wird. Außerdem ist highway=bus_stop wohl nur für Punkte, nicht Linien gedacht (taucht aber leider gelegentlich an Linien auf).
Variante 3: An einen zusätzlichen Punkt oder an einen Punkt der Bussteig-Linie. Problematisch, wenn sowohl Punkt als auch Linie ein public_transport=platform bekommen. Dann müssten beide in die Routen, was aber in PTv2 nicht vorgesehen ist (auch die Variante findet man in OSM nicht selten).
Ausgehend von Variante 3 schwebt mir folgende Lösung vor, die (aus meiner Anfängersicht) einerseits die tatsächlichen Gegebenheiten vor Ort gut widerspiegelt, andererseits aber auch die Doppelung von public_transport=platform vermeidet:
Auf der Straße eine Stopp-Position (hier nichts ungewöhnlich).
Den Bussteig als Linie mit highway=platform, aber OHNE public_transport=platform.
Einen Punkt am Haltschild (also auf dem Bussteig) mit public_transport=platform und highway=bus_stop und diversen anderen Tags (Name, Ausstattung usw. der Haltestelle).
Frage: Führt dieses Vorgehen irgendwo zu Problemen, die ich (noch) nicht sehe?
Überlegungen zum Warum: Der Bussteig selbst ist nur ein Stück Weg (begehbare Erdoberfläche), hat so direkt nichts mit der eher abstrakten Einrichtung Haltestelle zu tun. Analog dazu ist ein Gehweg (statt Busssteig) unter Haltestellen auch völlig frei von PT-bezogenen Tags. Die eigentliche Haltestelle wird (zu mindest in Deutschland) durch das Schild repräsentiert. Dieses Schild landet dann als Punkt mit den ganzen PT-bezogenen Tags in OSM. Der Bussteig wird als Linie gerendert und bekommt dank des Zusatzpunktes ein Haltestellensymbol. Aus Sicht des Renderings also genau richtig. In den Routen gibt es nur einen Bussteig pro Halt, also auch richtig.
Stören könnte man sich an der Tatsache, dass der eigentliche Bussteig als bauliche Einrichtung dann keinen Bezug mehr zur Gesamthaltestelle hat. Dies könnte man lösen, indem man die PT-Tag-freie Bussteig-Linie in die stop_area-Relation der Haltestelle aufnimmt. Dann ist die Bussteig-Linie einem konkreten (und korrekten) Kontext zugeordnet.
Bevor ich anfange Haltestellen und Routen zu ergänzen und zu korrigieren, würde ich mich über Meinungen zu diesem Vorgehen freuen. Will ja nichts kaputt machen…
A bus stop is a place where passengers can board or alight from a bus. Its position may be marked by a shelter, pole, bus lay-by, or road markings.
[…]
How to map:
A bus stop should be defined for each discrete location where a pole or shelter is placed or where a person should wait for a vehicle. The widely used approach is to place bus stop nodes off to one side of the highway way, and not with the node being part of the highway=* way […]
Ich mappe diesen Node fast immer zwischen Bushaltestellenschild und Straßenrand, da bei mir in der Region die Busse (fast) immer unmittelbar mit der ersten Bustür auf Höhe des Bushaltestellenschildes (plus/minus ca. einen Meter) anhalten.
Wir müssen hier in der Region in der ersten Bustür (beim Busfahrer) einsteigen.
edit:
Zusätzlich public_transport=stop_positionals Node des highway=* way mappen. Imho ca. auf derselben Höhe wie ich oben beschrieben habe.
Wenn der Bussteig nicht als Linie oder Fläche gemapt werden soll, dann ist die Sache klar (so wie von @Map-Peter beschrieben). Mein Problem sind die zwei public-transport=platform, eins an Linie/Fläche, zusätzlich eins am highway=bus_stop-Node.
Das Profi-Beispiel zeigt eine Variante, die ich für mich ausgeschlossen hatte: es gibt eine Fläche mit public-transport=platform und einen Node mit public-transport=platform. Soweit okay. Allerdings wird nur der Node in die Routen aufgenommen, nicht die Fläche. In platform als Linie und highway=bus_stop trotzdem neben der Straße ok? - #10 by axelr schrieb @Weide
PTv2 sagt dazu, dass “beide” in die Route eingetragen werden müssen, sofern sie vorhanden sind. Das geht also nicht.
Das kann ich so direkt nicht aus dem PTv2-Proposal entnehmen, muss also nicht allgemeiner Konsens sein.
Ich würde dann statt meiner Variante die Variante aus dem Profi-Beispiel nutzen. Der Unterschied ist letztlich nur, ob man public_transport=platform an die Linie/Fläche macht und mit der Doppelung lebt oder ob die Linie/Fläche ohne dieses Tag bleibt.
Ich habe die Beschäftigung mit PT in OSM aufgegeben, Aber zu diesem Punkt steht im beschlossenen PTv2-Schema:
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.
So wird sichergestellt, dass jedes Haltestellenelement in allen zugehörigen Relationen auftaucht.
Dazu kommt noch, dass die alten Tags in PTv2 voll gültig bleiben.
Ein railway=platform ist eine PTv2-Platform. Es ist völlig egal, ob da zusätzlich public_transport=platform dran steht. Ein highway=bus_stopauf dem Fahrweg ist ein PTv2-Stop und ein highway=bus_stopneben dem Fahrweg ist eine PTv2-Platform. Auch hier ist es ganz egal, ob man da auch noch public_transport=stop_position bzw. public_transport=platform dranschreibt. public_transport wird bei Bussen nur für Nicht-Punkte benötigt und für zweite Haltestellenobjekte, denn in PTv1 durfte man den highway=bus_stop-Punkt nur entweder auf die Straße setzen (beide Richtungen) oder neben die Straße (eine Richtung) aber nicht beides.
Mein (vielleicht zu hoher) Anspruch an das Mappen von PT trotz der Unklarheiten/Konflikte/Variantenvielfalt ist, dass
geänderte/ergänzte PT-Sachen PTv2-konform sind (ja, nur highway=bus_stop neben der Straße ist auch PTv2-konform).
Der Standard-Renderer die Dinge nutzerfreundlich darstellt, also hier ein Haltestellensymbol mit erkenntlicher Fahrtrichtung zeigt und ggf. auch den Bussteig dazu.
Die Datenbank ordentlich strukturiert ist (ein OSM-Objekt pro Realobjekt).
Mit meiner Variante 3 aus dem Eingangspost ist das alles einigermaßen gegeben. Die Variante 4 (Profi-Beispiel) ist nicht so recht PTv2-konform, da zwei platform-Objekte (ob nun explizit wegen public_transport=platform oder implizit wegen highway=bus_stop neben der Straße ist da erstmal egal), aber nicht beide in den Routen.
Je mehr ich mich in OSM vertiefe, desto mehr komme ich zu der Ansicht (Einsicht?), dass man die Dinge nicht zu genau nehmen darf, sonst wird man depressiv. Ich warte mal noch ein bisschen, ob noch weitere Meinungen reinkommen zu Variante 3 vs. Variante 4. Wenn nichts kommt, nehme ich die 4 getreu dem Motte ‘Falsch darf es sein, aber einheitlich muss es sein’.
Danke für die Blumen Peter. “Profi” aber nur, weil ich mich viel damit beschäftige (Mappen, PTNA, GTFS, …), nicht weil ich meine, dass meinen Meinung “Gesetz” sein muss.
Im Laufe der Jahre habe ich viele Varianten gesehen und mir einen “Reim” daraus gemacht.
Aus Sicht der Passagiere:
Alle Dinge/Objekte, die ich vor Ort sehe und zur Infrastruktur gehören können entsprechend gemapped werden
Haltestellenschild (Node mit …)
Wartebereich kann sein
Node (quasi nichts vorhanden sein, dann mit Haltestellenschild gemeinsam)
Way, die Bordstein-/Bahnsteigkante an der das Fahrzeug zum Stehen kommt
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.
Hier widerspricht sich PTv2 selber: “all available” versus “included with two elements”
Ja, dieser Widerspruch ist nicht schön. Der Gedanke, dass es zwei Objekte mit public_transport=platform geben könnte, wurde bei PTv2 nicht mitgedacht. Zwei solche Objekte sind eigentlich auch nicht nötig. Das Problem ist halt, dass man das highway=bus_stop nicht an eine Linie oder Fläche anbringen kann/soll/darf (wird dann auch nicht als Haltsymbol gerendert) und man somit einen zusätzlichen Node dafür nebst dem eigentlichen Bussteig braucht. Dass die Renderer nicht PTv2 komplett umsetzen können (zu viele unklare Fälle) und damit das highway=bus_stop entfallen könnte, war wahrscheinlich in diesem Ausmaß nicht absehbar beim Schreiben von PTv2.
Werde mich an der Variante von @ToniE orientieren. Die sagt mir am meisten zu und er scheint ja eine akzeptierte Instanz in dieser Frage zu sein.
Ich selber bin nicht ein Fan vom mappen von Bushalten, da es u.a. zu Redundanzen enstehen die m.M.n. nicht nötig sind.
Außerdem gibt es railway=tram_stop, welches äquivalent zu highway=bus_stop für Straßenbahnen ist, dieses aber wird soweit ich weiß nur an Gleisen platziert und nicht an Bahnsteigen.
Das Ergebnis ist, dass ich Bussteige folgend (inkonsistent) mappe:
Bei einem einfachen Halt (ohne highway=platform bzw. als Node) gebe ich dem public_transport=platform das highway=bus_stop.
Wo es ein highway=platform gibt, gebe ich dem public_transport=stop_postition das highway=bus_stop; es gibt kein separates public_transport=platform also Node.
Nein. In PTv2 darf es eben maximal einen PTv2-Stop und maximal eine PTv2-Platform pro Halt geben.
Jedes dieser Objekte (egal ob highway=bus_stop, railway=platform, public_transport=stop_position, public_transport=platform, highway=platform, …) ist Mitglied aller Relationen, zu denen dieser Halt gehört. Das ist eine wichtige Datenbankeigenschaft, die nicht kaputt gemacht werden sollte.
Natürlich hat das PTv2-System Schwächen. Z.B. ein Bahnsteig, der teilweise im Tunnel liegt und deshalb eigentlich aufgespalten werden müsste. Oder etwa Bus-Platforms, an denen man nicht auf den Bus warten darf. Da müsste ein nächstes PTvx Abhilfe schaffen. Aber deshalb in PTv2 illegale zusätzliche Haltestellenobjekte zu erzeugen, die zur Datenbankauskunft “Hier hält nix” führen ist eine Lösung, die ganz PTv2 unbrauchbar macht. Viele ÖPV-Auskünfte nutzen unsere Karten und keiner unsere Routen dazu … das ist kein Zufall.
Die zwei pt=platform-Objekte machen mich auch nicht glücklich. Letztlich landet nur eins davon in den Routen, sodass aus Sicht der Routen alles okay ist. Sucht man aber nach Haltestellen und möchte dann schauen, welche Routen dort halten, haben wir das von @Weide angesprochene Problem (keine Routen, weil die am anderen platform-Objekt hängen.
Mein ganz praktisches Problem hier vor Ort (Raum Chemnitz) ist, dass es Halte gibt, die eine pt=stop_position auf der Straße haben (ist okay) und dazu zur eine Linie mit pt=platform und hw=bus_stop. Im Standard-Renderer wird die Linie nicht gerendert, weil das hw=platform fehlt, und das Haltsymbol wird nicht gerendert, weil das hw=bus_stop an Linien ignoriert wird (soll ja nur an Punkten vorkommen). Die Haltestelle ist also in keiner Weise auf der Standardkarte erkennbar. Nun soll man nicht für den/einen Renderer mappen, aber das hw=bus_stop an einer Linie ist auch ohne Renderer falsch.
Man könnte nun hw=bus_stop an der Linie durch hw=platform ersetzen. Dann ist das alles PTv2-konform. Die Linie wird auch gerendert, nur fehlt das Haltestellensymbol samt Beschriftung in der Standardkarte.
Will man das Haltestellensymbol sehen, muss zwangsläufig ein Punkt mit hw=bus_stop her. Um die Doppelung von pt=platform zu vermeiden, müsste die Linie ohne pt=platform leben (nur hw=platform). Wäre aus meiner Sicht okay, scheint aber eher unüblich zu sein. Deshalb hatte ich ja diesen Thread aufgemacht, um zu schauen, ob etwas geben diese Vorgehensweise spricht.
Wesentliches Argument gegen meinen Vorschlag ist bisher nur, dass das scheinbar bisher niemand so macht. Im Grunde reicht (mir) das aus, meinen Vorschlag nicht umzusetzen; gibt schon genug verschiedene Varianten. Interessehalber wären aber inhaltliche Gegenargument schön, sofern jemand welche sieht. Mit Blick auf ein mögliches PTv3 und angesichts der Wichtigkeit von guten PT-Karten kann man gar nicht genug über das Thema nachdenken…
Habe mal ein bisschen in größeren Städten geschaut wie es da gemacht wird; nur so zur allgemeinen Information:
Berlin hat sehr viele Punkt-Linie-Kombinationen und nimmt die Linie in die Routen auf. Dabei hat der Punkte oft kein pt=platform, wird ja aber laut PTv2 durch hw=bus_stop (neben der Straße) impliziert, also letztlich doppeltes pt=platform.
Leipzig hat etliche direkte Doppelungen von pt=platform und nimmt die Linie in die Routen auf.
Dresden hat doppeltes pt=platform und nimmt sowohl Punkt als auch Linie in die Routen auf.
Ist kein Problem für mich, pro Haltestelle in einer Relation nur eine public_transport=stop_position und nur eine public_transport=platform zu haben.
highway=bus_stop als “überliefertes” Tag scheint mir immer wieder ein “Totschlagargument” gegen PTv2 zu sein:
weil die wichtigsten Kartenstile PTv2 nicht unterstützen
man daher, um das Bus-Icon zu bekommen, highway=bus_stop nimmt
weil das aber nicht auf ways, areas, MPs definiert ist/unterstützt wird hat dessen Verwendung einen für PTv2 einschränkenden Effekt zusammen mit public_transport=platform
warum nicht highway=bus_stop an die public_transport=stop_position und gut is?
IIRC, war zunächst nie definiert, wo highway=bus_stop gemapped werden soll.
Vor einiger Zeit hat wohl jemand das Wiki dahingehend geändert, dass es neben die Straße gehört, und quasi mit public_transport=platform.
Womöglich basierend auf dieser Diskussion in 2012?
Das führte wohl zu
weil das aber nicht auf ways, areas, MPs definiert ist/unterstützt wird hat dessen Verwendung einen für PTv2 einschränkenden Effekt zusammen mit public_transport=platform
Oben wurde u.a. das Berliner Schema erwähnt, welches ich für komplett falsch halte und dies auch z.B. durch den OSM Inspector bestätigt wird. Das eigentliche Problem besteht ja lediglich an Haltestellen wo die Plattform als Linie getaggt ist. Dies wurde vor Jahren in ganz Berlin mal knallhart durchgezogen, auch dort wo gar keine explizite Haltekante o.ä. Plattform vorhanden ist (z.B. nur ein Haltemast auf dem Bürgersteig). Hier wird anders als ToniE es tut (wobei sein Vorgehen für mich auch keine Lösung ist), ein node hw=bus_stop an jeder Haltelinie angelegt, meist ohne weitere Merkmale, da nur für das rendering, weil unbedingt das Symbol neben der Straße zu sehen sein soll. Warum? War nie zwingend so angedacht und nach wie vor steht lediglich"widely used ". Ich leg das zur stop_position auf die Straße (war auch mal so im wiki angesagt). Dass ich die Seite des Einstieges so nicht erkennen kann ist auch kein Argument, mit hw=platform wird auch die Linie gerendert.
Da das Berliner Schema nun auch wieder verstärkt bei mir im Umland eingesetzt wird und ich auf diesen Beitrag aufmerksam gemacht wurde, werde ich das noch mal beim Stammtisch ansprechen und mich dann notfalls doch wieder aus dem ÖPNV tagging zurückziehen (da bin ich ja leider nicht allein).
Da dieser Beitrag ja leider wieder wunderbar zeigt wie fehleranfällig und missverständlich das aktuelle PTv2 ist, abschließend noch ein Gedanke der mich schon lange begleitet: Es bräuchte vielleicht so etwas wie public_transport=bus_stop nur als node mit allen relevanten Merkmalen aus bus_stop/plattform, dieser wird an der Stelle des Haltemastes eingetragen (hw=bs ist nicht der Haltemast, auch wenn meist an dessen Stelle) und nur dieser wird in die Routenrelation aufgenommen. Dort findet sich dann (temporär!?) auch hw=bus_stop wieder, denn vielleicht schaffen wir es ja mal uns von PTv1 zu trennen. Das wäre, nachdem man sich verständigt hat zukünftig pt=bus_stop anstelle hw=bs zu rendern, auch fix gemacht. Das schmückende Beiwerk bleibt natürlich für die Haltestellenrelation, wie jetzt schon.
Das ganze Thema hat mir die letzten Tage keine Ruhe gelassen. Habe ein bisschen Python-Code zusammengebaut, der für eine Region die verschiedenen Tagging-Varianten bei Bushalten visualisiert und Zahlen zu deren Häufigkeiten liefert. Schreibe gerade ein paar Verse dazu. Sollte die nächsten Tage fertig werden; Link zu Text, Karten und Code stelle ich dann hier rein.
Spoiler: Die Lage ist schlimmer als gedacht. So viel Wildwuchs hatte ich nicht erwartet.
Die gute Nachricht: Beim Analysieren der verschiedenen Varianten habe ich gesehen, dass der Standard-Renderer bei Areas mit hw=bus_stop ein Haltestellensymbol mittig in den (flächigen) Bussteig setzt. Das Problem des fehlenden Symbols trifft also nur linienförmige Bussteige. Nachteil: Mangels hw=platform (ist ja schon hw=bus_stop) wird der eigentliche Bussteig dann nicht mehr gerendert
Karten sind im Text fast ganz unten verlinkt, hier nur der Direktlink für Chemnitz-Zwickau; die 6 MB HTML/JS stressen den Browser eventuell etwas; bitte oben rechts die Auswahllisten beachten, sonst ist die Karte mit Infos überfrachtet
Wesentliche Erkenntnisse:
Mein Gedanke, die Platform ohne pt=platform zu mappen, damit es nur ein platform-Objekt gibt (den Node), ist praktisch no nie umgesetzt worden; finde den aber immer noch gut.
In manchen Gegenden sind die Bushalte ganz gut/einheitlich (Berlin, München). In anderen Gegenden sieht es sehr wild aus mit vielen nicht guten Tagging-Varianten (Chemnitz-Zwickau, Darmstadt, Reutlingen).
