Baan.failBeta

Methodik

Wie wir messen

Baan.fail erhebt Crowd-Daten zur Bahn-Realität und ergänzt sie um öffentlich verfügbare Echtzeitdaten. Diese Seite legt offen, wie aus einzelnen Meldungen aggregierte Aussagen werden — und welche bewussten Tradeoffs wir treffen.

1. Sekundengenaue Verspätungsmessung

Die DB definiert "pünktlich" als maximal 5:59 Min Verspätung am Zielbahnhof (siehe DB-Pressemitteilungen). Wir definieren "wirklich pünktlich" als maximal 60 Sekunden. Die offizielle Statistik blendet damit eine ganze Klasse Realität aus — fünf Minuten Verspätung sind aus DB-Sicht ein Erfolg, aus Pendler-Sicht ein verpasster Anschluss.

User melden in groben Stops (0 / 5 / 15 / 30 / 60 / 120 Min). Diese Stufung entspricht der subjektiven Wahrnehmung "wie schlimm war's": 5 Min sind grenzwertig, 15 Min sind "Anschluss vermutlich weg", 60 Min sind "ich denk mir was aus". Sekundengenauigkeit liefert das DB-Echtzeitsystem dazu, wenn die Meldung DB-bestätigt wird.

2. Dreistufiges Vertrauensmodell

Nicht jede Meldung wiegt gleich schwer. Wir gewichten Reports nach Verifikationsgrad des Melders, damit Coordinated-Bot-Spam keinen Effekt auf das Aggregat hat:

Die Gewichte fließen in die Aggregation der Verspätungs-Minuten und in die Bestätigungs-Counter ("X Mitreisende bestätigt, davon Y verifiziert").

3. DB-Bestätigt-Siegel

Wenn eine Crowd-Meldung mit den DB-Echtzeitdaten zum gleichen Zug übereinstimmt — also unsere Plausibilitätsprüfung den Trip findet, die Verspätung ähnlich hoch ist und der Geo-Standort zur Strecke passt — bekommt der Report ein DB-Bestätigt-Siegel. Im Frontend ist das die rote "DB-bestätigt"-Markierung neben dem Eintrag.

Das ist Doppel-Validierung: die Crowd sagt was los ist, die DB bestätigt es passiv. Solche Reports sind besonders glaubwürdig — und besonders peinlich für die DB-PR- Abteilung, weil sie ihrer eigenen Statistik widersprechen.

4. baan.fail-Kasse-Berechnung

Kein realer Anspruch — politische Forderung. Die Kasse visualisiert, was die DB theoretisch zurückzahlen müsste, wenn faire Erstattungsregeln gälten: Verspätung größer als Fahrzeit ⇒ 100 % Ticketpreis-Erstattung. Aktuell zahlt die DB ab 60 Min 25 % und ab 120 Min 50 %, was unter dem real entstandenen Schaden liegt.

Pro Meldung addieren wir 30 € zur Kasse, wenn:

Die 30 € sind eine MVP-Pauschale, weil wir den tatsächlichen Ticketpreis pro Reise nicht kennen. Ein durchschnittliches Sparpreis-ICE-Ticket ist eher 50–80 €, eine BahnCard-50- Vollpreis-Reise oft > 100 € — wir bleiben absichtlich konservativ. Phase 2 könnte echte Strecken-Preise einrechnen, wenn die DB endlich eine Tarif-Schnittstelle öffnet.

5. Bot-Schutz und Spam-Abwehr

Crowd-Daten sind nur so verlässlich wie der Schutz vor manipuliertem Input. Vier Schichten:

6. Offene Datenquellen

Alle nicht-versteckten Crowd-Meldungen sind öffentlich abrufbar — als JSON oder CSV, ohne API-Key, ohne Anmeldung. Lizenz: Creative Commons CC BY-SA 4.0. Du darfst die Daten teilen, weiterverarbeiten und veröffentlichen, sofern du Baan.fail als Quelle nennst und Weiterverarbeitungen unter derselben Lizenz stehen.

Endpoints und Beispiele: /api. Der Wochenreport unter /wochenreport aggregiert die letzten sieben Tage als shareable Snapshot.

Unsere Echtzeit-Bahn-Daten kommen vom Open-Data-Endpoint v6.db.transport.rest (gemeinwohl-orientierter Wrapper um die DB-Hafas-API, von Jannis "derhuerst" Redmann betrieben).

Bewusste Limitierungen

Worum geht's?

Wir machen sichtbar, was die Bahn lieber verschweigt.

Reisende dokumentieren hier Verspätungen, Ausfälle und verpasste Anschlüsse — die ganze Realität, nicht nur die Zahlen, die in DB-Pressemitteilungen passen.

Warum? Weil die offizielle Pünktlichkeitsquote der Bahn die Wirklichkeit beschönigt. Weil unser Ärger über Stunden auf falschen Bahnsteigen, kaputten Klimaanlagen und verlorenen Anschlüssen ein Ventil braucht. Weil politischer Druck nur durch belastbare Fakten entsteht — und die müssen wir Reisenden selbst sammeln.

Eine Meldung dauert unter 15 Sekunden. Anonym oder eingeloggt.

→ Verspätung melden