Vorschlag Wochenaufgabe: ÖPNV-Haltestellen

Ich kann anbieten, stupide zu wiederholende Zählungen durch OSM Count zu triggern. Noch hält sich die von mir gewünschte Flexibilität in Grenzen, das ganze ist noch stark auf die Gemeindeschlüsselstruktur fixiert, aber es soll ja noch flexibler werden.

Christoph

Wäre interessant, da in meiner Gegend nahezu alle Haltestellen entweder noch nach v1 oder gleich völlig falsch getaggt sind. (platform und stop verwechselt, und so...)

Also da wäre ich dabei. Kann aber leider nicht mit Vorarbeit dienen, nur als armer Knecht, der jeden Wunsch erfüllt. (Nach 4.000 hochgeladenen Objekten in Überherrn tun mir die Hände weh...)

Hachja, ich trage momentan auch gerade die ganzen alten oder fehlenden Buslinien bei uns nach. Die haben leider teilweise in jede Richtung 5 verschiedene Varianten (macht dann einen route_master mit 10 Mitgliedern) und da geht dann pro Linie gerne mal ein ganzer Tag drauf, bis ich wirklich die ganzen Haltestellen abgeklappert habe, etc. Ist eher eine Monatsaufgabe 🤔

Das erinnert mich an einen interessanten Fall:

Seit dem Fahrplanwechsel in, ich glaube 2010 war das, gibt es bei uns eine neue Haltestelle namens "Carl-Benz-Straße".
Dort hat man aber nie eine Haltestelle aufgebaut, sondern einfach zwei Schilder mit der Beschriftung "Ersatzhaltestelle" hingestellt. Die stehen da bis heute.

Wenn wir ganz, ganz streng nach dem on-the-ground mapping gehen, müsste die Haltestelle in OSM dann doch "Ersatzhaltestelle" heißen, und nicht "Carl-Benz-Straße". Oder sehe ich das falsch?

Ha! Genau das Problem habe ich hier auch. Es gibt eine Haltestelle "Hinteres Finsingermoos". Seit letztem Jahr nun wird eine andere angefahren, aber auf dem Fahrplan und in den Ansagen im Bus kommt immer noch "Hinteres Finsingermoos", obwohl auf der Haltestelle nur "Schulbus" steht. Ich habe das nicht geaendert und so faehrt der Bus offiziell die Haltestelle Schulbus an in OSM. Ich halte das zwar fuer Unsinn, aber ich meine, hier gelesen zu haben, dass jemand mal sagte, wie man die Diskrepanz zwischen Fahrplanname (z.B. "Oberding, Markt" - aber am Schild steht nur "Markt") und Name auf dem Schild taggen kann. Ich finde den Faden allerdings gerade nicht mehr.

Edit: Hab's gefunden. Man sollte mit "name" taggen, was auf der Haltestelle steht und mit "ref_name" das, was im Fahrplan steht.

Nadjita wrote:

Edit: Hab's gefunden. Man sollte mit "name" taggen, was auf der Haltestelle steht und mit "ref_name" das, was im Fahrplan steht.

Hmm, falls ich das war...: Ich würde dann doch eher mappen, was sein sollte. Wenn aber auf dem Schild "Bahnhof" steht, dann sollte man daraus nicht "Hintertupfingen Bahnhof" machen (auch wenn es sich auf der Karte besser macht).

Weide

PS: ref_name ist zum Nachschlagen im Internet. Da sollte man hier in Deutschland irgendwas suchen, dass sowohl bei der Bahn als auch bei der lokal üblichen Verkehrsauskunft klappt. Garantiert braucht man das bei Namen wie "Rathaus" oder "Goethestraße".

Hallo,
ich habe im letzten Jahr die Buswartehallen (ja die heißen so) (-häuschen) hier in der Umgebung eingezeichnet. Und einige völlig daneben liegende Haltestellen verschoben.
Wer die suchen möchte sollte sich bei der Gemeinde / Stadt an den Bauhof wenden. Die sind für die Unterhaltung zuständig. Nett fragen dann bekommt man eine Liste mit den Haltestellen die über eine "Wartehalle" verfügen.
Aber nicht immer sind die auch direkt an den Haltestellen.
Ich werde dieses Jahr mal die ein ober andere Runde mit dem Fahrrad fahren und mir die Haltestellen ansehen. Geht aber nicht in einer Woche... 😉

Prince Kassad wrote:

Wenn wir ganz, ganz streng nach dem on-the-ground mapping gehen,

"Good practice" heißt ja nicht, den Verstand auszuschalten, finde ich :-) Offenkundige (Schreib)Fehler aber auch offenkundige Versäumnisse bei der Namensgebung vor Ort sollte man m.E. stillschweigend korrigieren. Die alleinige Information "Ersatzhaltestelle" ist richtig aber offenkundig sinnlos. Wer von dort abfahren möchte und die Fahrplanverbindung online suchen muss -l der Plan an der Haltestelle ist durch Vandalismus gerade unlesbar - braucht den "richtigen" Namen. Wer wissen will, wie die Haltestelle heißt, bei der er aussteigen will, will - wenn er z.B. gerade im Bus sitzt und auf sein Smartphone schaut - den "richtigen" Namen auf der Karte sehen. Der Umstand, dass dort offenkundig veraltet (noch) "Ersatzhaltestelle" steht, kann dann ja gern in eine Note gepackt werden (mit Datumsangabe).

Ich hab mich mal an einem Beispiel versucht:

https://www.openstreetmap.org/relation/4583580

Stimmt alles, hab ich alles richtig gemacht, fehlt irgendetwas?

Prince Kassad wrote:

Stimmt alles, hab ich alles richtig gemacht, fehlt irgendetwas?

Perfekt.

Nur in den Routen dazu hab ich was gefunden. Bei der Reihenfolge stop-platform ist es ein Halt mit zwei Angaben, bei platform-stop sind es zwei Halte mit je einer Angabe.

bis dann
Weide

