Vom Wecker zur nachvollziehbaren Pendelplanung.

Der Ausgangspunkt war ein intelligenter Wecker. Daraus wurde bewusst ein Pendelplaner: Arbeitsbeginn, Aufstehen, Losgehen, Verbindung und Ankunft sollen als zusammenhängende Kette sichtbar sein.

Im Prototyp: Arbeitsbeginn, Vorbereitung, Pendelzeit und Puffer fließen in eine nachvollziehbare Empfehlung ein.

Die Zeit zwischen Aufstehen und Losgehen ist nicht für alle gleich. IXIT behandelt Vorbereitung deshalb als Profilwert statt als versteckte Pauschale. Start, Ziel, Verkehrsmittel und Alarmton werden ebenfalls im Pendelprofil gehalten.

Im Prototyp: Profilwerte bilden den Rahmen für die Planung und den späteren Alarm.

GTFS-Daten werden vorab aufbereitet und als Android-lesbare SQLite-Datenbasis genutzt. Dadurch bleiben Stationssuche und Routing auf dem Gerät nachvollziehbar, während aufwendige Aggregationen nicht bei jeder Eingabe neu entstehen.

Im Prototyp: lokale Fahrplandaten, StopArea-Profile, Aliase und Linieninformationen.

Abkürzungen, Umlaute, Bahnhofsnamen und Linienkontext machen eine einfache Textsuche schnell unzuverlässig. IXIT trennt deshalb Suchhilfe von stabilen Routing-Identitäten und zeigt Vorschläge mit Linienbadges.

Im Prototyp: Stationsfamilien, Aliase, Suchranking und Linienhinweise.

Eine Verbindung ist mehr als eine Minutenangabe. IXIT führt Direktverbindungen, Umstiege, Zwischenhalte, Linien, Gleis- oder Steiginformationen und Datenstatus in einer Pendelkette zusammen.

Im Entwicklungsstand: Direktverbindungen und Verbindungen mit bis zu sechs Umstiegen, einschließlich Walk- und Umstiegsbeziehungen.

Ein gesetzter Alarm enthält einen Snapshot des zugrunde liegenden Pendelplans. Dadurch ändert eine spätere Profilanpassung nicht stillschweigend die Bedeutung eines bereits geplanten Alarms.

Im Prototyp: Alarmplanung, Berechtigungsprüfung, Benachrichtigung und Wiederherstellung nach Neustart.

Verspätungen und Verbindungen können nützlich sein, müssen aber als Datenstand erkennbar bleiben. IXIT trennt deshalb statische Daten, Entwicklungsdiagnostik und spätere Echtzeit-Anbindungen bewusst voneinander.

In Prüfung: produktive Echtzeitnutzung und die dafür nötige Datenqualitätsabsicherung.

Arbeitsorte, Routinen, Schichtzeiten und Alarmdaten sagen viel über den Alltag aus. IXIT soll so viel wie möglich lokal verarbeiten und Datenquellen sowie spätere Freigaben transparent machen.

In Prüfung: Datenschutz- und Datenkontrolloberflächen vor einer öffentlichen Testphase.

Der GTFS-Preprocessor erzeugt eine vollständige Deutschland-SQLite-Datenbasis. Die naheliegende Lösung wäre gewesen, diese Daten beim App-Start vollständig in In-Memory-Objekte zu laden. Genau das wurde verworfen: Der Deutschland-Gesamtdatensatz ist dafür zu groß und würde den eigentlichen Vorteil der Vorverarbeitung wieder zunichtemachen.

Stattdessen entstand eine query-native Datenzugriffsschicht: findDirectLegs() und findNextLegs() laufen direkt gegen SQLite, nicht gegen geladene Maps. Der bestehende Hybridrouter wurde nicht verworfen, sondern bekommt SQLite als Datenquelle unterhalb der Routingentscheidung, nicht als Ersatz für sie.

Festgelegte No-Gos: kein vollständiges Laden von Deutschland in den Speicher, keine SQLite-Datei im APK, keine Search-Tokens im Routing selbst.

Aus den einzelnen Bausteinen ist ein durchgängiges System geworden. Die Android-App (Kotlin, Jetpack Compose, MapLibre) berechnet nichts mehr selbst, sondern spricht mit einer eigenen Transit-API. Die wiederum liest aus einer versionierten SQLite-Laufzeitbasis für Deutschland und die Schweiz, einem Corridor- und Timetable-Routing-Index sowie separaten WALK- und Auto-Provideradaptern.

