Sollte eines Tages mal PTv2 gerendert werden erwarte ich ein Bussympol innerhalb der Platform.
Es ist nicht sinnvoll zwingend den bus_stop an der stop_position zu verlangen. Die meisten Akzeptanzprobleme von PTv2 liegen an dieser Festlegung.
Wenn man wie Thoschi beschrieben hat an einen Knoten der Platform den bus_stop legt, ihn aber sonst unbeachtet lässt, ist das vom Ergebnis die beste Lösung.
In josm wird beim laden einer route die platform mit geladen und damit ist auch jener Knotenpunkt sichtbar (ohne ihn irgendwo einzubinden).
Bei einer Wochenaufgabe wäre das wichtigste, vor Ort Haltestellen auf Lagerichtigkeit und Namen zu überprüfen. Die Modellierung der Haltestellen ist zweitrangig. Eine Renovierung der routen wäre dann erst der dritte Schritte.
Niemand will generell das highway=bus_stop an der stop_position haben. Es ist nur die einzige Möglichkeit, wenn man die Einrichtung zusätzlicher nicht real existierender Platforms und die Folgeprobleme vermeiden will.
Ein kleiner Tipp zum erfassen: Normalerweise gibt es in (kleineren) Dörfern eine Bushaltestelle an der Hauptstraße. Damit man nicht alle Dörfer selbst abklappern muss bietet sich Mapillary ganz gut an, falls es schon Aufzeichnungen gibt.
Eine beim Recherchieren für die Wochennotiz entdeckte ich neulich eine Diskussion auf der Dresdner Mailingliste, welche für mich Anlass war, auf DE:How_to_tag_a ein paar Widersprüche im Wiki zu beseitigen.
Mir fiel einfach nichts Besseres ein, wo man ein highway=bus_stop hintaggen könnte, um erstens neben der Straße zu sein und zweitens highway=bus_stop auf einen Node zu taggen. Wenn die Plattform ein Node ist, dann gibt es das Problem nicht. Wenn aber die baulichen Einrichtungen linien-/flächenförmig sind (z.B. Busbord, Blindenpflaster, andere Befestigung vorhanden), dann kann man schlecht auf die Plattform highway=bus_stop taggen, den Plattformen bekämen eigentlich ein highway=platform.
Irgendwie hat jeder hier Recht, egal ob Jojo4u, Thoschi, axerl oder Weide.
Wieso sollte man den highway=bus_stop-Node noch in die Route aufnehmen wollen, wenn man die Route nach PTv2 mappt (PTv1 ist auf dem absteigenden Ast)?
Wer sagt denn, dass man dem losen highway=bus_stop-Node die Rolle platform geben muss? Man kann in Stop-Area-Relationen eigentlich alles Mögliche sammeln. Nur für Bahnsteige und Haltepositionen sind die Rollen wichtig.
Wie wäre es mit dem Extra-Tag public_transport:compatible=v1, das man an diese losen highway=bus_stop-Nodes taggt. Dann können Auswerter erkennen, dass das keine unzureichend getaggte Plattform, sondern eine Abwärtskompatibilitätskrücke ist.
Weil man sonst eine Platform einer Haltestelle hat, deren Verweisliste nicht die Buslinienliste ergibt.
Oder ganz praktisch gesagt: Wenn ich in der Karte http://www.openstreetmap.org/#map=19/51.15985/7.00456 mit dem Fragezeichen auf eine Bushaltestelle klicke, dann bekomme ich falsche Auskünfte über die dort haltenden Buslinien.
Erstens ist “platform” die richtige Rolle für ein highway=bus_stop neben der Fahrbahn, denn es ist eine voll gültige Platform in PTv2.
Zweitens kommt keine andere Rolle in Frage: “stop” geht nicht, weil es dann ein Node des Fahrwegs sein müsste. Die leere Rolle geht nicht, weil dort nur public_transport=station - Objekte und amenity-Objekte zulässig sind. Man kann nicht beliebige Objekte in eine stop_area stecken. Da ich es in letzter Zeit öfter gesehen habe: Wege und Treppen können nicht Mitglieder von stop_areas sein.
Ich sehe da auch kein großes Problem mit der Darstellung. Wenn da tatsächlich ein linien- oder flächenartiges Objekt ist, da sollte das highway=platform dran, man sieht es in der Karte und dass das H-Symbol auf dem Weg ist, ist eigentlich kein Problem.
Wenn dort aber nichts real sichtbares ist, dann reicht ein Node mit highway=bus_stop und es muss keine Linie oder Fläche dahin.
Das verstehe ich nicht. Da ist keine “unzureichend getaggte Platform”. Das ist aus PTv2-Sicht eine völlig korrekte Platform. PTv2 hat die Bedeutung der alten Haltestellentags nicht aufgehoben. Beim Hinzufügen von public_transport=platform geht es nicht darum, die Angaben zu komplettieren oder richtig zu machen. Es geht nur darum, dass man irgendwann PTv1 schmerzlos abschaffen kann.
Ja, ganz absichtlich. Ein highway=bus_stop-Node neben der Fahrbahn ist eine platform im Sinne von PTv2. Ein highway=bus_stop auf der Fahrbahn ist eine stop_position im Sinne von PTv2. PTv2 hat die alten Tags ausdrücklich nicht aufgehoben. Es wurde nur durch die neuen Tags (public_transport=stop_position/platform) bzw. Rollen(stop und platform statt stop für beides) möglich, sowohl vor Ort als auch in den Routen beides anzugeben und beides ohne geographische Analyse voneinander zu unterscheiden.
Vielleicht sollte dann mal jemand die Templates im JOSM korrigieren. Ich habe nämlich so unwissenderweise sehr viele highway=platform hinzugefügt, weil er das als abwärtskompatibles Tag hinzufügt wenn man bei public_transport=platform sagt, dass man ein Legacy-Tag hinzufügen soll. Nunja, dann werde ich da wohl aufräumen müssen demnächst
Das hab ich nicht verstanden. Wenn da was Sichtbares ist, das man als Linie oder Fläche mappen kann, dann ist highway=platform doch ok. Aber ich hab Dich vermutlich falsch verstanden.
highway=bus_stop, railway=halt etc. gab es schon lange, als PTv2 erfunden wurden. Es ist also keine der PTv2-Erfindungen wie route_master, stop_area, public_transport=…
Aber es war ausdrücklich die Absicht von PTv2, die alten Haltestellentags nicht aufzuheben.
Unausgesprochen war natürlich die Idee, dass sie irgendwann in Zukunft einfach überflüssig werden, weil es keine alten Routen mehr gibt und keine Renderer sie noch anzeigen.
Ja, schon. Man könnte sie weglassen, wenn kein Renderer sie noch braucht und wenn es keine alten Routen mehr gibt. Aber wenn sie da sind, sind sie voll gültig.
Ich vermute, dass die Renderer sie noch weiter benutzen werden. Wenn ein Renderer ein highway=bus_stop findet kommt ein H-Zeichen auf die Karte und fertig. Wenn er ein public_transport=stop_position findet, dann müsste er erstmal in allen Routen nachsehen, ob es platform-Einträge dazu gibt, die man vielleicht lieber auf der Karte sehen würde. Es will ja niemand drei H-Zeichen auf der Karte haben, wenn auf der Landstraße grade mal zwei Haltestellenzeichen einander gegenüberstehen.
Nein. Beide haben Routen und sie sehen sich sehr ähnlich. Aber wenn man dasselbe hinschreibt, dann bedeutet es was ganz anderes. Das ist ein grauenhafter Mist und der größte Designfehler in PTv2. Deshalb hab ich die Gegenüberstellung http://wiki.openstreetmap.org/wiki/User:Weide#Public_Transport_Versionen_1_und_2 gemacht.
Diese Verwechselbarkeit der beiden Routenarten hat üble Folgen. Wir haben z.B. keine brauchbaren Linienpläne mehr mit Richtungsangaben. Das liegt an der Verwechselbarkeit und dem sich daraus ergebenden Schrott in den Daten:
In PTv1-Routen wird für die ganze Buslinie incl. aller Varianten jede Straße einmal angegeben und mit der Rolle gibt man die Richtung für den Beobachter am Straßenrand an:
Leere Rolle: von links nach rechts und von rechts nach links
“forward”: nur von links nach rechts
“backward”: nur von rechts nach links
(wenn die gemappte OSM-Orientierung von links nach rechts war)
In PTv2-Routen wird aber nur eine Variante einer Richtung pro Route erfasst und die leere Rolle bedeutet was ganz anderes: “Es ist ein Stück Fahrweg”. Die Richtung ergibt sich aus der Reihenfolge der Einträge der Straßen. Das was bei PTv1 einfach dran stand, kann man bei PTv2 erst nach dem Durchlesen aller Routen zu dieser Linie sagen.
Mit PTv1-Routen kann man also ganz einfach Linienpläne malen, aber man sieht oft nicht von wo nach wo die Busse fahren. Wenn der Linienplan im Prinzip wie ein großes “X” aussieht, dann kann man das “X” mit einer PTv1-Route detailliert malen … aber mit PTv2-Routen kann man sagen, ob es überhaupt einen Bus von links unten nach rechts oben gibt oder ob die von links unten immer nur nach links oben fahren.
Fragezeichen anklicken
In die Nähe des des Bus-Symbols (Beispiel zweiter von unten) klicken
In der Liste links das Objekt zum Bus-symbol raussuchen (“Bushaltestelle Hauptbahnhof”)
Unten stehen dann die Routen, Z.B.
Relation TB 694: Hbf<=>Buchweizenberg (3687224) (als platform)
Relation TB 691: Hbf<=>Teichstraße (3687223) (als platform)
Wiederholt man das für die Platform-Linie dazu (“Way Hauptbahnhof”), so ergibt sich statt dessen:
Relation Bus NE25: Graf-Wilhelm-Platz=>Hbf (1731865) (als platform)
Relation Bus NE25. Hbf=>Graf-Wilhelm-Platz (1731866) (als platform)
4a. Scrolle NICHT nach unten (da stehen schon alle Linien)
4b. Klicke NICHT auf die ersten Einträge “Node Hauptbahnhof” (da stehen die PTv2 Linien)
4c. Klicke auf den Eintrag “Bushaltestelle Hauptbahnhof”
Scrolle nach unten, dann siehst du nicht die PTv2 Linien sondern nur die PTv1 Linien, das ist das Fragezeichen-Problem.
Das Problem ist nur durch PTv2 Tags in der Datenbank lösbar, und eben deren Fehlen ist unser ständiges Problem.
Weide erwartet volle Information an “Bushaltestelle Hauptbahnhof” statt “note Hauptbahnhof” oder “way Hauptbahnhof”. Eben das ist wie wir schon oft getestet haben nur mit einem engen Korsett mit anderen Nachteilen zu leisten.
Der bus_stop ist eine Krücke, die wir mit Freude löschen, wenn PTv2 in der Datenbank gelistet wird, aber bis dahin müssen wir Einschränkungen akzeptieren oder auf PTv2 verzichten.
Das gleiche Fragezeichen-Problem besteht bei dem Bahnhofs-Zentralpunkt (etwas höher in der Karte) “Bahnhof Solingen Hauptbahnhof” zeigt keine Linien an.
Das hört sich an, als müsste man sonderbare Dinge tun, um das Problem zu sehen. Das Fragezeichen gibt alles Mögliche aus der Umgebung zur Auswahl und man wählt einfach das von vornherein angeklickte Haltestellensymbol aus. Das wird auch angezeigt, wenn man mit der Maus über den richtigen Eintrag kommt.
Ich sehe diese Probleme nicht. PTv2 hat das berücksichtigt.
Das highway=bus_stop an die stop_position.
Die PTv1-Routen auf die stop_position zeigen lassen.
Die zweite Platform (den Node) wegschmeißen.
(Hat nichts damit zu tun: Aus den PTv1-Routen die Platform-Einträge rausschmeißen)
(Hat nichts damit zu tun: Die Platform mit highway=platform markieren)
Also ich komme ach gerade ein wenig durcheinander mit dem was man wie zur Kompatibilität mappen soll. Wenn ich eine PT1-Haltestelle gefunden habe, wurde sie nur um die PT2-Tags von mir erweitert. Habe ich allerdings selbst eine neue erfasst, habe ich sie als Node mit public_transport=platform erfasst und über das JOSM-Template wurde dann highway=platform zur Kompatibilität ergänzt. Es liest sich aber so, als wäre hier die Meinung, dass man highway=bus_stop mappen sollte. So steht es auch im How to. Ist das nun ein Fehler im JOSM-Template oder ein Verständnisproblem meinerseits? Ich kam erst nach PT2 zu OSM und hab keine Ahnung vom Mappen mit PT1.
Wo der bus_stop hinkommt wird hier strittig gesehen. Er kann auf dem Fahrweg oder neben dem Fahrweg stehen. Es gibt für beide Arten Vor- und Nachteile.
Ich hab es gerade mit dem JOSM probiert. Der hat bei einem Node nichts hinzugefügt…
Man sollte im Moment Haltestellen auf beide Arten taggen, da in den meisten Karten nur die PTv1-Tags zählen und die PTv1-Routen nur für Haltestellen mit PTv1-Tags gemacht sind. PTv2-Routen funktionieren dagegen problemlos auch mit nur auf PTv1-Art getaggten Haltestellen. Inkompatibel sind nur die Routen der beiden. Bei den Haltestellen sollte man daher doppelt taggen. Einer der beiden Teile einer PTv2-gemappten Haltangabe muss ein highway=bus_stop bekommen, es kommen nur Nodes in Frage und es darf nicht an beide Teile. Das führt manchmal dazu, dass man keinen der beiden Teile weglassen kann, obwohl das in PTv2 eigentlich zulässig wäre.
Ich geb mal als Beispiel an, wie ich es bei neuen Halten mache:
Landstraße mit zwei gegenüber liegenden Halten mit gleicher Ausstattung: Ein Node auf die Fahrbahn mit highway=bus_stop und public_transport=stop_position. Hat in beiden Arten von Routen die Rolle “stop”.
Unterschiedliche Ausstattung oder nicht gegenüberliegend: für jede Richtung einen Node neben der Fahrbahn mit highway=bus_stop (und evtl. public_transport=platform (ist umstritten, es gibt da verschiedene Übersetzungen)). Hat in PTv1-Routen die Rolle “stop” und in PTv2-Routen die Rolle “platform”.
Wenn jetzt eine Steig tatsächlich vor Ort existiert (mir reicht da eine durch Blindenleitbelag erkennbare Zone), dann mappe ich den mit highway=platform und public_transport=platform und das highway=bus_stop kommt mit public_transport=stop_position an einen einigermaßen passenden Knoten des Fahrwegs.
Da habe ich ja eine ganz schöne Diskussion losgetreten…
So sehe ich das auch. “Ausstattung” wäre aber auch noch ein wichtiger Punkt.
Habt ihr ein paar Haltestellen greifbar (am besten inklusive Foto), anhand derer wir das Tagging dokumentieren können?
TheFive hatte ja schon angeboten, sein OsmCount-Script für Apotheken entsprechend umzubauen für Haltestellen, damit kann man dann den Fortschritt und die überhaupt vorhandene Abdeckung feststellen.
Vielleicht findet sich nächstes Wochenende in Karlsruhe auch ein Grüppchen, das an der Vorbereitung arbeiten will?
Blindenleitbelag (tactile_paving), Bank (bench) und Unterstellmöglichkeit (shelter) fallen mir da erstmal ein.
Wenn Bank oder Wartehäuschen getrennt gemappt sind, dann soll man es m.W. nicht nochmal angeben.
Bei shelter kann m.E. manchmal auch ein “yes”, wenn da kein Wartehäuschen ist … es geht ja um die Unterstellmöglichkeit. Die kann ja auch durch die Bauweise der naheliegenden Häuser gegeben sein. Wenn man sich da für den Busfahrer sichtbar unterstellen kann, dann ist shelter=yes m.E. passend.
Die Blindenleitbeläge können auch schonmal ganz unsinnig sein – da steht schonmal mitten im Weg ein Laternenmast. Zu den Problemen gibt es aber irgendwo extra Seiten.
Ganz schwierig finde ich den Rollstuhlfahrerbereich. Da mappen die einen wie gut die Haltestelle erreichbar ist und die anderen, wie gut sie in den Bus gekommen sind. Eigentlich müsste der ganze Rolli-ÖPV-Bereich mal überdacht (nicht wie “Dach”, wie “denken” mein ich) werden. Es gibt lokale Eigenschaften wie Rampen an Hochbahnsteigen und Kombinationseigenschaften wie bei Bussen mit Kneelingeinrichtung bei Sägezahnhaltestellen mit schrägen Kantensteinen. Oder bei Zügen die Höhen von Bahnsteigen und Ausstiegen. Da gute Datenstrukturen zu bauen ist nicht einfach.
