DE:Proposed features/Public transport schema

From OpenStreetMap Wiki
Jump to navigation Jump to search

broom

Dieser Artikel oder Abschnitt kann veraltete Informationen enthalten: Die Idee des hier vorgeschlagenen Tagging-Schemas wurde in ein Proposed Feature Public Transport verpackt. Diese Seite hier dient nur noch historischen Dokumentationszwecken, um die Entwicklungsgeschichte des ÖPNV-Mappings in OSM nachvollziehen zu können.
Wenn du aktuelle Informationen beitragen kannst, hilf bitte bei der Aktualisierung oder teile diese auf der Diskussionsseite mit. (Discussion)


Dieses Schema ist ein Vorschlag für die verbesserte Integration und Darstellung des öffentlichen Personennahverkehrs (ÖPNV) in OpenStreetMap (OSM): Er entstand im Bewusstsein der zahlreichen Probleme, die das bisher verwendete Schema aufwirft, und ist das Resultat eines Workshops, der vom 16. bis 17. Mai 2009 in der Geofabrik in Karlsruhe stattfand. Teilnehmer des Workshops waren:

Public transport schema
Zustand: Abandoned (inactive)
Vorgeschlagen von: Oxomoa
Darstellung: undecided

Die Einzelaspekte des Schemas, die unten ausführlich erläutert sind, gingen aus den folgenden Diskussionspunkten hervor:

  • Grundkonzept für linienhafte Verkehrsinfrastrukturen
  • Grundkonzept für punkthafte Verkehrsinfrastrukturen
  • Grundkonzept für Netzinformationen (Linien)
  • Grundkonzept für Netzinformationen (Verkehrsverbünde)
  • Trennung von Infrastrukturen und Netzinformationen
  • ÖPNV-Routing, Taktzeiten, Bedienungshäufigkeiten
  • Rendering/Visualisierung
  • Tagging
  • Microtagging
  • Realisierung automatischer Datenabgleiche


Linienhafte Verkehrsinfrastrukturen

Das größte Problem im Zusammenhang mit linienhaften Verkehrsinfrastrukturen des ÖPNV in OSM ist zur Zeit die Abgrenzung der unterschiedlichen Schienenwege und Bahnkörper voneinander. Dies ist der Tatsache geschuldet, dass diese auch in der Wirklichkeit oftmals nicht eindeutig identifiziert oder kategorisiert werden können. Damit MapperInnen einen Schienenweg oder Bahnkörper möglichst eindeutig identifizieren und korrekt erfassen können, sollten sie bereits bei der Datenaufnahme eine Entscheidung treffen. Sie können daher folgenden Entscheidungsgraphen verwenden:

Entscheidungsgraph für die Erfassung von Schienenwegen und Bahnkörpern

Folgende Tabelle listet alle Arten von linienhaften Verkehrsinfrastrukturen im ÖPNV auf. Außerdem zeigt die Tabelle, mit welchen Geometrien und Tags die Elemente nach dem bisherigen Schema modelliert werden und wie sie nach dem hier vorgeschlagenen Schema in Zukunft erfasst werden sollen. Elemente, die weiter unten näher erläutert werden, sind fett angegeben:

Art Geometrie (bisher) Geometrie (Vorschlag) Tag(s) (bisher) Tag(s) (Vorschlag)
Fahrwege für Spurbusse Linienzug Linienzug highway=bus_guideway highway=bus_guideway
Straßen mit Fahrdrähten für Oberleitungsbusse nicht vorhanden Linienzug nicht vorhanden highway=* und trolley_wire=yes
Schienenwege für Eisenbahnen Linienzug Linienzug railway=rail railway=rail
Bahnkörper für Stadtbahnen Linienzug Linienzug railway=light_rail railway=light_rail
Bahnkörper für Stadtschnellbahnen Linienzug Linienzug railway=subway oder railway=monorail railway=subway oder railway=monorail
Bahnkörper für Straßenbahnen Linienzug Linienzug railway=tram railway=tram
Standseilbahnen nicht vorhanden Linienzug nicht vorhanden railway=funicular
öffentliche Fahrsteige nicht vorhanden Linienzug nicht vorhanden Vorschlag bei escalator war highway=speedwalk highway=conveyor
öffentliche Fahrtreppen Linienzug Linienzug highway=steps und escalator=yes highway=steps und escalator=yes
Luftseilbahnen Linienzug Linienzug aerialway=* aerialway=*
Fahrwasser für Personenfähren nicht vorhanden Linienzug route=ferry waterway=ferry_way