Ein automatischer Static-GTFS-Updater prüft registrierte Quellen alle sechs Stunden, baut nur bei geändertem Inhalt und aktiviert eine neue Datenversion erst nach Contract-, SQLite-, Health- und Stationssuche-Prüfung. Jede Datenversion bleibt unveränderlich und rollbackfähig.

Verifiziert am 29.07.2026: Debug-APK auf echtem Samsung-Gerät installiert, kein Absturz beim Start, Testserver meldet status=UP.

Der deutschlandweite Realtime-Feed lieferte in einem gemessenen Snapshot rund 80.400 Fahrten und zwischen 754.000 und 775.000 StopTimeUpdates ins Overlay, bei einer harten Grenze von 100.000 Fahrten beziehungsweise 2.000.000 StopTimeUpdates – ohne einen einzigen Drop. VBB und VRN/RNN matchen zusätzlich über eigene Alias-Tabellen: rund 9.070 beziehungsweise 1.000 TripUpdates eindeutig zugeordnet.

Ein Livetest bestand alle drei Fälle, drei Tage später lieferten dieselben Korridore für denselben Test ausschließlich statische Zeiten. Das ist kein Fehler, sondern der Alltag von Echtzeitdaten: Ein technisch erfolgreicher, aber 39 Sekunden alter Feed-Abruf wurde korrekt als STALE bewertet statt stillschweigend als aktuell behandelt. Diese Unterscheidung – Datenqualität vom eigentlichen Matchproblem zu trennen – ist wichtiger als eine hohe Trefferquote im Einzeltest.

Der erste vollständig signierte Kandidat für die geschlossene deutsche Android-Beta wurde aus einem sauberen Git-Arbeitsbaum gebaut: Version 0.8.0-beta.1, Version Code 80001, Application-ID de.ixit.android. APK und AAB tragen dasselbe Zertifikat, beide Signaturen wurden geprüft, ein maschinenlesbares Release-Manifest mit SHA-256-Hashes liegt daneben.

Die Installation auf einem Samsung SM-S938B lief nicht ganz reibungslos: Eine alte Installation verwendete noch ein anderes Zertifikat und musste einmalig deinstalliert werden, bevor der neue Beta-Key greifen konnte. Ab diesem Kandidaten ist der Updatepfad stabil.

Noch offen: Pflichtfälle des Beta-Bugtestplans, Update mit aktivem Profil und Alarm, ein zweites Testgerät.

IXIT verlangt kein Benutzerkonto. Pendelprofil, gespeicherte Orte, Verbindungen und Weckerdaten werden stattdessen lokal auf dem Gerät gehalten – und zwar AES-GCM-verschlüsselt, mit einem Schlüssel, der im Android Keystore erzeugt wird und diesen nie verlässt. App-Backups sind für IXIT global deaktiviert, damit diese Daten nicht versehentlich unverschlüsselt in einem Cloud-Backup landen.

Für Suche, Routing und Live-Prüfung sendet die App nur die jeweils nötigen Angaben per HTTPS an den Server – ohne serverseitiges Nutzerkonto oder Routenhistorie. Standort wird nur nach expliziter Android-Freigabe verwendet; IXIT fordert keine allgemeine Hintergrundstandort-Berechtigung an. Externe Dienste werden nur für die tatsächlich genutzte Funktion eingebunden: openrouteservice für Fußwege, Google Routes nur für angeforderte Autoverbindungen, OpenFreeMap für Kartenkacheln. Werbe-, Analyse- oder Tracking-SDKs sind kein Teil der App.

Mit dem Google Navigation SDK und einem NavigationTemplate bekam IXIT projizierte Android-Auto-Navigation. Die technisch schwierigere Entscheidung war nicht die Integration selbst, sondern der Lebenszyklus: Handy- und Fahrzeuganzeige teilen sich genau einen Navigator und einen Turn-by-turn-Feed, nicht zwei unabhängige Instanzen.

