Streckensammler
Daten

Von der DB InfraGO bis in dein iPhone

Stationen, Strecken und Kilometrierung kommen aus einer einzigen, offiziellen Quelle: dem DB InfraGO Infrastrukturdaten-GeoPackage, das die Deutsche Bahn monatlich auf der Mobilithek veröffentlicht. Eine eigens gebaute Python-Pipeline destilliert daraus die JSON- und SQLite-Daten, die in der App liegen.

1. Quelle: DB InfraGO Infrastrukturdaten

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 Streckennummer (VzG, z.B. 2600 für Köln–Aachen). Pro Zeile zusätzlich Kilometrierung, Betriebszustand und Bundesland.
  • M1 Betriebsstellen — eine POINT-Geometrie pro (Station × Strecke)-Paar (~10.600 Zeilen, ~7.700 unterschiedliche Stationen). Schlüssel ist Kürzel (Ril100/DS100), Foreign Key Streckennummer mit exakter km_lage.

Frühere Iterationen versuchten, das Streckennetz aus OpenStreetMap per CDT-Skelettierung zusammenzusetzen — zu viele Heuristiken, zu wenig Stabilität. Die DB-Daten liefern die Beziehung (Station × Strecke) bereits explizit, ohne Proximity-Tricks.

2. Pipeline

Die Python-Pipeline (uv-Projekt) fasst beide Layer zu einem v2-Schema zusammen:

  1. Pro Kürzel einen repräsentativen Stationsdatensatz mit Name, Art (Bf/Hp/...), Bundesland und Status.
  2. Pro Streckennummer alle Geometrien nach DB Betrieb bucketen, je Bucket via linemerge verschmelzen, mit 5 m Toleranz vereinfachen, in WGS84 reprojizieren und als Google-Polylines codieren.
  3. Pro Strecke die zugehörigen Stops aus Betriebsstellen-Zeilen sammeln, nach km_lage sortieren und doppelte Einträge entfernen.

Bundesland-Namen werden auf ISO 3166-2-Suffixe gemappt (NW, BY, …). Stationen jenseits der deutschen Grenze, die auf einer deutschen VzG-Strecke liegen (Basel Bad Bf, Schaffhausen, Enschede, Varnsdorf), bleiben erhalten — sie tauchen später in einer eigenen „Ausland"-Kategorie auf.

3. Override-Workflow

Roh-DB-Daten sind nicht perfekt. Daher gibt es einen lokalen Web-Viewer (FastAPI + React + Mantine), in dem Edge-Cases manuell korrigiert werden:

  • Strecke-Overrides in strecke_overrides.yaml: Strecken ausschließen, umbenennen, Stops ergänzen oder entfernen.
  • Stations-Overrides in station_overrides.yaml: Tipp-Korrekturen pro Ril100.
  • Insel-Triage: Komponenten ohne Hub werden gelistet; meist liegt ein fehlender Endpunkt-Stop oder ein doppelter Ril100-Code zugrunde.

Beide YAMLs sind in das Source-Hash der Punkteberechnung eingerechnet. Eine Änderung markiert den Export automatisch als „stale".

4. Export

Aus dem Roh-Output destilliert ein Filter-Schritt das, was die App tatsächlich braucht — passenger-fähige Stationen, Strecken mit gültigem Status, schlanke Polylines. Heraus fällt ein JSON+SQLite-Bundle (data-v2026-MM-DD.*), das per App-Update mitgeliefert wird.

Eine OTA-Auslieferung über Cloudflare/S3 ist im Konzept vorgesehen, aber noch nicht implementiert — bis dahin ist jedes Datenupdate gleichzeitig ein App-Update.

5. Lizenz

DB InfraGO Infrastrukturdaten sind unter der DB Open Data Initiative bereitgestellt. OpenStreetMap (für die optionale Linien-Shortcut-Funktion in einer späteren Version) ist unter ODbL lizenziert. Die App enthält die nötige Attribution unter „Mehr → Lizenzen".