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)	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?	Due to changes in Query-to-map this Template does not work anymore. You can use Template:Osm-query2. Please replace or delete this use of Osm-query template. ^{[ toter Link ]}
`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)

DE:Proposed features/Public transport schema

Contents