Gleise und Trassen

Wenn bei Schienenwegen und Bahnkörpern einzelne Gleise statt Trassen aufgenommen werden sollen, so können alle zu einer Trasse gehörenden Gleise ohne Unterschied gleich getaggt werden, und zwar so, wie die gesamte Trasse getaggt würde, wenn nur diese erfasst würde. Unabhängig davon sollte stets mit dem zusätzlichen Tag tracks=* die jeweilige Anzahl der Gleise notiert werden: Dessen Wert nimmt 1 an, wenn einzelne Gleise statt Trassen erfasst werden und einen Wert größer 1, falls Trassen erfasst werden.


Schienenwege für Eisenbahnen

Für die Unterscheidung zwischen verschiedenen Arten von Eisenbahnschienenwegen sollte zusätzlich zu railway=rail das Tag usage=* verwendet werden, das die jeweilige Nutzung einer Strecke ausdrückt:

Weitere Tags für Eisenbahnschienenwege sind unter anderem:

Schlüssel Wert Erläuterung
service siding / spur / yard kennzeichnet verschiedene Arten von Nebengleisen
ref Zahl oder Text Streckennummer
name Text Streckenname
maxspeed Zahl zulässige Höchstgeschwindigkeit in Kilometern pro Stunde
traction cable / rack kennzeichnet Zusatzantrieb durch Kabel oder Zahnrad
disused yes / no nicht mehr in Benutzung?
construction yes / no im Bau befindlich?
planned yes / no in Planung befindlich?
tunnel yes / no Tunnel?
bridge yes / no Brücke?
gauge Zahl Spurweite in Millimetern
loading_gauge Zahl Lichtraumprofil in Millimetern
electrified yes / no / contact_line / rail Elektrifizierung
voltage Zahl Spannung in Volt
operator Text unterhaltendes Infrastrukturunternehmen


Bahnkörper für Stadtbahnen

Tags für Stadtbahnkörper sind zusätzlich zu railway=light_rail unter anderem:

Schlüssel Wert Erläuterung
ref Zahl oder Text Streckennummer
name Text Streckenname
traction cable / rack kennzeichnet Zusatzantrieb durch Kabel oder Zahnrad
disused yes / no nicht mehr in Benutzung?
rail=construction
construction=light rail
yes / no im Bau befindlich?
planned yes / no in Planung befindlich?
tunnel yes / no Tunnel?
bridge yes / no Brücke?
gauge Zahl Spurweite in Millimetern
loading_gauge Zahl Lichtraumprofil in Millimetern
electrified yes / no / contact_line / rail Elektrifizierung
voltage Zahl Spannung in Volt
operator Text unterhaltendes Infrastrukturunternehmen

Bahnkörper für Stadtschnellbahnen

Stadtschnellbahnen (Metros) lassen sich in zwei Kategorien einteilen, für die jeweils unterschiedliche Tags zur Verfügung stehen:

Bei U-Bahnen kann und sollte stets auch das Tag tunnel=* verwendet werden, das bei unterirdischem Verlauf (also dem überwiegenden Normalfall) den Wert yes annimmt und bei oberirdischem U-Bahn-Verlauf den Wert no.

Bei Einschienenbahnen kann und sollte stets auch das Tag monorail=* verwendet werden, das den Wert hanging annimmt, wenn es sich um eine Hängebahn handelt, und den Wert magnetic, wenn es sich um eine Magnetschwebebahnen handelt.

Weitere Tags für Stadtschnellbahnkörper sind unter anderem:

Schlüssel Wert Erläuterung
ref Zahl oder Text Streckennummer
name Text Streckenname
disused yes / no nicht mehr in Benutzung?
construction yes / no im Bau befindlich?
planned yes / no in Planung befindlich?
bridge yes / no Brücke?
gauge Zahl Spurweite in Millimetern
loading_gauge Zahl Lichtraumprofil in Millimetern
electrified yes / no / contact_line / rail Elektrifizierung
voltage Zahl Spannung in Volt
operator Text unterhaltendes Infrastrukturunternehmen


Bahnkörper für Straßenbahnen

