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

Gesamtüberblick AG_QGIS

Stand: 2. September 2026

Quelle: Gitea-Organisation 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

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.