Fachmodell

Erläutert die Lastenheft-Begriffe mit dem, was in meta_docs/ bereits entschieden oder betrieben wird. Keine neuen Muss-Anforderungen — bei Widerspruch gilt das Lastenheft.

Drei Stufen, nicht drei Flags

Operativ ist die GIS-Arbeit ein 3-Schritt-Workflow. Der CEO hat 2026-06 festgehalten: Rohdaten und normierte Trasse sind zwei Bestände, kein Statusflag in einer Tabelle.

flowchart LR
  files[AG-Dateien: Shape, PDF, …] --> raw[Planung / Rohinput]
  raw -->|Kopie + Skripte + manuell| norm[Normierung]
  norm -->|Auftrag auf Abschnitt| prod[Produkte]
  raw -.->|Versionen| v1[Korrektur-Fassungen]
  norm -.->|Versionen| v1
  prod -.->|Versionen| v1

Warum zwei Trassen-Bestände (Kontext): Original bleibt Nachweis; Produkte dürfen nur an der normierten Qualität hängen; Transformation ist oft nicht 1:1. Eine manuelle Kopie Planung → Normierung legt eine neue Zeile an und speichert die Herkunft in source_object_id (sichtbar in den Attributen); danach sind die Geometrien unabhängig.

Arbeitsnamen aus älteren Notizen: fiber_routes_client (Roh) / fiber_routes_linetra (normiert). Verbindlich ist die Trennung, nicht der Tabellenname.

Auftrag und Abschnitt

Ein Auftrag im Lastenheft ist die Bearbeitung eines Abschnitts, nicht der ganzen AG-Lieferung. Der Abschnitt ist generisch (work_sections mit eigener Geometrie); Linearreferenz auf einer Trasse ist optional. Der Genehmigungsantrag hängt am Abschnitt, nicht an jeder Produktzeile.

Im heutigen Schema gibt es section_orders und projects als grobe Klammer. Das Lastenheft fordert die fachliche Kette Abschnitt → Auftrag → Produkte → Antrag. Ob Jira Quelle bleibt, ist Betrieb — nicht Lieferumfang.

Bestehende Leitplanken aus dem Kontext (nur soweit sie das Lastenheft stützen):

• Normierte Geometrie hängt am Projekt, nicht am Auftrag.
• Ein Produkt-Objekt gehört zu genau einem Auftrag; ein Auftrag kann viele Objekte haben.
• route_id zur Normierung ist optional (Direktauftrag ohne Planung).
• Produkt-Geometrie ist eigen — 1 000 m Planung können 10 000 m Produktstrecken enthalten.
• Vertikale (Glasfaser, Verkehrszeichen, Tunnel) sind Kind-Packs, keine eigenen Zentrumstabellen.

Produkte: gemeinsam und trotzdem eigene Tabellen

Lastenheft: geteiltes Hauptprodukt plus eigene Entities TKG und VAO mit eigenen Tabellen.

Dazu passt die bereits bestätigte Variante C (Hybrid):

• Stamm: was alle Produkte teilen (Geometrie, Status, Behördenbezug, KPIs, Auftrag, optional Route).
• Beilage 1:1: Fachfelder nur dieses Typs (bei Querungen existiert das Muster crossing_enrichments).
• Abgelehnt: eine Monolith-Tabelle mit allen Feldern, oder dieselbe Geometrie n-fach kopiert.

flowchart TB
  stamm[Gemeinsamer Produkt-Stamm]
  stamm --> tkg[TKG-Beilage]
  stamm --> vao[VAO-Beilage]
  stamm --> quer[Querung-Beilage]
  stamm --> vz[Verkehrszeichen-Beilage]
  stamm --> verl[Genehmigungsverlängerung-Beilage]

Genannte Produktarten im Lastenheft:

Abrechnungs-Stammdaten products (product_id, Namen) sind kaufmännisch und kollidieren namensmäßig mit einem Geometrie-Stamm. Für GIS-Objekte einen anderen Namen wählen (Kontextvorschlag: geo_objects / vergleichbar) — das ist HOW, nicht Lastenheft.

Berichte und kundenspezifische Sets

Berichte sind Sichten auf Produkt + Stamm + Beilage, nicht ein dritter Geometriebestand.

• Pro Kunde ein Feld-Set (und abweichend je Gemeinde, wo nötig).
• Optional später: Felder aus Formular, API oder Scraper (Kann ED-12).
• Im Schema existieren bereits Anker für Behördenlogik (jurisdictions, territorial_rules, admin_*) — nutzbar, sobald Sets konkret werden; kein Vorgriff.

Editor-Modi und Layer

Die drei Editor-Modi sind dieselben drei Stufen. Layer, Zeichnen und GIS-Import gelten immer nur für den aktiven Modus, damit Roh-, Norm- und Produktgeometrie nicht in einem Layer landen.

.ltp ist das Projektaustauschformat (ZIP + Magic-Header). Es ersetzt PostGIS nicht.

Dashboard vs. heutiges Web-CMS

QGIS bleibt Exportziel (INT-01), parallel zum Editor.

Glossar

Was der Kontext bewusst nicht ins Lastenheft hebt

Bleibt Betrieb oder späteres Backlog, solange ANFORDERUNGEN.md es nicht fordert: Jira-Import, Billing-Spalten an Organisationen, Soft-Delete von Orgs, Personen über mehrere Orgs, fiber_routes.order_id physisch droppen. Die Pipeline-Trennung selbst ist Lastenheft (ED-01, ED-04, ED-07).