Besitzerwechsel, Fahrzeugtrennung, Stopp und veraltete Routing-Callbacks werden über eine testbare Lifecycle-Koordination abgesichert – sonst drohen doppeltes Audio oder eine Navigation, die auf dem Fahrzeugdisplay weiterläuft, obwohl sie auf dem Telefon beendet wurde.

Debug-Unit-Tests und Kotlin-Kompilierung sind grün. Der reale Fahrzeugtest über einen internen Google-Play-Build steht noch aus.

Damit "fast fertig" nicht zu einer Dauerausrede wird, ist der Weg zur Beta in sechs Freigabetore (G0 bis G5) unterteilt – vom eingefrorenen technischen Ist-Stand über ein reproduzierbares signiertes Artefakt bis zum Release Candidate. Die Regel dahinter ist absichtlich streng: Ein späteres Tor darf vorbereitet werden, gilt aber nicht als erreicht, solange ein vorheriges Tor offen ist.

Jedes Tor hat konkrete, prüfbare Exit-Kriterien statt eines Gefühls von „passt schon". G2 verlangt zum Beispiel explizit: kein doppelter Alarm in der Gerätematrix, kein verlorener Wecker nach Neustart, Autonavigation endet auf Telefon und Fahrzeug konsistent. Ohne Nachweis bleibt das Tor zu, unabhängig davon, wie viel Code schon läuft.

Das interne Aufgabenregister unterscheidet bewusst zwischen ERLEDIGT, TEILWEISE, EXTERN und SPÄTER – und ein Punkt gilt erst als erledigt, wenn Implementierung, Test und gegebenenfalls Deployment nachgewiesen sind. Ein Beispiel: Die OSM-/OpenFreeMap-Attribution in der Kartenansicht ist als ERLEDIGT markiert, weil sie konkret auf einem Samsung-Gerät mit Drei-Tasten-Navigation sichtbar und anklickbar geprüft wurde, nicht von Systemleisten verdeckt.

Turn-by-turn-Autonavigation dagegen bleibt bewusst TEILWEISE: Telefon- und Android-Auto-Oberfläche sind implementiert, aber Desktop Head Unit, ein interner Play-Build und ein reales Fahrzeug stehen noch aus. Diese Disziplin ist unbequem, weil sie den Fortschritt langsamer aussehen lässt – sie verhindert aber, dass ein Beta-Test auf ungeprüften Annahmen aufbaut.

Bevor ein einziger GTFS-Feed geprüft wurde, entstand ein fachlicher Contract für die erste öffentliche Feed-Audit-Demo. Der größte Teil davon beschreibt, was die Demo nicht ist: kein frei bedienbarer Onlinevalidator, kein Datei-Upload, kein offizielles GTFS-Zertifikat, kein automatischer Reparaturdienst und ausdrücklich kein Gesamtscore wie „74/100" – weil eine ungewichtete Kennzahl bei fünf sehr unterschiedlichen Prüfkategorien vor allem Scheingenauigkeit erzeugen würde.

Stattdessen definiert der Contract ein striktes Finding-Schema: Jeder Fund braucht einen stabilen Regelcode, eine getrennt ausgewiesene severity und confidence, einen Status zwischen CONFIRMED und REVIEW_REQUIRED – und die klare Regel, dass automatisierte Erkennung, heuristische Kandidaten und manuell geprüfte Beispiele öffentlich unterscheidbar bleiben müssen.

Für die erste Demo kam nicht der erstbeste öffentliche GTFS-Feed infrage. Acht Kandidaten wurden anhand von Pflicht-, Wunsch- und Ausschlusskriterien verglichen: öffentlich zugänglich, nachvollziehbare Lizenz, überschaubare Größe, aber auch genug komplexe Umstiegssituationen, um interessant zu sein.

Am Ende blieben drei Empfehlungen: VRS GTFS-SOLL (klein, täglich aktualisiert, klar lizenziert) als konservativer Startkandidat, VGN als fachlich reichhaltigere Alternative mit dokumentiertem Gültigkeitszeitraum, hvv als besonders anschaulicher multimodaler Kandidat. Ausdrücklich nicht empfohlen: der bundesweite DELFI-Gesamtfeed, weil er dem Ziel einer überschaubaren ersten Demo widerspricht, und VRR wegen eines Beta-Hinweises der Quelle, der eine faire öffentliche Darstellung erschwert hätte.