Straßenbahnkörper sollten stets als separate Geometrien erfasst werden, vor allem auch dann, wenn die Bahnkörper direkt auf Straßen verlaufen, wofür bislang oftmals ein gemeinsamer Way mit der Straße verwendet wurde. Dies war und ist aber problematisch, weil die weiteren Tags in solchen Fällen nicht eindeutig der Straße oder dem Straßenbahnkörper zugeordnet werden können.

Weitere Tags für Straßenbahnkörper sind zusätzlich zu railway=tram unter anderem:

Schlüssel Wert Erläuterung
ref Zahl oder Text Streckennummer
name Text Streckenname
traction cable / rack kennzeichnet Zusatzantrieb durch Kabel oder Zahnrad
disused yes / no nicht mehr in Benutzung?
construction yes / no im Bau befindlich?
planned yes / no in Planung befindlich?
tunnel yes / no Tunnel?
bridge yes / no Brücke?
gauge Zahl Spurweite in Millimetern
loading_gauge Zahl Lichtraumprofil in Millimetern
electrified yes / no / contact_line / rail Elektrifizierung
voltage Zahl Spannung in Volt
operator Text unterhaltendes Infrastrukturunternehmen

Standseilbahnen

Standseilbahnen, die bislang nicht als eigenständige Kategorie in OSM auftraten, werden fortan als Ways mit railway=funicular modelliert.

Weitere Tags für Standseilbahnen sind unter anderem:

Schlüssel Wert Erläuterung
ref Zahl oder Text Streckennummer
name Text Streckenname
disused yes / no nicht mehr in Benutzung?
construction yes / no im Bau befindlich?
planned yes / no in Planung befindlich?
tunnel yes / no Tunnel?
bridge yes / no Brücke?
gauge Zahl Spurweite in Millimetern
loading_gauge Zahl Lichtraumprofil in Millimetern
operator Text unterhaltendes Infrastrukturunternehmen


Öffentliche Fahrsteige

Öffentliche Fahrsteige, die bislang ebenfalls nicht als eigenständige Kategorie in OSM auftraten, werden fortan als Ways mit highway=conveyor modelliert.

Weitere Tags für öffentliche Fahrsteige sind unter anderem:

Schlüssel Wert Erläuterung
oneway yes / -1 / no Benutzung nur in einer Richtung möglich?
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen? wheelchair

Fahrwasser für Personenfähren

Um auch in diesem Bereich eine eindeutige Trennung von Infrastrukturdaten und Netzinformationen zu erreichen, werden die Fahrwege (Fahrwasser) von Personenfähren in Zukunft mit dem Tag waterway=ferry_way erfasst.


Punkthafte Verkehrsinfrastrukturen

Im Bezug auf die größte Gruppe der punkthaften Verkehrsinfrastrukturen im ÖPNV, die Halte, fehlt in OSM bis jetzt die Möglichkeit, diese vereinheitlichend zu gestalten, ohne explizit zwischen Bushaltestellen, Bahnhaltepunkten usw. unterscheiden zu müssen. Außerdem fehlt die Möglichkeit, Halte, die von mehreren Verkehrsmitteln bedient werden, als zusammenhängende Gesamtelemente zu gestalten. Auch Bahnsteige, Stationsgebäude oder ähnliche Elemente können bisher nie eindeutig einem Halt zugeordnet werden.


Grundlegendes Modell für Halte

Daher sei hier ein Modell vorgeschlagen, dessen Grundstruktur unabhängig ist vom jeweiligen Verkehrsmittel oder Verkehrsweg, an dem der Halt liegt. Das Modell soll von den MapperInnen stets auf einfache Weise angewendet, aber auch leicht erweitert werden können, sodass optional eine detaillierte Gestaltung der Halte möglich ist. Zu diesen Zwecken besteht das Modell aus vier Komponenten:

  • Halteposition des Verkehrsmittels auf dem Verkehrsträger
  • Zugangsstelle für Fahrgäste zum Verkehrsmittel
  • Gesamthalt
  • Gesamthalt-Gruppe
Modell für die Erfassung von Halten

Aus der Graphik geht hervor, dass das Modell aus maximal drei Stufen besteht: Ein Gesamthalt umfasst dabei als Relation mindestens eine Halteposition sowie keine oder beliebig viele Zugangsstellen und stellt den Zusammenhang zwischen diesen Komponenten her. Eine Gesamthalt-Gruppe wird als weitere, übergeordnete Relation dann verwendet, wenn mehrere Gesamthalte zusammengefasst werden sollen, weil sie beispielsweise nur durch Namenszusätze voneinander unterschiedene Teile eines Haltes repräsentieren.


