Proposed features/Drop stop positions and platforms

Ich finde den Vorschlag abstrus.

Er schlägt vor, die public_transport tags optional zu machen. Nur … das sind sie in PTv2 schon.

Er kritisiert, dass hunderte oder tausende Haltetellen schon da waren und man die nicht alle ummappen kann. Gemäß PTv2 muss man keine einzige alte Haltestelle ummappen.

Er behauptet, dass man statt eines Node jetzt mindestens zwei Objekte mappen müsste. Das ist in PTv2 nicht so.

Die Gründe für die Einführung von public_transport=stop_position und public_transport=platform kommen da überhaupt nicht vor und scheinen völlig unbekannt zu sein.

PTv2 ist da nicht wiederzuerkennen.

Ich schließe mich @Weide an.

Ilya scheint ausschließlich etwas wieder entfernen zu wollen, was nicht mandatory ist.

Das, für mich alte Problem, bleibt bestehen: wie ist die Position von highway=bus_stop definiert? Neben oder auf der Fahrbahn?

Über dieses Problem geht er ganz nebenbei hinweg indem er bei public_transport=stop_position sagt:

Eine Lösung biete er aber auch nicht.

Ich finde es steckt schon ein bisschen Wahrheit darin.

public_transport=stop_position finde ich haben sehr oft eine sehr schlechte Qualität. Meines Erachten wurden die meisten Stop-Positionen geraten oder angenommen Anhand der Plattform, aber nicht vor Ort aufgenommen. Eine Stop-Position in der Lage zu korrigieren, wenn es größere Entpfernungen sind oder um Kurven, ist meist sehr aufwendig da der Punkt auf einer Straße plaziert ist und nicht immer einfach verschoben werden kann. Sollte der Weg auch noch aufgetrennt sein kann man schon mal Stunden damit verbringen die Relationen zu begutachten und zu korrigieren oder man lässt es so. Das Tagging ist auch sehr wechselhaft.

public_transport=platform gibt es auch sehr viele Konstruktionen wo ich sage: Das hat auch nichts mehr mit der Wirklichkeit zu tun. Da werden irgendwelche Flächen und Wege gezeichnet die vor Ort noch nie gesehen habe. Im Tagging oft Doppelungen.

Am liebsten sind mir einzelne Nodes für jede Fahrrichtung die man ausführlich Taggen kann. public_transport=stop_position werd ich nicht mehr unterstützen… das ist mir ehrlich gesagt zu blöd auf Dauer, das kann gerne wer anders machen :frowning:

Warum immer wieder diese Frage… Antwort: neben der Fahrbahn… ich such es nicht wieder aus dem Wiki raus: siehe highway=bus_stop

Es besteht keinerlei Notwendigkeit die detaillierten Haltestellen wegzuschmeißen , wie Weide oben beschrieben hat.

Das Verständnisproblem bei Neu-Mappern besteht darin, das wir im wiki den Unterschied zwischen PTv1-Routen und PTv2-Routen nicht deutlich machen, sondern nur irgendwo Irgendetwas davon beschreiben.

iD - Editor hatte in den letzten Tagen einige Probleme mit der Reihenfolge der Haltestellen. Diese Probleme wurde aber jeweils binnen zwei Tagen gelöst. Dieser Editor ist nach meiner Meinung nicht ideal zur Bearbeitung von Routen, aber wir haben doch einige Mapper, die Routen damit korrekt erstellen und bearbeiten können.

OK, mag sein, dass das vor längerem genauer definiert wurde.

Die Realität sieht leider anders aus, highway=bus_stop sehe ich häufig noch auf der Straße, oder machnmal sogar als way oder area neben der Straße.

highway=bus_stop ist “vom Namen” her nicht eindeutig auf oder neben der Straße (und welcher Anfänger liest schon für jeden tag das Wiki?). Hier hat public_transport=stop_position einen gewissen Vorteil: keine Historie und eindeutiger.
Verzichten könnte ich auf die stop_position aber auch.