Bevor Phase 4 begann, wurde ehrlich Bestand aufgenommen: Der vorhandene GTFS-Preprocessor (Java 21, Maven, SQLite-Ausgabe) ist bereits deutlich weiter entwickelt, als für die erste Demo nötig wäre. Ein vorhandener Report weist beispielhaft 685.781 Stops, 1.668.306 Trips und 34.489.200 StopTimes aus einem großen Lauf nach; der SQLite-Contract-Validator bestand dabei 23 von 23 Prüfungen.

Was fehlt, ist nicht Technik, sondern Übersetzung: Die öffentliche Finding-Struktur mit stabilen Codes wie NAME001 oder CAL001 existiert im Preprocessor noch nicht. Die Entscheidung für Phase 4 fiel deshalb bewusst gegen einen zweiten, parallelen Preprocessor – die vorhandene Namens-, Such- und Stationslogik wird wiederverwendet, nicht neu gebaut.

Der KVV-Feed wurde als erste konkrete Version geprüft, lieferte zunächst einen STOP005- (mögliche doppelte Haltestelle) und einen SEARCH002-Kandidaten (fehlende Hbf-Schreibweise). Beide wurden nach manueller Prüfung als NOT_SELECTED abgeschlossen: Die getrennten Betriebshof-West-Areas haben unterschiedliche Bedienungsmuster ohne GTFS-Transferregel – die 4-Minuten-Nähe ist nur eine IXIT-Distanzheuristik, kein belastbarer öffentlicher Befund. Die vermeintlich fehlende Suchform lag bereits auf der gemeinsamen kanonischen Station vor.

Auch die StopTime-Prüfungen (nicht-monotone Folgen, negative Aufenthaltszeiten) ergaben nichts. Das Ergebnis: Der KVV-Feed lieferte nach konservativer Prüfung keine ausreichende Grundlage für die geplante öffentliche Finding-Auswahl – der Contract-Fallback wechselte auf VGN.

Der VGN-Feed lieferte technisch ein brauchbares Ergebnis: Der Preprocessor brach korrekt ab, weil zwei von 1.710.427 stop_times-Zeilen weder Ankunfts- noch Abfahrtszeit enthalten, ohne timepoint-Feld. Der Preprocessor erfindet keine Zeiten – das ist genau das gewünschte Verhalten. Der strikte Audit-only-Lauf dokumentierte den Fund als ROUTING005 mit HIGH Severity, MEDIUM Confidence.

Trotzdem wurde die VGN-Version nicht für die Demo freigegeben: Die offizielle Open-Data-Seite nennt CC BY 3.0 DE, die verlinkten Nutzungsbedingungen dagegen CC BY-SA 3.0 DE. Ein Widerspruch, den man nicht einfach zugunsten der bequemeren Lizenz auflöst – bis zur schriftlichen Bestätigung durch den VGN gilt intern die strengere Annahme, und der Status bleibt NOT_READY_FOR_PUBLIC_DEMO.

Nach KVV und VGN wurde der gemeinsame VRN-/RNN-Feed als neue, nicht aktive Version abgelegt. Der strikte Audit-only-Lauf – ohne Runtime-Import, ohne Zeitinterpolation, ohne Quelländerung – bestätigte zunächst nur die Zeitfeldvollständigkeit: ZIP intakt, 1.910.530 Zeilen in stop_times.txt, kein ROUTING005-Kandidat.

Der anschließende vollständige Lauf lieferte eine technisch app-ready SQLite-Ausgabe mit 18.832 Stops, 17.228 StopAreas, 1.199 Routen, 90.258 Trips, 1.910.530 StopTimes und 19.148 GTFS-Transfers – aktiviert wurde sie trotzdem nicht. Ein Auditlauf ist eine Feedprüfung, keine Freigabe.

Die automatisierten Kandidatenregeln lieferten für VRN/RNN zunächst große Mengen: 12 technisch markierte Stationsnamen (NAME003), 1.362 als AVOID eingeordnete Transferpaare (TRANSFER003), 5.508 räumlich nahe Area-Paare mit gleichem Namen (STOP005). Jede dieser Mengen wurde manuell verkleinert, nicht einfach veröffentlicht.

