Wie kommt die Schiene in dein iPhone?

1. Basisquelle: Infrastrukturdaten der DB InfraGO

Die GeoPackage-Datei (Format .gpkg, EPSG:25832) enthält sechs Layer. Streckensammler verwendet zwei davon:

• M1 Streckennetz — eine MULTICURVE-Geometrie pro Streckenabschnitt (~33.000 Zeilen). Schlüssel ist die STREDA-Streckennummer (VzG, z.B. 2600 für Köln–Aachen).

  Daraus leite ich für die App die Strecken und ihre Liniengeometrien ab. In dieser Geometrie sind alle Streckengleise enthalten. Für die App ist das nicht relevant, daher werden die Geometrien nach dem von P. Czioska et al. entwickelten Algorithmus zur Erstellung eines vereinfachten Bahnnetzes durch Generalisierung vereinfacht.

• M1 Betriebsstellen — eine POINT-Geometrie pro (Station × Strecke)-Paar (~10.600 Zeilen, ~7.700 unterschiedliche Stationen). Schlüssel ist Kürzel (Ril100/DS100).

  Daraus leite ich für die App die Bahnhöfe und weiteren Betriebsstellen sowie ihre Verbindung zu den Strecken und die Kilometrierung ab.

2. Manuelle Kontrolle

Die Datenpipeline fasst alle diese Rohdaten zusammen und bereitet sie optisch für eine Kontrolle auf:

1. Dabei wird analysiert, ob es sich bei einer Betriebsstelle um einen Bahnhof/Haltepunkt oder eine sonstige Betriebsstelle handelt. Sonstige Betriebsstellen wie Abzweigungen oder Übergabestellen sind für die App nicht relevant und werden herausgefiltert.
2. Automatische Analysen finden Inkonsistenzen in den Daten:
   • Strecken, die nicht mit dem Gesamtnetz verbunden sind („Inseln"). Es gibt zwar legitime Inseln (wie die Wangerooger Inselbahn ), aber meist liegt ein Fehler in der Datenbank zugrunde, wie eine fehlende Verknüpfung. Diese werden manuell überprüft und mit anderen Quellen wie z.B. VIA von bahnkonzept.de oder dem entsprechenden Wikipedia Artikel abgeglichen und die fehlenden Betriebsstellen werden ergänzt.
   • Cluster von Haltestellen. Es gibt Fälle, in denen mehrere Betriebsstellen sehr nahe beieinander oder quasi übereinander liegen. Dafür gibt es valide Gründe (z.B. Frankfurt Hbf und Frankfurt Hbf (tief) sind betrieblich getrennt, aber räumlich sehr nah). In anderen Fällen (gerade bei Importen aus OpenStreetMap) kann es sich um Duplikate handeln, weil z.B. ein einzelner Bahnsteig als eigener Bahnhof erfasst wurde. Diese werden manuell überprüft und ggf. zusammengeführt.
   • Haltestellen mit besonders vielen oder keinen Verbindungen. Alle Bahnhöfe, die mit mehr als 5 Strecken verbunden sind, sollten zumindest einmal händisch auf Plausibilität geprüft werden. Ebenso alle Bahnhöfe, die mit keiner einzigen Strecke verbunden sind. Da handelt es sich meist um Fehler in der Datenbank, wie z.B. fehlende Verknüpfungen oder fehlende Strecken, die dann manuell ergänzt werden.
   • Strecken, die lediglich mit nicht-passagierfähigen Betriebsstellen verbunden sind Im Netz der InfraGO gibt es einige Strecken, die nur mit Betriebsstellen verbunden sind, an denen kein regulärer Personenverkehr stattfindet, wie z.B. Verbindungsstrecken, Rangierbahnhöfe oder Güterterminals. Diese Strecken sind für die App nicht relevant und werden herausgefiltert.

     Mir ist bewusst, dass das für einige Nutzer:innen ärgerlich sein kann, da es sich teilweise um legitime, befahrbare Strecken handelt und man im Sinne von "Gotta Catch 'Em All" gerne jede Strecke tracken würde. Allerdings habe ich mich bisher dazu entschlossen das Tracking der Strecken durch das Tracken der Bahnhöfe darzustellen. Viele Nutzer:innen wissen nicht, dass sie gerade über die Abzweigung Frankfurt am Main Kleyerstraße FKY von der Strecke 3610 auf die Strecke 3683 wechseln, und können das auch nicht treffsicher tracken. Wenn ihr coole Ideen habt, wie man das sinnvoll abbilden kann, meldet euch.

3. Erweiterung mit OpenStreetMap-Daten

Identifizieren von fehlenden NE-Bahn-Strecken. Die Nichtbundeseigenen Bahnen (NE-Bahnen) sind nicht in der DB-Quelle enthalten. Leider gibt es keine konsistente Datenquelle, die von diesen EVUs bereitgestellt wird. Da es eine großartige deutsche Community in der OpenStreetMap gibt, sind viele dieser Strecken dort aber sehr gut gepflegt. In der Datenpipeline gibt es dazu zum einen die Möglichkeit, die OpenRailwayMap als Overlay einzublenden um visuell direkt zu sehen, ob Strecken fehlen.

In der OpenStreetMap sollen die STREDA-Streckennummern eigentlich an einer Relation mit dem Tag route=tracks hinterlegt und mit dem Attribut ref versehen sein. In der Praxis ist das leider nicht immer der Fall, daher gibt es zusätzlich die Möglichkeit, teilweise sind auch Bahnlinien mit route=train getaggt, oder die Streckennummern sind in den Namen der OSM-Relationen. Das wird von der Suche in der Datenpipeline berücksichtigt.

Die Punkte, Wege und Relationen der gefundenn Strecken werden zusammengeführt um einen konsistenten Streckenverlauf zu ermitteln. Leider sind an vielen Stellen in den OpenStreetMap Daten die Betriebsstellen nicht mit der Strecke verknüpft. Daher suche ich Bahnhöfe in der Nähe der Strecke und zeige diese beim Import an. Zusammen mit einem anderen Datenabgleich wie der Wikipedia oder VIA von bahnkonzept.de kann so manuell entschieden werden, welche Bahnhöfe zur Strecke gehören und eventuell in meinem Datensatz ergänzt werden sollen.

4. Punkteberechnung

Aus dem Streckennetz wird zusätzlich für jeden Bahnhof ein Punktewert zwischen 1 und 100 berechnet — schwer erreichbare Endbahnhöfe zählen viel, gut vernetzte Knoten wenig. Die ausführliche Erklärung mit Beispielen steht auf der Punkte-Seite.

Für die Pipeline ist die Punktewert-Karte vor allem ein Plausibilitätscheck: Stationen werden farblich nach ihrem Score eingefärbt, und Ausreißer fallen auf einen Blick auf.

So ist zum Beispiel aufgefallen, dass Montabaur ICE und Montabaur Regio als zwei separate Ril100-Codes geführt werden, obwohl die Bahnsteige nur ~20 m auseinander liegen. Ohne Verknüpfung wäre dort ein dichter Cluster aus 100-Punkte-Stationen entstanden, der über die Schnellfahrstrecke Köln–Frankfurt direkt angebunden ist — also alles andere als „schwer erreichbar". Die Punkteberechnung verbindet solche co-lokalisierten Bahnhöfe daher mit einer virtuellen Fußweg-Kante, sodass die Topologie der tatsächlichen Erreichbarkeit entspricht.