Was Du da sagst spricht überhaupt nicht gegen PTv2 … nur gegen die verbreiteten PTv2-Irrtümer.

Wenn man eine Bushaltestelle mit einem Node gut beschreiben kann, dann sollte man das einfach tun. Das ist die beste Lösung. Das ist gültiges PTv2 und funktioniert ganz ohne public_transport=xxx. Das highway=bus_stop ist voll gültig in PTv2.

Nur wenn Du mehr mappen willst brauchst Du die public_transport=xxx - Tags. Z.B. ist highway=bus_stop nicht zulässig für Linien und Flächen (denn das würde PTv1-Routen kaputt machen oder anderen Mappern verbieten, dort PTv1-Routen anzulegen).

Oder: Sollte jemand unbedingt beide Möglichkeiten mappen wollen (stop_position und platform), dann darf wegen der Regeln zu highway=bus_stop nicht an beiden das highway=bus_stop stehen. Daher braucht man in dem Fall einen Ersatz und den macht PTv2 möglich.

Das ist über lange Zeit historisch gewachsen. Ganz früher (als die Straßen noch Dinosaurierspuren hatten) waren auch große Kreuzungen einfach zwei Striche mit einem gemeinsamen Punkt und an den Punkt hat man highway=bus_stop und name=soundso geschrieben, wenn es an der Kreuzung Bushaltestellen gab.

Dann waren alle highway=bus_stop auf der Straße und es brach ein Streit aus, ob man an die Nodes für eine Richtung sowas wie “dir=NW” schreiben soll oder ob man sie besser neben die Straße legen soll. Auch ein shelter=yes auf der einen Straßenseite und “no” auf der anderen war schwer auf der Straße zu mappen.

Wir sind dann eigentlich einvernehmlich dazu gekommen, dass man sie gewöhnlich neben die Straße legt.

PTv2 hat dann Linien und Flächen als Platforms neben der Straße möglich gemacht ohne PTv1 kaputt zu machen. PTv1 kann aber nur Nodes für Haltestellen. Jetzt gab es nur die Möglichkeit, bei Linien oder Flächen als platform das highway=bus_stop im Node unterzubringen. PTv1 verlangt ja genau einen highway=bus_stop-Node pro Halt … nicht mehr und nicht weniger. PTv2 verbietet aber einen zusätzlichen Node. Also geht bei Linien oder Flächen als Platform nur das Taggen der stop_position mit highway=bus_stop und das liegt auf der Straße.

Man kann es sich auch so hindrehen wie man es gerne hätte. highway=bus_stop => public_transport=platform! Obwohl public_transport=platform erstmal garnichts heißt, weil da kann theoretisch alles halten…public_transport=platform + bus=yes wäre dann korrekt das Klarheit bestände. Und wenn du sagt darf man nur als node erfassen werden dann muss es getrennt gemappt werden…

public_transport=stop_position sieht kein highway=bus_stop vor, siehe Wiki.

https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform

Jetzt wurde highway=platform als Fehler erhoben… zumindest im Englischen Teil des Wikis

PTv2 unterscheidet klar zwischen dem Fall in dem highway=bus_stop public_transport=stop_position entspricht und dem Fall, in dem es public_transport=platform entspricht. In beiden Fällen ist damit klar, dass man es nicht als zusätzlichen Node zu zwei bereits vorhandenen Objekten des Haltes verwenden darf. PTv2 verlangt ganz explizit, dass sämtliche stop_positions und sämtliche platforms in die Routen gehören und man kann in eine PTv2-Route keine drei Halt-Objekte reinschreiben und dabei weniger als zwei Halte des Fahrzeugs bekommen.

Die Idee, an eine Platform bus=yes oder ähnliches zu schreiben, ist PTv2 unbekannt. Platforms gehört zu allen Linien in denen sie erwähnt werden.

