Korrektes Mappen von Bushaltestellen und -linien

Hallo, beim Beschäftigen mit dem richtigen Mappen von Bushaltestellen sind mir ein paar Fragen gekommen:

  1. Wenn ich eine Bushaltestelle auf einer Straße mappen will, dann setze ich direkt auf den highway-Way auf Höhe der Bushaltestelle einen Node mit highway=bus_stop. So weit so gut. Dann gibt es aber auch noch den public_transport:stop_position. Warum brauche ich das extra noch? Im Idealfall ist das doch schon durch highway=bus_stop geklärt oder? Kann mir das jemand erklären?

  2. Und wenn ich das einsetze, falls mir die Erklärung einleuchtet, was ist mit Stopposition gemeint? Da wo der Bus mit seiner Front zum Stehen kommt? Oder mit dem Eingangsbereich? Oder mit seinem Mittelpunkt?

  3. Wie mache ich das mit den Relationen für die einzelnen Haltestellen: eine Straße, eine Bushaltestelle für jede Richtung die mehr oder weniger gegenüber liegen, die mache ich in eine Relation (oder doch nicht?). Aber wie weit auseinander dürfen die sein um noch in eine Relation gehören zu dürfen? Und gehört in die Relation auch highway=bus_stop mit rein?

  4. In die Routen-Relation für die einzelnen Buslinien, was kommt da alles rein? Die Straßen, klar, aber auch highway=bus_stop? Und noch mehr wie die Relation der ganzen Haltestelle oder die Plattform oder was?

Ich denke mal das waren die wichtigsten Fragen zu Bushaltestellen und -linien die ich nicht so ganz verstehe. Vielleicht könnt ihr mir da helfen und Erkenntnis geben? :slight_smile:

highway=bus_stop ist das alte Schema und wird nur zur kompatibilität gesetzt. Früher hat man mit highway=bus_stop das gemapped, was heute public_transport=platform ist. Also: public_transport=stop_position bekommt kein highway=bus_stop, aber public_transport=platform darf eins bekommen.

Mit der Front

Also wenn Du einfach nur 2 Haltestellen hast, in jede Richtung eine, würde ich das als Overkill ansehen. Ansonsten: wenn du eine Relation des Typs stop_area hast, kommen sowohl public_transport=stop_position, wie auch public_transport=platform hinein. Zusätzlich alles, was dazugehört, also auch amenity=shelter wenn das Bushäuschen separat gemapped ist, etc.

Die Best Practise ist:
Zuerst alle public_transport=stop_position und public_transport=platform, dann alle Straßenabschnitte. ich würde immer die stop_position und platform die zusammegehört untereinandersetzen, aber es gibt keine Regel, dass es so sein muss. Du kannst Dir ja einfach mal eine bereits gemappte Buslinie anschauen. Die highway=bus_stop sind ja normal eh dasselbe wie public_transport=platform, von daher ignorier sie einfach. Die Rolle wird immer entsprechend korrekt vom Relations-Editor getagged.

Vorschlag:

Vielleicht könnte auf der WIKI-Seite eine Route als Beispielroute (zum ansehen) verlinkt werden. (Besonders auch mit forward/backward - tritt öfters auf)

Ah okay, danke Nadijta, das erklärt einiges. Es gibt einige Seiten die dazu was schreiben, aber dann fehlt der Hinweis, das jenes eigentlich veraltet ist, dann das dieses veraltet ist. Dann schreibt es eine Seite eher so, eine andere wieder eher so. Teilweise sehr verwirrend.
Zusätzlich mit geri-ocs Seite habe ich glaube die Idee raus.

Apropos verwirrend: hier ( http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Examples ) sind die Beispiele so angegeben, dass highway=bus_stop auf public_transport=stop_position sitzt und nicht auf public_transport=platform. Was ist denn vorzuziehen?

Und gehe ich richtig in der Annahme, dass die Reihenfolge in der Relation keine Auswirkungen hat, lediglich der Übersichtlichkeit dient?

Selbst die genannte Wikiseite selbst sagt allerdings:

