Projektwissen/docs/analyse/00_gesamtueberblick_2026-09-02.md

# Gesamtüberblick AG_QGIS

Stand: 2. September 2026

Quelle: [Gitea-Organisation AG_QGIS](https://entwicklung.flurneuordnung-sachsen.de/AG_QGIS)

## Kurzfazit

`AG_QGIS` ist kein einzelnes Git-Repository, sondern eine Organisation mit elf getrennten Repositories. Die Zielarchitektur besteht aus einem gemeinsamen QGIS-Basisplugin (`sn_basis`) und mehreren darauf aufbauenden Fachplugins. Wirklich ausgebaut sind derzeit `sn_basis`, `sn_plan41` und `sn_verfahrensgebiet`. `sn_widmung` ist ein UI-Gerüst; `sn_flt`, Topografie und Template sind noch Platzhalter.

Die Entwicklung erfolgt überwiegend auf dem Branch `unstable`. Es gibt einen eigenen Gitea-basierten Release-Prozess mit den Kanälen stable, testing und unstable. Der stable-Kanal ist noch leer. Die vorhandenen Unit-/Mock-Tests sind umfangreich, auf den aktuellen unstable-Ständen aber nicht vollständig grün.

## Lokaler Stand

Alle elf öffentlichen Repositories wurden in Unterordner dieses Verzeichnisses geklont. Jeder Checkout steht auf seinem vom Server vorgegebenen Default-Branch und war nach dem Klonen unverändert.

| Repository | Branch | Commit | Stand | Umfang / Rolle |
|---|---|---:|---:|---|
| `Plugin_SN_Basis` | `unstable` | `7755e3e` | 31.08.2026 | Zentrale Laufzeit, 58 Python-Dateien, 13 Testdateien |
| `Plugin_SN_Plan41` | `unstable` | `7fe8115` | 22.07.2026 | Plan-§-41-Fachplugin, 17 Python-Dateien, 5 Testdateien |
| `Plugin_SN_Verfahrensgebiet` | `unstable` | `70c1478` | 02.09.2026 | Fachplugin Verfahrensgebiet, 29 Python-Dateien, 12 Testdateien |
| `Plugin_SN_Widmung` | `unstable` | `b72369d` | 02.07.2026 | UI-Gerüst ohne Fachlogik |
| `Plugin_SN_FLT` | `unstable` | `c1b7460` | 19.06.2026 | Platzhalter, noch kein Plugin-Code |
| `Plugin_SN_Topografie` | `unstable` | `443b5bd` | 19.06.2026 | Platzhalter, noch kein Plugin-Code |
| `Plugin_SN_Template` | `unstable` | `92462d3` | 19.06.2026 | Noch unvollständige Vorlage |
| `Plugin_Test_Action` | `unstable` | `3fd13d8` | 25.03.2026 | Minimales Testplugin für den Release-Prozess |
| `Defaults` | `main` | `440e84b` | 17.07.2026 | Beispiel-Verfahrensdaten und ein QML-Stil |
| `Linkliste` | `main` | `08fbb29` | 17.07.2026 | Zentrale Diensteliste und Formatkonvertierung |
| `Repository` | `main` | `a8db6c0` | 02.09.2026 | QGIS-Plugin-Feeds und Release-Orchestrierung |

Die drei großen Plugins umfassen zusammen rund 29.500 Python-Zeilen einschließlich Tests. Der gesamte lokale Klon ist etwa 7 MB groß.

## Architektur

```mermaid
flowchart TD
    QGIS[QGIS 3.40+] --> BASIS[sn_basis]
    BASIS --> NAV[Menü, Toolbar und DockManager]
    BASIS --> SHARED[Prüfen, Laden, Schreiben, Druck und Projekteinstellungen]
    BASIS --> VG[sn_verfahrensgebiet]
    BASIS --> P41[sn_plan41]
    BASIS --> WID[sn_widmung]
    VG --> ALKIS[Sächsische ALKIS-WFS]
    P41 --> FACH[Fachdienste aus Linkliste]
    P41 --> API[VLN-Karten-API]
    FACH --> GPKG[Verfahrens-GeoPackage]
    REPO[Repository] --> QGIS
    LINKS[Linkliste] -. derzeit nicht direkt angebunden .-> P41
    DEFAULTS[Defaults] -. derzeit nicht direkt angebunden .-> BASIS
```

### Plugin-Zusammenspiel

- `sn_basis` ist eine zwingende Laufzeitabhängigkeit der Fachplugins. Diese importieren Klassen und Wrapper direkt aus `sn_basis`.
- `sn_basis` erzeugt das gemeinsame Menü und die Toolbar „LNO Sachsen“. Fachplugins registrieren dort ihre Aktionen mit Prioritäten.
- Der `DockManager` zeigt jeweils nur ein `sn_dock_*`-Dock an.
- Gemeinsam genutzte Tabs für Druck und Projekteigenschaften werden in die Fachplugin-Docks eingebaut.
- QGIS-Projektvariablen werden zentral mit dem Präfix `sn_` gespeichert, beispielsweise `sn_verfahrensnummer`, `sn_landkreis_kennzahl` und die ID des Verfahrensgebiet-Layers.
- Die Repository-Namen (`Plugin_SN_Basis` usw.) unterscheiden sich von den installierten QGIS-Paketnamen (`sn_basis`, `sn_plan41`, `sn_verfahrensgebiet`, `sn_widmung`). Die Release-ZIPs stellen die korrekten Paketordner her.

## Zentrale Basis: `Plugin_SN_Basis`

Das Basisplugin ist sowohl UI-Rahmen als auch gemeinsame Bibliothek.

Wesentliche Bausteine:

- QGIS-, Qt-, Datei-, Dialog-, Layer-, Style-, Netzwerk- und Variablen-Wrapper mit einem Mock-Modus für Tests ohne QGIS.
- Einheitliches Fehler- und Entscheidungsmodell über `pruef_ergebnis` und `Pruefmanager`.
- `DataGrabber` zur Klassifikation und Prüfung von Excel-, GeoPackage-/SQLite- und Dienstquellen.
- `Datenabruf` für WFS, ArcGIS REST und lokale OGR-Quellen; räumliche Filterung über Verfahrensgebiet, Puffer oder ohne Filter.
- `LayerLoader` und `Datenschreiber` zum Erzeugen, Filtern, Stylen, Speichern und erneuten Laden von Layern in GeoPackages.
- Zentrale Verfolgung des jeweils gewählten Verfahrensgebiet-Layers.
- Drucklogik für § 38, § 41 und „Anlage zur Baufreigabe“, einschließlich Druckbereich, Maßstab, Papierformat/Endlosrolle, Karten-Themen, Legende, Gitternetz und Atlas.
- Projekt- und Benutzerdaten wie Amt, Behörde, Landkreis, Sachgebiet, Verfahrensname und Verfahrensnummer.

Die UI enthält derzeit noch sichtbaren Entwicklungsballast: Beim Aufbau der gemeinsamen Navigation wird eine Aktion `TEST ACTION` angelegt und mehrere Debug-Ausgaben werden per `print()` geschrieben.

## Fachplugin `Plugin_SN_Plan41`

Das Plugin hat zwei fachliche Datenwege.

### Fachdaten aus Linkliste

Die mitgelieferte `assets/Linkliste.xlsx` enthält 44 Dienstzeilen. Das erwartete Schema lautet:

`ident`, `gruppe`, `kartenebene`, `inhalt`, `link`, `provider`, `stildatei`

Der Ablauf ist:

1. Eingabe-GeoPackage und Linkliste prüfen.
2. Linklistenzeilen einlesen und validieren.
3. Raumfilter bestimmen: Verfahrensgebiet, Pufferlayer oder ohne.
4. Fachdienste abrufen und lokal nach Geometrie/Extent filtern.
5. Ergebnislayer und QML-Stile in das Verfahrens-GeoPackage schreiben.
6. Layer ins Projekt laden und ein HTML-Protokoll erzeugen.

Die aktuelle Liste enthält vor allem Umwelt-, Gewässer-, Naturschutz-, Bauleitplanungs-, Energie- und Altlastendienste von LUIS Sachsen und RAPIS. Alle 44 zentral erfassten Einträge sind derzeit als ArcGIS-REST-Dienste gekennzeichnet; 24 haben einen zugeordneten QML-Stil.

### VLN-Karten-API

Das Plugin bindet `https://api.flurneuordnung-sachsen.de/v2` direkt ein:

- Login per E-Mail und Passwort, danach Authentifizierung über `X-API-Key`.
- Laden der verfügbaren Verfahren und des Plan-41-Datensatzes einer VKZ.
- GeoJSON-Daten werden in QGIS-Memory-Layer nach Punkt-, Linien- und Flächengeometrie getrennt.
- Arbeits-CRS ist EPSG:25833.
- Beim Upload werden alle zusammengehörigen Teillayer wieder zu einer FeatureCollection vereinigt; der PUT ersetzt den kompletten Serverbestand dieser VKZ.
- API-Key und E-Mail werden über `QSettings` lokal gespeichert, die VKZ in der QGIS-Projektdatei.

Der dokumentierte Datenbankentwurf in `doc/Datenbank_ERD.md` beschreibt unter anderem Maßnahmen, Konten, Ausbauarten und Akteure. Er ist derzeit eher fachlicher Zielentwurf; eine entsprechende Schema-Migration oder ORM-Schicht ist im Plugin nicht vorhanden.

## Fachplugin `Plugin_SN_Verfahrensgebiet`

Dies ist aktuell das größte und am aktivsten bearbeitete Fachplugin. Der jüngste Commit vom 02.09.2026 erweitert den Shape-Import um Mehrfachauswahl, temporäres ZIP-Entpacken und `FBSchl`-Prüfung.

Wesentliche Funktionen:

- Verfahrensgebiet über `BauRaumOderBodenordnungsrecht` aus dem sächsischen ALKIS laden, wahlweise per Verfahrensnummer oder Landkreis.
- Mehrfachauswahl und Zusammenführung mehrerer ALKIS-Objekte.
- Verfahrensgebiet aus einem oder mehreren Shapefiles bzw. ZIP-Archiven laden.
- Klassifikation der NoBIS-Shapes über `FBSchl` (`901/10110F` Neuordnungsgebiet, `901/10120F` Neuvermessungsgebiet).
- Gemarkungen und Flurstücke aus den vereinfachten bzw. vollständigen ALKIS-WFS laden.
- Verfahrensgebiet aus ausgewählten Flurstücken bilden sowie vorhandene Gebiete ergänzen, verkleinern oder ersetzen.
- Grenzpunkte/PunktortTA gemarkungsweise und in URL-sicheren Batches laden.
- Flächenvergleich zwischen ALKIS-/Shape-Gebiet und flurstücksbasiertem Gebiet.
- Umrings-, Knickpunkt- und Grenzpunktstatistik mit Ergebnislayern.
- Abgleich eines BI-Server-CSV-Exports mit den im Verfahrensgebiet beteiligten Flurstücken.

Externe Hauptquellen:

- Vereinfachtes ALKIS: `https://geodienste.sachsen.de/aaa/public_alkis/vereinf/wfs`
- ALKIS-NAS/SF: `https://geodienste.sachsen.de/aaa/public_alkis/sf/wfs`

Die Implementierung berücksichtigt konkrete Diensteinschränkungen, etwa blockierte POST-/GML-Filter, URL-Längen und serverseitige Feature-Limits. Viele Operationen sind deshalb batching- und dialogorientiert.

## Weitere Repositories

### `Plugin_SN_Widmung`

Das Grundgerüst registriert sich korrekt im gemeinsamen Menü und verwendet das gemeinsame Dock. Die beiden Fachtabs enthalten aber nur Beispiel-Labels und Eingabefelder; produktive Widmungslogik ist noch nicht implementiert. Es gibt keine Tests.

### `Plugin_SN_FLT`, `Plugin_SN_Topografie`, `Plugin_SN_Template`

Diese Repositories enthalten jeweils nur Release-Workflow, Metadata-Vorlage, leere README und Changelog. Es fehlen insbesondere `__init__.py`, `main.py`, UI und Tests. Die Metadata-Vorlagen verwenden noch den Platzhalternamen `Plugin_SN_Neu`.

### `Defaults`

Enthält vier kleine JSON-Beispiele für Verfahren in den Bereichen `22` und `99` sowie einen Verfahrensgebiet-Stil. Im aktuellen Plugin-Code gibt es keine direkte Referenz auf dieses Repository; es ist derzeit eher ein externer Datenvorrat bzw. Prototyp.

### `Linkliste`

`linkliste.csv` ist die manuell zu pflegende Quelle. Eine Gitea Action erzeugt daraus XML, JSON und YAML und committed die Ergebnisse zurück nach `main`. Die Plan41-Laufzeit verwendet derzeit jedoch nicht dieses Repository, sondern eine separat mitgelieferte Excel-Datei. Damit existieren zwei zu synchronisierende Wahrheiten.

### `Repository`

Stellt drei QGIS-Plugin-Feeds bereit:

- `plugins.xml`: stable, aktuell leer.
- `plugins-testing.xml`: Basis 26.7.2, Plan41 26.7.2 und Verfahrensgebiet 26.7.3.
- `plugins-unstable.xml`: FLT 0, Widmung 4711, Plan41 26.7.2, Basis 26.8.3 und Verfahrensgebiet 26.8.3.

Die eigentliche Release-Orchestrierung liegt auf den separaten Branches `hidden/workflows` und `hidden/templates`. Ein `v*`-Tag in einem Plugin-Repository löst dessen Workflow aus. Aus dem Tagsuffix wird der Kanal bestimmt, das Plugin als korrekt benannter ZIP-Ordner gepackt, als Gitea Release veröffentlicht und der passende XML-Feed aktualisiert.

## Entwicklungs- und Teststand

Die vorhandenen Tests wurden in einer temporären Kopie unter Python 3.14 im eingebauten QGIS-/Qt-Mock-Modus ausgeführt. Das ist ein schneller Logiktest, ersetzt aber keinen Test in QGIS 3.40/OSGeo4W.

| Plugin | Ergebnis | Einordnung |
|---|---:|---|
| Basis | 87 Tests: 86 bestanden, 1 Fehler | Aufruferpräfix-Erkennung erwartet im Test `sn`, erkennt aber `test` |
| Plan41 | 44 Tests: 43 bestanden, 1 Fehler | Ein UI-Test initialisiert die neu hinzugekommene VLN-Statusanzeige nicht vollständig |
| Verfahrensgebiet | 201 Tests: 157 bestanden, 15 fehlgeschlagen, 21 Fehler, 8 übersprungen | Viele Tests erwarten noch ältere Einzeldatei-/Einzellayer- und WFS-Mock-Schnittstellen |

Für Widmung, FLT, Topografie und Template gibt es keine Test-Suiten. Es existiert außerdem kein Push-/Pull-Request-CI-Workflow, der die Tests automatisch ausführt; die vorhandenen Plugin-Workflows dienen ausschließlich Releases.

Offene öffentliche Vorgänge zum Stichtag:

- Basis: 17, Schwerpunkt Drucklayout, Atlas, Legende, Schriftfeld und weitere Fachprüfungen.
- Plan41: 6, unter anderem Fachdatenumfang, Pipeline-Meldungen und Planstand-Versionierung.
- Verfahrensgebiet: 12, aktuell besonders Shape-Laden, Beteiligungsabgleich, doppelte Flurstücke, BROBOR-Manipulation und `openpyxl` unter Linux.
- Test-Action: 1; alle anderen Repositories: 0.

## Auffälligkeiten und Risiken

1. **Entwicklungsreife:** Der produktive stable-Feed ist leer; die wichtigen Plugins sind offiziell experimentell und werden hauptsächlich aus unstable entwickelt.
2. **Rote Tests:** Vor weiterer Funktionsentwicklung sollte geklärt werden, welche Fehler echte Regressionen und welche lediglich veraltete Tests nach den jüngsten Schnittstellenänderungen sind.
3. **Implizite Basisabhängigkeit:** Plan41, Verfahrensgebiet und Widmung starten ohne `sn_basis` nicht. Diese Abhängigkeit und die notwendige Ladereihenfolge sind in den Metadata-Dateien nicht als Plugin-Abhängigkeit deklariert.
4. **Nicht reproduzierbare Python-Abhängigkeiten:** Es gibt weder `requirements.txt` noch `pyproject.toml`. `openpyxl` ist ein harter Import der Basis, `requests` ein optionaler Fallback. Ein offenes Linux-Issue bestätigt bereits Probleme mit fehlendem `openpyxl`.
5. **Doppelte Linklistenpflege:** Das zentrale Linklisten-Repository und die eingebettete Plan41-Exceldatei sind technisch nicht verbunden. Änderungen können auseinanderlaufen.
6. **Release-/Metadata-Inkonsistenzen:** Die Plan41-Metadata verweist als Quellrepository auf `Plugin_Test_Action`; das XML-Template hängt an bereits vollständige Tracker-URLs nochmals `/issues` an; FLT zeigt noch auf `Plugin_SN_Neu`; die Widmungs-Version `4711-unstable` passt nicht zum letzten fachlichen Tag `26.3.1-unstable`.
7. **Branch-/Metadata-Mischung:** Auf den ausgecheckten unstable-Branches tragen Basis, Plan41 und Verfahrensgebiet teilweise noch testing-Versionen bzw. testing-URLs in `metadata.txt`. Der Release-Prozess generiert diese Datei neu, der Quellstand selbst ist dadurch aber missverständlich.
8. **Dokumentationslücken:** Die meisten README-Dateien sind leer oder nur ein Zweizeiler. Im Repository-README heißen die Dateien in der Tabelle irrtümlich `plugins_testing.xml` und `plugins_unstable.xml`, tatsächlich verwenden sie Bindestriche.
9. **Kein organisationsweiter Versions-Lock:** Die elf Repositories werden unabhängig versioniert. Es gibt kein Manifest/Superprojekt, das eine nachweislich kompatible Kombination von Commitständen festhält.
10. **Laufzeit und Integration:** Umfangreiche WFS-Abrufe und räumliche Verarbeitung laufen weitgehend im QGIS-Prozess mit blockierenden Requests und manuell gepumpten Fortschrittsdialogen. Reale QGIS-Integrationstests sind daher besonders wichtig.
11. **Lokale Zugangsdaten:** Der VLN-API-Key wird über `QSettings` persistiert. Je nach Plattform ist das eine normale Konfigurationsdatei bzw. Registry und kein sicherer Schlüsselspeicher.

## Sinnvolle nächste technische Schritte

1. Einen reproduzierbaren Entwicklungsaufbau für QGIS 3.40 mit den Paketnamen `sn_*` dokumentieren.
2. Die drei aktuellen Test-Suiten auf einen grünen unstable-Ausgangsstand bringen und als Gitea CI bei Push/Pull Request ausführen.
3. Basisabhängigkeit, Python-Abhängigkeiten und unterstützte QGIS-/Python-Versionen explizit festhalten.
4. Metadata- und Release-Feed-Inkonsistenzen korrigieren und Releases automatisiert validieren.
5. `Linkliste` zur einzigen Quelle machen und daraus die vom Plugin benötigte Laufzeitdatei erzeugen.
6. Einen kompatiblen organisationsweiten Stand per Manifest oder Meta-Repository festhalten.
7. Danach die nächste Fachfunktion gezielt in Plan41 oder Verfahrensgebiet umsetzen.