Projekte

Wanderzeiten vorhersagen: aus 5.211 GPS-Punkten ein Modell.

Eigenprojekt30. Juli 2026

Bereich

Tourismus

Umsetzung

seit Juni 2026, laufend

Kompetenz

Machine Learning · Data Engineering

Stack

Python · SQLite · pandas · scikit-learn · Geodaten · Git

In vier Sätzen: Aus zwanzig Jahren Wandern liegen Daten vor — 5.211 handgesetzte Punkte, 1,77 Millionen GPS-Positionen, 101 handgeschriebene Tagesprotokolle und ein Temperatursensor — nur eben in einer undokumentierten App-Datenbank, in Notiz-Exporten und in Dateien aus 2012. Ziel war eine einfache Frage: Wie lange brauche ich für eine Etappe, die ich noch nie gegangen bin? Das Ergebnis ist ein Modell mit 15 % Fehler auf der Gesamtzeit einer Tour, gegen 43,5 % der Standardformel aus der Wanderliteratur — und interessanter als das Ergebnis ist, was auf dem Weg dorthin nicht funktioniert hat: Ein Gradient-Boosting-Modell schlug die einfache Formel nicht, und drei physikalisch völlig sinnvolle Faktoren mussten wieder raus, weil sie die Prognose messbar verschlechterten. Dieser Text handelt von Datenarchäologie, von Feature-Auswahl mit einer harten Metrik und davon, warum «mehr Signale» selten «bessere Vorhersage» heißt.

Hinweis: Ein eigenes Projekt, kein Kundenauftrag. Alle Zahlen stammen aus dem laufenden Repository. Wo Wissensbasis und Code auseinanderliefen, steht hier der Code — es waren fünf Stellen, dazu am Ende mehr.

Die Ausgangsfrage und das Datenchaos

Das Wanderziel ist ein Fernwegnetz in den Alpen, das über Jahre in Etappen abgelaufen wird. Für die Planung braucht man eine belastbare Antwort auf «wann bin ich abends da?». Die üblichen Antworten sind schlecht: Wegweiser nennen Zeiten für einen Durchschnittswanderer, und die Standardformel der Literatur — Naismith, 1892 — kennt nur Distanz und Aufstieg.

Die eigenen Daten sollten es besser können. Sie lagen in vier Töpfen, die nichts voneinander wussten:

Quelle	Umfang	Problem
Wander-App (Locus Map)	5.211 Punkte, 381 Routen, 1,77 Mio. GPS-Positionen	undokumentiertes Schema, Binärfelder
Alt-Archiv	GPX aus Georgien 2012, Tienschan 2013	anderes Gerät, keine Höhenreferenz
Notiz-Export	101 Tagesprotokolle 2015–2023	Freitext, gemischt mit Privatem
Temperatursensor	452 Segmente, 10 Touren	eigene Zeitzone, Mikroklima am Gürtel

Datenarchäologie: ein Binärformat ohne Dokumentation

Die App speichert in zwei SQLite-Dateien. Das Schema ist zugänglich, die Bedeutung nicht. Drei Funde, die typisch für Reverse Engineering sind:

Erstens: Der Datentyp im Schema lügt. Die Koordinatenspalten sind als INTEGER deklariert, enthalten aber Fließkommazahlen — SQLite erlaubt das, weil es Typen pro Wert und nicht pro Spalte führt. Wer sich auf das Schema verlässt und als Ganzzahl liest, bekommt gerundete Koordinaten und wundert sich über Punkte im Nachbartal.

Zweitens: Ein Feld ist ein eigenes Binärformat. Jeder Punkt hat ein extra_data-Feld — ein BLOB ohne Dokumentation. Es enthält Beschreibung, Symbol, Adresse, Telefonnummer, Quelle und, entscheidend, die Pfade zu Fotos und Audioaufnahmen. Ohne dieses Feld sind 2.805 Anhänge in der Datenbank unsichtbar.