Daher würde ich davon abraten, diese Seite allzu ernst zu nehmen. Insbesondere die dort propagierten forward/backward-Rollen sind im aktuellen Schema überhaupt nicht mehr vorgesehen, weil sie sich zwanglos aus der Reihenfolge der Wege und der Regel “eine Relation pro Fahrtrichtung” ergeben. Hier wäre die ÖPNV-Karte gefragt, dies endlich zu unterstützen.

Nein. Die Wege und Haltestellen werden jeweils in der Reihenfolge sortiert, wie sie angefahren werden.

Hi,
obwohl ich den ÖPNV eigentlich aufgegeben habe, muss ich jetzt doch kommentieren:

Nein. Bei Platforms mit Wartebereich als Node kann public_transport=platform nicht benutzt werden. Dort geht nur highway=bus_stop.

Nein. highway=bus_stop wurde sowohl für die heute mit public_transport=platform als auch für die heute mit public_transport=stop_position Nodes benutzt.

Nein. public_transport=stop_position ist immer auf dem in der Relation angegebenen Fahrweg. Aber auf Höhe der Front würde ich es auch machen.

Nein. forward und backward treten niemals auf, wenn es sich um eine Public-Transport-Relation handelt.

Nein. Zuerst kommen alle Haltestellen und ihre Reihenfolge gibt an, in welcher Reihenfolge sie angefahren werden. Dann kommen alle Wege und ihre Reihenfolge gibt an, in welcher Reihenfolge sie vom Bus benutzt werden und damit wird auch indirekt angegeben, ob sie von links nach rechts oder von rechts nach links durchfahren werden.

Das unverfälschte Original des Public Transport Proposals findet man unter
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726

MfG
Weide

Vielen Dank, jetzt bin ich vollständig verwirrt. :slight_smile:

Es fehlt glaube ich eine relativ leicht verständliche, einfach und übersichtlich gehaltene, deutschsprachige, aktuelle Übersichtsseite (die gerne auch unterschiedliche Meinungen wiedergibt). Kann das sein? :slight_smile:

Jederzeit gerne wieder.

Eventuell hilft das hier bei der weiteren Verwirrung weiter: http://forum.openstreetmap.org/viewtopic.php?pid=193181#p193181
Da findet sich zumindest eine in sich geschlossene, konsistente Aufbereitung des Themas. Inwieweit die Dokumente noch aktuell sind, vermag ich allerdings nicht zu sagen.

Genau dafür ist doch platform da. Im Proposal heißt es:

Ich kombiniere mal scharf, dass wenn man public_transport=platform setzt und das Haltestellenschild damit meint, drumherum gewartet werden darf. Wobei der Wartebereich eh nicht so klar ist. Wenn es regnet, sind vermutlich alle Passagiere im Shelter statt neben dem Schild ;o)

Das Stimmt natürlich, aber außer im Wiki habe ich das nocht nicht erlebt. In der freien Wildbahn kam’s mir noch nicht über den Weg ;o)

Genau das hab ich doch gesagt…

Da steht aber nicht, dass damit das Haltestellenschild gemeint ist. Da steht sinngemäß: Ein Haltestelle wird als Linie oder Fläche getaggt. Wenn garnichts da ist, dann kann man auch einen Punkt an die Stelle des Pfahls setzen. Public_transport=platform an einem Node bedeutet also explizit, dass dort nichts außer dem Schild ist. Also können die Leute bei Regen auch nicht ins Häuschen :slight_smile:

Damals war die gängigste Mappingart, dass man bei gegenüberliegenden Haltestellen einen Punkt auf die Fahrbahn macht und bei weit auseinanderliegenden zwei (oder mehr) Punkte neben die Fahrbahn.

Ich wollte nur klarstellen, dass man nicht diese Stelle vermessen darf und da einen Punkt hinsetzen – das wäre dann ja meist neben der Linie, die die Straße repräsentiert.

MfG
Weide

Und wie unterscheide ich dann auf einer Straße die Haltestellen der unterschiedlichen Richtung?
Für jede Richtung eine Relation?
Dann hat eine Linie mindestens 2 Relationen - wenn die Schulbusroute gefahren wird kommen noch einmal 2 Relationen dazu?

Hier eine “dritte” Meinung:

Dazu kopiere ich einfach mal, was ich vor einiger Zeit jemandem per PN erklärt hatte:

