eine Bushaltestelle soll gem. PTv2 ja mit einer Stopposition auf der Straße und einer Platform als Punkt oder Area getaggt werden.
Wenn man die Area-Platform in die Relaltion aufnimmt gibt es beim Routenanalyzer eine Fehlermeldung.
Jetzt kann man die Fehlermeldung ignorieren. Das ist für mich aber nicht akzeptabel.
Man kann neben der Area auch noch einen Punkt als Haltestelle einfügen und den in die Relation aufnehmen. Dann ist der Analyzer zufrieden. Dann habe ich aber zwei Platform-Objekte.
Mmmhh?
Nicht ganz. Man darf es … wenn man es für sinnvoll hält. Eine der beiden Angaben darf entfallen. Wenn es aber gemappt ist, dann muss es auch in die Routen. Für die Platform kommen übrigens auch noch Ways in Betracht.
Der ist auch nicht für PTv2-Routen gemacht. Er nimmt Platform-Ways als Fahrweg. (Erst fährt der Zug über alle Bahnsteige der Strecke und danach nimmt er die Schienen )
Da bin ich ganz Deiner Meinung. Zwei Platform-Objekte wäre eines zuviel. (Es gibt aber andere Meinungen zu dem Thema)
Für die PTv2-Regel, dass man bei einem Halt nicht beides mappen muss aber gemapptes in die Relation soll, gibt es m.E. nur eine Erklärung: Man soll zu jedem Haltestellenobjekt die ÖPNV-Linien durch Nachschlagen der Routen-Mitgliedschaften ermitteln können. Das geht nicht mehr, wenn zwei Platforms zu einem Haltevorgang des Fahrzeugs gehören – PTv2 kann das nicht.
Anscheinend wird PTv2 noch nicht so richtig unterstützt.
Eigentlich müsste ein public_transport=platform oder public_transport=stop_position auch gerendert werden.
Aber da ist bei Mapnik oder Openstreetmap Deutschland nichts zu sehen.
Man muss immer den alten Tag highway=bus_stop hinzufügen.
Wann ist denn da mal eine Änderung vorgesehen?
Wenn eine Platform da ist, dann will man vermutlich die in der Karte haben und die stop_position nicht noch zusätzlich haben. Wenn aber keine Platform da ist, dann soll ein Symbol an die stop_position. Aber woher weiß man, welche zusammengehören? Dazu muss man die Routen analysieren. Hinzu kommt, dass sowohl die Platform als auch die stop_position auch ohne public_transport=* gemappt sein können. (Und ganz gemein: es kann sogar passieren, dass zwei Platforms sich eine stop_position teilen und eine der Platforms nicht gemappt wurde.) Im Endeffekt muss man eine ganze Gegend analysieren, bloß um so ein blödes “H” in die Karte malen zu können. Dagegen ist das Rendern von einem highway=bus_stop doch echt einfach. Ich glaub nicht, dass da noch viel passiert und ich kann es verstehen…
Nein. Eine Stop_position darf ohne Platform vorkommen, eine Platform darf ohne Stop_position vorkommen und keiner der beiden muss unbedingt public_transport=* haben! (Alle alten Haltestellen sind PTv2-kompatibel – ganz anders als bei den Routen.)
Das Problem ist gut beschrieben.
Aber das hieße, highway=bus_stop wäre eine reine Anweisung an den Renderer: “Hier bitte das H hinsetzen.”
Ich darf in OSM nur dann etwas mappen, wenn ich es vollständig mappe!?! Das wäre im Blick auf die Gewinnung neuer Mapper der Tod im Topf: “Hallo! Du hast da einen Bahnhofs-node gemappt ohne die Bahnsteige - ich revertier dir jetzt den Changeset!” Bitte nicht!
Ich gebe Weide recht. Das wäre wirklich schwierig bis unmöglich hier alle Möglichkeiten zu berücksichtigen.
Das highway=bus_stop ist dann wirklich eine Anweisung für das Bussymbol.
Die Notwendigkeit einer Stopposition bei einer normalen Haltestelle ist mir nicht klar. Mit einer Node mit highway=bus_stop und public_transport=platform neben der Straße ist die Richtung der Haltestelle festgelegt. Für was brauche ich dann noch die Node auf der Straße?
Bei einer Fläche als Platform habe ich, neben dem Routenanalyzer, noch das Problem, das bei einer Fläche mit highway=bus_stop das Bussymbol gerendert wird nicht aber die Fläche.
Bei highway=platform wird die Fläche gerendert, aber kein Bussymbol. Hier wäre die Stopposition angebracht. Oder man setzt auf einen Eckpunkt der Fläche highway=bus_stop und public_transport=platform. Dann natürlich kein public_transport=platform auf die Fläche. Diese Node wird in die Relation aufgenommen. Damit funktioniert der Analyzer und alles wird gerendert.
Wenn die Haltestellen aber genau gegenüber liegen und gleiche Tags hätten, dann kann man auch einfach einen Node auf die Straße machen und die beiden neben der Straße weglassen. Dann hat man den umgekehrten Fall.
Aber nur im “Nebenberuf”. Es sind schon echte Objekte, nämlich Bushaltestellen. Ob sie in PTv2 als stop_position oder als platform zählen, hängt von ihrer Lage auf oder neben der Straße ab – aber auf jeden Fall zählen sie. Und sie sind die einzigen Bushaltestellen, die PTv1 versteht.
Gibt es nicht. highway=bus_stop ist nur für Nodes. Es ist die alte Art der Bushaltestelle und da waren nur Nodes zulässig. In den alten PTv1-Routen sind einfach alle Nodes Haltestellen (jede ein Halt) und alle Wege Fahrwege. Deswegen braucht man in PTv1-Routen auch keine Rollen zur Unterscheidung von Haltestellen und Fahrwegen während in PTv2-Routen Haltestellen ohne Rolle und Fahrwege mit Rolle strikt verboten sind.
@Weide Was macht eigentlich die dankenswerterweise von Dir angestoßenen Diskussion um Public Transport Vorschlag P3 (siehe http://gafte.de/onewebmedia/memo.pdf Ich war diese Woche in Lübeck auf dem OSM-Stammtisch und fühle mich in meiner Einschätzung bestätigt, dass PTv2 (besonders hinsichtlich der Fahrwege) zu komplex ist. Da würde die “Segmente” aus Deinem Vorschlag viel Begeisterung auslösen würde.
Na ja, auf Begeisterung bin ich noch nirgendwo gestoßen. Ab und zu finde ich noch ne Macke oder ne Verbesserung und ändere was. Da diskutiere ich aber i.W. mit mir selbst und das ist … äh … überraschungsarm.
Ich will ja nicht behaupten, dass er die fertige Lösung ist. Er birgt aber (aus Sicht des Menschen, der einen Fahrweg in eine Relation packen will (oder solche pflegen will) mit den Relationssegmenten eine wichtige Verbesserung.
Es löst Taggingprobleme. Aber was wollen oder können wir überhaupt mit den Routen machen? Mir fällt da im Moment nur das Fußgängerrouting beim Umsteigen und am Anfang und Ende der Reise ein (+Fahrradrouting und Autorouting bei einigen Fähren). Dazu brauchen wir aber die wirklichen Platforms …
Das ist, finde ich, der richtige Ansatz für ein PTv3.
Mir ist aktuell keine Karte oder Anwendung bekannt, die die mit viel Mühe erfassten Routen(varianten) auswertet. Ich wüsste auch nicht, warum sich ein Programm damit auseinandersetzen sollte, denn es gibt wohl nur sehr wenige Städte oder Regionen, in den >80 Prozent der Routen(varianten) PTv2 konform erfasst sind. Ich habe mal vor einem halben Jahr mit putr ein paar norddeutsche Städte durchsucht und fand da sehr viel Verbesserungspotential).
Fahrwege von Bussen, wenn sie variantengenau erfasst werden sollen, müssen alle halbe Jahr mit dem Fahrplanwechsel überprüft werden. Wenn dann das Ändern oder Erfassen von Routen nicht einfach von der Hand geht, wird die Motivation fehlen.
Und ob man diese Routen wirklich für das Routen gebrauchen kann? Sicher nicht! Denn dann müsste die Variante dem Fahrplan zugeordnet werden können, damit um 10.00 Uhr morgens kein Routingvorschlag kommt, der die Samstagsvariante nutzt. PTv2 schlägt aber kein tagging vor, dass das sicher ermöglichen könnte. Wir schaffen also Datenfriedhöfe, die keiner nutzen kann. Dann kann man es auch sein lassen und je Linie eine Relation schaffen, die alle Fahrwege beinhaltet und für eine Einfärbung von Karten taugt, in denen die Linienwege wiedergegeben werden - dann aber bitte auch mit Richtungspfeilen.
Positiv formuliert.
Der Nutzen eine Fahrweg-Relation aus Sicht einer Karte die Darstellung einer Streckenkarte.
Für Auswertungen ist es sicher sinnvoll zu wissen, ob auf einem Wegstück wenigstens ab und an ein Bus fährt (und wenn ja, in welche Richtung).
Eine Auswertung “fährt da in der nächsten Stunde ein Bus” halte ich für vorstellbar, weiß aber nicht, wie und ob - man solche Daten in der OSM-DB mit vertretbarem Aufwand hinterlegen könnte.
Da scheint es mir sinnvoller, sich erstmal auf die Plattformen zu konzentrieren, um sowohl ein Fußgängerrouting zu oder von einer Plattform als auch die Darstellung auf einer Karte zu gewährleisten.
)