Die Struktur ließ sich durch Vergleichen erschließen: ein Kopf aus neun Bytes, dann ein 32-Bit-Zähler, dann so viele Einträge, wie der Zähler sagt — jeder aus Schlüssel, Länge und Nutzdaten. Was welcher Schlüssel bedeutet, stand nirgends; es wurde empirisch bestimmt, indem bekannte Punkte mit bekannten Fotos gesucht und die Werte abgeglichen wurden.

Drittens: Der gespeicherte Kennwert ist nicht der beste. Zu jeder Route liegt eine fertige Statistik im Datensatz — Distanz, Aufstieg, Dauer, als Zwischenspeicher der App. Verlockend, aber unzuverlässig: Sie stammt aus dem Zustand, als die Route zuletzt in der App angefasst wurde. Verlässlich ist nur, was man aus den 1,77 Millionen Positionsdatensätzen selbst nachrechnet. Regel daraus: Zwischengespeicherte Kennzahlen sind ein Hinweis, keine Quelle.

Der Fund, ohne den alles falsch geworden wäre

Der wichtigste Schritt hat mit Modellen nichts zu tun. Es geht darum, was ein Datenpunkt eigentlich bedeutet.

Die Punkte in der Datenbank sehen alle gleich aus. Tatsächlich entstehen sie auf zwei völlig verschiedene Weisen:

• Feldpunkte — im Gehen gesetzt, bei einer Hütte, an einer Abzweigung, mit Foto. Sie sind ein Beweis, dass jemand dort war.
• Vorbereitungspunkte — zu Hause am Kartentisch gesetzt oder importiert, wenn eine Etappe geplant wird. Sie sind eine Absicht und beweisen nichts.

Vermischt man beides, entsteht ein systematischer Fehler in jeder Auswertung: Geplante, nie gegangene Etappen erscheinen als «abgelaufen», und in ein Zeitmodell fließen Zeitabstände ein, die niemand gegangen ist.

Unterscheiden lassen sich beide durch Physik. Zwei Punkte, die innerhalb von drei Minuten entstehen, aber mehr als 800 Meter auseinanderliegen, kann kein Mensch zu Fuß erzeugt haben — das ist Kartentischarbeit. Punkte ohne gültigen Zeitstempel sind Importe. Alles andere gilt als Feldpunkt.

Das Ergebnis: 4.917 Feldpunkte, 294 Vorbereitungspunkte. Die Regel ist grob, aber prüfbar — und sie bestätigt sich an bekannten Fällen: Bei einer Städtereise mit vorab gesammelten Sehenswürdigkeiten stehen 12 Feld- gegen 17 Vorbereitungspunkte, bei der Planung einer Inselrunde 5 gegen 45, bei den alpinen Touren praktisch null Vorbereitungspunkte.

Merkmale bauen: was ein Segment beschreibt

Das Zeitmodell arbeitet nicht mit ganzen Tagen, sondern mit Segmenten — den Abschnitten zwischen zwei aufeinanderfolgenden Feldpunkten. Für jedes Segment entstehen Merkmale, die den Aufwand beschreiben könnten:

• Distanz — nicht Luftlinie, sondern entlang des Referenzwegs. Punkte werden dafür auf die Wegline gefangen; wer bei 120 m nicht mehr zuordenbar ist, fällt heraus.
• Auf- und Abstieg aus einem Höhenmodell (SRTM, 90-Meter-Raster).
• Steigung, mittlere und Netto — die Richtung des Tages.
• Windungsgrad: Weglänge geteilt durch Luftlinie. Serpentinen kosten Zeit, die in der Distanz nicht steckt.
• Sonnenstand und daraus ein Dunkelheits-Kennzeichen.
• Stunden seit Tagesstart als Ermüdungsproxy und Tag der Tour für den Rucksackgewicht-Effekt.
• POI-Dichte aus OSM als Proxy für «hier bleibt man stehen».
• Temperatur und Luftfeuchte aus dem Sensor, wo vorhanden.

Am Ende steht eine flache Tabelle: 2.393 Segmente, 59 Touren, 21 Spalten. Das ist der eigentliche Wert des Projekts — nicht das Modell, sondern der Datensatz, der jede weitere Frage beantwortbar macht.

