Korrektes Mappen von Bushaltestellen und -linien

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.

Ist das auf den Bahnhöfen nicht genau so? Da gibt es doch diese H-Schilder, die dem Lokführer zeigen, wo der Haltepunkt ist. Davon auch manchmal mehrere am selben Gleis für z.B. Kurzzüge.

Keine Ahnung, ob und ggf. wie das bei OSM umgesetzt wird, aber man sollte das bei Bussen und Straßenbahnen identisch machen machen.

ym2c
Walter

Ja, genau dahin sind wir inzwischen abgedriftet :wink:

jau, kommt davon, wenn man die Chausse nur mal kurz überfliegt. naja, falsch war es immerhin nicht.

Gruss
walter

Ich hatte damit nicht die Türen gemeint, sondern eine Stelle, an welcher in jedem Fall ein Wagen zum Stehen kommt.
Für mich spricht nichts dagegen sämtliche Haltepunkte einzutragen, nur sollten wir ein Mapping-Schema finden, mit welchem die Karten und App-Hersteller etwas anfangen können, denn die Schilder gehören nicht zum public-transport sondern zu railway (siehe taggingvorschlag openrailwaymap)

Lg Jimmy

Anwendungen ist ein gutes Stichwort. Eine mögliche Nutzung der stop_positions wäre die Anzeige der Strecke bis zum nächsten Halt (also im Display für den Fahrer). Als “Position des Haltes” sieht man als Fahrer aus den in Antwort 16 genannten Gründen (und weil man selbst dann etwa an dieser Stelle ist) die Position der Fahrzeugspitze. Für den Anwendungsfall “Wo am Bahnsteig kann ich das Fahrzeug betreten” wäre imo das public_transport=stop_position ungeeignet, da dafür ein Node an der Bahnsteigfläche besser wäre.

In Karten dargestellt werden sollten die stop_positions eigentlich eh nicht (ausser evtl. in Spezialkarten).

Dass die Ne5/Sh7 nicht zum PT-Tagging gehören stimmt, aber bedenke, dass es auch Ne5 an Gleisen ohne Bahnsteig gibt und Bahnsteige ohne Ne5 (aber z.B. mit Empfehlungen oder allgemein üblichen Halteplätzen). Da sollte das auch richtig funktionieren. Ähnliches gilt für Bahnsteige: Es gibt auch Bahnsteige ohne Personenverkehr (die ich zur Klarstellung mit public_transport=no erfasse).

Fürs Mapping finde ich die Erfassung so genauer stop_positions teilweise selbst unschön: An meinem Heimatbahnhof gibt es Empfehlungstafeln für 70m (also “Kurzzüge”) und “Vollzüge” halten am Bahnsteigende (zweite stop_position). Welche soll nun für eine Linie auf der beides vorkommt in die route-Relation? :smiley:

…oder aber wie mein Heimatbahnhof. Da sind keine H-Tafeln… Ja das gibt es… Mein “Informant” bei der DB zuckte mit den Schultern und meinte, daß muß nicht mehr unbedingt sein.

Sven