Initial: Mesh-Skills, Configs, Scripts

2026-09-02 23:49:07 +02:00
commit 26c7980750
783 changed files with 145393 additions and 0 deletions
@@ -0,0 +1,66 @@
+# GTFS-Verbindungssuche: RAPTOR real erprobt (2026-08-19)
+
+Kontext: Webseite urlaub.perfekt-ohne-en.de (Zugsuche, nur Nahverkehr/kein ICE).
+Nutzer stellte echte GTFS-Datei bereit (Regional/S-Bahn) — Verarbeitung brachte
+mehrere harte Lektionen.
+
+## Lektion 1: RAPTOR verbessert, aber ist KEINE fertige Lösung
+
+Einfacher **Dijkstra** auf GTFS ist instabil bei grossen Knoten: benachbarte Ziele
+ergaben absurde Differenzen (Mainz→Berlin 11h vs. Nachbar Wiesbaden 3h — unmoeglich).
+**RAPTOR** (Round-Based) ist der richtige Algorithmus und verbessert die Konsistenz
+(Mainz & Wiesbaden → Berlin wurden konsistent ~8h22).
+
+**ABER:** RAPTOR erzeugt weiterhin einzelne absurde Fernwerte (z.B. Mainz→Berlin
+~22h, real Regional ~7-9h; Trefferquote ~66-95%). Ein Algorithmus mit solcher
+Einzelfehlerquote darf NICHT als finale Fahrzeit-Quelle ausgegeben werden.
+
+**Praxisfix (Nutzer-Entscheidung „3 dann 1"):**
+- **Option 3 (sofort):** nur *team-verifizierte* Kernzeiten konkret anzeigen
+  (Plausibilitaets-Anker: Trier→Saarbruecken ~1h, Koeln→Aachen ~50min, vom Team
+  bestaetigt). Alle anderen Verbindungen → `fahrzeit_h='pruefen'` in SQLite; Template
+  rendert stattdessen orangen Hinweis „vor Fahrt prüfen". NIE absurde/inkonsistente
+  Zahl als real stehen lassen.
+- **Option 1 (danach):** robuste Suche erst auf die Seite schreiben, wenn JEDER Wert
+  separat gegen einen Plausibilitaets-Anker verifiziert ist.
+
+## Lektion 2: Konsistenz-Check = Nachbar-Ziele gegeneinander pruefen
+
+Der schnellste Fehlerdetektor: benachbarte Ziele vergleichen. Mainz→Berlin darf
+nicht dramatisch von Wiesbaden→Berlin abweichen (gleiche geographische Lage).
+Erst wenn das Cluster konsistent ist, Werte freigeben.
+
+## Lektion 3: PDF-Haltestellenliste via VORAB-PFAD-CACHE
+
+Nutzerwunsch: PDF soll die komplette Verbindung (`von → zwischenhalte → nach`) zeigen,
+nicht nur Start/Ziel. On-the-fly-Routing bei jedem PDF-Aufruf ist zu langsam
+(RAPTOR ~40-200s → nginx **504 Gateway Timeout**).
+
+**Lösung:** Vorab einmalig Pfad-Cache bauen (`pfade_cache.json`), NUR die Kern-Ebenen
+1+2 (~1.900 eindeutige `von|nach`-Paare; Ebene 3 = Kleinstaedte braucht keine eigenen
+PDFs). PDF-Route liest `json.load(cache)[f"{start}|{ziel}"]["seg"]` → Ladezeit von
+504 auf **~0,4s**. Wiederverwendbares Muster: Wenn On-the-fly-Berechnung zu langsam
+ist, vorab einen Cache bauen und die Route daraus lesen.
+
+- Template ergaenzt Start-Stadt als ersten + Ziel-Stadt als letzten Eintrag, damit
+  die Liste immer den Rahmen `von → ... → nach` bildet.
+
+## Lektion 4: GTFS-Datenmodell-Fallen
+
+- `stops.txt` Spaltenreihenfolge ist NICHT `stop_id,stop_name,...` — sie ist
+  `stop_name,parent_station,stop_id,stop_lat,stop_lon,...`. Beim Import die echte
+  stop_id aus den richtigen Spalten ziehen (parent_station ist oft die nutzbare ID).
+- Ein Bahnhof hat **mehrere stop_ids** (Saarbruecken Hbf hat 6, nur je 1 aktiv in `st`;
+  Koeln Hbf hat 2). Geo-Merging (<350m) gruppiert sie; sonst matcht die Suche auf
+  eine tote ID und liefert „keine Verbindung".
+- Zeit-Spalten: `HH:MM` ODER `HH:MM:SS` — to_sec() muss beides handhaben.
+- COROS/Efa-Text-APIs liefern oft `\\n` als literalen Backslash-n statt echten
+  Zeilenumbruchen → vor dem Parsen `text.replace('\\n','\n')`.
+
+## Performance-Falle bei Gesamt-Neuberechnung
+
+Pro-Profile-Query (33 Abfahrtszeiten) × pro Verbindung ist zu teuer fuer ~12.000
+Verbindungen (huubai 18h). Effizienter: **EIN Dijkstra/RAPTOR je eindeutiger
+Start-Bahnhof (Ausbreitung zu allen Zielen in einem Lauf)** → ~250 Starts statt
+12.000 × viele → von Stunden auf ~10min. Cache die Ausbreitung je Start und lese
+die Ziel-Ankunft daraus ab.