Schon nach dem alten Schema war es richtiger, für jedes Haltestellenschild einen Node mit highway=bus_stop zu erfassen. Ein Node pro gesamte Haltestelle war “schon immer” eher eine Notlösung falls es nicht so genau bekannt ist.

highway=bus_stop ist aber eigentlich veraltet. Aktuell sollte ein public_transport=stop_position an der Stelle, an der etwa die Fahrzeugspitze zum Halten kommt (optimalerweise auf einem Way), und public_transport=platform an Stelle des Mastes oder als Fläche für den Bahn-/Bussteig (als Fläche mit area=yes). Hinzu kommen jeweils Tags zum Erfassen, wofür das jeweils genutzt werden kann (tram=yes/no, bus=yes/no, train=yes/no). Das ganze wird dann in einer Relation vom Typ public_transport=stop_area zusammengefasst.

Oft lässt sich das aber nicht so einfach so genau sagen, weshalb normalerweise immernoch nur highway=bus_stop erfasst wird. Ausserdem werden Haltestellen im neuen Schema (noch) nicht im osm.org-Style dargestellt, weshalb meistens auch noch an der Mastposition (also wenn es keine Fläche ist am public_transport=platform) highway=bus_stop eingetragen wird.

Also nochmal alles zusammengefasst: Erfasse an der Mastposition highway=bus_stop. Wenn du erkennen kannst, wo die Fahrzeugspitze zum Halten kommt, erfasse diese Stelle mit public_transport=stop_position und am highway=bus_stop zusätzlich public_transport=platform. Wenn du einen Bussteig erkennen kannst erfasse diesen als public_transport=platform area=yes (hierbei highway=bus_stop ohne public_transport=stop_position). In letzterem Fall lässt sich auch fast immer zumindest eine Halteposition erkennen.

Und natürlich zum Schluss noch das, was ich auch gerne vergesse: Wenn bei einer Haltestelle irgendwas mit public_transport=* erfasst ist kommen alle Objekte dieser Haltestelle in eine Relation mit type=public_transport=stop_area, die auch z.B. das name=* erhält.

Fahrzeugspitze.

In eine stop_area-Relation darf alles rein, was zur Haltestelle gehört, also auch highway=bus_stop oder amenity=shelter. Eine stop_area stellt eine Haltestelle dar, also üblicherweise alles, was den selben Namen hat. Schon eine kleine Abweichung (z.B. “Käfertal Bahnhof” und “Käfertal Bahnhof (RNV)”) ist ein Zeichen dafür, dass es zwei getrennte Haltestellen sind, bei der dann die stop_area über eine stop_area_group zusammengefasst werden.

Zuerst alle Halte in der richtigen Reihenfolge: Wenn nur ein highway=bus_stop erfasst ist dieses mit der Rolle “stop”, sonst erst das p_t=stop_position mit der Rolle “stop” und direkt darauffolgend das p_t=platform mit der Rolle “platform”.

Nach allen Halten kommen dann alle genutzen Verkehrswege: Diese müssen ebenfalls in der richtigen Reihenfolge sein (also vom ersten genutzten Way durchgägnig bis zum letzten genutzten Way). Wenn dabei ein Way mehrmals genutzt wird muss er also auch mehrfach enthalten sein.

Und weil darum hier irgendwo gebeten wurde: Für ein Beispiel kannst du im Prinzip jede Buslinie in Mannheim, Ludwigshafen und Heidelberg nutzen (Linien 11 bis 20 und 27 bis 97). Bevorzugt eine ohne fixme=* :wink:

@geri-oc: Ja.

Ja. Das ist eine der brandaktuellen Neuerungen des Oxomoa-Entwurfs. Entwickelt AD 2009.

Bevor jemand anders daran erinnern muß: Oxomoa ist längst überholt, aber “eine Relation je Fahrtrichtung” ist bei allen weiteren Entwicklungen geblieben.

