Mindestens genau so schlimm ist es, wenn nur ein highway=bus_stop für beide Richtungen existiert. Da habe ich dann auch keine Lust mehr, das in Relationen einzutragen.
Das Linienrelationen beschrieben werden müssen/sollten hat doch grundsätzlich nichts mit dem Mappen von Haltestellen zu tun. Auch müssen dies nicht die gleichen Leute machen. Ich erstelle für meinen Bereich die Linienrelationen häufig erst nach Erfassung der Haltestellen.
Dazu sind die platform-Tags, die auf jeder Seite der Fahrbahn erfasst werden sollen. Die stop_position ist für den Straßenverkehr.
Also geht die unterschiedliche Auffassung nur darum, ob das Bushaltestellensymbol auf der Straße oder neben der Straße steht. Denn eines ist doch klar, auch wenn das public-transport-Schema noch nicht oder noch nicht vollständig gerendert wird, maßgebend sind doch public_transport=stop_position auf der Straße und public_transport=platform neben der Straße, beide aber mit der entsprechenden Fahrtrichtungsrelation der Buslinie.
Diese beiden Tags werden meines Wissens auch nur für die Verkehrsverbünde ausgewertet.
Was spricht denn dagegen, solche Relationen zu erfassen? M.E. ausser Aufwand nichts. Aber die Tatsache, dass sich nicht jeder den Aufwand zumuten will oder kann, darf doch nicht ausschlaggebend für ein korrektes Mapping sein (ohne in diesem speziellen Fall ein Votum für oder gegen bus_stop abzugeben).
Da ging es ja gerade um den bus_stop auf der Straße (altes Schema), der mir nicht so gefällt. Beim neuen Schema (stop_position und platform) ist das ja kein Thema mehr.
Zu den Relationen: Das ist nicht ganz trivial.
Die Haltestellen zu einer Linie kann man idR relativ gut aus den Fahrplänen (sehr oft online) erhalten.
Problem ist der Fahrweg. Die Netzpläne der Verkehrsunternehmen (so vorhanden) sind von sehr unterschiedlicher Qualität/Abstraktion. Längst nicht immer ist der Fahrweg zwischen zwei gemappten Haltestellen zweifelsfrei zu erraten.
Da müsste man mitfahren oder dem Bus hinterherfahren. Das macht man höchstens in der nächsten Umgebung.
Auch die Wartung hinterher ist nicht zu vernachlässigen, da es praktisch zu jedem Fahrplanwechsel Änderungen in den Routen gibt, monatelangen Baustellenumleitungen kämen da eigentlich noch hinzu.
Same here: “Da ging es ja gerade um den bus_stop auf der Straße (altes Schema). Beim neuen Schema (stop_position und platform) ist das ja kein Thema mehr.” (um mal seichter zu zitieren) Wenn es so gerendert wird ist ja alles gut. Das highway=bus_stop dient eben dazu, dass die Haltestellen auch von alten Anwendungen genutzt werden können. Und da sieht man das eben nur, wenn der Node neben der Strasse liegt, also an der Mastposition.
1.: Man sollte das Mapping von Infrastruktur und Verkehrslinien getrennt halten. Eine Haltestelle muss funktionieren, egal ob und wie dort Linien erfasst sind. Eine Linie muss funktionieren egal wie die Haltestellen erfasst sind. Beispiel: Eine Strasse ändert sich nicht dadurch, dass dort ein Bus durchführt. Eine Buslinie ändert sich nicht, wenn bei einer Strasse die Höchstgeschwindigkeit geändert wird.
2.: Es gibt Haltestellen ohne Linien. Das sind z.B. vergessene Haltestellen (irgendwo im KVV steht eine mit mehrere Jahre altem Fahrplan und ohne Bedienung, das ist aber immernoch eine Haltestelle), SEV-Haltestellen, Reservebahnsteige (selten auch im Busverkehr), vorübergehend ungenutzte Haltestellen, …
/edit: Unzutreffenden Zitatteil entfernt
Die Frage ob nun hw=bus_stop auf dem Weg oder daneben, lässt sich vermutlich nicht lösen. Ich persönlich finde es besser diesen Tag in den Wartebereich zu setzen, also neben den Weg, da man so auch die Fahrtrichtung des Busses ableiten kann, wenn zwei oder mehr hw=bus_stop vorhanden sind. Allerdings kann ich auch nachvollziehen, warum man ihn auf den Weg setzt. Z.B. Analogie zu railway=tram_stop oder Konfliktvermeidung mit hw=platfrom als Node. Hauptproblem ist vermutlich was man unter “bus_stop” versteht und wie man das Übersetzt. Für mich wäre die Übersetzung “Bushaltestelle” aber die Verwendung als Position des Wartebereiches. Hmm, je mehr ich darüber nachdenke, desto schlimmer wird es.
Bleibt also vorallem die Frage, wie eng die Wikiseite an der englischen Seite sein soll und was mit dem Punkt “Vorgeschlagene Änderungen” passieren soll?
Naja, auch wenn es jetzt hart klingt, nur weil jemanden etwas nicht gefällt muss das noch keine Änderung bewirken.
Da haben wir es im VRR einfacher, der Fahrtweg lässt sich in den meisten Fällen aus dem online-Fahrplan ablesen. Meine Überprüfungen (=Mitfahren) haben das bisher bestätigt.
Bzgl. temporärer Umleitungen etc. wäre eine Lösung schön. Es gibt da verschiedene Vorschläge im wiki (highway:conditional=construction) und hier im Forum (neuer Tag mit temporary). Zwar gefällt mir die erste Lösung besser (ist ja auch von mir 
), weil kein neuer Tag erfunden werden MUSS, aber wichtiger ist ja, dass dies von der Navisoftware und ggf. Renderern ausgewertet wird.
Bezügl. gefällt mir oder nicht, da steht meine Meinung zu in der Antwort zu seichter. Das die alten Anwendungen hw=bus_stop nur anzeigen, wenn es neben der STraße gemapped ist, ist mir allerding bisher noch nicht aufgefallen. Vielleicht kenne ich die speziellen Anwendungen dafür auch nicht.
Da core, es war von mir auch gar nicht so gemeint, ich wollte nur sagen, dass man die Haltestellen (stop_position und platform) problemlos auch ohne Linienrelationen erfassen kann, diese können ja auch später und von anderen Mappern nachgetragen werden.
Eine Linie kann allerdings auch ohne Haltestellen funktionieren, wenn auch mit der Einschränkung, dass man nicht weiß, wo man zu- bzw. aussteigen kann.
Streiche das “der mir nicht gefällt”. Ich hatte es überlesen, an der eigentlichen Aussage ändert es nichts und bei meinem Zitat gehört es auch gestrichen.
Ich meinte nicht, dass sie es nur dann anzeigen, sondern dass man nur dann eine Richtung sehen kann.
Wer arbeitet denn noch mit Win95? Aber mal im Ernst, sicherlich sollte so viel wie möglich auch in alten Programmen noch funktionieren, aber wenn diese alten Anwendungen selbst auch nicht mehr gepflegt bzw. angepasst werden, dann kommt man irgendwann dazu, sie zu vernachlässigen. Wenn ich sehe, dass man dem Tag railway=station eine neue Bedeutung verpassen will, dann kommen alte Anwendungen damit auch nicht mehr klar.
Das neue Schema ist doch das public_transport-Schema, und dann muss man auch mal in den sauren Apfel beissen und sagen, o.k., hw=bus_stop läuft aus und wir animieren alle, auf das neue Schema umzustellen.
Ich weiß, als Programmierer ist das leichter gesagt als getan, aber so läuft das im Geschäft, wenn viele Köche da sind.
Es war beides möglich. Bei einander ziemlich gegenüberliegenden gleichartigen Haltestellen reichte es, auf die Straße ein highway=bus_stop zu pappen. Wenn man differenzieren musste (Bänke, Regenschutz, verschiedene Positionen) hat man mehrere neben der Straße benutzt. Einige haben auch mehrere auf der Straße mit Richtungsangaben benutzt. An dieser Bedeutung sollte man nichts ändern, da es viele alte Haltestellen gibt. Das Löschen dieser Tags dient nur der Platzersparnis, denn es gibt keinerlei Konflikte wenn sie drin bleiben. Das neue ÖPV-Schema ist voll und ganz kompatibel damit und es spricht garnichts dagegen, Nodes mit highway=bus_stop mit der Rolle stop bzw. platform in eine ÖPNV-Relation zu stecken.
(Ist ist völlig OK, auch wenn der JOSM einem dauernd was anderes einreden will.) Man kann highway=bus_stop also völlig entspannt sehen.
Konflikte gibt es nur zwischen den Relationen des alten und neuen Schemas. Hier muss man sich klar entscheiden und mischen der Schemata führt zu Problemen.
Weide
Erklär das mal den Mappern aus anderen Ländern, insbesondere UK. Die haben mir damals im diary als auch auf github jedes mal vorgehalten, dass highway=bus_stop immer an den Rand kommt und 100% eindeutig definiert ist.
Damals…aber heute doch nicht mehr. Im VRR-Gebiet mappe ich durchgängig so und ich habe noch nie eine Beschwerde bekommen.
Naja damals war vor 3 Monaten. Und bei mir in der Gegend war es eben auch nicht eindeutig.
Also, ich habe jetzt einmal die deutsche Wikiseite neu übersetzt. Kleine Änderungen von mir sind in Kursiv geschrieben. Mag sich das jemand einmal anschauen, ob das so bleiben kann? Und eventuell auch einmal nach Gramatik und Rechtschreibung schauen?
Bei nicht gefallen ist natürlich immer ein Revert drin; ich würde aber kleine Anpassungen lieber sehen.
Besten Gruß
Hubert
Sieht auf den ersten Blick gut aus. Jedoch bin ich der Meinung, dass der Tag bus=yes zwingend in die stop_area-Relation gehört und nur optional zur stop_position.
Eine Tram-Haltestelle bekommt eine eigene stop_area-Relation und beide zusammen werden in einer stop_area_group-Relation zusammengefasst.
Kann gut sein. Dann würde ich aber auf jeden Fall bus=yes auch bei stop_position als empfohlen statt optional setzen. Zu mindest habe ich das im Moment so im Kopf, ohen spontan auf Quellen verweisen zu können. stop_area_group-Relation kannte ich noch nicht, klingt aber logisch. Ist halt die Frage ob man das unter hw=bus_stop schreiben sollte. Falls ich es falsch übersetzt habe bitte korregieren.
Das widerspricht dem angenommenen Proposal. bus/tram/etc.=yes gehört demnach eindeutig an die stop_position. An der stop_area hat es nur begrenzt Sinn, weil da mehrere Verkehrsmittel zusammengefasst sein können. (“Rule of thumb: Everything that has/belongs to the same station name is in a stop_area” war die wesentliche Beschreibung auf der Diskussionsseite; stop_area_group wurde im Laufe des Proposal-Prozesses als überflüssig verworfen.)
O.k., ich nutze optional und empfohlen deckungsgleich, von daher macht es für mich keinen Unterschied.
Ist zwar erstmal viel Arbeit, ist aber flexibler gegenüber Änderungen bei nur einem Verkehrsmittel. Zudem lassen sich so die jeweiligen Verkehrssysteme sauber trennen. Ob sinnvoll oder nicht, ist aber so bei der public_transport-Relation vorgesehen, auf der DE:Öffentlicher_Verkehr ist es weggefallen. Ich nutze es, weil ich es für sehr sinnvoll halte.
Im übrigen finde ich, dass man bei den ständigen kurzfristigen Änderungen gerade beim ÖPNV überhaupt nicht mehr korrekt täggen, wenn man sich jede Woche die Wiki-Seiten neu ansieht. Einfach nicht mehr durchschaubar.