Im Projekt CITWIN wird ein generisches Digital-Twin-Framework zur Analyse von Veränderungen aktiver Mobilitätsinfrastruktur im Kontext der 15-Minuten-Stadt entwickelt. Zur Integration von Erreichbarkeitsanalysen in diese Architektur wurde eine eigenständige REST-API mit Python / FastAPI implementiert. Sie stellt die Berechnung fuß- und fahrradbasierter Erreichbarkeit von ÖPNV-Haltestellen als Service bereit und liefert die Ergebnisse als räumliche Layer zur weiteren Verarbeitung und Visualisierung.

Die zugrunde liegende Geo-Pipeline basiert auf einem routingfähigen Netzwerk mit bewerteten Kanten für Walkability und Bikeability auf Basis von NetAScore. Eingabedaten (Startpunkte, Zielpunkte, OD-Daten) werden räumlich vorverarbeitet und auf den Analysebereich begrenzt. Einzugsbereiche werden über eine definierte Zeitgrenze bestimmt (z.B. 15 Minuten). Zusätzlich wird ein gefilterter Graph erzeugt, der ausschließlich Kanten oberhalb eines definierten Qualitätsschwellenwerts enthält (z.B. Bikeability ≥ 0,5). Die Erreichbarkeit wird sowohl im vollständigen Netzwerk als auch im gefilterten Graphen berechnet. Für jeden Zielpunkt (z.B. Haltestelle) wird ermittelt, wie viele Startpunkte (z.B. Haushalte) diesen innerhalb der definierten Grenzwerte in beiden Netzwerken erreichen können. Im gefilterten Graphen werden dabei nur jene Startpunkte berücksichtigt, die den Zielpunkt innerhalb einer festgelegten Umwegetoleranz erreichen (z.B. 1,5 × kürzeste Distanz). Die Anzahl der möglichen Verbindungen wird erfasst und in Relation gesetzt. Ergänzend werden aggregierte Kennwerte für das jeweils erreichbare Netzwerk berechnet (Netzwerklänge, durchschnittliche Qualität). Neben der vollständigen Pipeline steht zudem eine vereinfachte Variante mit reduzierten Anforderungen an die Eingabedaten zur Verfügung. Methodische Details des Bewertungsansatzes sind in einer separaten Publikation dokumentiert.

Die API implementiert ein asynchrones Job-Modell zur Entkopplung rechenintensiver Routing-Prozesse von der HTTP-Schnittstelle. Analyse-Jobs werden über dedizierte Endpunkte gestartet. Nach dem Anlegen eines Jobs werden entsprechende Metadaten zurückgegeben. Der Fortschritt kann entweder per Polling oder über eine WebSocket-Verbindung verfolgt werden. Nach Abschluss stehen die generierten Ausgaben über Download-Endpunkte zur Verfügung.

Intern werden Jobs in einer einfachen Datenstruktur verwaltet und sequenziell abgearbeitet. Die Analyse selbst wird in einem separaten Thread ausgeführt, sodass die HTTP-Schnittstelle während der Berechnung erreichbar bleibt. Die Architektur ist auf einen projektbezogenen Einsatz mit begrenzter Last ausgelegt. Gleichzeitig ist sie so gestaltet, dass sie bei Bedarf erweitert werden kann, etwa durch die Integration einer persistenten Queue oder einer Worker-Architektur zur parallelen Abarbeitung von Jobs (z.B. Redis / Celery).

Die Verwendung von FastAPI ermöglicht durch die automatische Generierung einer OpenAPI-konformen Dokumentation eine unmittelbare, interaktive Bereitstellung der Schnittstellenbeschreibung. Sämtliche Endpunkte, Parameter und Antwortformate sind dadurch online einsehbar und direkt testbar. Dies reduziert den Dokumentationsaufwand, stellt die Konsistenz zwischen Implementierung und Beschreibung sicher und erleichtert die Integration der API.

Zur Sicherstellung einer kontrollierten Laufzeitumgebung wurde die Codebasis von NetAScore direkt in das Projekt integriert. Dadurch bleiben Methodik und Implementierungsstand versioniert und unabhängig von externen Änderungen. Ein Deploy-Skript übernimmt das Auschecken einer definierten Git-Referenz, den Build eines Docker-Containers sowie die Konfiguration eines vorgelagerten Nginx-Servers. Dadurch kann die API mit wenigen Schritten auf einem Server in Betrieb genommen werden.

Die Geo-Pipeline wird als eigenständiger Service bereitgestellt. Analytische Methoden werden dabei als klar definierte Schnittstellen implementiert. Sie können unabhängig von Visualisierung oder Datenhaltung betrieben, erneut ausgeführt und in andere Kontexte integriert werden. Im wissenschaftlichen Kontext bedeutet dies, dass methodische Ansätze nicht nur als Publikation oder Code-Repository vorliegen, sondern als ausführbare Services bereitgestellt werden. Dadurch wird der Zugang zu Analysen erleichtert und die Integration in externe Systeme oder weitere Forschungsvorhaben vereinfacht. Die hier entwickelte API ist prototypisch und auf einen projektbezogenen Einsatz ausgerichtet, stellt jedoch eine reproduzierbare und klar abgegrenzte Service-Schnittstelle für Erreichbarkeitsanalysen bereit.