Eigenschaften von Bushaltestellen

Communities Deutschland (Germany)
1

Unter Berücksichtigung der in diesem älteren Thema diskutierten Details habe ich bisher Bushaltestellen, die noch nicht erfasst waren, als Knoten mit überlicherweise diesen Tags gemappt:

highway=bus_stop
public_transport=platform
name=*
network=*
network:short=*
network:wikidata=*
shelter=*
bench=*
bin=*
departures_board=*
route_ref=*
tactile_paving=*
wheelchair=*

Dabei ist mir aufgefallen, dass iD zusätzlich ein bus=yes fordert. Davon steht aber im Wiki nichts, da wird bus=yes lediglich in Zusammenhang mit der stop_position gefordert.

1. Frage: Trotzdem ergänzen oder weglassen?

Wenn der Wartebereich als zusätzliche Linie oder Fläche gemappt ist und das public_transport=platform vom Knoten dorthin verschoben wird, meckert iD erneut und will ein zusätzliches public_transport=platform am Knoten haben.

2. Frage: Redundant an beiden Objekten taggen oder die Aufforderung von iD einfach ignorieren?

Bei bereits erfassten Haltestellen gibt es ein ziemliches Durcheinander an Vorgehensweisen, so wie es OSM angemessen ist. Ab und zu gibt es einen Hinweis

wheelchair:description=Kasseler Bord (bzw. Kein Kasseler Bord)

Dafür gibt es m.W. mittlerweile ein akzeptiertes Tagging:

kerb=raised
kerb:approach_aid=yes/no

3. Frage: Kann ich die “wheelchair:description” durch die entsprechenden Tags ersetzten?

4. Frage: Wohin gehört der Name?

An den Knoten highway=bus_stop?
An den Weg public_transport=platform ?
An die public_transport=stop_positon ?
An 2 davon oder an alle 3?

2

Das ist nicht sehr intelligent, da highway=bus_stop bus=yes impliziert… :stuck_out_tongue_winking_eye:

3

Sollte man meinen, deswegen meine Frage …

4

Jo, da bei public_transport=platform nicht eindeutig ist, um welche Art Haltestelle es sich handelt. Es gibt auch Haltestellen wo sowohl Busse als auch Trams halten, z. B. in Frankfurt.

Mach. Es gibt da einen bestimmten Mapper in der Region Mittel-/Südhessen der das damals genau so getaggt hat.

public_transport=platform als Weg/Area halte ich inzwischen zumindest bei Bushaltestellen für ungünstig, da 1. viele Auswerter das nicht korrekt verarbeiten und davon ausgehen, dass die Platform mit zum Fahrtweg gehört (z. B. unsere eigene Verkehrskarte), und 2. highway=bus_stop auf Wegen nicht gerendert wird, was dann wiederum viele Mapper stört, da sie (verständlicherweise) das Haltestellen-Symbol auf der Karte sehen wollen.

Ansonsten aber grundsätzlich alle.

5

Könnte man als eine kontroverse Entscheidung ansehen, da es ursprünglich nicht Teil des PT-Schemas ist.

Ich selber bin kein Fan davon, da es zu viele unterschiedliche Meinungen dazu gibt. Ich selber verwende public_transport=platform + highway=platform mit public_transport=stop_position mit highway=bus_stop bei einem existierenden Bussteig (z.B. Bordstein, andere Oberfläche, Verkehrsinsel) und sonst public_transport=platform mit highway=bus_stop wenn kein Bussteig gibt. Nachteilig ist aber, dass andere auch ihre eigene Vorstellungen haben, wie Bussteige aussehen und haben dennoch ein eigenes highway=platform zum highway=platform und dann hat man plötzlich zwei public_transport=platform…
Auch habe ich kompromissweise ein highway=platform ohne public_transport=platform verwendet, wenn schon ein highway=bus_stop mit public_transport=platform schon existierte, aber einige haben über iD andromechanisch ein public_transport=platform zum highway=platform hinzugefügt, was ggf. zu Datenredundanz führt (diese habe ich mittlerweile durch ein barrier=kerb ersetzt).

Kann man ruhig ersetzen.

Streng genommen nur in die Relation aber für die meisten Renderer gehört es ins highway=bus_stop und public_transport=platform und optional füge ich es noch ins public_transport=stop_position um den Halt zu standardisieren.

6

Es geht hier aber um Knoten mit dem primary tag highway=bus_stop und da sollte bus=yes eigentlich überflüssig sein.

Korrekt, highway=bus_stop ist nur für Knoten vorgesehen und so verwende ich selber es auch nur. Eine Haltestelle ist für mich grundsätzlich als erstes ein Knoten mit den oben aufgelisteten Tags.

Zusätzlich kann man sicher auch die Ausdehnung des Wartebereiches mit einer Linie oder einer Fläche darstellen, aber dafür braucht es m.E. dann nicht mehr als public_transport=platform, wenn alle haltestellenrelevanten Tags bereits am Haltestellenknoten erfasst sind.

highway=platform benutze ich überhaupt nicht, da ich die Haltestelle grundsätzlich als Knoten mit highway=bus_stop mappe, und dann braucht es kein zusätzliches highway=platform. Siehe dazu auch die Wikiseite von highway=bus_stop.. Das wird wohl auch mehrheitlich so gehandhabt, da highway=bus_stopmit 3,77 Mio Verwendungen highway=platform mit 175K deutlich aussticht.

