DE:Proposed features/Public transport schema

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

• Markus Bader
• Christian Berreth
• Christoph Eckert
• Heiko Jacobs
• Matthias Merz
• Melchior Moos, Autor der ÖPNV-Karte
• Frederik Ramm
• Thomas Reincke, Aachener Verkehrsverbund GmbH
• Frank Sautter
• Sebastian Schwarz
• Jochen Topf
• Malte Ahrens

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			highway=bus_guideway	highway=bus_guideway
Straßen mit Fahrdrähten für Oberleitungsbusse	nicht vorhanden		nicht vorhanden	highway=* und trolley_wire=yes
Schienenwege für Eisenbahnen			railway=rail	railway=rail
Bahnkörper für Stadtbahnen			railway=light_rail	railway=light_rail
Bahnkörper für Stadtschnellbahnen			railway=subway oder railway=monorail	railway=subway oder railway=monorail
Bahnkörper für Straßenbahnen			railway=tram	railway=tram
Standseilbahnen	nicht vorhanden		nicht vorhanden	railway=funicular
öffentliche Fahrsteige	nicht vorhanden		nicht vorhanden Vorschlag bei escalator war highway=speedwalk	highway=conveyor
öffentliche Fahrtreppen			highway=steps und escalator=yes	highway=steps und escalator=yes
Luftseilbahnen			aerialway=*	aerialway=*
Fahrwasser für Personenfähren	nicht vorhanden		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:

• usage=main für Hauptbahnen
• usage=branch für Nebenbahnen
• usage=industrial für Industriebahnen
• usage=military für Militärbahnen
• usage=tourism für ausschließlich touristisch genutzte Strecken

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:

• railway=subway für U-Bahnen
• railway=monorail für Einschienenbahnen

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	oder oder	public_transport=platform
Eingänge (z.B. oberirdische U-Bahn-Eingänge)		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

• Proposed features/Public_Transport
• Proposed features/unified_stoparea
• detailed Railway Network (Mirko Küsters Konzept zur Diskussion) Große Netze schon in Sachsen (etc.?) s.a. Forum
• Proposed features/Railway Größere Umsetzung vor allem im Stuttgarter Raum
• DE:Aachener Verkehrsverbund Umsetzung des Schemas für Buslinien in und um Aachen
• Upper Austria Public Transport Umsetzung des Schemas für Verkehrsunternehmen des Oberösterreichischen Verkehrsverbundes
• QROTI Australien