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

Positionierung des Alternativansatzes zu AG_QGIS

Stand: 2. September 2026

Verglichen wurden:

• der bisherige Projektstand in AG_QGIS gemäß AG_QGIS/GESAMTUEBERBLICK.md,
• das sechsseitige Dokument Alternativansatz/Konzept LNO Verfahren in QGIS.pdf,
• der zugehörige Prototyp Alternativansatz/lnofachschale_plugin.

Ergebnis in einem Satz

Der Alternativansatz ist kein fachlich gleichwertiger Ersatz für AG_QGIS, sondern ein früher Architekturprototyp für eine zentrale, versionierte und konfigurationsgetriebene GeoPackage-Fachschale. Diese Idee kann das bestehende Projekt sinnvoll ergänzen; die bestehende modulare Plugin- und Fachlogik sollte sie aber nicht ersetzen.

Grundpositionierung

AG_QGIS denkt primär von Fachaufgaben und Plugins aus:

• gemeinsame Plattform in sn_basis,
• getrennte Fachplugins für Verfahrensgebiet, Plan41, Widmung usw.,
• Daten werden für einen konkreten Arbeitsablauf geladen, geprüft, bearbeitet, gedruckt oder in ein GeoPackage geschrieben,
• komplexe Fachlogik liegt im jeweils zuständigen Fachplugin.

Der Alternativansatz denkt primär von einem dauerhaften Datencontainer aus:

• ein einzelnes Plugin,
• ein GeoPackage als zentrale „Fachschale“ eines Verfahrens,
• ein JSON beschreibt die vorgesehenen Layer und ihre Version,
• ein zweites JSON beschreibt auswählbare Webdienste und deren Ziellayer,
• das Plugin erzeugt bzw. erweitert das GeoPackage und lädt die darin enthaltenen Layer strukturiert in QGIS.

Damit beantworten beide Ansätze unterschiedliche Fragen:

Ansatz	Leitfrage
AG_QGIS	Welche fachliche Aufgabe soll der Anwender ausführen?
Alternativansatz	In welcher einheitlichen, fortschreibbaren Struktur sollen die Verfahrensdaten liegen?

Diese Perspektiven sind grundsätzlich kombinierbar.

Vergleich der wesentlichen Merkmale

Aspekt	AG_QGIS	Alternativansatz
Organisation	Elf getrennte Repositories	Ein kopierter Plugin-Prototyp ohne eigenes Git-Repository
Architektur	Plattformplugin plus Fachplugins	Ein monolithisches Fachschalen-Plugin
Zentraler Baustein	sn_basis als Code- und UI-Plattform	Ein GeoPackage als Daten- und Projektplattform
Fachlogik	Umfangreiche spezialisierte Workflows	Generisches Erzeugen und Befüllen von Layern
Datenmodell	Teilweise dynamisch und workflowbezogen; Plan41-ERD als Entwurf	Layerstruktur deklarativ in geopackage_schema.json
Schemaänderungen	Keine organisationsweite GeoPackage-Migration	Einfacher Versionsvergleich und additive Schemaergänzung
Dienstekatalog	44 Einträge; zentrale CSV plus separate Plugin-XLSX	23 Einträge direkt in services_config.json
Dienstimport	WFS, REST/ArcGIS und OGR, mehrere Raumfilter, Protokollierung	WFS/ArcGIS, BBOX-Vorfilter und lokaler räumlicher Filter
Verfahrensgebiet	Eigenes großes Fachplugin mit ALKIS-, Shape-, Flurstücks- und Prüfworkflows	Verfahrensumring wird aus einer vorhandenen Vektordatei importiert
Plan § 41	Fachdatenpipeline, Druck, VLN-API, GeoJSON-Laden und -Upload	Nicht umgesetzt
Druck/Atlas	Umfangreich in sn_basis	Nicht umgesetzt
Projekteigenschaften	QGIS-Projektvariablen und gemeinsamer Einstellungstab	Leere GeoPackage-Tabelle projekt_info als Ansatz
Zusammenarbeit	VLN-API für zentralen Plan41-Datenbestand vorhanden	GeoPackage lokal; Postgres/Oracle nur als offene Konzeptfrage erwähnt
Veröffentlichung	Gitea-Releases und stable/testing/unstable-Feeds	Keine Release- oder Repository-Integration
Umfang	Rund 29.500 Python-Zeilen in den drei Hauptplugins einschließlich Tests	2.491 Python-Zeilen einschließlich generierter Tests
Reife	Aktive Entwicklung mit vielen Fachfunktionen, aber unstable und rote Tests	Machbarkeitsnachweis Version 0.1

