Mich würde interessieren, wer das alles war. [1] (Ich habe bisher keine Kritik an Bushaltestellen geäußert, ich fahre Bahn :D) Ihr könnt ja über einen Endlos-Thread hier im Forum nachdenken (ähnlich Internationale Administrative Grenzen), wo fortlaufende Diskussion über Mentz-Aktivitäten stattfinden. Das ist bloß ein Vorschlag, den ihr intern mal diskutieren könnt. Ohne geht es genauso gut.
Bei der Frage gibt es fast so viele Meinungen wie bei der Frage, wo eine Adresse hinzutaggen ist.
Hier (Barbarossaplatz, Karlsruhe, Fahrtrichtung Bulach/Oberreut) gibt es keine spezielle Plattform, hier würde ich die Plattform als Punkt mappen (highway=bus_stop, public_transport=platform): http://www.mapillary.com/map/im/N_QNRrmxgQhs8YJ_ilW4Ow
Hier (Friedhof, Brackenheim-Dürrenzimmern, beide Richtungen) gibt es zwar eine Haltebucht, aber keine besondere Plattform (bloß Bordstein). Ich würde es genauso mappen wie den Barbarossaplatz in Karlsruhe: http://www.mapillary.com/map/im/fkzC0cfmMIczG06eU9WlAA Der Platform-Node käme an die Position des Schildes.
Wenn man Plattformen als Fläche mappt, stellt sich die Frage, wo man dann highway=bus_stop hintaggt.
Es gab kürzlich auf der Umfrageplattform eine Umfrage zu einem ähnlichen Thema. Auf dem Treffen in Dortmund Ende März war es auch Gegenstand der Diskussion. Ich würde den dortigen Kompromiss zur Übernahme vorschlagen.
Viele Grüße und viel Spaß beim Mappen
Michael
[1] Bitte nicht die Leute öffentlich an den Pranger stellen. Ich erwarte hierauf keine Antwort.
Ich bin nach wie vor dagegen, zusätzlich zu einer Platform als Linie oder Fläche eine zweite Platform mit highway=bus_stop an einem der Nodes der anderen Platform zu definieren. Das ist nicht PTv2. Die Relationsmitgliedschaften können dann nicht mehr die Zugehörigkeiten zu den Routen ausdrücken, da PTv2 unfähig ist, mehrere Platformangaben einer Haltestelle zuzuordnen.
Das sieht für mich danach aus, als wäre Steig D im ÖPNV-Sinn etwas anderes als Steig E.
Ich würde deshalb die Steige nur als Bauwerke mappen (highway=platform ohne public_transport=platform) und die Nodes als die Steige im Sinne des ÖPNV betrachten und in den Routen und stop-areas angeben.
Man könnte natürlich auch die Nodes rauswerfen und die Flächen teilen, so dass z.B. Steig E und Steig D unterscheidbar sind. Das zieht aber einen Rattenschwanz weiterer Änderungen nach sich.
Ein Kompromiss bedeutet ja nicht unbedingt, dass alle einer Meinung sind, daher ja Kompromiss.
Ich verstehe immer noch nicht, warum ich nicht einen gesonderten Node einer bestehenden ptv2-Platform, die als area oder way getaggt ist, nur mit den beiden Tags highway=bus_stop und name=xyz taggen kann (ohne irgendwelche Relations- oder Routenzugehörigkeit). Dieser Node wäre dann ptv1, der Rest wäre ptv2. ptv1 wäre nur für die Darstellung auf der Karte (quasi for rendering), ptv2 für die Routen.
Persönlich bin ich weiterhin der Meinung, ptv1 auslaufen zu lassen und ptv2 nur noch rendern zu lassen.
Ja. Aber “Kompromiss” bedeutet schon, dass man sich auf etwas für alle noch akzeptables geeinigt hat. Das haben wir nicht und wir haben auch nicht nennenswert darüber diskutiert.
highway=bus_stop ist nicht nur eine Haltestelle nach PTv1, es ist auch voll und ganz eine PTv2-Haltestelle:
This proposal does not replace, deprecate or obsolete the already existing and
well known tags. The usage of the proposed tags is recommended but not mandatory.
Das funktioniert erst nach Abschaffung aller PTv1-Routen, denn die haben pro Haltestelle nur einen Node und der muss (bei Bussen) highway=bus_stop haben.
Wir müssen also kompatibel rendern. PTv2 verlangt die Einbeziehung aller Haltestellenobjekte in die Route, kann aber nur mit einer stop_position und einer platform pro Halt umgehen. PTv1 verlangt einen Node mit highway=bus_stop. Wenn die platform kein Node ist, dann bleibt nur der Eintrag des highway=bus_stop in die stop_position. (Das ist durchaus zulässig. Wir haben nur damals dringend empfohlen, die highway=bus_stop_Nodes für nur eine Richtung immer neben die Fahrbahn zu setzen, weil die Auswertung und Darstellung von “highway=bus_stop” mit “dir=NE” beim Rendern unnötig kompliziert war.)
Sehe ich langfristig auch so. Allerdings ist es sehr schwierig für die Renderer. Niemand will sowohl die stop_position als auch die platform in einer Karte sehen, aber jeder einzelne der beiden darf entfallen und in keinem der beiden steht, ob es den anderen gibt oder wer überhaupt zu wem gehören könnte.
Dafür hatte ich mal angedacht, stop_position und highway mit einem Fußweg zu verbinden. Gut, war ein dilettantischer Versuch und wir haben uns ja auch dagegen entschieden. Andere mögliche Lösung ist über die IFOPT-Nr., zwar aufwendig, aber m.E. lösbar. Zumindest innerhalb des VRR (vermutlich sogar ganz NW) ist diese Nummer bereits flächendeckend vergeben.
Nun, das ist ja bereits jetzt z.B. auf der ÖPNV-Karte das Problem. Wenn ich es richtig sehe (und da lasse ich mich gerne berichtigen), ist diese für ptv1 geschaffen. Sie wertet aber ptv2-Routen aus, die als ptv1-Route angesehen wird und daher erscheinen bei den Haltestellen alle Verbindungsbusse doppelt. AUCH weil ptv2-Alternativrouten der gleichen Busverbindung als eigene ptv1-Route angesehen werden, statt sie als eine Linie anzusehen.
Es bleibt aber auch die Frage, warum die Renderer sich an dieser Stelle nicht bewegen?
Genau das wollen wir doch zumindest im VRR, also ptv1-Routen abschaffen. Von daher ist es doch abgesehen von der Routeninterpretionsproblemtik wie oben beschrieben, m.E. unschädlich den bus_stop auf einen Node des way oder der area platform zu setzen.
Eine VRR-Lösung nützt nichts; wir müssen eine weltweite Lösung haben und die gilt dann auch für den VRR. In PTv2 können wir die Zusammengehörigkeit über die Routen ermitteln. Das hab ich ja in meinem Programm gemacht, dass aus den OSM-Daten einer Region neue Daten erzeugt, bei denen die fürs Rendern benötigten Daten in den Stops und Platforms stehen.
Ja. Ich hab nur argumentiert, dass das Konzept des Doppelmapping von Platforms die erfolgte Abschaffung der PTv1-Routen voraussetzt während PTv2 für die Umstellung Route für Route gemacht ist und das daher dieses Konzept der Doppelplatforms etwas ganz anderes ist als PTv2 und nicht damit kompatibel ist.
Weide
PS: Im Übrigen bin ich natürlich weder für PTv1 noch für PTv2 Das von mir vorgeschlagene P3 finde ich viel besser :-))
Ich habe mich zwar noch nicht detailliert damit beschäftigt, aber ich bin gerne bereit P3 umzusetzen und auf eine weitere Umsetzung von PTv2 zu verzichten, wenn dieses highway=bus_stop dadurch endgültig Geschichte wird.
Thoschi
PS: Dies ist kein Aufruf, dies als historic:highway=bus_stop zu taggen.
Ich habe keine Ahnung wie zuverlässig deine Lösung ist, aber ich sehe bei allen Städten mit Straßenbahn im Straßenraum und Bussen am Fahrbahnrand ein Problem. Hier werden die selben Masten zu unterschiedlichen stop-positions zu geordnet.
Die IFOPT-Nr ist eine weltweit eindeutige Nummer, auf die sich die Verkehrsunternehmen geeinigt haben. Fraglich ist nur, inwieweit der Irak oder HOnduras diese bereits vergeben haben. Andererseits glaube ich, dass dort nichtmal PTv1 umgesetzt ist.
Ja, auch den umgekehrten Fall mit routenweise unterschiedlichen Platforms zu einer stop_position findet man oft. Ich markiere (in der umgesetzten Datei; nicht in OSM!) die stop_positions mit has_platform=yes/no und die platforms mit has_stop=yes/no. Die “yes”-Markierung wird gesetzt, sobald eine Route beide als Paar benutzt. Das geht gewöhnlich bei diesen nicht-eins-zu-eins-Sachen ganz gut, aber Fehler im Tagging schlagen schnell auf die Karte durch.
Auch am Rand des Gebietes wird es evtl. kritisch, wenn Objekte da sind aber die zu ihnen gehörenden Relationen oder Paar-Objekte fehlen.
Das geht. (aber nicht von einem Tag auf den anderen)
Ich hab versucht, den Übergang anders als bei PTv1->PTv2 zu lösen, so dass die Renderer und Editoren sehr früh unterstützen können. Die neuen Datenstrukturen sind erstmal zusätzlich und die dazu gehörigen alten Daten werden mit p3_ignore=yes markiert. Das stört alte Programme nicht, denn sie verstehen weder diese Markierung noch die neuen Daten. Umgestellte Programme benutzen soweit vorhanden nur die neuen Daten und machen ansonsten weiter wie bisher. Die P3-Routen stellen keine Anforderungen an das Tagging der Steige und Haltepositionen und damit kann OSM für die Haltestellen alles Mögliche beschließen… auch die Abschaffung von highway=bus_stop.
Moin
Da stellt sich mir die Frage, inwieweit P3 denn schon abgestimmt ist. Bei einer Suche nach Public Transport im Wiki finde ich allerdings keinen Link.
Dabei ist mir aufgefallen, dass der Artikel zu Public Transport keinerlei Verweise auf PTv1 und PTv2 enthält und auch keinen Hinweis, dass es ggf. für Verkehrsverbünde zusätzliche Tags und Regeln gibt. Sollte man den Artikel nicht entsprechend erweitern?
Thoschi
Nein, nein. Im Moment ist das nur 'ne Idee von mir, die man auf http://www.gafte.de nachlesen kann. Niemand sollte jetzt danach mappen. Sollte es darauf positive Resonanz geben – was bisher nicht der Fall ist – dann mache ich daraus ein Proposal und dann kann es eine Abstimmung geben und danach ggf. etwas in die Wikis kommen.
(Ich habe bisher keine Kritik an Bushaltestellen geäußert, ich fahre Bahn :D) Ihr könnt ja über einen Endlos-Thread hier im Forum nachdenken (ähnlich 