Ich muss nochmal auf den Ausgangspunkt diese Threads zurückkommen.
Wenn ich eine Linie oder Fläche als Platform habe, kann ich diese nicht mit highway=bus_stop versehen, da dieser Tag nur für Nodes zugelassen ist.
Wie weiter oben festgestellt, braucht es diesen Tag um das Bushaltestellensymbol anzuzeigen.
Meiner Meinung nach sollte dieses Haltestellensymbol auch neben die Straße, da dadurch die Richtung bestimmt wird.
Ich habe jetzt die Möglichkeit eine Fläche/Linie mit allen relevanten Tags zu erstellen.
highway=platform
bus=yes
public_transport=platform
u.s.w.
Dann setze ich auf eine Node der Fläche/Linie highway=bus_stop und name=Musterstraße.
Bei der Fläche/Linie darf ich dann den Namen aber nicht angeben, weil er sonst auch in der Fläche nochmal angezeigt wird.
Bei dieser Variante hat jetzt aber die Platform in der Relation keinen Namen.
Die zweite Variante ist bei der Fläche/Linie nur die Tags
highway=platform
bus=yes
und bei Fläche noch area=yes
zu setzen und alle anderen Tag auf einen Node der Fläche/Linie
Dann kommt dieser Node in die Relation, hat einen Namen und alle relevanten Informationen.
Die dritte Möglichkeit ist highway=bus_stop auf die Stopposition und damit auf die Straße zu setzen.
An die Fläche/Linie kommen dann alle relevanten Tags einschl. Name.
Diese Fläche/Linie wird dann auch in die Relation aufgenommen und hat einen Namen.
Nachteil ist hier das Haltestellensymbol auf der Straße.
Beispiel: http://www.openstreetmap.org/#map=19/50.14714/8.92941&layers=N
Jetzt kann wieder einer sagen: “Wir mappen nicht für den Renderer”, aber eigentlich muss der ja die public_transport Tags auch rendern, was er aber z.Zt. nicht tut.
Mein Favorit ist Variante zwei.
Bitte keine Beiträge: “Ich mache es so” mit einem Link, sondern Argumente für eine der Varianten.
Variante 1: Da sind dann zwei Platforms wo in der Realität nur eine ist. Schreibt man beide in die Route, dann gilt dass als zweimal anhalten und ist falsch. Schreibt man nicht beide in die Route, dann kann man bei einer von den beiden nicht mehr die Liste der Linien zur Haltestelle nachschlagen, da sie ja nicht Mitglied der Route ist.
Variante 2: Da sind dann zwei Platforms wo in der Realität nur eine ist. Es werden sicherlich Mapper die Platform in irgendwelchen Routen benutzen und wir hätten wieder das Problem wie in Variante 1.
(Variante 2a: Ich hab diese Lösung auch schon mit highway=pedestrian statt highway=platform gesehen. Das geht … ist aber irgendwie häßlich …)
Variante 3: Geht
Was soll der Renderer dann mit der stop_position machen? Auch Rendern ist übertrieben. Nicht rendern geht auch nicht … vielleicht ist nur die stop_position da und die platform nicht. Die Beziehung zwischen stop_position und platform ist ja auch keine 1:1-Beziehung. Man kann also nicht einfach sagen “Wenn sie in einer Variante als Päärchen auftreten, dann rendern wir ein H-Symbol an der platform und keins an der stop_position” … da könnte ja in der Gegenrichtung dieselbe stop_position ohne Platform benutzt werden. Durch eine platform die zu mehreren stop_positions gehört wird die Sache nochmal gemeiner. PTv2 hat uns da ein kaum ausbrütbares Rendering-Ei ins Nest gelegt.
Zustimmung. Das hattest Du neulich schon mal sehr anschaulich belegt. Ein PTv3 (oder v2.1) müsste auch da aufräumen. Wegen der großen Verbreitung von highway=bus_stop wohl mit dessen Beibehaltung/Integration. Sonst kommen wir wohl nie aus der “Falle” raus.
Na ja, wir könnten die beiden Teile eines Haltpärchens einer PTv2-Route mit Prioritäten versehen. Dann müssten die Renderer nicht alle Routen kompliziert analysieren:
primary=yes/no
Man könnte dann sagen, dass ein jetzt dargestellter stop (z.B. highway=bus_stop" oder “railway=stop”) durch “primary=no” als “wir haben noch was besseres, stell ihn nicht dar” markiert wird und ein jetzt nicht dargestelltes Platform-Objekt (Fläche oder einfache Linie) durch “primary=yes” als (“hier könnte die Steignummer oder das Haltestellensymbol hin.”) markiert wird. Man würde damit den Renderern nicht sagen, was sie tun sollen … nur wo sie es besser können. Das wäre in einfachen Fällen einfach und nur in komplizierten Fällen mit n:m-Beziehungen zwischen Haltespositionen und Steigen komplizierter.
Variante 3 ist die datentechnisch saubere Variante, sieht halt heute nicht gut aus.
Der Marktplatz in Hanau hat 5 Haltestellen. Wenn die als Fläche gemappt wären würde dann überall nochmal Marktplatz stehen.
Das würde dem geneigten Betrachter wahrscheinlich komisch vorkommen. http://www.openstreetmap.org/#map=18/50.13271/8.91731&layers=N
Variante 1 und 2 sind Trickserei um ein gescheites Bild zu erzeugen.
Dabei ist das Renderproblem mit einer einfachen Regeländerung zu lösen.
Der Renderer muss nur eine Linie oder Fläche mit public_transport=platform genau so rendern wie highway=platform. Dazu das Bussymbol und den Namen. highway=platform an der Linie/Fläche wird dann ignoriert.
Oder - um das Thema Platform mit mehreren Halts abzufangen - wird an einer Node der Linie/Fläche der Tag name=* gemappt. An dieser Node wird dann das Bussymbol mit dem Namen gerendert. Dann könnte hier bei Busbahnhöfen der Steig stehen, bzw kann man bei Linien oder Flächen die Position des Bussymbols und des Namens steuern. Das wäre dann die Darstellung gem. Variante 1 oder 2.
Ist public_transport=platform eine Node wird genauso wie highway=bus_stop gerendert.
Damit kann bei einer PTv2 Haltestelle die highway Tags entfallen.
Ein Haltestellensymbol mitten auf der Straße ist absolut unschön.
PTv2 lässt m.E. viel zu viel offen, bzw. dem Mapper zur Entscheidung frei.
Immer “kann” irgendwas gemappt werden. Das hat mir am Anfang auch große Probleme bereitet und viel Zeit gekostet, um nichts falsch zu machen.
Ich denke hier muss klar definiert werden wie zu mappen ist. Dann ist es auch für Neulinge leichter.
Wenn wir festschreiben, dass eine Haltestelle nach PTv2 immer eine stop_position (wegen evtl. Routingthematik) und eine platform haben muss und wenn man sich dann noch über die Namensgebung einigt sind wir ein gutes Stück weiter.
Wenn ich dann eine stop_area nur als eine Haltestelle betrachte, also nur eine stop_position und platform plus Bank usw. dann habe ich auch die Verknüpfung zwischen dem Halt und der Platform.
Wofür brauchen wird denn in einer stop_area die Haltestellen in beide Richtungen?
Die stop_area soll bei größeren oder unübersichtlichen Haltestellen alle stops und platforms zusammenfassen. Damit kann man in Karten eine Fläche mit dem Namen versehen und an den Einzelobjekten die Steignummern angeben oder kleine Symbole ohne Namen anbringen. Stopareas mit einem Element sind Quatsch und bei zwei gegenüberliegenden Haltestellen an der Landstraße braucht man auch keine stop_area.
Wieso? Wenn da Busse in beiden Richtungen verkehren und die Ausstattung auf beiden Seiten gleich ist und die Dinger einander gegenüberliegen, dann ist die gesamte Haltestelle durch einen einzigen Node auf dem Weg mit highway=bus_stop und name=xy sehr gut beschrieben. (Da kommt dann ggf. noch die Ausstattung hinzu).
Es gibt jetzt schon viel zu viele Angaben an den Haltestellen und das liegt weniger an PTv2 als an den Gerüchten darüber. Man muss nicht überall eine Platform machen oder einen stop. Man muss nicht überall PTv-Haltestellentags haben. PTv2 hat das nie verlangt. Ich finde sehr viele Haltestellen mit einer Halteposition und zwei flächigen Steigen daneben und sämtlichen zur Verfügung stehenden Tags wo auch ein einfacher Node auf der Straße wie oben beschrieben gereicht hätte. (Ich lösche sie nicht, denn es ist ja nicht falsch)
Schuld daran ist die Idee, dass es PTv2-Haltestellen gibt. Es gibt aber nur PTv2-Routen. Alle PTv1-Haltestellen sind in PTv2 vollwertige Haltestellenangaben. Da müssen keine PTv2-Tags dran. Die PTv2 Tags braucht man dann, wenn man da mehr mappen will als nach PTv1 möglich ist. PTv2 ist aber kein Grund, da mehr zu mappen.