Ein Detail, das später wichtig wird: Das Höhenmodell unterschätzt den Aufstieg gegenüber einer GPS-Aufzeichnung, um etwa das 1,37-fache. Das ist zunächst schlecht — aber solange Training und Prognose dieselbe Quelle benutzen, ist es konsistent: Der gelernte Koeffizient je Höhenmeter saugt die Unterschätzung auf. Gefährlich wird es erst, wenn man den Aufstieg später «korrigiert» und dabei die Zeit doppelt bestraft. Genau dieser Fehler passierte einmal und wurde zurückgebaut.

Das Modell und die Metrik, die zählt

Es gibt zwei Arten, ein Zeitmodell zu bewerten, und sie führen zu unterschiedlichen Modellen.

Die naheliegende Metrik ist der Fehler pro Segment. Die nützliche ist der Fehler auf der Gesamtzeit einer Tour — denn das ist die Frage im Leben: Bin ich abends vor der Dunkelheit da? Segmentfehler heben sich über einen Tag teilweise auf; wer auf Segmentfehler optimiert, optimiert an der Frage vorbei.

Zweite Entscheidung: die Aufteilung für die Kreuzvalidierung. Zufällig geteilt wäre wertlos, weil Segmente derselben Tour sich ähneln — das Modell würde sich selbst prüfen. Deshalb leave-one-trip-out: Es wird auf allen Touren außer einer trainiert und auf der ausgelassenen geprüft, für jede Tour einmal.

Die Ergebnisse gegen zwei Formeln aus der Literatur:

Modell	Fehler Segment (min)	Fehler Gesamtzeit
Naismith (1892)	7,23	43,5 %
Tobler (Wanderfunktion)	7,65	51,9 %
kalibrierte Formel	6,17	20,5 %
Gradient Boosting	6,31	18,7 %

Auf der Zielgruppe der alpinen Fernwegtouren, für die das Modell gebaut ist, liegt die kalibrierte Formel bei 15,0 %. Der Sprung von 43,5 auf 15 kommt nicht von einem klugen Algorithmus, sondern davon, dass die Formel auf dieser Person gelernt ist statt auf einem Durchschnittswanderer.

Die gelernte Formel für die Segmentzeit in Minuten:

20,15 · km
+ 0,088 · Aufstieg_m
+ 0,094 · Abstieg_m
+ 0,93 · km · (ist_dunkel)
− 0,108 · km · (Stunden seit Start)
+ 0,74 · km · (Windungsgrad − 1)

Jeder Term ist lesbar, und genau das ist der Punkt:

• 20,15 min/km Grundtempo entspricht knapp 3 km/h inklusive der üblichen kleinen Stopps — nicht Bewegungstempo, sondern verstrichene Zeit.
• 0,088 min je Höhenmeter Aufstieg — bemerkenswert nah an Naismiths historischer Regel von einer Stunde pro 680 Höhenmeter.
• Abstieg kostet wie Aufstieg. Das widerspricht der Intuition und passt zum Stil: vorsichtige, fotografierende Abstiege.
• Dunkelheit macht langsamer, nicht schneller — plus knapp eine Minute je Kilometer.
• Windungsgrad kostet Zeit. Dieser Term hatte in einer früheren Version das falsche Vorzeichen: Serpentinen erschienen als Beschleuniger. Es war ein Artefakt zu kleiner Datenmenge — mit den alten Expeditions-GPX kippte das Vorzeichen ins Erwartbare. Ein Vorzeichen, das der Physik widerspricht, ist ein Datenproblem, kein Fund.
• Der Ermüdungsterm ist leicht negativ: Über einen Mehrtagesmarsch wird man im Tagesverlauf eher schneller. Auf Mehrtagesdaten liest sich das als Einlaufen, nicht als Erschöpfung.

Warum das Machine-Learning-Modell nicht gewonnen hat

Ein Gradient-Boosting-Modell auf denselben Merkmalen liegt beim Segmentfehler schlechter und bei der Gesamtzeit rund zwei Prozentpunkte besser. Trotzdem geht die Formel ins Produkt. Drei Gründe:

