ÖPNV BUS-Haltestellen Schema

Hallo Julia,

EJ_ wrote:

Wir bekommen aber viele unterschiedliche Anmerkungen von Mappern wie wir es anders machen sollen.

Mich würde interessieren, wer das alles war. [1] :-) (Ich habe bisher keine Kritik an Bushaltestellen geäußert, ich fahre Bahn 😄) 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. 🙂

EJ_ wrote:

Deshalb hier unserer Frage an alle: Wie sind BUS Haltestellen mit einer Plattform als Linie oder Fläche zu taggen?

Hier scheinen viele unterschiedliche Meinungen zu herrschen. Deswegen wäre es schön, eine einheitliche Lösung zu finden.

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.

Hier (Zerbster Straße, Dessau) gibt es richtige Plattformen, die man als Fläche oder Linie mappen kann: http://www.mapillary.com/map/im/YEmePA0Y98GhYXoE1Ld8Uw

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.

Nakaner wrote:

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.

Wie war der Kompromiss?

Nakaner wrote:

Auf dem Treffen in Dortmund Ende März war es auch Gegenstand der Diskussion.

Ist das irgendwo dokumentiert?

Swen Wacker wrote:

...Ist das irgendwo dokumentiert?

http://wiki.openstreetmap.org/wiki/VRR_Tagging#Platform

Nakaner wrote:

Ich würde den dortigen Kompromiss zur Übernahme vorschlagen.

Einigkeit gab es dort nicht.

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.

Weide

Weide wrote:

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.

Was macht man denn dann an einem Busbahnhof wie dem da?

Prince Kassad wrote:

Weide wrote:

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.

Was macht man denn dann an einem Busbahnhof wie dem da?

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.

frohes Mappen
Weide

Weide wrote:

Nakaner wrote:

Ich würde den dortigen Kompromiss zur Übernahme vorschlagen.

Einigkeit gab es dort nicht.

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.

Weide

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.

Ein Kompromiss bedeutet ja nicht unbedingt, dass alle einer Meinung sind, daher ja Kompromiss.

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.

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.

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.

ptv1 wäre nur für die Darstellung auf der Karte (quasi for rendering), ptv2 für die Routen.

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.)

Persönlich bin ich weiterhin der Meinung, ptv1 auslaufen zu lassen und ptv2 nur noch rendern zu lassen.

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.

frohes Mappen
Weide

Weide wrote:

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.
Weide

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.

Weide wrote:

ptv1 wäre nur für die Darstellung auf der Karte (quasi for rendering), ptv2 für die Routen.

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.

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.

Weide wrote:

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.)

Es bleibt aber auch die Frage, warum die Renderer sich an dieser Stelle nicht bewegen?

weide wrote:

ptv1 wäre nur für die Darstellung auf der Karte (quasi for rendering), ptv2 für die Routen.

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.

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.

Thoschi

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.

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.

Genau das wollen wir doch zumindest im VRR, also ptv1-Routen abschaffen.

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 :-))

Weide wrote:

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. 🤣

Weide wrote:

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.

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.

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.

Weide wrote:

Eine VRR-Lösung nützt nichts; wir müssen eine weltweite Lösung haben und die gilt dann auch für den VRR.

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.

viw wrote:

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.

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.

Weide

Thoschi wrote:

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.

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.

Weide

Weide wrote:

Thoschi wrote:

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.

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.

Weide

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

Thoschi wrote:

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.

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.

Weide

Hallo zusammen,
ich frage mal allgemein.
Ich denke wir alle sind uns einig, dass wenn eine Plattform als Fläche vorhanden ist, wird auch eine Fläche gezeichnet. Bei einer kleinen Haltestelle am Bordstein nur ein Punkt.

Highway=platform wird nicht mehr verwendet?

Was passiert mit Highway=bus_stop, wenn die Plattform als Fläche erfasst ist? Kommt der Tag dann ganz weg, wird er auf einen neuen Knoten gesetzt? Kommt er mit zu public_transport=stop_position? Wenn Letzteres der Fall ist: Warum wird der Tag dann nicht immer dort gesetzt?

Viele Grüße,
Julia

EJ_ wrote:

Highway=platform wird nicht mehr verwendet?

Es wird benutzt und angezeigt. Es spielt aber keine besondere Rolle für die Routen.

EJ_ wrote:

Was passiert mit Highway=bus_stop, wenn die Plattform als Fläche erfasst ist? Kommt der Tag dann ganz weg, wird er auf einen neuen Knoten gesetzt?

Darüber streiten wir.
Ich vertrete, dass highway=bus_stop dann an die stop_position gehört.