Halteposition

Haltepositionen werden als Nodes erfasst und mit dem Tag public_transport=stop_position gekennzeichnet. Die Platzierung der Nodes wird direkt auf den Ways der Verkehrswege vorgenommen: Dies erleichtert Routing-Anwendungen das Leben enorm und führt zu einer wesentlich größeren Einheitlichkeit als bisher.

Um beim Rendern trotz der Unabhängigkeit des Modells von den jeweiligen Verkehrsmitteln korrekte Symbole setzen zu können (mit Bus-, Bahn-, Tram-Icons und so weiter), sind für Haltepositionen weitere Tags notwendig, die die bedienenden Verkehrsmittel ausweisen:

Schlüssel Wert Verkehrsmittel
bus yes / no Bus
rail yes / no Eisenbahn
light_rail yes / no Stadtbahn
subway yes / no U-Bahn
monorail yes / no Einschienenbahn
tram yes / no Straßenbahn
funicular yes / no Standseilbahn
aerialway yes / no Luftseilbahn
ferry yes / no Personenfähre

Fehlen diese zusätzlichen Tags, so könnten die entsprechenden Informationen aus den Linienrelationen herausgelesen werden, die die Halteposition beinhalten: Dies wäre aber ungleich aufwendiger.

Optional kann auch noch das Tag operator=* verwendet werden, um das betreibende Verkehrsunternehmen anzugeben.

Ein weiterer wichtiger Aspekt im Bezug auf Haltepositionen ist die Frage, wann eine und wann mehrere Haltepositionen erfasst werden: Eine wird gegenwärtig nur dann erfasst, wenn nur eine Halteposition vorhanden ist, wenn sich zwei Bushaltestellen direkt gegenüberliegen oder bei Halten auf eingleisigen Schienenwegen oder Bahnkörpern. In allen anderen Fällen werden mehrere Haltepositionen modelliert, und zwar so viele, wie in der Realität vorhanden sind. Irgendwann in der Zukunft werden wohl bei straßenbezogenen Halten generell mehrere Haltepositionen aufgenommen werden, da langfristig auch die unterschiedlichen Spuren von Fahrbahnen einzeln modelliert werden können.


Zugangsstelle

Die Geometrie und das kennzeichnende Tag, mit denen Zugangsstellen modelliert werden, hängen ab von der Art der Zugangsstelle:

Art Geometrie(n) Tag(s)
Zugangsplattformen (z.B. Bahn- und Bussteige) oder einfache Haltestellenschilder Knoten oder Punkt oder Linienzug oder Fläche oder Gebiet public_transport=platform
Eingänge (z.B. oberirdische U-Bahn-Eingänge) Knoten oder Punkt public_transport=entrance


Zusätzlich sollten für Zugangsstellen folgende Tags verwendet werden:

Schlüssel Wert Erläuterung
ref Zahl Bezugsnummer (relevant für Zugangsplattformen)
name Text Name (z.B. Bussteig Süd)
bus yes / no halten Busse?
rail yes / no halten Eisenbahnen?
light_rail yes / no halten Stadtbahnen?
subway yes / no halten U-Bahnen?
monorail yes / no halten Einschienenbahnen?
tram yes / no halten Straßenbahnen?
funicular yes / no halten Standseilbahnen?
aerialway yes / no halten Luftseilbahnen?
ferry yes / no halten Personenfähren?
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?
bench yes / no Sitzbank vorhanden?
bin yes / no Abfalleimer vorhanden?
shelter yes / no Unterstellmöglichkeit vorhanden?
toilet yes / no Toilette vorhanden?

Optional kann auch noch das Tag operator=* verwendet werden, um das betreibende Verkehrsunternehmen anzugeben.

Zu den Zugangsstellen zählen freilich auch Gebäude, Fährterminals, Piers/Kais/Anleger oder andere Einrichtungen (z.B. Toilettenhäuschen), die auch in eine Gesamthalt-Relation mitaufgenommen werden können. Die Modellierung solcher Map Features kann verbleiben wie bisher.

Gesamthalt

Eine Gesamthalt-Relation wird mit public_transport=stop_area getaggt. Die Tags, mit denen sie zusätzlich ausgestattet werden können, dienen vorwiegend ihrer eindeutigen Identifizierbarkeit:

