User:Adjuva/strecken
Die OpenRailwayMap hält sich beim Definieren des Taggings von Eisenbahn-Relationen ziemlich zurück. Ein paar Tags für die Relationen werden angeführt - eine genauere Beschreibung der Details fehlt. Das soll hier (in Form eines Vorschlags) zum Teil nachgeholt werden.
Anwendungsfälle
Openstreetmap schlägt drei Typen von Routen-Relationen für Eisenbahnen vor:
- Train-Relationen route=train (route=light_rail, route=subway, route=tram usw. ist hier mitgemeint)
- Tracks-Relationen route=tracks und
- Railway-Relationen route=railway
Und verbietet auf letztgenannter Seite ausdrücklich route=rail.
Sinnvoll sind Routen für folgende Zwecke:
- den Laufweg einzelner Züge
- den (leicht verallgemeinerten) Laufweg einer ganzen Zug-Linie
- einer genau spezifizierten Strecke der Infrastruktur
- einer Kursbuchstrecke (KBS)
- eine Zusammenfassung von Gleisen, um dieser Zusammenfassung einen Namen zu geben
- eine Zusammenfassung von Gleisen, um diese Zusammenfassung mit Wikipedia zu verlinken
Weitere Zwecke sind mir in den OSM-Daten bisher nicht aufgefallen.
Für 1. und 2. sind Train-Relationen nach den ÖPV-Schemen PTv1 und PTv2 gedacht. Hierzu muss ich nichts mehr sagen.
Für 3. sind explizit die Tracks-Relationen gedacht. Dazu unten mehr.
Für 4., 5. und 6. sollten aus meiner Sicht Railway-Relationen genutzt werden. Hierfür habe ich keine konkreten Tagging-Vorschläge sonder eher allgemeine Vorstellungen.
Aus meiner Sicht sollte man die verschiedenen Arten von Relationen strickt auseinander halten und für jeden Typ eine eigene Relation einrichten. Häufig sah man eine Railway-Relation, an der dann mit ref=abcd noch schnell die VzG-Nummer hinzugefügt hat. Nur gehört zur VzG-Strecke häufig noch ein Bahnhofsgleis, das meistens nicht in der Relation enthalten war. Wegen solcher feiner Unterschiede sollten man die Relationen trennen.
Für die eingleisige Stichstrecke von Wicklesgreuth nach Windsbach (KBS 922, VzG 5253) habe ich da mal beispielhaft ausgeführt:
Relation | Tag | Beschreibung |
---|---|---|
8710003 8710003 | Tag:route=railway | KBS 922 mit Bahnhofs-Nodes, von Stop-Position zu Stop-Position |
8710005 8710005 | Tag:route=tracks | VzG 5253 mit aktuellen Betriebsstellen-Nodes, von Weiche bis Prellbock |
135690 135690 | Tag:route=railway | Für Wikipedia mit aktuellen und historischen Betriebsstellen-Nodes, von Weiche bis Prellbock |
2200627 2200627 | Tag:route=train | PTv2 nach Windsbach, von Stop-Position zu Stop-Position |
161015 161015 | Tag:route=train | PTv2 nach Wicklesgreuth, von Stop-Position zu Stop-Position |
Ich habe mittlerweile fast alle elektrifizierten Strecken in Deutschland als Tracks-Relation erfasst und eine Motivation dafür war auch, dass diese Relationen dann als leicht zu benutzenden Vorlagen für weitere Relationen dienen können.
Tracks-Relationen in Deutschland
In Deutschland drängen sich die VzG-Strecken für die Infrastruktur, die mit Tracks-Relationen erfasst wird, geradezu auf. Von der Deutschen Bahn gibt es einen Open-Data-Datensatz geo-strecke, der die entsprechenden Strecken beschreibt und auch in OpenSteetMap genutzt werden darf. VzG-Nummer sind aber auch für Strecken, die nicht von der Deutschen Bahn betrieben werden, vergeben worden.
Grundsätze
Mein Konzept ist, dass es für jede VzG-Strecke genau eine Relation in OSM gibt.
Gemappt werden ausschließlich die Streckengleise - in Bahnhöfen die durchgehenden Hauptgleise der Strecke. Genau diese Verläufe sind auch im Datensatz geo-strecke enthalten.
Das bedeutet, dass insbesondere Gleiswechsel (bei zweigleisigen Strecken), Ausweichgleise, Abstellgleise und Anschlussgleise in der Relation nicht erfasst werden. Im Datensatz geo-strecke kann eindeutig zwischen ein- und zweigleisgen Strecken unterschieden werden[A 1]
In die Relation werden zuerst (Hin-Richtung) die Ways mit railway=rail für das das einzige Gleis oder das rechte Streckengleis (Regelgleis) eingetragen. Die Reihenfolge erfolgt in aufsteigender Kilometrierung. Bei Strecken ohne Unterbrechung ist dies in der Regel eine lückenlose Folge von Ways[A 2].
Bei zweigleisigen Strecken werden anschließend (Rück-Richtung) mit absteigender Kilometrierung alle Gegengleise der zweigleisigen Abschnitte eingetragen. Die eingleisigen Abschnitte werden nicht doppelt erfasst - hier existiert dann eine Lücke in der Relation.
Alle Übergänge von ein- zu zweigleisigen Abschnitten oder von einer Strecke zur anderen sollen an Nodes mit railway=switch erfolgen. Diese Nodes sollen immer erster oder letzer Node eines Way sein. Falls nicht, sollte der Way hier geteilt werden. Dies macht es später einfacher Relationen anzulegen.
Nodes werden erst mal nicht in die Relation eingetragen. Rund um Berlin (bis einschließlich Außenring) habe ich allerdings testweise alle Betriebsstellen nach DS100 am Anfang der Relation eingetragen. In Richtung der Kilometrierung wurden dabei alle Betriebsstellen-Nodes mit der Rolle site eingetragen.
Tags
Folgende Schlüssel können bei der Relation gesetzt werden:
Schlüssel | Wert | Beschreibung |
---|---|---|
type | route | Routen-Relation |
route | tracks | Tracks-Relation |
name | <nr> <von> - <bis> oder <nr> <von> - <via> - <bis> |
Beschreibung der Relation. Dieses Tag ist nur für die Anzeige in OSM-Editoren gedacht. Es ist deswegen nicht möglich, der Relation irgendwie einen zusätzlichen Namen zu geben. Dafür sollte man eine Railway-Relation mit passendem Namen anlegen. Bei langen Strecken reichen für <von> und <bis> die Ortsnamen ohne weiteren Zusatz - bei ganz kurzen Strecken sollten hier die genauen Namen aus der DS100 stehen, die (mit Ausnahme von Bahnhöfen) um den Typ der Betriebsstelle ergänzt werden (also z.B. 'Abzw Kanal' statt nur 'Kanal'). |
ref | <nr> | vierstellige VzG-Nummer der Strecke |
operator | <Betreiber, ggf. getrennt durch Semikolon> | Die Betreiber der Strecke. Dies kann mehr als ein Betreiber sein. Bei der Deutsche Bahn ist dies entweder die 'DB Netz AG' oder die 'DB RegioNetz Infrastruktur GmbH'. |
from | <Start-Betriebsstelle> | Name der Betriebsstelle am Beginn der Strecke in der genauen Schreibweise aus der DS100. |
to | <End-Betriebsstelle> | Name der Betriebsstelle am Ende der Strecke in der genauen Schreibweise aus der DS100. |
via | <via-Betriebsstelle> | Einige Streckennamen sind zweideutig (es gibt z.B. zwei Strecken von Berlin nach Stralsund), so dass sie mit einer Zwischen-Station eindeutlig beschreiben werden müssen. In der Regel ist dieser Schlüssel nicht vorhanden. |
long_name | <lange Name> | Langer Name, der häufig auch Weichen- oder Gleisnummern am Beginn oder Ende der Strecke enthält. Wenn keine Nummer genannt wird, dann beginnt oder endet die Strecke meist in Bahnsteigmitte. Dieser Wert sollte immer aus der Datei strecke.csv aus dem geo-strecke-Datensatz übernommen werden. Dieses Tag dient dann auch als Quasi-Quellenangabe, wenn eine Weichen- oder Gleisnummer aus diesem langen Namen in die OSM-Daten übernommen wird. |
Die Werte für via=* und Template:Long name können der Datei strecken.csv aus dem oben genannten Datensatz geo-strecke entnommen werden. Die Werte für from=* und to=* können dem Betriebsstellenverzeichnis DS100 (Open-Data-Datensatz Betriebsstellenverzeichnis) entnommen werden.
Auf Tags für spezielle Eigenschaften der Strecke (Haupt- oder Nebenbahn; ein- oder zweigleisig; Schmal, Normal- oder Breitspurbahn; Misch, Güter-, Hafen-, Personen- oder S-Bahn-Verkehr; Oberleitung, Stromschiene oder nicht elektrifiziert; Gleichstrom oder Wechselstrom, usw.) verzichte ich, denn all diese Eigenschaften können auf verschiedenen Abschnitten der Strecke unterschiedlich sein. Man müsste also für eine Zusammenfassung ggf. mit durch Semikolon getrennten Listen arbeiten, was aber für die Schlüssel usage=*, gauge=*, railway:traffic_mode=* oder electrified=* ungewöhnlich ist und ich deshalb vermeiden möchte.
Nur für den Betreiber der Strecke mache ich eine Ausnahme, weil ich denke, dass er häufig als Suchkriterium benutzt wird.
Besondere Rollen
Rolle 'other'
Üblicherweise sollte man denken, dass ein Gleisabschnitt maximal zu einer Strecke gehören kann. Nun gibt es aber dutzende Stellen in Netz der DB, bei der Strecken sich kreuzen - und zwar nicht mit echten Kreuzungen[A 3], sondern über mehrere Weichenverbindungen hinweg. Das führt dazu, dass kurze Gleisabschnitte zwischen den Weichen zu zwei oder noch mehr Strecken gehören können - und genau so ist es auch im oben genannten Datensatz modelliert (zwei Strecken liegen exakt übereinander).
Diese Fälle bilde ich wie folgt in OSM ab. Ich wähle willkürlich eine Strecke aus (meist die vermeintlich wichtigste) und füge die ganz normal der dazugehörenden Relation hinzu. Auf den betroffenen Ways setze ich mit ref=* auch nur diese eine Streckennummer. Bei allen anderen Strecken füge ich den Way an passender Stelle mit der Rolle other hinzu. Damit erreiche ich Folgendes:
- Alle Relationen sind an dieser Stelle lückenlos (das ist mir am Wichtigsten)
- Die Rolle markiert, dass hier was besonderes vorliegt
- Ich vermeide ein außergewöhnliches Tagging der Ways (mehrere durch Semikolon getrennt Werte für ref=* und ggf. für usage=* oder operator=*), mit dem viele andere Anwendungen nichts anfangen können
- Die wichtigste Strecke ist durchgehend widerspruchsfrei getaggt.
Rollen 'historic' und 'future'
In OSM werden auch historische oder geplante Abschnitte einer Strecke eingetragen und sie sollten auch Bestandteil der Relation sein. Diese Abschnitte werden mit den Rolle historic für stillgelegte Gleise und mit der Rolle future für geplante Gleise versehen.
Mappen
In den Daten der Deutsche Bahn sieht man, dass der Übergang einer Strecke in eine Andere Strecke immer an einer Weichenspitze erfolgt. Das ist für mich einer der Gründe, bei Weichen den Node mit railway=switch immer an der Weichenspitze zu mappen und nicht in der Weichenmitte oder im Herzstücke zu mappen[A 4].
Railway-Relationen in Deutschland
Wikipedia
Insbesondere die Verlinkung mit Wikipedia ist schwierig:
- Als erstes fehlt bei vielen bis den meisten Bahnstrecken-Artikeln die Einbindung der Vorlage:Karte (Zu klärende Frage: Soll man die Vorlage ganz an den Anfang des Artikels stellen oder irgendwo bei den Kategorien einfügen?). Ohne diese Vorlage fehlt oben rechts das Karte-Icon, mit dem sich OSM-Daten anzeigen lassen. Ich selber habe aber keine Lust dies überall von Hand nachzutragen.
- Es dauert sehr lange (Tage bis Monate), bis ein OSM-Element, das neu mit einem wikipedia=*-Tag versehen wurde, auch auf der Karte in der Wikipedia angezeigt wird.
- Das Tag wikipedia=* auf einzelende Wege mit railway=rail) zu setzen kommt zwar noch häufig vor - ist für mich aber keine sinnvolle Lösung. Deswegen ärgert es mich, dass jetzt im OSM-Standard-Style genau so die Namen von Eisenbahnstrecken gerendert werden.
- Eine Möglichkeit ist, an passende VzG-Relationen das Tag wikipedia=* einzutragen. Das habe ich bei den drei Relationen gemacht (2630, 2638 und 3510), die die Linke Rheinstrecke bilden. Das funktioniert - hat aber den Nachteil, dass es nun in OSM kein Objekt gibt, das 'Linke Rheinstrecke' heißt und die ganze Strecke repräsentiert (es gibt nur jede Menge Wege mit railway=rail).
- Die zweite Möglichkeit ist eine Railway-Relationen anzulegen und dort das Tag wikipedia=* zu setzen.
Anmerkungen
- ↑ Der WMS-Server von Nakaner zeigt diesen Unterschied leider nicht an und mein Tile-Server ist leider noch nicht öffentlich.
- ↑ Ich kenne nur eine zweigleisige Strecke (S-Bahn-Strecke 2670 Köln - Duisburg, 1311847 1311847, bei der das Regelgleis im Bahnhof Düsseldorf-Oberbilk einfach endet und das Gegengleis als eingleisige Strecke bis Düsseldorf-Wehrhahn weitergeführt wird.
- ↑ Wie hier südlich von Saarbrücken.
- ↑ Andere Gründe sind, dass die Weichenspitze auf Grund des Weichenantriebs und des Weichensignals meist deutlich besser auf Luftbildern zu erkennen ist und dass das abzweigende Gleis dann in OSM unter einem geringerem Winkel abzeigt (insbesondere dann, wenn man im abzweigenden Gleis auf Höhe des Herzstücks einen zusätzlichen Node setzt)