Zur Ausstattung:
Auf der Wikiseite ( http://wiki.openstreetmap.org/wiki/DE:T … 3Dbus_stop ) fehlt mir als Ausstattung:
- tactile_paving : hier bei mir in der Stadt werden neue/umgebaute Haltestelle damit ausgestattet
- Der Bordstein ist an Haltestellen als erhöht, damit, wenn der Bus sich absenkt, man "eben" einsteigen kann. Wie wird soetwas dann gemappt?
- Wie werden "Drängelgitter" an Bushaltestellen gemappt?
- Wie werden Stehhilfen gemappt? (Bsp: http://hank-reshape.blogspot.de/2011/12 … telle.html ; https://hms-nvv.etc-consult.de/nvv_hms/ … -1fdfi.jpg )

Maskulinum wrote:

Auf der Wikiseite ( http://wiki.openstreetmap.org/wiki/DE:T … 3Dbus_stop ) fehlt mir als Ausstattung:

Wo Du auf highway=bus_stop verlinkst. Dort lese ich Sätze wie

Allerdings verwenden einige lokale Gruppen den tag auf eine andere Weise, aus welchem Grund einige den (less-standard ?) public_transport=platform zusammen mit highway=bus_stop neben der Straße verwenden

während im Ausgangsposting unter anderem

mueschel wrote:

- Umstellen auf das neuere v2-Schema wo notwendig

steht:

Sind wir uns einig, dass die "lokale Gruppe" Deutschland umfasst? Und wie definieren wir "notwendig"? Müssten man sich darauf einrichten, dass es eine nennenswerte Anzahl von Nutzern gibt, die etwa bei der Anlage von public_transport=stop_position oder bei der Ergänzung vonpublic_transport=platform o.ä. den Untergang des Abendlandes beklagen? Und warum steht da überhaupt "less-standard"?

Swen Wacker wrote:

Sind wir uns einig, dass die "lokale Gruppe" Deutschland umfasst? Und wie definieren wir "notwendig"? Müssten man sich darauf einrichten, dass es eine nennenswerte Anzahl von Nutzern gibt, die etwa bei der Anlage von public_transport=stop_position oder bei der Ergänzung vonpublic_transport=platform o.ä. den Untergang des Abendlandes beklagen? Und warum steht da überhaupt "less-standard"?

Das less-standard kommt direkt aus dem Englischen und sollte weg, PTv2 ist Standardm, so wie bus_stop auch.

Ich störe mich eher an dem hier, dies sollte mit Hinblick auf Kompatibilität zum PTv2 nicht empfohlen werden:

Es ist zum Teil auch üblich, highway=bus_stop auf die Straße zu setzen, falls die Position der Haltestellen nicht genau bekannt ist, zwei Haltestellen genau gegenüber liegen, oder aus analogie zum railway=tram_stop. Im letzterem Fall wird highway=platform als Punkt/Linie/Fläche Anstelle des sonst üblichen Knotens highway=bus_stop gestzt.

Unter http://wiki.openstreetmap.org/wiki/DE:H … altestelle hat Nakaner die aktuell "beste" Version kodifiziert. Einzige Dikussion die für mich da noch übrig bleibt wohin mit dem bus_stop? Meiner Meinung nach als Node auf public_transport=platform, bis jetzt steht aber nur "neben der Straße ein weiterer Node".

Jojo4u wrote:

Unter http://wiki.openstreetmap.org/wiki/DE:H … altestelle hat Nakaner die aktuell "beste" Version kodifiziert. Einzige Dikussion die für mich da noch übrig bleibt wohin mit dem bus_stop? Meiner Meinung nach als Node auf public_transport=platform, bis jetzt steht aber nur "neben der Straße ein weiterer Node".

Meiner Auffassung nach kann man "neben der Straße" auch als "auf p_t=platform" interpretieren. Das Wort "weiterer Node" impliziert ja nicht, dass es ein von der plattform getrennter Node sein MUSS. Dies sollte man entsprechend klar stellen, dass dieser Node ein Node des Way "platform" ist oder identisch mit einem Node "platform"

Wenn der platform aber ein way oder eine area ist, dann kann man nur einen separaten Node mit dem alten highway=bus_stop dranklatschen.

Prince Kassad wrote:

Wenn der platform aber ein way oder eine area ist, dann kann man nur einen separaten Node mit dem alten highway=bus_stop dranklatschen.

Jeder way und jede area hat besteht doch aus mehreren Nodes...ich hatte es so gemeint, dass man keinen EXTRA Node in der "Pampa" setzen muss, sondern einen der verbundenen.

Und dann willst du den highway=bus_stop in die Ecke der Plattform setzen? *kopfkratz*

Bei Wegen kannst du ja noch einfach einen Extra-Node in die Mitte setzen... bei Flächen geht das nicht so einfach.

Prince Kassad wrote:

Und dann willst du den highway=bus_stop in die Ecke der Plattform setzen? *kopfkratz*

Bei Wegen kannst du ja noch einfach einen Extra-Node in die Mitte setzen... bei Flächen geht das nicht so einfach.

Guter Einwand. Wir sollten aber bedenken dass highway=bus_stop beim Detailmapping mit PTv2 nur noch für die Rückwärtskompatibilität gemappt wird, aber vermutlich noch längere Zeit das Bus-Symbol auf Standardstilen bleiben wird.

Ich bin sehr gegen den Gebrauch zusätzlicher Nodes für highway=bus_stop.

Ein Node mit highway=bus_stop zählt in PTv2 als Haltestellenangabe, da dort ja die alten Haltestellentags ausdrücklich nicht aufgehoben werden. Dann haben wir also (bei einem Node neben dem Weg) zwei Platforms, wo real nur eine ist. Das ist schonmal unabhängig von allen Folgeproblemen falsch. Zum Ausgleich die Platform durch Streichen von highway=platform unsichtbar zu machen, ist Mapping for the Renderer. Es gibt aber auch noch Folgeprobleme:

Die beiden Platforms kann man in den Routen nicht beide angeben, das ist technisch weder bei PTv1 noch bei PTv2 machbar ohne real nicht vorhandene zusätzliche Halte des Fahrzeugs zu erfinden. Die Mitgliedschaftslisten der doppelten Platforms müssen daher unvollständig sein und das hat Folgen in der Karte. Geht man in der Standardkarte mit dem "Fragezeichen" auf eine dieser Platforms und sieht so nach den benutzenden Bussen, so ist mindestens eine dieser Liste garantiert unvollständig.

Auch die stop_areas sind betroffen. Die zusätzlichen Nodes müssten rein, sonst bringt die stop_area keinen Überblick. Dann stimmt aber die Anzahl der Platforms nicht mehr.

Die automatische Suche nach Fehlern wird auch eingeschränkt. Eine unbenutzte platform ist dann kein Hinweis mehr auf Probleme in der Gegend.

Ich sehe nur eine Möglichkeit: Wenn die Platform kein Node ist, dann muss das highway=bus_stop an die stop_position. (Notfalls muss man sie dafür einrichten.)

Weide

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.

axelr wrote:

Es ist nicht sinnvoll zwingend den bus_stop an der stop_position zu verlangen.

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.

Weide

Weide wrote:

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.

Sorry, aber du sprichst von platforms wenn es um bus_stop geht, kannst du bitte das Problem welches du siehst bitte noch etwas audröseln?

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.

Zur Problematik, wohin mit dem highway=bus_stop:

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.

Weide wrote:

Ich bin sehr gegen den Gebrauch zusätzlicher Nodes für highway=bus_stop.

Ein Node mit highway=bus_stop zählt in PTv2 als Haltestellenangabe, da dort ja die alten Haltestellentags ausdrücklich nicht aufgehoben werden. Dann haben wir also (bei einem Node neben dem Weg) zwei Platforms, wo real nur eine ist. Das ist schonmal unabhängig von allen Folgeproblemen falsch. Zum Ausgleich die Platform durch Streichen von highway=platform unsichtbar zu machen, ist Mapping for the Renderer. Es gibt aber auch noch Folgeprobleme:

Die beiden Platforms kann man in den Routen nicht beide angeben, das ist technisch weder bei PTv1 noch bei PTv2 machbar ohne real nicht vorhandene zusätzliche Halte des Fahrzeugs zu erfinden. Die Mitgliedschaftslisten der doppelten Platforms müssen daher unvollständig sein und das hat Folgen in der Karte. Geht man in der Standardkarte mit dem "Fragezeichen" auf eine dieser Platforms und sieht so nach den benutzenden Bussen, so ist mindestens eine dieser Liste garantiert unvollständig.

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

Weide wrote:

Auch die stop_areas sind betroffen. Die zusätzlichen Nodes müssten rein, sonst bringt die stop_area keinen Überblick. Dann stimmt aber die Anzahl der Platforms nicht mehr.

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.

Weide wrote:

Die automatische Suche nach Fehlern wird auch eingeschränkt. Eine unbenutzte platform ist dann kein Hinweis mehr auf Probleme in der Gegend.

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.

Nakaner wrote:

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

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.

Nakaner wrote:

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.

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.

Nakaner wrote:

Dann können Auswerter erkennen, dass das keine unzureichend getaggte Plattform, sondern eine Abwärtskompatibilitätskrücke ist.

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.

Weide

Jojo4u wrote:

Sorry, aber du sprichst von platforms wenn es um bus_stop geht...

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.

Weide

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 😐

Weide wrote:

Nakaner wrote:

Dann können Auswerter erkennen, dass das keine unzureichend getaggte Plattform, sondern eine Abwärtskompatibilitätskrücke ist.

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.

Weide

Fragen:
1. Ist highway=bus_stop nicht ausschließlich Teil von ptv1 und ausdrücklich NICHT von ptv2?
2. Wird highway=bus_stop nicht NUR wegen der Abwärtskompatibilität getaggt?
3. Und hier bin ich mit nicht sicher: Sind die Routen nicht erst Teil von ptv2 und somit für bus_stop irrelevant?

Weide wrote:

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

Ich schaffe es nicht, mit dem Fragezeichen die Linien - Information auszulassen.

Nadjita wrote:

...sehr viele highway=platform hinzugefügt..,

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.

Weide

Thoschi wrote:

1. Ist highway=bus_stop nicht ausschließlich Teil von ptv1 und ausdrücklich NICHT von ptv2?

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.

Thoschi wrote:

2. Wird highway=bus_stop nicht NUR wegen der Abwärtskompatibilität getaggt?

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.

Thoschi wrote:

3. Und hier bin ich mit nicht sicher: Sind die Routen nicht erst Teil von ptv2 und somit für bus_stop irrelevant?

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 … en_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.

Weide

axelr wrote:

Ich schaffe es nicht, mit dem Fragezeichen die Linien - Information auszulassen.

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)

Weide

Das Fragezeichen-Problem ist etwas schwierig zu erkennen, aber ich habs jetzt verstanden. Also:

1. Öffne den Link von Weide http://www.openstreetmap.org/#map=19/51.15985/7.00456

2. Klicke auf das Fragezeichen

3. Klicke auf den rechten zweiten Bushalt von oben

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"

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

axelr wrote:

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"

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.

axelr wrote:

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.

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)

und alles ist in Butter.
Beispiel: http://www.openstreetmap.org/#map=19/51.16758/6.92300

Weide

Weide wrote:

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.

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.

Nadjita wrote:

Weide wrote:

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.

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.

Der beste Vergleich PTv1 und PTv2 steht bei Weide erste Tabelle http://wiki.openstreetmap.org/wiki/User:Weide

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.

Nadjita wrote:

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.

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.

Weide

Da habe ich ja eine ganz schöne Diskussion losgetreten...

axelr wrote:

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.

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?

mueschel wrote:

"Ausstattung" wäre aber auch noch ein wichtiger Punkt.

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.

Weide

Weide wrote:

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.

Imho müsste das aber an die route-Relation getaggt werden. Es gibt verschiedene Buslinien die verschiedene Fahrzeuge einsetzen. Wenn eine Haltestelle von zwei Buslinien angefahren wird und die eine rollstuhlgerecht ist und die andere nicht, wirst du Schwierigkeiten bekommen, das an die Bushaltestelle zu taggen.

Hallo,

nur als Hinweis: Mit dem Diskutieren brauchen wir uns nicht so arg beeilen. Die aktuelle Wochenaufgabe geht noch (wegen Verlängerung) bis zum 23. Februar, die nächste Wochenaufgabe (Bücherschränke) beginnt am 23. Februar und dauert zwei Wochen. Anschließend wäre dann die WA Bushaltestellen dran (d.h. vsl. Beginn am 9. März 2015). Die WA Bücherschränke hat einen schon fast fertigen Text.

Viele Grüße

Michael

Das sind ja auch nur noch 3 Wochen bis zum eventuellen Beginn, also gar nicht allzuviel Zeit.

Zum Thema Rollstuhltauglichkeit: Im Proposal zum Tag "kerb" ( http://wiki.openstreetmap.org/wiki/Prop … b#Examples ) schlägt vor "kerb=raised" für erhöhte Bordsteinkanten an Haltestellen zu verwenden - das klingt für mich nach einer guten Idee.

Add to either the bus stop or the platform kerb=raised. It is assumed the kerb tag refers to the edge between the road and the platform. If you wish to explicitly map, tag the actually kerb as the way on the platform area.

mueschel wrote:

Das sind ja auch nur noch 3 Wochen bis zum eventuellen Beginn, also gar nicht allzuviel Zeit.

Zum Thema Rollstuhltauglichkeit: Im Proposal zum Tag "kerb" ( http://wiki.openstreetmap.org/wiki/Prop … b#Examples ) schlägt vor "kerb=raised" für erhöhte Bordsteinkanten an Haltestellen zu verwenden - das klingt für mich nach einer guten Idee.

Add to either the bus stop or the platform kerb=raised. It is assumed the kerb tag refers to the edge between the road and the platform. If you wish to explicitly map, tag the actually kerb as the way on the platform area.

Bei der proposal Seite werden wir nicht das gewünschte Ergebnis bekommen.
Die wird irgend ein Kontrollfreak nutzen um
alle Bordsteine über 3cm als raised zu markieren und
die Bindung an Nodes in den Vordergrund stellen.
Selbst die kerb:height mit direkter unit Angabe wird im Chaos der Abkürzungen enden.

Wir müssen für wheelchair an der public_transport= platform eine Definition haben und dem gemeinen Mapper (wie mir) eine Einstufungsregel an die Hand geben.
Ich betone public_transport= platform, weil highway=platform in die Mottenkiste gehört.

Baulich wäre erkennbar zu unterscheiden zwischen:

A unbefestigte Flächen
Z.B. Grasnarbe über die eingestiegen wird, die der Rollstuhlfahrer erst garnicht befahren kann.
Fällt damit eindeutig unter wheelchair=no in platform und route.

B. Kein Bordstein
Eigentlich klar wheelchair=no , könnte kann aber bei einer route wie Grayhound mit Ausziehrampe und dortigen Begleiterregeln wieder zu wheelchair=yes werden.

C. Abgesenkter Bordstein
Bushalt in Auffahrten. Beurteilung wie B

D. Normalbordstein
Bei uns etwa 11cm über Straßenbelag. (Höhenangabe ist noch durch von/bis zu ersetzen und zu illustrieren)
Ist für mich vom Fahrzeug abhängig ob rollstuhlgerecht, würde vermutlich unter wheelchair=limited fallen.

E. Erhöhter Bordstein
Das was bei uns als rollstuhlgerecht vermarktet wird, aber fahrzeugabhängig ist.
(Höhenangabe ist noch durch von/bis zu ersetzen und zu illustrieren)
Liegt für mich zwischen wheelchair=limited und wheelchair=yes

F. Ebenerdiger Zugang zum Regelfahrzeug
Nur dieser wäre für mich eindeutig wheelchair=yes. (Regelfahrzeug wäre auch noch zu definieren, da Reisebusse in der Regel nicht rollstuhlgerecht sind)

Mein Verständnis für rollstuhlgerecht bezüglich Höhenlage ist:

wheelchair=yes kann von einem Rollstuhlfahrer selbständig unter Einhaltung der Rampenneigung von xx Promille genutzt werden.
wheelchair=limited alles zwischen yes und no
wheelchair=no es ist eine Stufe von über xx cm vorhanden, die nur mit fremder Hilfe überwunden werden kann.

Empfehlenswert wäre eine Zusatzangabe, die bei Änderung der Fahrzeuge einer route die Neubeurteilung zulässt:
Eine Angabe der Bordsteinhöhe über Fahrbahn, ähnlich dem Höhe über Schiene im railwaymap-Konzept wäre etwas, was jeder Mapper mit einem Meßband feststellen könnte und wenig Interpretationsspielraum lässt.

Gruß axelr

Prince Kassad wrote:

Es gibt verschiedene Buslinien die verschiedene Fahrzeuge einsetzen. Wenn eine Haltestelle von zwei Buslinien angefahren wird und die eine rollstuhlgerecht ist und die andere nicht, wirst du Schwierigkeiten bekommen, das an die Bushaltestelle zu taggen.

Genau. Da man aber genauso Schwierigkeiten bekommt, wenn man es an die Route taggt, ist es eine Kombinationseigenschaft. Man kann also dafür weder an der Haltestelle noch an der Route eine Bewertung taggen -- wheelchair=irgendwas ist solche Eigenschaften ungeeignet. Da müssen nicht Bewertungen sondern Eigenschaften getaggt werden, die in der Kombination eine Bewertung ergeben. Dass Routen aber zumindest zu Spitzenzeiten auch noch oft von Fahrzeugen unterschiedlicher Bauweise bedient wird, macht die Sache noch mal komplizierter. Ein schönes Beispiel sind auch noch Bahnsteige und Einstieghöhen der Züge: es ist nicht besser oder schlechter, wenn es 15cm höher ist ... was zählt ist die Unterschied.

Weide

PS: Und bei dem Ganzen sollten wir auch nicht vergessen, dass verschiedene Rollstuhlfahrer sehr verschiedene Fähigkeiten haben.

Inzwischen gibt es aber bei vielen Ausschreibungen die Auflage, nur behindertengerechte Fahrzeuge einzusetzen. Und das gilt dann immer, auch zu Stoßzeiten.

Zumindest bei der RMV-Suche sieht man das dann: normale, nicht für Rollstuhlfahrer geeignete Linien haben das normale Bussymbol, behindertengerechte Linien ein unterstrichenes N.

Dass die Bahn für Rollis ziemlich ungeeignet ist (S-Bahnen vielleicht ausgenommen) dürfte aber kein Geheimnis sein.

Ich habe mal versucht, eine kurze Liste mit notwendigen Tags und ihrer Verwendung aufzustellen:
http://wiki.openstreetmap.org/wiki/User … ltestellen
Ich würde euch bitten, die Seite nicht selbst zu editieren, sondern Änderungsvorschläge hier zu diskutieren.

Eine wichtige Frage habe ich schonmal: Wir werden um highway=bus_stop zur Kompatibilität nicht herumkommen, aber wie ihr schon disktutiert habt: Wohin?

highway=bus_stop wird bei public_transport=platform angegeben, wenn diese als Node getaggt wird. Wird die platform als way getaggt, dann wird er bei der stop_position angegeben. So haben wir es für den VRR am 29.03.15 festgelegt, da bus_stop nur auf Nodes ausgewertet wird.

Wo sich Harald mit seinem Umfragetool schon soviel Mühe macht wollen wir es doch einfach mal nutzen:
http://osm.haraldhartmann.de/umfrage/poll/15

Thoschi wrote:

highway=bus_stop wird bei public_transport=platform angegeben, wenn diese als Node getaggt wird. Wird die platform als way getaggt, dann wird er bei der stop_position angegeben. So haben wir es für den VRR am 29.03.15 festgelegt, da bus_stop nur auf Nodes ausgewertet wird.

Autsch, nein! Viel stärker wiegt bei bus_stop dass es neben der Straße getaggt wird. Hier herrscht in der Diskussion vom Standardstil Einigkeit. Auch wird darüber diskutiert ob man die Komplexität "Bushaltestelle komplexer als ein Node" überhaupt in der Karte möchte.
Durch die Verwässerung von bus_stop wird auch PTv2 geschwächt, es ist ein Argument gegen das Rendern von public_transport=platform. Es wird dann an PTv3 liegen endlich mal eine Übergangsmöglichkeit zu schaffen.

Jojo4u wrote:

Autsch, nein!

+1

Jojo4u wrote:

Autsch, nein! Viel stärker wiegt bei bus_stop dass es neben der Straße getaggt wird.

So eine Regel gibt es nicht. highway=bus_stop ist ein altes Tag. Es wurde auf die Straße oder daneben gesetzt. Falls man es neben die Straße gesetzt hat, hat man gewöhnlich für die Gegenrichtung einen getrennten Node genommen.

Ist die Platform kein Node, dann hat man m.E. keine Wahl: highway=bus_stop muss in die stop_position, die ja immer ein Node ist. Einen zusätzliche Platform als Node lehne ich ab. Das wäre ja eine zweite Platform und da sind nunmal nicht zwei. Da man unmöglich beide Platforms in eine PTv2-Route stecken kann, wäre die Liste der Routen zu jeder der Platforms und der stop_position unvollständig. Macht man dagegen das highway=bus_stop in die stop_position, dann ist zumindest die komplett. Sie enthält dann alle PTv1-Routen und alle PTv2-Routen, da in PTv2-Routen die Angabe von bereits gemappten stops/platforms nicht optional ist.

Weide

mueschel wrote:

Ich würde euch bitten, die Seite nicht selbst zu editieren, sondern Änderungsvorschläge hier zu diskutieren.

Z.B. wird ein Plattform-Knoten durch eine Platform-Fläche ersetzt, muss das neue Objekt wieder in die Relation aufgenommen werden. Dabei sollte das momentan verwendete Tagging-Schema (PTv1, PTv2) der Route zunächst beibehalten werden.

Einfach Austauschen geht bei PTv1 nicht, da PTv1 nur Nodes als Haltestellen kennt.

Weide

Jojo4u wrote:

Thoschi wrote:

highway=bus_stop wird bei public_transport=platform angegeben, wenn diese als Node getaggt wird. Wird die platform als way getaggt, dann wird er bei der stop_position angegeben. So haben wir es für den VRR am 29.03.15 festgelegt, da bus_stop nur auf Nodes ausgewertet wird.

Autsch, nein! Viel stärker wiegt bei bus_stop dass es neben der Straße getaggt wird. Hier herrscht in der Diskussion vom Standardstil Einigkeit. Auch wird darüber diskutiert ob man die Komplexität "Bushaltestelle komplexer als ein Node" überhaupt in der Karte möchte.
Durch die Verwässerung von bus_stop wird auch PTv2 geschwächt, es ist ein Argument gegen das Rendern von public_transport=platform. Es wird dann an PTv3 liegen endlich mal eine Übergangsmöglichkeit zu schaffen.

Wie weide schon schrieb, wenn die plattform nicht als Node getaggt ist, dann hat meine keine Wahl, bus_stop muss zur stop_position. Auch dem Argument von weide, dass ein zweiter Node als plattform für bus_stop mehr als schädlich wirkt, stimme ich zu.
Der Versuch, nur einen Node mit highway=bus_stop für zwar zu der gewünschten Darstellung neben der Straße um die Richtung zu erkennen, aber z.B. alle andere Funktionen von ÖPNV-Karten wie direkte Verknüpfung mit Fahrplanauskunft etc. bringen nicht immer die gewünschten Ergebnisse.

Die Aussage, PTv2 würde dadurch geschwächt ist kompletter Unsinn, da bus_stop nur bei PTv1 existiert und für v2 vollkommen unnötig ist.

Die Angabe von highway=bus_stop zu einer platform die als way getaggt ist, führt zu unheimlichen Straßenmehrungen unter anderem bei Routing-Apps, und auf einer Platform fahren möchte man ja nicht.

Eine andere Frage: Legt man auf talk.de verbindlich fest, was und wie etwas auf die Karte kommt, oder waschen die sich dort nicht auch nur mit Wasser? Im VRR-Gebiet hat man sich nun auf das oben aufgeführte Schema geeinigt.
Und was soll es bedeuten "komplexer als ein node"? Eine Bushaltestelle ist nunmal in der Regel komplexer als nur ein Punkt auf der Straße. M.E. sind die eigentlichen Differenzen in dieser Frage weniger auf bus_stop begrenzt, sondern darauf, ob man die Karte realistisch, also das was man in der Realität auch sieht, dargestellt haben möchte oder ob man sie auf bestimmte "Funktionen" begrenzen will. Da dies Streitigkeiten sind, die unlösbar sind, muss man mit beiden leben. Eine Möglichkeit wäre z.B. festzulegen, dass bus_stop als eigener funktionaler Node mit einem anderen Tag als highway versehen wird. Aber an der Problematik der Darstellung in alten Karten ändert das auch nichts.

Neben dem globalen Streit über Funktionalität und Realität ist mit PTv2 nunmal eine vollkommene Änderung des ÖPNV-Taggings einhergegangen und die Problematik und unsere Diskussionen sind nur deshalb, weil die Kartenrenderer und App-Programmierer eben den Wechsel auf PTv2 nicht vorgenommen haben. Also, bevor wir uns im Kreis drehen, sollten die vielleicht etwas ändern...

v1 und v2 kriegt man nunmal nur schwer unter einen Hut, von daher bleibt für v2 der bus_stop immer nur eine Krücke.

Der aktuelle Stand der Umfrage und die Diskussion hier im Thread lässt wohl nur einen Schluss zu: Die Anweisung für die Wochenaufgabe bzgl. highway=bus_stop muss lauten "Macht doch was ihr wollt" 🙄

Was spricht denn genau gegen: "Wenn die Plattform ein Node ist, dann an diesen. Ansonsten einen extra-Node an die Stelle des Haltestellenschildes innerhalb der Plattform"?
Ein Renderer muss für eine gute Darstellung ohnehin nahe beieinanderliegende Objekte zu einer logischen Haltestelle zusammenfassen (z.B. der Name der Haltestelle taucht pro Halteposition mehrfach auf, an der stop_position und an der Plattform).
Warum stört der zusätzliche Node innerhalb der Plattform? Die Zählung der vorhandenen Haltestellen wird damit zwar etwas aufwendiger, aber definitiv nicht unmöglich.

mueschel wrote:

Was spricht denn genau gegen: "Wenn die Plattform ein Node ist, dann an diesen. Ansonsten einen extra-Node an die Stelle des Haltestellenschildes innerhalb der Plattform"?

Dass zwei Platforms gemappt werden wo nur eine ist. Es wird etwas Falsches in die Datenbank eingetragen, damit das H-Zeichen auf der Karte frei plaziert werden kann. Das ist Mapping for the Renderer.

Es ist nicht nötig, etwas Falsches einzutragen: highway=bus_stop ist nicht darauf festgelegt, ob es auf oder neben der Fahrbahn angegeben wird. Wenn beides Nodes sind, hat man die freie Wahl. Wenn nur eines ein Node ist, dann hat man keine Wahl.

Die PTv2-Routen kommen nicht mit dem Doppelmapping der Platform klar. Man kann zu einem Haltestellenobjekt immer die Liste der Routen zusammensuchen, die dieses Haltestellenobjekt benutzen. Dann sind entweder diese Listen Müll oder die Haltestellenlisten der PTv2-Routen selbst (durch Angabe von zwei platforms zu einem Halt).

Weide

Weide wrote:

Es ist nicht nötig, etwas Falsches einzutragen: highway=bus_stop ist nicht darauf festgelegt, ob es auf oder neben der Fahrbahn angegeben wird.

Wie immer widerspreche ich hier. Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.

Das Anpappen an die Platform nutzt bei PostGIS-basierten Karten (z.B. Standardstil) nichts da die Datenbank nicht weiß auf welchem Way sich ein Node mit Tags befindet. Daher ist es sicher besser als frei in der Wildbahn, aber nicht der Weisheit letzter Schluss.

Legen wir doch einmal den gewünschten Idealzustand für den Standardstil fest: Bus_stop und bei PTv2-exklusiven Mapping platform werden gerendert. Sind wir uns diesbezüglich einig?

EDIT: Verständlichkeit verbessert

Jojo4u wrote:

Bus_stop und bei PTv2-exklusiven Mapping platform werden gerendert. Sind wir uns diesbezüglich einig?

Wenn da nur eine stop_position und keine platform gemappt wurde, dann würde da also nichts gerendert.

Weide

Jojo4u wrote:

Weide wrote:

Es ist nicht nötig, etwas Falsches einzutragen: highway=bus_stop ist nicht darauf festgelegt, ob es auf oder neben der Fahrbahn angegeben wird.

Wie immer widerspreche ich hier. Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.

Wenn das Argument für das doppelte Eintragen von einfach vorhandenen Platforms genutzt wird, dann wird das Anlegen und Pflegen von PTv2 Routen reine Beschäftigungstherapie.

Weide

Weide wrote:

Jojo4u wrote:

Weide wrote:

Es ist nicht nötig, etwas Falsches einzutragen: highway=bus_stop ist nicht darauf festgelegt, ob es auf oder neben der Fahrbahn angegeben wird.

Wie immer widerspreche ich hier. Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.

Wenn das Argument für das doppelte Eintragen von einfach vorhandenen Platforms genutzt wird, dann wird das Anlegen und Pflegen von PTv2 Routen reine Beschäftigungstherapie.

Was meinst du mit "einfach vorhandenen" - kannst du das bitte anhand Node/Way erläutern?

Jojo4u wrote:

Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.

Aber was verlieren wir, wenn wir den Node auch auf der Fahrbahn zulassen?

Weide wrote:

Dass zwei Platforms gemappt werden wo nur eine ist. Es wird etwas Falsches in die Datenbank eingetragen, damit das H-Zeichen auf der Karte frei plaziert werden kann. Das ist Mapping for the Renderer.

Nein, das ist nur die Interpretation der Daten. Es ist genauso möglich, highway=platform als Position des Haltestellenschildes zu interpretieren - so stand es übrigens auch im Wiki, bis die Seite 2010 geleert wurde mit Hinweis auf public_transport. Es ist einfach kein Problem, highway=platform (das Schild) neben einem public_transport=platform (die Bordsteinkante oder Wartefläche) zu haben. Da gibt es keinen Überlapp und keine Zweideutigkeiten, eine ordentliche Interpretation der Daten vorausgesetzt.
Edit: platform und bus_stop sollte man auseinanderhalten können.

mueschel wrote:

Jojo4u wrote:

Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.

Aber was verlieren wir, wenn wir den Node auch auf der Fahrbahn zulassen?

Den Richtungsbezug. Zu mindest bei Bussen.

viw wrote:

Den Richtungsbezug. Zu mindest bei Bussen.

Da wir hier von PTv2-gemappten Haltestellen mit all ihren Features reden: Ja, die Richtung kann man dann an diesem einen Node nicht mehr erkennen, genauso wie bei public_transport=stop_position. Aber durch die naheliegende Plattform sowie die Linienrelationen ist die Information vorhanden.
Außerdem kenne ich auch Fälle, bei denen ein Node neben der Fahrbahn nicht eindeutig einer Straße und Richtung zuzuordnen ist.

mueschel wrote:

viw wrote:

Den Richtungsbezug. Zu mindest bei Bussen.

Da wir hier von PTv2-gemappten Haltestellen mit all ihren Features reden: Ja, die Richtung kann man dann an diesem einen Node nicht mehr erkennen, genauso wie bei public_transport=stop_position. Aber durch die naheliegende Plattform sowie die Linienrelationen ist die Information vorhanden.
Außerdem kenne ich auch Fälle, bei denen ein Node neben der Fahrbahn nicht eindeutig einer Straße und Richtung zuzuordnen ist.

Die Frage ist doch was wollen wir? PTV2 ist ein Schema mit dem man die Daten sehr schön automatisch auswerten kann und in nachgelagerte Auskunfts-Systeme einspeisen kann. Es ist wesentlich näher an der Datenebene Linie-Richtung-Linienvariante-Fahrzeitprofil-Fahrt
PTV v1 was dieses Highway busstop soll für schöne Karten sprich Liniennetzpläne sorgen. Und jetzt kannst du nicht sagen, weil die technischen Informationen vorhanden sind, kann man bei den optischen darauf verzichten die Informationen abzulesen.
Der Unterschied liegt einfach hier:
http://www.openstreetmap.org/#map=17/52.58271/13.52892
während man bei Straße 4 genau weiß, dass die Haltestelle in beiden Richtungen bedient wird, ist das bei Straße 3 und 6 unklar. Siedlung Wartenberg hat übrirgens zwei Masten diecht nebeneinander, während der Mast der Gegenrichtung in gebührendem Abstand hinter der nächsten Kreuzung liegt.

mueschel wrote:

Es ist genauso möglich, highway=platform als Position des Haltestellenschildes zu interpretieren - so stand es übrigens auch im Wiki, bis die Seite 2010 geleert wurde mit Hinweis auf public_transport. Es ist einfach kein Problem, highway=platform (das Schild) neben einem public_transport=platform (die Bordsteinkante oder Wartefläche) zu haben. Da gibt es keinen Überlapp und keine Zweideutigkeiten, eine ordentliche Interpretation der Daten vorausgesetzt.

Es geht aber doch um highway=bus_stop ... oder nicht?

Weide

viw wrote:

Die Frage ist doch was wollen wir?

Genau. Deswegen auch die vielleicht fehlende Konsistenz zwischen meinen Posts - ich versuche mir noch klar zu werden, was wer genau möchte, um dann hoffentlich zu einem Kompromis zu kommen, mit dem alle leben können.

viw wrote:

Und jetzt kannst du nicht sagen, weil die technischen Informationen vorhanden sind, kann man bei den optischen darauf verzichten die Informationen abzulesen.

Am Symbol selbst kann man die Richtung nicht erkennen, wenn aber die Plattform gerendert wird, dann wäre die Sache wieder eindeutig. Dafür müsste man klären, ob "highway=platform" noch verwendet werden soll.

Weide wrote:

Es geht aber doch um highway=bus_stop ... oder nicht?

Ja... (fehlender Nachmittagskaffee und so ;-) )

mueschel wrote:

Jojo4u wrote:

Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.

Aber was verlieren wir, wenn wir den Node auch auf der Fahrbahn zulassen?

... dass man nie public_transport=platform rendern könnte weil ja bus_stop ggf. auf der stop_position hängt und man dann 2x Bussymbole hätte. D.h. wenn diese Änderung käme müsste man bei PTv1+PTv2 gemappten Hst. das bus_stop entfernen. Dies wäre eine ziemliche Herkulesaufgabe die ich im globalen Maßstab unwahrscheinlich finde.

mueschel wrote:

Nein, das ist nur die Interpretation der Daten. Es ist genauso möglich, highway=platform als Position des Haltestellenschildes zu interpretieren - so stand es übrigens auch im Wiki, bis die Seite 2010 geleert wurde mit Hinweis auf public_transport.

Sicher dass du highway=platform meinst? Hast du einen Link zu dem alten (will mich nicht durch 2 Wikiartikel wühlen).

Jojo4u wrote:

Sicher dass du highway=platform meinst?

Nein, das war Quatsch, ich habe es inzwischen gestrichen.

Jojo4u wrote:

... dass man nie public_transport=platform rendern könnte weil ja bus_stop ggf. auf der stop_position hängt und man dann 2x Bussymbole hätte.

Das hätte ich eher umgekehrt interpretiert... bus_stop neben der Straße führt dazu, dass man stop_position nicht rendert, weil man dann 2 Symbole hätte. Die Plattform kann ja weiterhin so gerendert werden wie es im Augenblick highway=platform ist.

Jojo4u wrote:

Was meinst du mit "einfach vorhandenen" - kannst du das bitte anhand Node/Way erläutern?

Nehmen wir eine einfache Haltestelle mit nur einer Richtung. Wenn nun ein OSM-Way mit "public_transport=platform" angelegt wird, dann ist das eine "platform" im Sinne von PTv2. Wird zusätzlich einer der OSM-Nodes dieses OSM-Ways mit "highway=bus_stop" markiert, dann ist es ebenfalls eine "platform" im Sinne von PTv2. Jetzt sind also zwei "platforms" gemappt und es ist nur eine in der Realität vorhanden.

Man muss in PTv2 nicht zwingend eine "platform" bei einer Haltestelle anlegen. Ist sie jedoch angelegt, dann muss sie in die Route. Das kann man aber nicht für beide "platform"-Objekte tun, ohne zu einer falschen Haltestellenliste der Route zu kommen. Lässt man eine der "platforms" in der Route weg, dann ist die Liste der Routenmitgliedschaften dieser "platform" keine Liste der nutzenden Buslinienvarianten mehr.

Weide

Weide wrote:

Jojo4u wrote:

Was meinst du mit "einfach vorhandenen" - kannst du das bitte anhand Node/Way erläutern?

Nehmen wir eine einfache Haltestelle mit nur einer Richtung. Wenn nun ein OSM-Way mit "public_transport=platform" angelegt wird, dann ist das eine "platform" im Sinne von PTv2. Wird zusätzlich einer der OSM-Nodes dieses OSM-Ways mit "highway=bus_stop" markiert, dann ist es ebenfalls eine "platform" im Sinne von PTv2. Jetzt sind also zwei "platforms" gemappt und es ist nur eine in der Realität vorhanden.

Exakt. Du denkst an die Routenrelation, ich denk an die Standardkarte oder auch die Transportkarte. Momenten würde ich bus_stop eher als "pole" als als "platform" sehen und in der Relation dann weglassen. Was hätte das für Auswirkungen?

Jojo4u wrote:

Weide wrote:

Jojo4u wrote:

Was meinst du mit "einfach vorhandenen" - kannst du das bitte anhand Node/Way erläutern?

Nehmen wir eine einfache Haltestelle mit nur einer Richtung. Wenn nun ein OSM-Way mit "public_transport=platform" angelegt wird, dann ist das eine "platform" im Sinne von PTv2. Wird zusätzlich einer der OSM-Nodes dieses OSM-Ways mit "highway=bus_stop" markiert, dann ist es ebenfalls eine "platform" im Sinne von PTv2. Jetzt sind also zwei "platforms" gemappt und es ist nur eine in der Realität vorhanden.

Exakt. Du denkst an die Routenrelation, ich denk an die Standardkarte oder auch die Transportkarte. Momenten würde ich bus_stop eher als "pole" als als "platform" sehen und in der Relation dann weglassen. Was hätte das für Auswirkungen?

Das hätte nur die Auswirkung, dass man nicht an dem node erkennen kann, welche Linien daran halten, da er nicht mitglied in den Relationen ist.
Für die Grafik wäre es kein Problem. Allerdings muss man sich fragen ob es nicht sinnvoll ist diesen Mast auch in den Routen zu erfassen. Ich denke es ist mindestens genauso wichtig zu wissen wo der Fahrplan hängt, wie wo man warten soll. und ein haltestellenmast ist bis auf wenige Ausnahmen an alle Bus und Straßenbahnlinien zu finden. Bei Eisenbahnen ist es eher ein Bahnsteig.

Eigentlich wäre das ganze Problem doch gelöst, wenn man beschließen könnte, dass highway=bus_stop auch an ways und areas benutzt werden darf. Woher kommt dieser Fakt eigentlich?

Jojo4u wrote:

Was hätte das für Auswirkungen?

Steht ein paar Zeilen tiefer...

Weide

mueschel wrote:

wenn man beschließen könnte, dass highway=bus_stop auch an ways und areas benutzt werden darf. Woher kommt dieser Fakt eigentlich?

Aus den alten Routen (PTv1). Dort gilt: alle Ways sind Fahrwege (und alle Fahrwege sind Ways) sowie alle Nodes sind Haltestellen (und alle Haltestellen sind Nodes). Relationen kommen dort nicht vor.

Bei den Bussen mussten die Haltestellen highway=bus_stop tragen. Natürlich konnte highway=bus_stop nicht an irgendetwas geschrieben werden, dass niemals als Haltestelle eingetragen werden kann.

Weide

mueschel wrote:

Eigentlich wäre das ganze Problem doch gelöst, wenn man beschließen könnte, dass highway=bus_stop auch an ways und areas benutzt werden darf. Woher kommt dieser Fakt eigentlich?

Zudem darf man Routing nicht vergessen, ich hatte das mal gemacht und den way platform als bus_stop getaggt, beim routen bekam man abenteuerliche Strecken (zu Fuß ja machbar, mit dem Auto nicht).
bus_stop an den Mast zu setzen, hat seinen Charme, allerdings stört "highway".

Aus der ganzen Nummer kommt man wohl nur raus, wenn man ptv1 auf ewig verdammt und voll auf ptv2 und höher setzt, und dies die "alten" Karten dann auch übernehmen (rendern).
<fantasiere>Dann könnte man einen node als Mast setzen und ihm in der Relation die Rolle "pole" zuweisen, falls eine Rolle notwendig ist. Aber dann sollte man es nicht mehr highway=bus_stop nennen, sondern z.B. man_made=bus_stop oder wenn man es kompliziert haben möchte man_made=pole + pole=bus_stop.</fantasiere>

Zwischendurch mal ein wenig Statistik zur Motivation:

Im Rhein-Main-Verkehrsverbund gibt es 10200 Haltestellennamen. Man kann also von ungefähr 20000 Haltepositionen ausgehen, die meisten davon sollten Bushaltestellen sein.
In OSM sind vorhanden:
14200 highway=bus_stop
5770 public_transport=stop_position
7770 public_transport=platform (Davon 2400 ways / areas)
1070 railway=halt/station/tram_stop

Ich würde sagen, da ist noch gut etwas zu tun.

Ein praktisches Beispiel, wo ihr ja so fleißig diskutiert: http://www.openstreetmap.org/relation/4584173

Evtl. wäre es möglich, den highway=bus_stop einfach ohne Rolle einzutragen, wie etwa den Fahrradparkplatz. Oder gibt es da ein Problem, das ich übersehen habe?

Prince Kassad wrote:

Ein praktisches Beispiel, wo ihr ja so fleißig diskutiert: http://www.openstreetmap.org/relation/4584173

Evtl. wäre es möglich, den highway=bus_stop einfach ohne Rolle einzutragen, wie etwa den Fahrradparkplatz. Oder gibt es da ein Problem, das ich übersehen habe?

Es ist eben die Frage, was man möchte. Wenn einem das schöne Symbol wichtiger ist als die Funktion, kann man das selbsterverständlich so tun.
Man sollte sich aber nicht darüber wundern, wenn Programme dann an dieser Haltestelle keine Buslinien aufführen.
http://www.öpnvkarte.de/?zoom=18&lat=50 … yers=TBTTT

Prince Kassad wrote:

Evtl. wäre es möglich, den highway=bus_stop einfach ohne Rolle einzutragen, wie etwa den Fahrradparkplatz. Oder gibt es da ein Problem, das ich übersehen habe?

Ja. Die leere Rolle ist eine Rolle wie alle anderen. Sie ist für amenity=* und public_transport=station reserviert.

Weide