Der Vorsprung ist nicht stabil. Zwei Prozentpunkte bei 59 Touren und einer Kreuzvalidierung, deren Streuung größer ist als der Unterschied — das ist kein belastbarer Sieg.

Die Formel ist erklärbar. Bei einer Prognose von neun Stunden kann ich sagen, welcher Anteil auf Distanz, Aufstieg und Dunkelheit entfällt. Das Boosting-Modell nennt eine Zahl. Für eine Entscheidung am Vorabend einer Tour ist Nachvollziehbarkeit mehr wert als zwei Prozentpunkte.

Sechs Koeffizienten passen auf ein Telefon. Die Formel läuft überall — auch offline im Tal ohne Netz. Ein trainiertes Modell mitzuschleppen wäre Aufwand ohne Gegenwert.

Das ist keine Ablehnung von ML. Es ist das Ergebnis einer Messung: Wenn das komplexere Verfahren nicht deutlich gewinnt, gewinnt das einfachere.

Drei gute Ideen, die die Prognose verschlechtert haben

Der interessanteste Teil. Alle drei Faktoren sind physikalisch plausibel, ihre Koeffizienten kamen mit richtigem Vorzeichen und sinnvoller Größe heraus — und keiner hat die Prognose verbessert.

Schnee. Aus Höhe und Monat lässt sich abschätzen, ob ein Segment oberhalb der Schneegrenze lag. Der Koeffizient kam mit +3,4 Minuten je Kilometer heraus — genau die Größenordnung, die man erwartet. Verbesserung der Prognose: keine.

Rucksackgewicht. Über den Tag der Tour als Proxy: Am ersten Tag ist der Sack am schwersten. Die Prognose wurde schlechter.

POI-Dichte. Aussichtspunkte und Wasserfälle als Proxy für Fotostopps. Koeffizient sinnvoll, Wirkung null.

Temperatur. Ein Sensor in der Netztasche am Hüftgurt, 452 Segmente aus 10 Touren, Zeitzonen sauber umgerechnet. Die Prognose wurde von 19,1 % auf 21,9 % schlechter.

Der Grund ist in allen Fällen derselbe: Konfundierung mit dem Relief. Schnee liegt oben — die Höhe steckt schon im Aufstieg. Aussichtspunkte liegen an Pässen — dasselbe. Kälte korreliert mit Höhe, frühem Morgen und Jahreszeit. Die neuen Merkmale bringen kaum Information, die nicht schon im Modell ist, kosten aber Freiheitsgrade — bei 59 Touren ist das teuer. Beim Sensor kommt Messrauschen dazu: Am Körper getragen misst er Sonne, Körperwärme und nachts das Zeltinnere.

Die Konsequenz war in allen vier Fällen dieselbe: nicht einbauen. Die Daten bleiben liegen, weil sich das mit mehr Touren ändern kann — aber nicht ins Modell, solange die Messung es nicht rechtfertigt.

Vom Bewegungsmodell zur Ankunftszeit

Ein Modell, das Gehzeit vorhersagt, beantwortet die Frage noch nicht. Wer um 6 Uhr startet und neun Stunden Gehzeit vor sich hat, ist nicht um 15 Uhr da — es fehlen die Pausen, und die Referenzgeometrie ist kürzer als der echte Weg.

Beim Kalibrieren dieser Aufschläge passierte der lehrreichste Fehler des Projekts. Der erste Vergleich nahm einen kompletten Mehrtagesblock und ergab einen Faktor von 1,66 auf das Grundtempo. Auf einzelne, saubere Etappen angewendet ergaben die Rückrechnungen aber 0,91 / 1,14 / 1,41 — der Blockfaktor überschätzte eine Einzeletappe um bis zu 50 %.

Die Ursache: Im Block steckten Abweichungen, die nicht zur Etappe gehören — Gipfelabstecher, Varianten, Wege zur Bushaltestelle. Wer daraus einen Faktor «pro Kilometer» macht, verteilt Extrastrecke auf das Tempo und macht das Modell dauerhaft pessimistisch. Heute steht der Faktor bei 1,15, und die Grenze ist offen benannt: sauber begrenzen ließen sich nur drei Etappen.