Schlüssel Wert Erläuterung
ref Zahl oder Text Identifikationsnummer
name Text Name
uic_ref Zahl Internationale Bahnhofsnummer
uic_name Text offizieller Name nach dem Internationalen Eisenbahnverband
operator Text betreibendes Verkehrsunternehmen

Beim Namen des Gesamthaltes kann (wie auch überall sonst bei OpenStreetMap) optional auch mit Keys wie nat_name, alt_name oder Ähnlichen gearbeitet werden, falls kein uic_name vorhanden ist oder einfach noch mehr Informationen erfasst werden sollen; Beispiel: name=Hauptstraße, reg_name=Neustadt,Hauptstraße, nat_name=Neustadt an der Weinstraße,Hauptstraße.

Optional kann ein Mitglied einer Gesamthalt-Relation mit der Rolle label versehen werden, um es im Hinblick auf das Rendering als Anzeigeort für ein Symbol und/oder einen Namen zu qualifizieren. Dies ist hauptsächlich für niedrige Zoomstufen von Bedeutung, wenn (noch) nicht jede Halteposition in Einzeldarstellung visualisiert wird.

Eine Gesamthalt-Relation ist nicht immer notwendig: Treten Haltepositionen isoliert auf, weil entweder noch keine weiteren Details erfasst worden sind oder weil es keine weiteren Elemente gibt, so wäre eine zusätzliche Gesamthalt-Relation mit dann nur einem Mitglied (nämlich der einen Halteposition) überflüssig. In solchen Fällen sollen die alleine stehenden Haltepositionen allerdings zusätzlich mit den oben aufgelisteten Tags für Gesamthalte versehen werden, um sie eindeutig identifizieren zu können.

Gesamthalt-Gruppe

Die Relation für eine Gesamthalt-Gruppe wird mit public_transport=stop_area_group getaggt. Sie sollte nicht als grundsätzliche und einzige Möglichkeit zur Modellierung von Umsteigebeziehungen missverstanden werden, sondern als Möglichkeit mehrere Gesamthalt-Relationen zusammenzufassen, die beispielsweise nur durch Namenszusätze voneinander unterschiedene Teile eines Haltes repräsentieren. Es sollte also nicht für jeden Halt, an dem mehr als eine Verkehrsmittelart hält, eine Gesamthalt-Gruppe erstellt werden, sondern nur dann, wenn es mehrere Halte gibt, die nur durch Namenszusätze voneinander unterschieden sind, aber im Netz zusammengehören; Beispiel: eine Gesamthalt-Relation mit name=Zentralplatz (Langgasse) und eine Gesamthalt-Relation mit name=Zentralplatz (Hauptstraße) werden in der Gesamthalt-Gruppe mit name=Zentralplatz gruppiert.

Eine Gesamthalt-Gruppe kann neben Gesamthalt-Relationen als Mitglieder auch zusätzlich noch beliebig viele isolierte Nodes enthalten, die andere punkthafte Verkehrsinfrastrukturen repräsentieren:

  • Taxistände und -rufsäulen
  • Rikschastände
  • Mietfahrzeug-Einrichtungen
  • Carsharing-Einrichtungen
  • Wassertaxistände und -rufsäulen


Beispiele für das Modell

Im einfachsten Fall existiert lediglich eine Halteposition mit einem Namen:

Halteposition (Kartenansicht)
Halteposition (Datenansicht)

Kommen zur Halteposition zwei Zugangsstellen hinzu, so entsteht ein Gesamthalt:

Gesamthalt (Kartenansicht)
Gesamthalt (Datenansicht)

Bilden mehrere benachbarte Gesamthalte nun Teile eines Haltes, der als zusammengehörig wahrgenommen wird, so entsteht eine Gesamthalt-Gruppe, die hier auch noch einen Taxistand umfasst:

Gesamthalt-Gruppe (Kartenansicht)
Gesamthalt-Gruppe (Datenansicht)


Kompatibilität des Modells