EJ_ wrote:

Warum wird der Tag dann nicht immer dort gesetzt?

Weil man dann in der Karte nicht sieht, für welche Fahrtrichtung die Haltestelle ist. Wenn ein mit highway=platform markierter Steig daneben liegt, dann sieht man es allerdings daran.

Außerdem muss man ja nicht unbedingt eine stop_position mappen ... nur ein Node neben der Fahrbahn mit highway=bus_stop ist ja auch schon eine komplette Haltestelle.

Weide

Weide wrote:

EJ_ wrote:

Highway=platform wird nicht mehr verwendet?

Es wird benutzt und angezeigt. Es spielt aber keine besondere Rolle für die Routen.

Ist aber für Fußgängerrouting von und zur Haltestelle ggf. interessant, u.a. auch, ob barrierefrei erreichbar oder nicht. Dieses Routing von Verkehrsunternehmen fängt gerade erst an.

Weide wrote:

EJ_ wrote:

Was passiert mit Highway=bus_stop, wenn die Plattform als Fläche erfasst ist? Kommt der Tag dann ganz weg, wird er auf einen neuen Knoten gesetzt?

Darüber streiten wir.
Ich vertrete, dass highway=bus_stop dann an die stop_position gehört.

Darauf haben wir uns erstmal innerhalb des VRR verständigt. Andere sind der Meinung, dass dies an einen Knoten der Plattform gesetzt werden kann. Vorteil wäre, dass die Haltestelle zurzeit auf der richtigen Strassenseite gerendert wird, Nachteil, dass 2platformen in dem alten Routenschema erscheinen, da PTv2 nocht nicht umgesetzt ist.

Weide wrote:

Außerdem muss man ja nicht unbedingt eine stop_position mappen ... nur ein Node neben der Fahrbahn mit highway=bus_stop ist ja auch schon eine komplette Haltestelle.

Zumindest per Definition. Wobei ich der Auffassung bin, zu einer Haltestelle gehört die stop_position und die platform und ich würde auf highway=bus_stop am liebsten ganz verzichten und lieber den "Mast" z.B. als "man_made=pole" und "pole"=bus_stop" setzen, um dies als Platzhalter für ein Haltestellensymbol zu nehmen. (Aber mit dem Vorschlag läuft man geschlossene Türen ein...)

Thoschi wrote:

und lieber den "Mast" z.B. als "man_made=pole" und "pole"=bus_stop" setzen, um dies als Platzhalter für ein Haltestellensymbol zu nehmen. (Aber mit dem Vorschlag läuft man geschlossene Türen ein...)

Ich würde lieber ein abstraktes Objekt "da muss man hingehen, um mit dem Bus zu fahren" nehmen. Ich hab in Schweden öfter die Sitte "ein Mast reicht doch für beide Richtungen" gefunden und der war dann manchmal sogar auf der "falschen" Straßenseite, weil man ihn da besser sehen konnte...

Auch bei Gate-Systemen, bei denen Passagiere im Gebäude warten müssen bis der Bus steht und danach erst auf den Steig mit dem Mast dürfen, ist der Mast für den Passagier uninteressant. Da sind die Sitzplätze im Gebäude das Ziel des Passagiers.

Weide

Weide wrote:

Auch bei Gate-Systemen, bei denen Passagiere im Gebäude warten müssen bis der Bus steht und danach erst auf den Steig mit dem Mast dürfen, ist der Mast für den Passagier uninteressant. Da sind die Sitzplätze im Gebäude das Ziel des Passagiers.

Hattest Du mir in Do Bilder von diesen Gates gezeigt? Ja, oder?
Aber auch hier ist dann für ein Fußgänger-Routing ODER, wenn man mal soweit ist für ein verkehrmittelübergreifendes Routing interessent, an welches Gate (m.E. dann gleichzusetzen mit Platform) er muss. Solche Gebäude wie in Schweden sind aber in unserer Verkehrslandschaft noch Utopie und bei der Bushaltestelle auf dem Lande funktioniert dass dann eh nicht.
Ein Mast für beide Richtungen würde dann reichen, wenn die Haltestellen direkt gegenüber sind, was nach meiner Erfahrung im ländlichen Raum bei uns nur in wenigen Fällen gegeben ist.

Thoschi wrote:

Hattest Du mir in Do Bilder von diesen Gates gezeigt? Ja, oder?

Kann gut sein. Ich hatte solche Bilder mitgebracht.

Für alle: Hier ein Beispiel: http://kartor.eniro.se/m/ksflo

Weide