Was der Alternativansatz konkret umsetzt

1. Erzeugen einer Fachschale

Aus geopackage_schema.json werden sechs Layer bzw. Tabellen erzeugt:

• wka_punkte
• wka_linien
• gewaesser_linien
• einzugsgebiete_flaechen
• projekt_info
• verfahrensumring

Die Konfiguration enthält Layername, Titel, Gruppe, Geometrietyp und Namen einer QML-Stildatei. Eine Tabelle fachschale_info speichert die Schema-Version, aktuell 0.0.1. Die Layer werden in einem nach GeoPackage und Version benannten QGIS-Layerbaum gruppiert.

2. Einfaches Schema-Update

Beim Laden eines GeoPackages vergleicht das Plugin dessen gespeicherte Version mit der im Plugin enthaltenen JSON-Version. Bei Abweichung können fehlende Tabellen und optional konfigurierte Felder ergänzt werden. Vorhandene Tabellen und Daten sollen erhalten bleiben.

3. Import des Verfahrensumrings

Eine Vektordatei wird in den vorbereiteten Layer verfahrensumring importiert. Dabei werden:

• Geometrietypen geprüft,
• Geometrien in das Ziel-CRS transformiert,
• Single- zu Multi-Geometrien angehoben,
• fehlende Attribute dynamisch ergänzt,
• Features in Batches geschrieben.

4. Konfigurierter Webdienstimport

Ein Dialog zeigt 23 Dienste aus vier Kategorien. Ausgewählte Dienste werden in das jeweils konfigurierte Ziellayer geschrieben. Optional soll der Verfahrensumring als räumliche Begrenzung dienen. Vor dem lokalen Filter wird eine um 500 Meter vergrößerte BBOX an den Dienst gegeben.

Inhaltliche Überschneidung der Dienstekataloge

Der Alternativansatz greift große Teile derselben LUIS-Dienste auf wie die heutige Plan41-Linkliste:

• 18 der 23 URLs stimmen exakt mit Einträgen der 44-zeiligen AG_QGIS-Linkliste überein.
• Zwei weitere WRRL-Themen entsprechen inhaltlich vorhandenen Einträgen, verwenden aber eine abweichende URL mit explizitem Layer /0.
• Drei Denkmalschutz-WFS-Layer (L1, L2, L3) sind im Alternativansatz zusätzlich enthalten.

Die Benennung mehrerer ArcGIS-Layer widerspricht sich jedoch zwischen den Ansätzen. Beispiele:

• dieselbe WKA-URL /2 heißt in AG_QGIS „Windkraftanlagen-vorBetrieb“, im Alternativansatz „Windkraftanlagen (Linien)“;
• Einzugsgebiets-Layer /0 und /1 werden einmal als Haupt-/Teileinzugsgebiete, einmal als Linien-/Flächenebene interpretiert;
• Natura-2000-Layer werden einmal nach fachlichem Inhalt, einmal nach vermeintlicher Geometriefamilie benannt.

Vor einer Übernahme muss daher die tatsächliche Bedeutung und Geometrie jedes Server-Layers gegen dessen Dienstmetadaten geprüft werden. Die Zuordnung darf nicht allein aus der Layernummer abgeleitet werden.

Die wesentlichen konzeptionellen Unterschiede

Fachbedeutung statt bloßer Dienstkopie

Der Alternativansatz möchte Layer langfristig nach stabilen Fachbedeutungen organisieren. Das ist konzeptionell stärker als ein GeoPackage, dessen Tabellen unmittelbar aus wechselnden Dienstnamen entstehen. Es schafft einen möglichen Datenvertrag zwischen Plugins, Projekten und Auswertungen.

Der aktuelle Prototyp erreicht diesen Anspruch allerdings noch nicht vollständig: Beim Dienstimport werden sämtliche neu gefundenen Quellfelder automatisch und als Textspalten in das Ziellayer übernommen. Dadurch bestimmt weiterhin der externe Dienst das lokale Schema, ohne dass sich die deklarierte Schema-Version ändert. Die im Konzept ausdrücklich aufgeworfene Frage „Welche Attribute benötigen wir wirklich?“ ist somit noch nicht gelöst.

Deklaratives Schema statt fest verdrahteter Workflows