Die Aufwärtskompatibilität des bisherigen Modells kann dadurch sichergestellt werden, dass die bisher in OSM vorhanden punkthaften Verkehrsinfrastrukturen des ÖPNV erhalten bleiben können und lediglich deren Bedeutung fortan anders interpretiert wird. So werden die bisherigen Map Features für Halte (die mit highway=bus_stop, railway=halt usw. getaggt sind) zukünftig als Haltepositionen interpretiert, falls sie direkt auf einem Verkehrsweg platziert sind. Falls sie dagegen nicht direkt auf einem Verkehrsweg platziert sind, so werden sie als Zugangsstellen interpretiert, wie freilich auch die bisherigen Map Features für Zugangsstellen (die mit highway=subway_entrance, railway=platform usw. getaggt sind). Durch zusätzliches Tagging können neue Informationen (public_transport=stop_position, public_transport=platform usw.) problemlos an die bestehenden Map Features angehängt werden. Die Gesamthalt-Relationen und -Gruppen können ungeachtet der bisherigen Daten neu erstellt werden.


Eignung des Modells

Das dargelegte Modell eignet sich für die Erfassung von:

  • Bushaltestellen und -bahnhöfen
  • Oberleitungsbushaltestellen und -bahnhöfen
  • Eisenbahnhaltepunkten und Bahnhöfen
  • Stadtbahnhaltestellen und -bahnhöfen
  • S-Bahn-Haltepunkten und -Bahnhöfen
  • Stadtschnellbahnhaltestellen und -bahnhöfen
  • Straßenbahnhaltestellen und -bahnhöfen
  • Standseilbahnstationen
  • Luftseilbahnstationen
  • Personenfähren-Anlegestellen


Öffentliche Personenaufzüge

Für öffentliche Personenaufzüge, die bislang noch nicht als eigenständige Kategorie in OSM auftraten, eignet sich jedoch das vorgestellte Modell nicht. Diese werden fortan als Nodes mit highway=elevator modelliert.

Weitere Tags für öffentliche Personenaufzüge sind unter anderem:

Schlüssel Wert Erläuterung
oneway yes / -1 / no Benutzung nur in einer Richtung möglich?
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?
capacity Zahl maximal beförderbare Anzahl von Personen
maxweight Zahl beförderbares Maximalgewicht in Kilogramm
toll yes / no oder Zahl Gebühren?
operator Text unterhaltendes Infrastrukturunternehmen

Netzinformationen (Linien)

Die größten Probleme im Zusammenhang mit ÖPNV-Linien in OSM sind zur Zeit:

  • die fehlende, eindeutige Differenzierung der Linien unterschiedlicher Verkehrsmittel,
  • die fehlende Unterscheidung zwischen Linien einerseits und Bahnstrecken andererseits und
  • fehlende Regeln zur gleichermaßen klar strukturierten Modellierung sowohl einfacher als auch komplexer Linienverläufe.


Grundlegendes Modell für Linien

Daher sei hier ein Modell vorgeschlagen, das den MapperInnen die einfache Erfassung sowohl der am häufigsten anzutreffenden Linienformen und -arten als auch unterschiedlicher Hin- und Rückwege ermöglicht. Das Modell ist problemlos und logisch erweiterbar, sodass beispielsweise auch abweichende Linienverläufe auf klar nachvollziehbare Weise integriert werden können. Zu diesen Zwecken besteht das Modell aus fünf Komponenten:

  • Verkehrsweg (als Mitglied)
  • Halteposition (als Mitglied)
  • Zugangsstelle (als Mitglied)
  • Linienvariante
  • Linie
Modell für die Erfassung von Linien

Aus der Graphik geht hervor, dass das Modell aus maximal drei Stufen besteht: Eine Linienvariante umfasst dabei als Relation beliebig viele Haltepositionen, Zugangsstellen und Verkehrswege. Eine Linie wird als weitere, übergeordnete Relation verwendet, um alle möglichen Varianten einer Linie zusammenzufassen.


Linienvariante

Für Hin- und Rückweg einer Linie wird jeweils eine eigene Relation verwendet: Dabei werden alle Haltepositionen, Zugangsstellen und Verkehrswege als Mitglieder aufgenommen. Deren Reihenfolge in der geordneten Mitgliederliste gibt dabei genau die reale Verbindung zwischen Quell- und Zielort wieder.

Zugangsstellen werden aus den folgenden beiden Gründen mitaufgenommen: Zum einen ermöglicht dies Routinganwendungen FußgängerInnen direkt auf die richtigen Zugangsstellen zu verweisen. Zum anderen sichert dies die Abwärtskompatibilität des Modells, da somit auch all jene Map Features nach wie vor gültige Relationsmitglieder sind, die als Halte getaggt sind, sich aber neben Verkehrswegen befinden und nicht auf solchen.

