Skip to content

ADR-0022: Feld-App (Capacitor) und AR-Stufe

  • Status: accepted
  • Datum: 2026-08-26
  • Phase: P11 / P12
  • Lastenheft: INF-07, FIELD-01–FIELD-04, AR-01

Kontext

Bauleiter brauchen genehmigte Abschnitte, Auflagen und Fotos vor Ort, oft ohne Netz. AR (Schilder / Grabungsbereich) ist die Differenzierung, aber ±30 cm ist RTK, nicht Consumer-VPS.

Lastenheft verbot einen dritten Web-Stack. Die Feld-App ist ein dritter Client, spricht weiter nur FastAPI.

Entscheidung

  • Client: Capacitor (Android first) unter linetra-app/, TypeScript wie Dashboard, Auth per Bearer (POST /auth/token für Rolle foreman).
  • Payload: nur genehmigte Anträge im Gebiet/BBox; Offline-Outbox, Sync bei Netz.
  • Fotos: bestehender File-Store (ADR-0005), nicht bytea.
  • AR später: ARCore Geospatial plus lokale Passpunkte. ±30 cm erst mit optionalem RTK-GNSS, nicht als v1-Garantie.
  • Kein QGIS-/ArcGIS-Plugin als Zweiterfassung.

Begründung

Ein Backend, gemeinsame DTOs, Android ist der Feldmarkt. Geospatial API ist der etablierte Outdoor-AR-Weg auf Android. Capacitor hält UI in TS; natives Overlay bleibt ein Plugin.

Verworfene Alternativen

Alternative Warum verworfen
Flutter / reines Kotlin Zweiter UI-Stack bzw. keine TS-Nähe zum Dashboard
±30 cm als v1 ohne RTK ARCore VPS liegt typisch bei ~1 m
ArcGIS Runtime / QGIS-Plugin Lizenz bzw. vierter Client ohne SSOT-Gewinn
Firebase vor Feld-App Push erst mit mobilem Client; Celery+SMTP reicht fürs Web

Folgen

linetra-app/ ist Host-Toolchain (wie der Editor), nicht Dashboard-Compose. CORS erlaubt die Capacitor-Origins. GIS-Write bleibt dem Editor vorbehalten.