Neue Layer lassen sich im Alternativansatz grundsätzlich per JSON hinzufügen. AG_QGIS benötigt für neue Fachfunktionen meist Code in einem Fachplugin. Umgekehrt kann JSON nur Struktur und Zuordnung beschreiben; es ersetzt keine Fachlogik wie:

• ALKIS-Suche nach Verfahrensnummer/Landkreis,
• Beteiligungsabgleich,
• Knickpunkt- und Umringsprüfung,
• Flächenvergleich und Korrektur,
• Drucklayout und Atlas,
• VLN-API-Synchronisation.

Monolith gegen Modulsystem

Ein einzelnes Plugin ist zunächst leichter zu installieren und kann eine einheitliche Fachschale erzwingen. Mit wachsendem Funktionsumfang drohen jedoch starke Kopplung und ein großer gemeinsamer Release-Zyklus. Das bestehende Plattform-/Fachplugin-Modell trennt Verantwortlichkeiten besser, leidet derzeit aber unter einer nur implizit deklarierten Basisabhängigkeit und unabhängigen Versionsständen.

GeoPackage als Primärmodell

Im Alternativansatz ist das GeoPackage die maßgebliche Projektinstanz. In AG_QGIS ist es derzeit eher ein wichtiges Arbeits- und Ausgabeformat neben QGIS-Projektvariablen, Memory-Layern, ALKIS-Diensten und der VLN-API.

Diese Festlegung berührt unmittelbar die Mehrbenutzerfrage. Ein lokales GeoPackage eignet sich gut für einen Bearbeiter und transportierbare Verfahren, aber nicht für gleichzeitiges verteiltes Schreiben. AG_QGIS besitzt mit der VLN-API bereits einen Ansatz für zentrale Zusammenarbeit, den der Alternativansatz nicht abbildet.

Umgang mit Geometrietypen

Das Konzept erwägt, Fachbedeutungen nicht unnötig nach Geometrietyp aufzuteilen. Für QGIS-/GeoPackage-Vektorlayer ist ein eindeutig deklarierter Geometrietyp jedoch der robuste Normalfall. Wenn eine Fachbedeutung tatsächlich Punkte, Linien und Flächen enthalten kann, ist die im aktuellen Plan41-API-Modul verwendete Aufteilung nach Geometriefamilie technisch sinnvoll. Vereinfachen sollte man daher nur nach fachlicher Prüfung, nicht als allgemeine Regel.

Stärken des Alternativansatzes

1. Explizites Ziel-Datenmodell: Er macht die bisher offene Frage nach einer organisationsweit stabilen Fachschale konkret.
2. Version im Datenbestand: Ein Verfahren kann erkennen, zu welchem Schema es gehört.
3. Konfiguration statt Code für Katalogdaten: Layergruppen, Dienstzuordnungen und Styles sind prinzipiell außerhalb der Fachlogik pflegbar.
4. Additive Weiterentwicklung: Fehlende Tabellen und Felder können ergänzt werden, ohne vorhandene Fachdaten pauschal neu aufzubauen.
5. Klarer Anwenderablauf: Fachschale anlegen, Umring importieren, Dienste auswählen und laden.
6. Datennahe Layerorganisation: Die QGIS-Layergruppen werden reproduzierbar aus dem Schema aufgebaut.
7. Neue Quellen: Die drei Denkmalschutz-WFS-Ebenen sind ein möglicher fachlicher Zusatz zur heutigen Linkliste.

Grenzen und Risiken des Prototyps

Fachliche und konfigurative Lücken

1. Von 23 konfigurierten Diensten besitzen nur vier ein passendes Ziellayer im sechs Layer umfassenden Schema. Die übrigen 19 Importe scheitern planmäßig.
2. Der Ordner styles ist leer, obwohl fünf Schemaeinträge QML-Dateien referenzieren. Die im Konzept gezeigte Ausgestaltung ist im übergebenen Stand nicht reproduzierbar.
3. projekt_info enthält keine definierten Fachfelder. Projekteigenschaften werden noch nicht gespeichert oder bearbeitet.
4. Der Schemaentwurf enthält überhaupt keine fields-Definitionen. Attribute entstehen ausschließlich beiläufig beim Import.
5. Diensttitel und angenommene Geometrien widersprechen teilweise dem heutigen AG_QGIS-Katalog und müssen fachlich validiert werden.

Schema- und Datensicherheit