Ja aber wie soll z.B. eine Software damit umgehen? Wenn einmal highway=bus_stop mal hier mal dort ist? Was ist wenn die Software public_transport=platform unterstützen möchte? highway=bus_stop einfach fallen lassen? Nein geht noch nicht… weil ca. > 1 Million Objekt haben noch kein public_transport=platform getaggt. Wie gehe ich mit beiden um, in den unterschiedlichen Situationen? Verblase ich unendlich viel Rechenleistung um Umkreise abzusuchen… tagging auszuwerten um abzuwägen was ich im Einzelfall dann zu machen ist? Wo platziere ich Symbole bei Platform-Ways, welche lat/lon verwende ich für mein Routing… usw. usw.?

Am besten wäre highway=bus_stop + public_transport=platform als eine Node zu belassen, mit allen Informationen, und die ganzen anderen Dinge extra zu Erfassen und meinetwegen in einer Relation public_transport=stop_area zusammenzufassen.

Man sollte hier die Dinge nicht ins Unendliche kompliziert machen… da verbaut man sich nur selbst die Dinge. Wie z.B. das es public_transport=platform nicht dargestellt werden kann im Standard-Tiles oder falsch wie bei http://www.öpnvkarte.de

mfg Miche

Abgesehen von der Einhaltung der alten Regeln:
1.: highway=bus_stop darf nur an Nodes
2.: Zu jedem Haltevorgang des Busses gehört nur ein highway=bus_stop
ist es nicht so wild:

highway=bus_stop in einem bus-geeigneten Weg wird als public_transport=stop_position mit bus=yes behandelt und highway=bus_stop woanders wird als public_transport=platform behandelt. Das wars. Sobald man es übersetzt hat, muss man sich nicht mehr darum kümmern. Jetzt sind keine Probleme mehr da, die man ohne highway=bus_stop nicht auch hätte.

Es wird also nie highway=bus_stop fallen gelassen und es sind auch nie besondere Regeln für highway=bus_stop in verschiedenen Situationen nötig oder irgendwelche Suchen.

Ja, da sind wir uns fast immer einig. Fast alle über-komplizierten Konstruktionen beruhen auf Missverständnissen von PTv2. Wenn ein Node als Platform reicht, dann sollte man diesen Node mappen und das wars. PTv2 verlangt nicht, dass man eine stop_position hinzufügt oder Multipolygone als Platforms nimmt oder alles mit stop_areas zupflastert. Man kann sogar einen Node auf der Straße für beide Richtungen nehmen, wenn die Halte einander gegenüberliegen und gleich ausgestattet sind. PTv2 hat nichts dagegen.

Ja. Da kommen wir zu einem echten Schwachpunkt von PTv2. Es gibt soviel Optionales beim Mappen der Haltestellen, dass man ohne Analyse aller beteiligten Routen bei einer Ansammlung von Halt-Objekten Probleme bekommt, auf Karten Symbole zu plazieren. Nur stops ist falsch, nur platforms geht auch nicht und immer beides anzuzeigen ist noch schlimmer. Deshalb ist es verbreitet, das highway=bus_stop für die Symbole zu benutzen und Namensgleichheit statt stop_areas für Haltestellen zu nehmen. (Deshalb hab ich damals das Analyseprogramm geschrieben, dass aus den Daten einer ganzen Gegend etwas von mkgmap auswertbares macht.) Da müssen wir beim nächsten Schema gut überlegen, wie man sowas vermeidet.

Die ÖPNV-Karte war unter PTv1 ideal … einfach klasse. Mit PTv2 wurde z.B. die Ermittlung der genutzten Wegrichtungen echt schwierig. Dass man dann noch die üblichen Fehler der Mapper bei der Kartenerzeugung berücksichtigen muss, hat die Sache fast unlösbar gemacht.