NAME003 schloss komplett als NOT_SELECTED: Alle zwölf Werte enthalten Bahnsteigkennzeichnungen wie „Bstg A/B", die eine echte Positions- oder Richtungsunterscheidung leisten – kein Darstellungsmangel. STOP005 wurde über mehrere Filterstufen (Abstand, kanonische Bereiche, Verkehrsmitteltyp) auf zwölf priorisierte Fälle reduziert und schloss dann ebenfalls komplett als NOT_SELECTED: unterschiedliche Bus-/Straßenbahn- oder Bergbahn-/Buspositionen, keine nachweisbare Such- oder Routingauswirkung. TRANSFER003 blieb ohne echte Fußweg-Evidenz DEFERRED_INTERNAL_ONLY. Bis zu diesem Punkt wurde kein einziges Finding veröffentlicht – und das ist der Punkt.

Nach vielen NOT_SELECTED-Entscheidungen lieferte eine gezielte Suche nach Anzeige- und Suchkollisionen zwei bestätigte Kandidaten für SEARCH003: Bei „Käfertal Jugendverkehrsschule" und „Eppelheim Rathaus" würde IXITs Kanonisierung mehrere sichtbare Stationsfamilien mit unterschiedlichen Rohnamen unter einem gemeinsamen Anzeigenamen zusammenfassen – obwohl Fahrtdaten der RNV 4 beziehungsweise Linie 713 sie als getrennte, aufeinanderfolgende Halte mit 120 beziehungsweise 60 Sekunden Fahrzeit ausweisen.

Ein zweiter, unabhängiger Fund betrifft SEARCH001: Die Bezeichnung „sous Forêts Gare, Soultz" liefert bei der akzentlosen Eingabe „sous Forets Gare, Soultz" keinen einzigen Treffer, weil die Sucheingabe normalisiert wird, der gespeicherte Suchwert aber weiterhin den Akzent enthält. Beide Fälle beschreiben ausdrücklich eine Lücke in der IXIT-Aufbereitung, nicht einen Fehler des Quellfeeds – und beide sind als SELECTED_AS_APP_READY_EXAMPLE_CANDIDATE markiert.

Für die visuelle Darstellung des synthetischen Demo-Netzes musste eine Grenze gezogen werden: Der Netzplan ist eine schematische Lesart des Demo-GTFS, keine geografisch genaue Karte und kein Routingnachweis. Der zentrale Korridor zwischen den Hauptstationen ist deshalb redaktionell und ausschließlich visuell definiert, mit einer geschützten Zone, in der nur parallele Liniensegmente und einheitliche Haltemarker erscheinen dürfen – keine Stationsnamen, keine diagonalen Einmündungen.

Eine Linie erscheint im Korridor nur, wenn eines ihrer Fahrtmuster mindestens zwei direkt benachbarte Korridorstationen tatsächlich bedient. Der Stationssteg selbst ist ausdrücklich als „lesbare Netzplan-Konvention" dokumentiert, keine Aussage über reale Bahnsteige oder Umstiege. Diese Zurückhaltung ist bewusst: Ein hübsches Diagramm darf keine Genauigkeit vortäuschen, die die zugrunde liegenden Daten nicht hergeben.

Der Cross-Border-Datenstand zeigt bewusst einen Grenzfall: zwei technisch und fachlich unabhängige synthetische GTFS-Feeds für „Land A" und „Land B", deren Linie G7 an der Grenze mit nur 20,9 Metern Abstand zwischen den Grenzhalten endet beziehungsweise beginnt. 36 Fahrtpaare korrespondieren zeitlich, mit einem normalen Grenzaufenthalt von vier Minuten – aber auch ein dokumentierter Kalenderkonflikt: An einem Stichtag ist Land A aktiv, Land B nicht.

Alle Objekte bleiben source-namespaced referenziert (land-a:HEITKAMP_GR_A, land-b:HEITKAMP_FRONTIERE_B) – eine gleichlautende route_id oder trip_id ist ohne Source-ID ausdrücklich kein Zusammenführungsgrund. Die Workbench kann eine mögliche durchgehende Fahrt „G7 Auenmark Hbf – Belleval Gare" nur als App-ready-Vorschau anzeigen, mit dem Status REVIEW_REQUIRED und dem festen Lebenszyklus DRAFT → REVIEW_REQUIRED → APPROVED → APPLIED. Keine Quelldaten werden dabei verändert.