1. Die Updatefunktion ist keine echte Migrationsengine. Sie kennt keine geordneten Schritte, Umbenennungen, Typänderungen, Löschungen, Rollbacks oder Migrationshistorie.
2. Jede Versionsabweichung löst ein Update aus; auch ein GeoPackage mit neuerer Version würde auf die im Plugin enthaltene Version zurückgestempelt.
3. Fehler beim Anlegen einzelner Layer werden teilweise nur protokolliert; anschließend kann die neue Gesamtversion trotzdem gespeichert und Erfolg gemeldet werden.
4. Die automatische Erkennung identifiziert jedes geladene OGR-GeoPackage als potenzielle Fachschale. Dadurch kann das Plugin auch für fachfremde GeoPackages ein Update anbieten oder beim manuellen Update Tabellen ergänzen.
5. Beim Neuanlegen wird eine vorhandene, nicht geladene Zieldatei vor dem erfolgreichen Neuaufbau gelöscht. Backup und transaktionaler Ersatz fehlen.
6. Beim Dienstimport wird das Ziellayer vollständig geleert und ersetzt. Liefert der Dienst dagegen null Treffer, kehrt die Funktion vor dem Leeren zurück; alte Daten bleiben dann unbemerkt erhalten.

Räumliche Verarbeitung

1. Der Dialog verspricht „Geometrien exakt auf Verfahrensumring zuschneiden“. Implementiert wird aber nur ein intersects-Filter gegen einen um einen Meter gepufferten Umring; die Geometrien selbst werden nicht geschnitten.
2. Das Standard-GeoPackage wird in EPSG:25832 erzeugt, während WFS-Verbindungen fest EPSG:25833 anfordern und AG_QGIS für Plan41 ebenfalls EPSG:25833 verwendet. Das kann transformiert werden, muss aber als verbindliche LNO-Entscheidung geklärt werden.
3. Neu erkannte Dienstfelder werden per OGR pauschal als Text angelegt. Zahlen-, Datums- und Boolesche Typen gehen als Datenmodell verloren.
4. Mehrere gleichzeitig geladene Fachschalen sind nicht eindeutig adressiert: ohne aktiven Layer wird der erste Pfad aus einer ungeordneten Menge verwendet; der Verfahrensumring wird nur über den sichtbaren Layernamen gesucht.

Auslieferung und Qualitätssicherung

1. Makefile und pb_tool.cfg paketieren nur die drei Python-Dateien im Wurzelverzeichnis. Die zwingend benötigten Ordner core, gui, config und styles fehlen in EXTRA_DIRS; ein so gebautes Plugin startet nicht.
2. Der Ordner ist kein Git-Repository. Versionshistorie, nachvollziehbare Herkunft und ein reproduzierbares Paket fehlen.
3. Die Metadata sind weitgehend Plugin-Builder-Platzhalter (about, Tracker, Repository, Homepage) und geben QGIS 3.0 als Minimum an, obwohl der Code deutlich neuere APIs verwendet.
4. Es gibt keine expliziten Abhängigkeits- oder Umgebungsangaben für QGIS/GDAL/OGR.
5. Die fünf Tests stammen überwiegend unverändert aus dem QGIS Plugin Builder. Es gibt keine Tests für GeoPackage-Erzeugung, Migration, Dienstimport oder Vektorimport.
6. Das Makefile unterdrückt Testfehler ausdrücklich mit || true; ein fehlerhafter Testlauf kann den Build daher nicht stoppen.
7. Die aktuelle Umgebung besitzt kein importierbares QGIS-Python-Modul. Deshalb waren nur ein erfolgreicher Metadata-Test und eine statische Syntaxprüfung aller 16 Python-Dateien möglich, kein realer Funktionstest.
8. Generierte __pycache__-Dateien liegen im übergebenen Quellordner; eine Bereinigung und .gitignore fehlen.

Empfohlene gemeinsame Zielarchitektur

Die beste Kombination wäre: bestehende modulare Fachplugins behalten, die Fachschale als gemeinsamen versionierten Datenvertrag ergänzen.