Für die Modellierung von abweichenden Linienverläufen wird auch jeweils eine eigene Relation für jeden auftretenden Verlauf erstellt. Der Grund: Verwendete man eine einzige Relation, beispielsweise mit den alternativen Mitgliedern in der Rolle alternate, so verlöre sich die Zuordnung dieser Mitglieder zueinander und bei der Verarbeitung wären die abweichenden Verläufe nicht zusammensetzbar.

Somit sind für jede Linienvariantenrelation lediglich folgende Tags erforderlich:

Schlüssel Wert Erläuterung
from Text Starthalt
to Text Endhalt
alternate yes / no kennzeichnet Haupt- oder abweichenden Verlauf

Diskussion zu Unterscheidung und Tagging von Linie vs Linienvariante

Beim Erstellen einer Linienvariantenrelation sind außer den genannten Punkten noch weitere Aspekte zu beachten. So sollten die Ways der Verkehrswege, die als Mitglieder in die Relation mitaufgenommen werden, nicht an jeder Halteposition aufgeteilt werden. Ferner können Bedarfshalte respektive deren Haltepositionen oder Zugangsstellen als Mitglieder der Linienvariantenrelation mit der Rolle on_demand versehen werden. Die Linien schienenbezogener Verkehrsmittel schließlich sollten entweder über das korrekte Gleis (falls alle einzeln erfasst sind), über das tendenziell richtige (z. B. bei drei erfassten von fünf) oder über das einzige (falls nur ein Gleis oder eine Trasse erfasst ist) verlaufen, was insbesondere in Bahnhöfen von Bedeutung ist.

Nicht benötigt werden zusätzliche Linienvariantenrelationen für sogenannte Teleskoplinien: Solche Linien weisen gelegentliche Verlängerungen um einen oder mehrere Halte zu bestimmten Tages- oder Nachtzeiten auf. Für deren Modellierung reicht es aus, die entsprechenden Mitglieder in den Relationen für Hin- und Rückweg mit der Rolle additional zu versehen.


Linie

Die übergeordnete Relation für eine Linie schafft die Möglichkeit, die verschiedenen Linienvariantenrelationen zu einer zusammengehörigen Einheit zusammenzufassen – zu diesem Zweck umfasst sie diese Relationen als Mitglieder. Die Liste der Tags für eine Linienrelation ist zwar vom Verkehrsmittel und anderen Faktoren abhängig (siehe die nachfolgenden Abschnitte dieses Textes), jedoch ist allen Linienrelation das Tag line=* gemeinsam, dessen Wert dann jeweils vom Verkehrsmittel abhängt.


Unterscheidung zwischen Strecken und Linien

Bei den schienenbezogenen Verkehrswegen gibt es Strecken (z.B. Kursbuchstrecken der DB), die fortan von Linien unterschieden werden sollen: Letztere können nämlich mehrere Strecken oder Teile davon bedienen, erstere wiederum fassen lediglich bestimmte Verkehrswegabschnitte zu einer Einheit zusammen. Zum Unterscheidungszweck wird das Tag route=* an Relationen fortan ignoriert, falls sein Wert nicht rail ist. Mit route=railway sind dann Relationen für Strecken zu taggen, die anderen route=*-Tags werden obsolet. Für das Tagging der Linien soll nur noch das Tag line=* Gültigkeit besitzen.


Bus- und Oberleitungsbuslinien

Tags für Bus- und Oberleitungsbuslinien sind unter anderem:

Schlüssel Wert Erläuterung Benutzung
line bus kennzeichnet die Relation als Bus- oder Oberleitungsbuslinie
bus express / long_distance / on_demand / regular / school / shopping / shuttle / train_replacement / urban Buslinien, die nur einem besonderen Zweck dienen (Rufbus, Schulbus)
service busway / feeder / night / peak / weekdays / weekend Verkehr in besonderem Fahrplan: Metro-, Nacht- oder Zubringerbus?
ref Zahl oder Text Liniennummer
nat_ref Zahl oder Text Liniennummer in nationalem Rahmen
name Text Sondername (z.B. Bussi-Bus)
color Text Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat
text_color Text Farbe der Linienbezeichnung als benannte Farbe oder Webfarbe im Hexadezimalformat
by_night yes / no / only Verkehr auch nachts?
on_demand yes / no / only Verkehr als Ruf-Bus? https://overpass-turbo.eu/s/1OxP
operator Text betreibendes Verkehrsunternehmen
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?

