Lastenheft
Verbindliche Anforderungen an Linetra. IDs sind stabil und tauchen in der Roadmap wieder auf.
Stand: 2026-08-26 · Quelle: meta_docs/ANFORDERUNGEN.md · Status: nicht umgesetzt
Prioritäten
Muss steht in den Anforderungen. Soll ist nötig, damit ein Muss erfüllbar bleibt (ohne HOW vorzuschreiben). Kann ist ausdrücklich optional („evtl.“).
1. Ausgangslage
Heute ist PostGIS die SSOT (SRID 25832). Erfassung läuft in QGIS; das Web-CMS (Next.js + FastAPI) deckt Stammdaten, Berichte/PDF und eine nur lesende Karte ab.
Das reicht nicht für den operativen GIS-Workflow: Rohdaten des Auftraggebers, Normierung, abschnittsweise Aufträge mit eigenen Produkt-Geometrien, Versionierung nach Rücksprachen, kunden- und gemeindespezifische Berichte und eine Kundenoberfläche mit Kommentar, Chat und Tickets.
2. Ziele
- QGIS + Linetra-Plugin als Capture-UI: Schema anwenden, Import-Mapper, Projekt-/Layer-Hierarchie; Digitize im QGIS-Canvas (ADR-0030, ADR-0033). Das Plugin schreibt kein Schema.
- Linetra Web für Schema-CMS, Stammdaten (Zentrale + Kopien), Analyse, Verfahren (Planer und Behörden), Audit, Kunden-Anzeige — nicht für GIS-Erfassung.
- Feld-App für Bauleiter an genehmigten Abschnitten (später AR).
- Vertikale (Glasfaser, Verkehrszeichen, Tunnel, …) als Kind-Packs am gemeinsamen GIS-Stamm.
- Alles (Rohinput, Normierung, Produkte) versionierbar.
- Austausch mit GIS-Werkzeugen: QGIS-Export (und optional
.ltp). - PostGIS nicht im Internet; QGIS über Auth-Proxy mit Client-Zertifikaten, Apps nur über die API (ohne VPN-Zwang).
- Eine Datenbank pro Organisation (Ziel); Planer einer Org teilen die DB ohne Tabellenisolation.
3. Nicht-Ziele
Aus den Anforderungen nicht gefordert — deshalb kein Lieferumfang dieses Lastenhefts:
- Billing-Automatisierung, Rechnungsprogramm, Factura Directa
- Jira als Steuerzentrale (bestehender Betrieb, siehe Fachmodell)
- QGIS-Capture ohne Export-Pfad (Export bleibt Muss)
- Drittes Web-Framework neben Next.js (die Feld-App ist ein dritter Client, nicht eine zweite Webapp)
- Zweite Desktop-App neben QGIS für denselben Capture-Workflow (Tauri-Editor ist Legacy, nicht Primärpfad)
- Implementierungsdetails (Tabellennamen, Framework-APIs, Hosting)
4. Infrastruktur
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| INF-01 | Muss | Die Anwendung ist in Clients geteilt: QGIS + Linetra-Plugin, Linetra Web als Webapp, später Feld-App (Tauri-Editor Legacy). | Getrennte Oberflächen; gemeinsame SSOT. |
| INF-02 | Muss | Capture läuft als QGIS-Plugin (linetra-plugin/); Stack PyQGIS. Schema wird in Linetra Web geschrieben, das Plugin wendet es an. |
Plugin in QGIS installierbar; keine Kind-Anlage im Plugin; keine zweite Desktop-App für denselben Workflow. |
| INF-03 | Muss | Linetra Web ist Next.js mit FastAPI. | Browser-App spricht die FastAPI; kein GIS-Schreiben in der Webapp. Schema, Analyse und Stamm liegen dort. |
| INF-04 | Muss | PostGIS ist von außen nicht erreichbar. Editor und Web nutzen nur die API; GIS-Clients (QGIS) erreichen die DB ausschließlich über einen Auth-Proxy. VPN ist nicht Voraussetzung. | Kein öffentlicher Postgres-Port; ohne Proxy bzw. ohne API keine Session zur SSOT. |
| INF-05 | Muss | Zugang über den Proxy nur mit persönlichem oder gerätegebundenem Schlüssel: mTLS, X.509-Client-Zertifikat (widerrufbar). Kein geteiltes DB-Passwort über das Internet. | Client ohne gültiges Zertifikat wird abgewiesen; Entzug eines Zertifikats sperrt genau diesen Client. |
| INF-06 | Muss | Der Proxy prüft die Identität und leitet die Postgres-Verbindung intern an PostGIS weiter (Wire-Protocol, nicht HTTP). | QGIS verbindet gegen den Proxy mit TLS verify-full; PostGIS akzeptiert diese Clients nur aus dem internen Netz. |
| INF-07 | Soll | Die Feld-App (Android, Capacitor) spricht nur die FastAPI; kein zweites Backend. | Bauleiter sehen genehmigte Abschnitte ohne GIS-Write. |
Bestehender Web-Stack
FastAPI + Next.js existieren bereits. Das Lastenheft verlangt daraus Linetra Web (Schema-SSOT, Stamm, Analyse, Kunden und Behörden-Verfahren) — nicht eine zweite Webapp.
DB-Zugang ohne VPN
Live: Datenbankzugang. Client-Zertifikate statt API-Keys, weil QGIS das Postgres-Protokoll spricht.
5. Linetra Editor
5.1 Pipeline: Rohinput → Normierung → Auftrag/Produkt
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-01 | Muss | Es gibt einen Rohinput des Auftraggebers (project_client), Typ Trasse, mit der kompletten Trasse. |
Pro Projekt ist die ungefilterte AG-Trasse als eigener Bestand abgelegt, getrennt von der Normierung. |
| ED-02 | Muss | Der Rohinput kommt als Dateien; Formate sind unterschiedlich (u. a. Shapefiles, PDFs). | Mindestens Datei-Import; unbekannte Formate als Datei speicherbar, nicht verworfen. |
| ED-03 | Soll | Inhalte, die nicht maschinell lesbar sind, lassen sich manuell in die Stufe Planung übertragen (heute QGIS / später Editor). | Planung kann ohne vollständigen Parser entstehen. |
| ED-04 | Muss | Rohinput wird in eine normierte Form überführt: überflüssige Daten entfallen, andere werden umformatiert. Ablauf: Skripte und manuelle Schritte. | Normierte Trasse ist vom Rohinput unterscheidbar; beide bleiben erhalten. |
| ED-05 | Muss | Ein Auftrag bearbeitet nur einen Abschnitt der normierten Trasse und erzeugt dabei Produkte. | Auftrag ist an einen Abschnitt gebunden, nicht zwingend an die ganze Trasse. |
| ED-06 | Muss | Beispielprodukte: Querungen (Genehmigungsart), Verkehrszeichen aufstellen, Verlängerungen der Genehmigung. | Jedes genannte Produkt ist als eigener Produkttyp anlegbar. |
| ED-07 | Muss | Produkte haben eigene Geometrie (nicht die Planungs-/Normierungslinie). | Produkt-Geometrie unabhängig speicher- und editierbar. |
| ED-08 | Muss | Produkte mit gemeinsamem Hauptprodukt und geteilten Feldern sind eigene Entities — mindestens TKG und VAO — und haben eigene Tabellen. | TKG und VAO sind getrennt modelliert, nicht nur ein Typ-Flag ohne Fachdaten. |
5.2 Versionierung
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-09 | Muss | Rohinput, Normierung und Produkte sind versionierbar, wenn Rücksprachen zu Korrekturen führen. | Nach einer Korrektur bleibt die vorige Fassung nachvollziehbar; aktuelle Fassung ist eindeutig. |
5.3 Berichte
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-10 | Muss | Ein Produkt lässt sich als Bericht darstellen, der die für Gemeinde und Kunden wichtigen Daten enthält. | Bericht aus Produktdaten erzeugbar. |
| ED-11 | Muss | Berichtsinhalte unterscheiden sich nach Gemeinde und Kunde; die Felder sind pro Kunde als Set zusammenstellbar. | Zwei Kunden können verschiedene Feld-Sets für denselben Produkttyp haben. |
| ED-12 | Kann | Berichtsfelder können aus einem Formular stammen und per API oder Scraper geholt werden. | Kein Blocker für ED-10/ED-11. |
5.4 Karteneditor
Eine Seite des Editors enthält den Karteneditor. Layer werden dort angelegt.
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-13 | Muss | Drei umschaltbare Modi: Planung, Normierung, Produkt. | Genau ein aktiver Modus; Layer und Werkzeuge gehören zum Modus. |
| ED-14 | Muss | Pro Modus lassen sich Punkte, Linien und Flächen anlegen. | Alle drei Geometrietypen in jedem Modus erzeugbar. |
| ED-15 | Muss | Werkzeugkasten: Auswahl Punkt, Linie oder Fläche. | Aktives Zeichenwerkzeug ist sichtbar und umschaltbar. |
| ED-16 | Muss | Rechte Seite: Kontextfenster mit Tab Koordinaten und Tab Attribute. | Beide Tabs vorhanden; Koordinaten der aktuellen Geometrie, Attribute editierbar. |
| ED-17 | Muss | Pro Projekt und Geometrietyp lässt sich ein Klick-Popup aktivieren und konfigurieren, das gewählte Attributinformationen zeigt. | Popup an/aus und Attributauswahl speicherbar. |
| ED-18 | Muss | Import und Export des Projekts (alle Layer und Daten) im Format .ltp (Linetra Projekt Package). |
Roundtrip: Export → Import stellt Layer und Daten des Projekts wieder her. |
| ED-19 | Muss | .ltp-Dateiformat: ZIP-Container, Magic-Header z. B. LINETRA-PP\0, MIME-Type application/vnd.linetra.project+zip. |
Datei ist als .ltp erkennbar (Header + MIME); Inhalt ist ZIP. |
| ED-20 | Muss | Import externer GIS-Geolayer in den jeweils aktiven Modus. | Import landet in Planung, Normierung oder Produkt — nicht vermischt. |
flowchart TB
subgraph editor [Linetra Editor]
mode[Modus: Planung / Normierung / Produkt]
map[Karte + Layer]
tools[Werkzeugkasten: Punkt / Linie / Fläche]
ctx[Kontext: Koordinaten | Attribute]
popup[konfigurierbares Klick-Popup]
end
mode --> map
tools --> map
map --> ctx
map --> popup
6. Linetra Web
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| DASH-01 | Muss | Linetra Web schreibt keine GIS-Geometrie. Kunden: Anzeige und Analyse. Behörden: Verfahren (Status, Auflagen), nicht GIS-Edit. Schema-CMS und Stammdaten-Kopien liegen in der Webapp. | Keine GIS-Erfassung, keine Normierung, kein Rohinput-Editing im Browser. |
| DASH-02 | Muss | Kommentarfunktion an Produkten. | Kommentar ist einem Produkt zugeordnet und für den Kunden sichtbar. |
| DASH-03 | Muss | Chat. | Kunden können im Dashboard chatten (Kanal intern vs. Kunde: offen, siehe Klärung). |
| DASH-04 | Muss | Ticketsystem. | Kunde kann ein Ticket anlegen und den Status nachverfolgen. |
| DASH-05 | Muss | Genehmigungsantrag je Abschnitt mit Statuskette Entwurf → Eingereicht → Prüfung → genehmigt (mit/ohne Auflagen) / abgelehnt / Rückfrage. | Statuswechsel nur über die API; Audit-Event je Wechsel. |
| DASH-06 | Muss | Behörden-Nutzer sehen nur Anträge, deren Abschnittsgeometrie ihr Gebiet schneidet. | Räumlicher Filter; kein Zugriff auf fremde Gemeinden. |
| DASH-07 | Muss | Auflagen (Katalogtyp + Freitext) und Frist am Antrag. | Auflage ist dem Antrag zugeordnet; optional einem Produkt. |
| DASH-08 | Muss | Audit-Export der Verfahrensereignisse je Abschnitt oder Projekt. | Export nachvollziehbar (wer, wann, von→nach). |
6.1 Feld-App
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| FIELD-01 | Muss | Bauleiter sehen nur genehmigte Abschnitte im eigenen Gebiet. | Keine Entwürfe, keine Ablehnungen. |
| FIELD-02 | Muss | Auflagen aus dem Verfahren sind am Abschnitt lesbar. | Dieselben Auflagen wie im Dashboard. |
| FIELD-03 | Soll | Fortschritt und Foto-Nachweis, Offline-Zwischenspeicher mit Sync. | Nach Wiederverbindung landen Outbox-Einträge in der SSOT. |
| AR-01 | Kann | Kamera-Overlay (ARCore Geospatial + Passpunkte). ±30 cm erst mit RTK. | Overlay zeigt genehmigte Produktgeometrien; keine v1-Genauigkeitsgarantie. |
7. Integration
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| INT-01 | Muss | Aus Editor und Dashboard lassen sich Exporte für QGIS 3.4.4 LTS erzeugen, die für das Projekt alle wichtigen Layer und Daten enthalten. | Export aus beiden Clients; in QGIS ladbar; Layer + Attribute des Projekts enthalten. |
Klärungsbedarf INT-01
In den Anforderungen steht QGIS 3.4.4 LTS (Release 2019). Der heutige Betrieb nutzt QGIS 4.2. Vermutlich ist 3.40 LTR gemeint. Bis zur Klärung gilt der Wortlaut; die Roadmap plant den Export so, dass die Zielversion austauschbar bleibt.
8. Qualitätsanforderungen
| ID | Prio | Anforderung |
|---|---|---|
| Q-01 | Soll | Geo-SSOT bleibt PostGIS, Speicher-SRID 25832 (bestehender Standard, nicht neu erfunden). |
| Q-02 | Soll | Editor hält keine eigene Business-Datenbank; Fachdaten laufen über die FastAPI (Tauri-Stackregel). .ltp ist Austauschformat, kein zweites SSOT. |
| Q-03 | Soll | Kunden sehen im Dashboard nur Daten ihrer Organisation/Projekte. |
| Q-04 | Soll | Versionierung darf keine stille Überschreibung sein: Korrekturen erzeugen nachvollziehbare Fassungen (ED-09). |
| Q-05 | Soll | Transit zur SSOT: TLS 1.3 am Proxy bzw. intern nur Compose-Netz; hostnossl von außen abgelehnt. |
9. Offene Punkte (kein HOW, nur Klärung)
Diese Punkte ändern das Lastenheft erst nach Entscheidung:
- QGIS-Zielversion — 3.4.4 vs. 3.40 LTR vs. 4.2 (INT-01).
- Chat-Teilnehmer — nur Kunde↔Betreiber, oder auch intern?
- Tickets vs. bestehendes Jira — Dashboard-Tickets parallel, oder später Ablöse?
- Offline-Editor —
.ltplokal bearbeiten ohne API, dann synchronisieren? - Bericht-Sets — wer pflegt die Sets (intern im Editor, Admin im Dashboard)?
- PDF-Rohinput — nur Dateiablage in Planung, oder Geometrie-Digitalisierung Pflicht (ED-03)?
- Zertifikat → DB-Rolle — entschieden (ADR-0031): kein Postgres-User pro Person; ein
{slug}_edit/{slug}_read-Paar pro Mandant; Cert-CN = Rollenname. - VPN danach — abschalten oder als optionale zweite Hülle behalten?
10. Abnahme des Lastenhefts insgesamt
Das Lastenheft ist erfüllt, wenn alle Muss-IDs abgenommen sind. Soll darf die Abnahme nicht blockieren, wenn das Muss nachweisbar anders erfüllt ist. Kann (ED-12) ist kein Abnahme-Kriterium.
Nächster Schritt fachlich: Fachmodell. Nächster Schritt zeitlich: Roadmap.