Man sieht es ja was so Software technisch so los ist. Viele ungelöste Probleme über Jahre hinweg… Es bleibt immer noch bei den Versprechungen was man damit alles machen könnte… nichts ist davon ist Realität. Der Mehrwert ist gegen null…

Wenn ich das umtagging an den Haltestellen betrachte würde ich ein minus davor setzen.

Dann sollte das auch mal in der Dokumentation => Wiki klar dargestellt werden. Und nicht wie jetzt unterschiedlich, über viele Seiten verteilt… mit groben Abweichungen zwischen den Übersetzungen usw.

Detail-mapping hat jeder das recht das zu machen… aber wie setzt man das am besten um… wie schaut es mit dem tagging aus Vor-/Nachteile usw.

Bei PTV1 hat man auch aufpassen müssen… aber man hat nur eine Relation gebraucht und keine Vielzahl :expressionless:

Hört sich für mich (als KISS Fan) erstmal gut an.
Haben die Profis (VRR, Mentz) da eigentlich schon was zu gesagt? Kann zB auf die stop-Position wirklich verzichtet werden?

Wenn die auf GTFS (General Transit Feed Specification) setzen als Technologie für das Routing würde ich sagen: Ja, da bräuchte man nur eine node die “Platform” wo man aus- bzw. einsteigt.

Auf der FOSSGis gab es einen schönen Vortrag dazu die sich mit dem Thema ÖPNV und OSM usw. beschäftigten und kombinierten:

Open Source Erreichbarkeitsanalysen im ÖPNV
https://media.ccc.de/v/2018-5379-ersatz_open_source_erreichbarkeitsanalysen_im_opnv

Die haben professionell überraschenderweise nichts mit dem ÖPNV in OSM zu tun. Es werden Nodes aus den Datenbanken der Verkehrsunternehmen als Start und Ziel des Fußgängerroutings beim Umsteigen benutzt und OSM-Daten nur für die Fußwege dazwischen. Es ist für diese Anwendungen ganz egal, ob da railway=platform oder highway=footway steht und welche weiteren Tags und Relationen da dran hängen.

Ich denke, dass wir in einem PTv3 komplett auf Haltepositionen des Fahrzeugs verzichten sollten. In PTv2 hätte die Abschaffung einige üble Nebenwirkungen und die Begründung der Abschaffung bezieht sich auf Regeln, die PTv2 garnicht hat. Es gibt nur viele Mapper, die auf die im Vorschlag kritisierte Art mappen. Der Vorschlag legt den Finger auf real existierende Wunden und er sollte gelesen werden … aber die Lösung ist nicht die Änderung von PTv2 sondern die Anpassung der Praxis an PTv2 und längerfristig ein neues Konzept.

Und wieso werden dann Daten von MENTZ und VRR in OSM eingetragen oder geändert?
Auf Fehler (Gebäude im Gebäude, level Angaben, Fußwege in Gebäuden, …) wird auch nicht reagiert.

Ich würde sagen für das Routing nach dem ÖPNV-Routing… also den Fuß-/Autoweg zum und weg von der Haltestelle

Siehe https://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit
Es werden vor allem Routing (Linienverläufe, Fußwege), Umgebungspläne, Linienpläne gemacht; Pläne zum Ausdrucken generiert; außerdem werden POI aus OSM in der Suche und allgemein eine Hintergrundkarte in den Apps verwendet.
Dann ist es doch auch normal, dass von denen OSM bearbeitet wird, vor allem damit die Daten besser werden.

Andersherum verwende ich deren Daten um sie mit OSM zu vergleichen und dann Fehler zu melden, das geht dann leider aber nur mit Umwegen und langen Wartezeiten, weil Daten wie Haltestellen und Steigzuordnungen ja komplett intern gepflegt werden und aus OSM nur sehr indirekt (z.B. als Hintergrundkarte) Daten dort einfließen und Fehler manuell korrigiert werden (oder auch nicht).