Ah. Du meinst die alte Art, sowas zu mappen. Die ist auch OK. Entschuldige bitte, die hatte ich nicht berücksichtigt. Dann gelten die folgenden Regeln (die schon etwas einschränkend sind):

  • Es gibt dann nur eine Relation pro Linie. Insbesondere gibt es keine Master-Route.
  • alle Nodes sind Haltestellen (und alle Haltestellen sind Nodes).
  • alle Ways sind Fahrzeugwege.
  • Flächen und Relationen gehören da nicht rein.
  • Die Sortierung der Elemente bedeutet nichts.
  • eine Haltestelle kann die Rolle “stop” oder “forward_stop” oder “backward_stop” haben. Es gibt kein “platform”. Anhängen darf man dabei noch “:1”, “:2” usw., um eine Reihenfolge anzugeben.
  • Linien haben die Tags “forward”, “backward” oder “”. Das gibt an, ob das Wegstück in oder gegen die OSM-Richtung durchfahren wird. “” bedeutet dabei “beide Richtungen” in Sinne von “von links nach rechts und von rechts nach links”. Anders als bei den Haltestellen hat das “forward” und “backward” hier nichts mit Hin- und Rückweg zu tun.
  • Es gibt noch einige “Ergänzungs-Rollen”. Da kommen das Rollen wie “forward_stop:17;alternate” vor… da wird’s dann langsam hässlich…

Das alte Schema ist für nicht allzu komplizierte Buslinien auch nicht sooo schlecht. Schlimm ist es aber, beides zu vermischen. Dann weiß kein Programm mehr, was eine Linie mit leerer Rolle jetzt bedeutet und ob die Reihenfolge eine Bedeutung hat.

MfG
Weide

Da die Fahrzeugspitze oft Fahrzeugabhängig ist, habe ich mir angewöhnt einen Punkt zu wählen, bei dem man immer Einsteigen kann.

Bei Schienenfahrzeugen ist die Halteposition über das Signal Ne5 (ESO) bzw. Sh7 (SOStrab) festgelegt. Diese bestimmen, an welcher Stelle ±5m die Fahrzeugspitze zum stehen kommen soll. Das ist also immer gleich und auch ohne ein haltendes Fahrzeug feststellbar. Dass wir nicht erfassen wollen was für Fahrzeuge auf einer Linie verkehren hatten wir ja kürzlich festgestellt.

Bei Bushaltestellen mit Blindenleitstreifen ist die Position der ersten Tür besonders markiert. Dort lässt sich also auch die Fahrzeugspitze relativ genau vor Ort ohne Fahrzeug feststellen. Hinzu kommt, dass die Fahrzeugspitze bei Bussen oft fast die erste Tür ist (Abweichung ca. 1m) und Fahrzeuge bei denen die erste Fahrgasttür weiter hinten ist trotzdem oft genauso halten.

Ausserdem soll sie stop_position eher Navigationsanwendungen als Fahrgästen dienen.

Dann schau dir doch mal so eine Örtlichkeit an. Je nachdem wo der Zugang ist gibt es verschiedene dieser Haltetafeln. Kurzzug, 3/4 Zug, Vollzug, 4 Wagen, 6 Wagen, Fahrzeugtypabhängig oder schlicht nach Gesamtlänge in Metern. Und das waren jetzt nur die Beispiele für Berlin.
Eindeutig ist also eindeutig anders!

Es ist trotzdem objektiver feststellbar als eine Stelle an der man “immer” einsteigen kann (was eh nicht Sinn des public_transport=stop_position ist).

Es führt auch zu Konflikten, wenn der Bahnsteig in 2 Richtungen benutzt wird. Dann muss es nämlich 2 stop_position geben.

Mehrere stop_positions: Ja. Einen Konflikt sehe ich da allerdings nicht. Es sind eben verschiedene Stellen an denen man hält.

Beim Erfassen von Einstiegsmöglichkeiten (von denen es viel mehr gibt wenn man alle erfassen will) gibt es auch Situationen, bei denen es nicht passt. Z.B. Bahnsteige an denen 423 und 425 halten. Erstere haben die Modulanordnung
FTFFTFFTF, letztere
FFTFFFTFF (F=Fenster, T=Tür) – bei gleicher Fahrzeuglänge, also gleichem Halteplatz. Durch die Untereinanderschreibung sieht man schön, dass die Türen nie zusammen passen, man also danach auch mehrere Positionen erfassen müsste oder den Punkt einfach irgendwo innerhalb der 400m Bahnsteiglänge platziert – da ist die Erfassung der Halteposition sinnvoller und (wie schon geschrieben) nebenbei der eigentlichen Bedeutung entsprechend.