Zwei weitere Entscheidungen an dieser Stelle:

Nur das Grundtempo wird korrigiert, nicht der Aufstieg. Der Aufstiegsanteil ist über dasselbe Höhenmodell gelernt, mit dem prognostiziert wird — er ist in sich konsistent. Ihn mitzuskalieren wäre eine doppelte Strafe für steile Etappen.

Pausen sind eine Konstante. Aus neun belastbaren Alleintagen: Median 100 Minuten, Spanne 15 bis 215. Ein Zusammenhang mit der Tageslänge war nicht erkennbar — die Korrelation liegt bei null. Also 1,7 Stunden pro Tag als Konstante, überschreibbar. Eine Scheinabhängigkeit hineinzumodellieren, wäre Genauigkeit vorgetäuscht.

Die Ausgabe nennt beides: den rohen Modellwert und die korrigierte Ankunft. Wer die Annahme nicht teilt, sieht, worauf sie aufsetzt. Zusätzlich prüft das Werkzeug, ob die Ankunft noch im Tageslicht liegt — mit der korrigierten Zeit, nicht der rohen.

Privatsphäre als Konstruktionsentscheidung

Die reichhaltigste Quelle für den echten Tagesverlauf sind 101 handgeschriebene Tagesprotokolle aus einem Notiz-Export. Sie liegen aber in einem Konto, das auch persönliche Tagebücher, Einkaufszettel und Notizen über andere Menschen enthält.

Deshalb steht im Projekt eine Regel, die vor dem ersten Parser da war: Es werden ausschließlich Reise-Chronometrien ausgewertet. Persönliche Tagebücher, private Notizen und Informationen über Dritte werden nicht geparst und nicht in die Wissensbasis übernommen. Konkrete Ausschlüsse sind dokumentiert.

Das kostet Datenmenge. Es ist trotzdem richtig — und zwar aus zwei Gründen. Der erste ist der offensichtliche. Der zweite ist praktisch: Sobald private Daten einmal in einen abgeleiteten Datensatz gelaufen sind, bekommt man sie nicht zuverlässig heraus, weil man sie in Zwischenergebnissen und Modellen nicht mehr findet. Datensparsamkeit ist billiger vorne als hinten. Dasselbe Argument bringe ich in Kundenprojekten, wenn es um Personendaten in Auswertungen geht.

Reproduzierbarkeit: ein Befehl nach jeder Tour

Ein Modell, dessen Aktualisierung ein Nachmittagsprojekt ist, wird nicht aktualisiert. Deshalb ist der komplette Weg von neuen Rohdaten zum neu trainierten Modell eine Kommandozeile:

Sie liest das neue Backup ein, sichert die alten Datenbanken weg, rechnet Referenz und Abdeckung neu, erzeugt Tourenlisten und Berichte, baut den Segmentdatensatz neu und trainiert das Modell neu. Danach vergleicht sie den Zustand vor und nach dem Lauf und schreibt die Differenz — wie viele Kilometer neu belegt sind — in ein Journal. Gibt es keine Änderung, wird das Journal nicht angefasst.

Zwei Eigenschaften daran halte ich für übertragbar:

Die Reihenfolge ist im Code, nicht im Kopf. Sechs Skripte in fester Folge, abbrechen beim ersten Fehler. Niemand muss sich erinnern, dass der Datensatz vor dem Training neu gebaut werden muss.

Das Ergebnis ist ein Diff, keine Meldung «fertig». Die interessante Information nach einer Tour ist nicht, dass der Lauf durchging, sondern was sich geändert hat.

Was die Wissensbasis falsch hatte

Das Projekt hat, wie mein Reiseportal, eine Wissensbasis aus Markdown im Repository — Datenmodell, Methoden, Grenzen, ein Journal. Beim Schreiben dieses Texts habe ich jede Zahl gegen den Code geprüft. Fünf Abweichungen:

Wissensbasis	Code
Formel mit 20,3 min/km und 0,79 für Dunkelheit	20,15 und 0,93
«Gehzeit × 1,47» im Anwendungsabschnitt	Faktor ist 1,15, zwei Absätze höher korrekt
Prognosefehler «~15,7 %» in der Übersicht	15,0 % in Modellseite und Auswertung
«~740 km» abgelaufen in der Übersicht	~719 km in der generierten Statusseite
Auswertung: «Windungsgrad kontraintuitiv», «Dunkelheit +2,3 min/km»	im selben Dokument oben bereits korrigiert

Keine davon ist dramatisch, und alle haben dieselbe Ursache: Zahlen, die einmal in Prosa geschrieben wurden, altern. Die generierten Seiten waren korrekt — sie kommen aus den Skripten. Falsch waren durchweg die handgeschriebenen Stellen.

Die Lehre steht inzwischen als Regel im Projekt: Was aus Daten folgt, wird generiert und nicht getippt. Und wer eine Zahl veröffentlicht, holt sie aus dem laufenden System.

Was ich daraus mitnehme

Die Bedeutung eines Datenpunkts ist wichtiger als die Menge. Der Unterschied zwischen «hier war ich» und «hierhin wollte ich» entscheidet, ob eine Auswertung stimmt. Kein Algorithmus repariert eine falsche Grundannahme.

Eine Metrik, die zur Frage passt, schlägt eine, die gut aussieht. Der Fehler pro Segment ist eine schönere Zahl. Der Fehler auf der Gesamtzeit ist die, die über einen Abend im Dunkeln entscheidet.

Ein plausibler Koeffizient ist kein Beweis. Vier Merkmale kamen mit richtigem Vorzeichen und sinnvoller Größe — und keines verbesserte die Prognose. Ohne Kreuzvalidierung wären alle vier im Modell, und es wäre schlechter.

Ein widersprüchliches Vorzeichen ist ein Datenproblem. Der Windungsgrad war mit wenig Daten ein Beschleuniger. Mehr Daten haben ihn gedreht. Wer solche Vorzeichen wegerklärt, baut Unsinn ein.

Einfacher gewinnt bei Gleichstand. Sechs erklärbare Terme statt eines trainierten Modells — weil der Vorsprung nicht stabil war und Nachvollziehbarkeit im Anwendungsfall mehr wert ist.

Was davon für kleine Betriebe übrig bleibt

Wanderzeiten sind ein ungewöhnliches Thema. Die Fragen darunter sind es nicht.

• «Wie lange dauert das?» Handwerk, Werkstatt, Dienstleistung — überall entscheiden Zeitschätzungen über Angebote und Termine. Und überall wird nach Gefühl geschätzt oder aus einer Pauschale, obwohl die eigene Historie in Aufträgen, Zeiterfassung und Rechnungen schon steht. Ein Modell auf eigenen Daten ist fast immer besser als eine Branchenpauschale — genau wie hier 15 % gegen 43 %.
• «Was bedeutet dieser Datensatz eigentlich?» Vor jeder Auswertung steht die Frage, was eine Zeile ist. Ein storniertes Angebot, ein Test-Auftrag, eine Doppelerfassung — wer das nicht trennt, rechnet Unsinn mit hoher Präzision.
• «Brauchen wir dafür KI?» Meist nicht. Eine nachvollziehbare Formel auf saubere Merkmale geschlagen ist oft genauso gut und im Betrieb erklärbar. Ich messe beides und nehme das Einfachere, wenn es nicht schlechter ist.
• «Was ist mit Personendaten?» Was nicht in die Auswertung wandert, muss man später nicht suchen. Bei Auswertungen über Kunden oder Mitarbeitende ist das der günstigste Zeitpunkt für diese Entscheidung.

Wenn Sie Zahlen haben, aus denen sich etwas ableiten ließe — Zeiten, Aufträge, Verbräuche — und niemand kommt dazu, sie anzusehen: Offen für eine Festanstellung in Data Analytics und Automatisierung? Kontakt aufnehmen.

← Alle Projekte