1 Like
7

Das Problem ist, dass beide nicht vergleichbar sind. Viele Bushalte sind einfach nur ein Pfosten am Boden und haben keine Infrastruktur, die man als Bussteig benennen kann. Zudem befinden sind an fast alle Bushalte ein highway=bus_stop (entweder am Schild oder an der Warteposition). Schon alleine aus diesen Gründen ist es logisch, dass highway=platform selterner vorkommt als highway=bus_stop.

Außerdem sind Bussteige auch reale Infrastrukturen, was allein schon der Grund dafür spricht, diese zu erfassen, weil diese auch den eigentlichen Wartebereich kennzeichnen. Wenn man der Meinung ist, die Fläche eines Bushaltes unwichtig ist, kann man genau so sehr mit den Bahnsteigen aber auch andere Elemente wie Gebäude, Unterstände, usw. auch die könnte man durch einzelne Knoten ersetzen und ihre Dimensionen als “unwichtig” bezeichnen.

8

Dem stimme ich zu, siehe:

Die Kombination aus Haltestelle=Knoten mit highway=bus_stop + Wartebereich=Linie oder Fläche mit public_transport=platform habe ich so auch schon vielfach vorgefunden. Ein zusätzliches highway=platform scheint dafür nicht erforderlich zu sein, da alle relevanten Informationen auch ohne dieses Zusatztag bereits vorhanden sind.

9

Eine für mich wichtige Eigenschaft ist die “stop_id” aus den GTFS-Fahrplandaten von OpenData, um die Haltestellen zwischen beiden Datenbanken in beide Richtungen referenzieren zu können.

Im OSM-Wiki finde ich das Tag
gtfs:stop_id
bereits für Haltestellen genannt.

Nur verwendet wird es (meinen Stichproben zufolge) bislang nicht (oder kaum).

Verstehe ich das richtig, dass ich dieses Tag gerne Haltestellen hinzufügen darf und soll?
(Zum möglichen Import aller stop_ids aus OpenData mache ich später noch Vorschläge, muss mich aber erst noch besser einlesen.)

10

Eine eindeutige Lösung für meine Frage gibt es eigentlich nicht, was vermutlich damit zusammenhängt, dass es auch kein wirklich einheitliches Tagging dafür gibt, schon alleine wegen der unterschiedlichen PT-Schemata.

Ich bin jetzt dazu übergegangen, Bushaltestellen grundsätzlich wie hier beschrieben zu erfassen und solche, die unvollständig erfasst sind, entsprechen zu ergänzen.

Damit ist das Topic hier für mich abgeschlossen.

11

Falls du da ran kommst, nimm statt gtfs:stop_id lieber ref:IFOPT. Das ist eine internationale, global eindeutige ID deren Wert gerade auch für andere Anwendungen deutlich größer ist als die interne ID der Verkehrsunternehmen. Viele GTFS-Datensätze enthalten die auch, dort manchmal auch als Global ID bezeichnet, so dass auch da ein Bezug hergestellt werden kann.

2 Likes
12

+1. ref:IFOPT wird in DE bereits vielfach genutzt. Quelle hierfür ist das zentrale Haltestellenverzeichnis des DELFI e.V. Es ist unter DE-DL/BY-2.0 mit expliziter OSM-Freigabe veröffentlicht. Aber Vorsicht, die Angaben sind, gerade was die Lage angeht, mitunter schlechter als OSM. Unter https://gtfs.mfdz.de/delfi/ veröffentliche ich wöchentliche die gegen OSM abgeglichenen zHV-Haltestellen und eventuelle größere Abweichungen zwischen diesen.

2 Likes
13

Das kannte ich noch gar nicht und scheint mir sehr nützlich zu sein. Schön fände ich noch, wenn man sich da die tatsächlichen Abweichungen irgendwo ansehen könnte, oder übersehe ich da etwas? Wird da auch die IFOPT aus OSM ausgewertet?

14

Darstellung ist seit langem auf der TODO-Liste. Bis dahin lässt sich am Seitenanfang jeweils kreis-weise eine CSV abrufen. IFOPT wird ausgewertet (falls OSM und zHV Koordinate weniger als 400m auseinander liegen) und führt bei Match zu einer Bewertung von 1.0. In Fällen mit Match-Status MATCHED_THOUGH_REVERSED_DIR könnte die in OSM erfasste DHID aber auch dem falschen Steig zugeordnet sein. Oder die Fahrplandaten referenzierten den falschen Steig.

1 Like
15

Gilt die OSM-Freigabe nur für die Haltestellen oder auch für die GTFS-Daten?

16

Leider bisher nur für die Haltestellendaten. Die Sollfahrplandaten im NeTEx und GTFS-Format bisher nicht. Meine Anfrage wurde bisher noch nicht beantwortet. Es scheint DELFI intern immer noch nicht angekommen zu sein, dass dies auch für den DELFI immense Vorteile hätte-

2 Likes
17

Ich nehme für die IFOPs in meinem Gebiet dann weiterhin die GTFS-Daten vom AVV die CC0 sind. Mit den Linien lassen die sich besser zuordnen, als nur über die Koordinaten der Haltestellen, die sehr grob und oft fehlerhaft sind.