Bahnlinien

Tags für Bahnlinien sind unter anderem:

Schlüssel Wert Erläuterung
line rail kennzeichnet die Relation als Bahnlinie
service high_speed / long_distance / regional / commuter Hochgeschwindigkeits-, Fern-, Regional- oder S-Bahn-Verkehr?
ref Zahl oder Text Liniennummer
nat_ref Zahl oder Text Liniennummer in nationalem Rahmen
name Text Sondername (z.B. Rasender Rantanplan)
color Text Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat
text_color Text Farbe der Linienbezeichnung als benannte Farbe oder Webfarbe im Hexadezimalformat
by_night yes / no / only Verkehr auch nachts?
operator Text betreibendes Verkehrsunternehmen
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?

Stadtbahnlinien

Tags für Stadtbahnlinien sind unter anderem:

Schlüssel Wert Erläuterung
line light_rail kennzeichnet die Relation als Stadtbahnlinie
ref Zahl oder Text Liniennummer
nat_ref Zahl oder Text Liniennummer in nationalem Rahmen
name Text Sondername (z.B. StarLine)
color Text Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat
text_color Text Farbe der Linienbezeichnung als benannte Farbe oder Webfarbe im Hexadezimalformat
by_night yes / no / only Verkehr auch nachts?
operator Text betreibendes Verkehrsunternehmen
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?

Stadtschnellbahnlinien

Tags für Stadtschnellbahnlinien sind unter anderem:

Schlüssel Wert Erläuterung
line subway oder monorail kennzeichnet die Relation als Stadtschnellbahnlinie (U-Bahn- oder Einschienenbahnlinie)
ref Zahl oder Text Liniennummer
nat_ref Zahl oder Text Liniennummer in nationalem Rahmen
name Text Sondername (z.B. X-Metro)
color Text Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat
text_color Text Farbe der Linienbezeichnung als benannte Farbe oder Webfarbe im Hexadezimalformat
by_night yes / no / only Verkehr auch nachts?
operator Text betreibendes Verkehrsunternehmen
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?

Straßenbahnlinien

Tags für Straßenbahnlinien sind unter anderem:

Schlüssel Wert Erläuterung
line tram kennzeichnet die Relation als Straßenbahnlinie
ref Zahl oder Text Liniennummer
nat_ref Zahl oder Text Liniennummer in nationalem Rahmen
name Text Sondername (z.B. SchleichTram)
color Text Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat
text_color Text Farbe der Linienbezeichnung als benannte Farbe oder Webfarbe im Hexadezimalformat
by_night yes / no / only Verkehr auch nachts?
operator Text betreibendes Verkehrsunternehmen
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?

Personenfährlinien

Tags für Personenfährlinien sind unter anderem:

Schlüssel Wert Erläuterung
line ferry kennzeichnet die Relation als Personenfährlinie
ref Zahl oder Text Liniennummer
nat_ref Zahl oder Text Liniennummer in nationalem Rahmen
name Text Sondername (z.B. Channel Star)
color Text Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat
text_color Text Farbe der Linienbezeichnung als benannte Farbe oder Webfarbe im Hexadezimalformat
by_night yes / no / only Verkehr auch nachts?
operator Text betreibendes Verkehrsunternehmen
wheelchair yes / no / limited / only geeignet für RollstuhlfahrerInnen?

Netzinformationen (Verkehrsverbünde)

Verkehrsverbünde werden in OSM derzeit noch selten als übergeordnete Relationen modelliert; dies soll sich allerdings durch diesen Vorschlag ändern. Als Mitglieder solcher übergeordneten Relationen fließen alle Linien und Haltepositionen eines Verbundes ein. Die Aufnahme der Haltepositionen ist dabei allerdings von größerer Bedeutung, da diese einen Verkehrsverbund begrenzen. Die Linien hingegen liegen oft nur teilweise in einem Verbund: Solche Linienteile können aber nur durch die Haltepositionen, die sie abgrenzen, identifiziert und abgegrenzt werden. Für die Ausweisung einer Relation als Verkehrsverbund soll das Tag public_transport=network benutzt werden.

Zusätzliche Tags für Verkehrsverbünde sind:

Schlüssel Wert Erläuterung
name Text Name (z. B. Verkehrsverbund Niederes Oberland)
abbreviation Text Abkürzung des Namens (z. B. VNO)


See also