flowchart TD
    QGIS --> BASIS[sn_basis: Plattform und gemeinsame Dienste]
    BASIS --> SCHEMA[Schema-Registry und Migrationen]
    BASIS --> CATALOG[zentraler Dienstekatalog]
    BASIS --> GPKG[versionierte Verfahrens-Fachschale.gpkg]
    VG[sn_verfahrensgebiet] --> BASIS
    P41[sn_plan41] --> BASIS
    WID[sn_widmung] --> BASIS
    FLT[sn_flt / Topografie] --> BASIS
    VG --> GPKG
    P41 --> GPKG
    WID --> GPKG
    CATALOG --> P41
    GPKG <--> API[VLN-API / spätere Mehrbenutzer-Datenbank]

Dabei sollte gelten:

• sn_basis stellt Schemaerkennung, Migration, Backup, Transaktionen und einen gemeinsamen Layerkatalog bereit.
• Jedes Fachplugin kann einen eigenen, versionierten Schemaabschnitt und eigene Migrationen beitragen.
• Das GeoPackage besitzt eine eindeutige Fachschalen-Kennung, nicht nur eine Version. Fremde GeoPackages werden nie automatisch verändert.
• Schemaänderungen erfolgen über geordnete Migrationen (0.1 -> 0.2 -> 0.3) mit Protokoll, Validierung und Rollback/Backup.
• Felder, Typen, Pflichtwerte, Schlüssel und Relationen werden explizit definiert. Externe Dienstattribute werden über ein konfiguriertes Mapping übernommen, nicht pauschal als Text.
• Die zentrale Linkliste wird zur einzigen Dienstquelle. Daraus können JSON für die UI und bei Bedarf XLSX/XML/YAML generiert werden.
• Dienstkonfiguration und Zielschema werden automatisiert gegeneinander validiert: kein Dienst ohne Ziellayer, kein Geometriekonflikt, keine fehlende Style-Datei.
• Verfahrensgebiet, Plan41, Druck und Prüfungen bleiben Fachlogik in ihren bestehenden Plugins.
• Lokales GeoPackage und zentrale VLN-API erhalten klar getrennte Rollen: Offline-/Arbeitskopie einerseits, Mehrbenutzer- und Austauschsystem andererseits.

Bewertung der Übernahmeideen

Idee aus dem Alternativansatz	Bewertung	Empfohlene Verwendung
Versioniertes GeoPackage	Sehr wertvoll	Als gemeinsamer Datenvertrag in sn_basis neu und migrationssicher umsetzen
Deklaratives Layerschema	Wertvoll	Um Felder, Typen, Schlüssel, CRS und Zuständigkeit je Fachplugin erweitern
JSON-Dienstekatalog	Wertvoll	Mit dem bestehenden Linkliste-Repository zusammenführen, keine dritte Quelle schaffen
Dienst → festes Ziellayer	Wertvoll	Nur mit validiertem Attribut- und Geometriemapping
Reproduzierbarer Layerbaum	Gut übernehmbar	Als gemeinsame Ladefunktion in sn_basis
Ein einziges Gesamtplugin	Nicht empfohlen	Bestehende Fachplugin-Trennung beibehalten
Einfacher Versionsvergleich	Für Produktion unzureichend	Durch echte inkrementelle Migrationen ersetzen
Automatische Erweiterung aller GPKGs	Gefährlich	Nur explizit markierte Fachschalen zulassen
Alle Quellattribute dynamisch übernehmen	Nicht empfohlen	Fachlich ausgewählte und typisierte Zielfelder definieren
Lokales GeoPackage als alleinige Wahrheit	Nur für Einzelplatz geeignet	Mit VLN-API bzw. später PostgreSQL für Mehrbenutzerfälle kombinieren

Empfohlene nächste Entscheidung

Vor weiterer Implementierung sollte fachlich entschieden werden, ob eine verbindliche, versionierte Verfahrens-Fachschale das gemeinsame Zielbild ist. Wenn ja, sollte nicht der Prototyp direkt in AG_QGIS kopiert werden. Sinnvoller ist eine kleine gemeinsame Spezifikation mit:

1. Fachbedeutungen und verantwortlichem Fachplugin,
2. Layern und Geometrietypen,
3. benötigten Attributen, Typen, Schlüsseln und Relationen,
4. verbindlichem CRS,
5. lokaler versus zentraler Datenhoheit,
6. Migrations- und Abwärtskompatibilitätsregeln,
7. kanonischem Dienstekatalog.

Auf dieser Grundlage kann die starke Grundidee des Alternativansatzes in die bestehende, deutlich weiter entwickelte AG_QGIS-Architektur integriert werden, ohne die bereits vorhandenen Fachfunktionen und die Release-Struktur neu bauen zu müssen.