Neu in docs/wissen: wfs_dienste.md (ALKIS-WFS-Endpunkte der saechsischen Dienste, erprobte Anfragen je Objektart, die vom WAF blockierten Normfaelle) und alkis_objektarten.md (die von sn_verfahrensgebiet genutzten AAA-Objektarten mit Attributen, Filterkonventionen und den FlurbG-Werten von artderfestlegung). Neu in docs/konzept: 09_alkis7_umstellung.md - Vergleich ALKIS 6 (GID 6.0) gegen ALKIS 7 (GID 7.1) und die konkrete Anpassungsliste fuer sn_verfahrensgebiet (fest verdrahteter NAS-Namespace, abgeflachte WFS-Feldnamen, Codelisten, Tests). Als offene Baustelle 14 in STATUS.md verlinkt. Quellmaterial (OK-AAA 7.1.2, ALKIS-FSK 2.1.0, EA-Modellexporte, ~180 MB) liegt lokal unter referenz/ und wird per .gitignore nicht versioniert; Herkunft ist in alkis_objektarten.md dokumentiert. Querverweise aus externe_dienste.md, fallstricke.md, docs/README.md ergaenzt; Glossar um NAS, ZUSO/REO, OK-AAA erweitert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NqvdHqySjQMVowB3G3Vf3U
7.0 KiB
ALKIS 6 → ALKIS 7: Vergleich und Anpassungsbedarf in den Plugins
Stand 04.09.2026. Vorschlag/Prüfliste, noch kein Beschluss. Betroffen ist ausschließlich
sn_verfahrensgebiet (functions/*_alkis*.py); sn_plan41 spricht kein ALKIS an.
„ALKIS 6/7" meint die GeoInfoDok-Version des AAA-Modells: ALKIS 6 = GID 6.0,
ALKIS 7 = GID 7.1. Das Referenzmaterial unter referenz/alkis/ (lokal, nicht versioniert)
ist bereits GID 7.1.2. Verwandte Doku: ../wissen/wfs_dienste.md,
../wissen/alkis_objektarten.md.
Teil 1 – Was sich für uns als WFS-/NAS-Konsument ändert
| Thema | ALKIS 6 (GID 6.0) | ALKIS 7 (GID 7.1) | Wirkung auf uns |
|---|---|---|---|
| NAS-/GML-Namespace | http://www.adv-online.de/namespaces/adv/gid/6.0 |
…/adv/gid/7.1 |
Hart. Jeder fest verdrahtete Namespace findet keine Elemente mehr. |
| Codelisten | viele Attribute sind Enumeration mit Ganzzahlwert (2110) |
dieselben Attribute sind extern verwaltete CodeList (adv-Registry, versioniert); Wert kommt als Code oder als Registry-URI, neue Werte ohne Schemaänderung |
artDerFestlegung kann als URI statt 2110 ankommen; neue FlurbG-nahe Werte (z. B. 2180 Freiwilliger Nutzungstausch) |
| ISO-Angleichung | ältere ISO-19100-Stände | Raumbezug/Zeit/Metadaten/Datenqualität an 19107/19108/19115/19157 angeglichen | qualitaetsangaben (AX_DQ*) umstrukturiert |
| Modellpflege | — | neue Supertypen (AX_Flurstueck_Kerndaten), normalisierte Relationsrollen, Anschrift/Lagebezeichnung angepasst |
abgeflachte WFS-Feldnamen können sich verschieben |
| Objektarten | — | neue/geänderte Objektarten v. a. in Tatsächlicher Nutzung und Bau-/Raum-/Bodenordnung | BROR-Filterung prüfen |
| Dienst-Infrastruktur | vorhandener public_alkis-WFS |
GeoSN stellt i. d. R. neue Capabilities-Version, ggf. neuen Pfad, Parallelbetrieb für Übergangszeit; outputFormat-Profilstring ändert sich |
Endpunkt/Capabilities neu verifizieren |
Unverändert: WFS 2.0.0, GML 3.2, EPSG:25833. Die WAF-Grenzen (POST/GML-Filter blockiert,
URL-Länge, COUNT-Limit) sind sächsische Infrastruktur, nicht Schema – trotzdem gegen die
neue Instanz neu sondieren (referenz/wfs/).
Teil 2 – Konkrete Anpassungen
A. Fest verdrahteter NAS-Namespace — der harte Bruch
functions/grenzpunkt_alkis.py:274—_ADV = "…/gid/6.0"in_erstelle_layer_aus_gml. Diese Funktion parst PunktortTA- und Grenzpunkt-GML von Hand; gegen einen 7.1-Dienst liefertroot.findall(".//{…/6.0}…")nichts →None→ „keine Grenzpunkte". Fix: Namespace aus dem GML-Wurzelelement ableiten (bzw. Liste bekannter Namespaces akzeptieren), nicht als Konstante.- Betrifft auch die verschachtelte Suche
.//{_ADV}genauigkeitsstufe(Zeile ~340) undreferenz/wfs/_test_wfs_post.py:8,55(nur Referenz).
B. Fest verdrahtete, abgeflachte Attributnamen in sql=-Filtern
Der QGIS-WFS-Provider flacht verschachtelte Datentypen zu eltern_kind_…-Feldnamen ab.
Ändert GID 7.1 den Schemapfad, ändert sich der Feldname — und jedes WHERE <name> = …
liefert stillschweigend 0 Features:
| Datei | Feld / Filter |
|---|---|
functions/flurstueck_alkis.py:101 |
gemarkung_ax_gemarkung_schluessel_gemarkungsnummer |
functions/verfahrensgebiet_alkis.py (~112) |
bezeichnung LIKE '<vkz5>%' auf BROR |
functions/verfahrensgebiet_alkis.py:20–28 |
Liste BROR_ATTRIBUTE_FELDER |
functions/verfahrensgebiet_edit_service.py:26–27 |
FELD_KENNZEICHEN, FELD_GEMARKUNG (Pflichtfelder) |
functions/beteiligung_pruefung.py |
flurstueckskennzeichen, zaehler, nenner, land, gemarkungsnummer |
functions/gemarkung_alkis.py |
schluessel, ave_name (vereinf. Dienst — separat prüfen, Sachsen-eigenes Schema) |
Aktion: sobald ein ALKIS-7-Testdienst verfügbar ist, je Objektart DescribeFeatureType
ziehen, Feldnamen diffen, alle Namen als benannte Konstanten an einer Stelle sammeln;
wo möglich tolerante Feldsuche wie bereits _erkenne_gehoert_zu_feld.
C. artDerFestlegung als Codeliste
functions/verfahrensgebiet_alkis.py / verfahrensgebiet_dialoge.py (ask_bror_kombinationen):
falls auf artderfestlegung verglichen/gruppiert wird, vor dem Vergleich normalisieren
(letztes URI-Segment nehmen). Werteliste in ../wissen/alkis_objektarten.md
um neue GID-7.1-Werte ergänzen. Der bezeichnung LIKE-Filter bleibt unberührt (String-Attribut).
D. PunktortTA → Grenzpunkt-Referenz
grenzpunkt_alkis.py:64 _GEHOERT_ZU_KANDIDATEN = ["istTeilVon","gehoertZu","gehoertZuAX_Grenzpunkt"]
ist bereits tolerant — den in GID 7.1 tatsächlich abgeflachten Namen prüfen und ggf. aufnehmen.
xlink:href="urn:adv:oid:DE…" sollte bleiben.
E. Qualitätsangaben
qualitaetsangaben_ax_dqpunktort_genauigkeitsstufe (grenzpunkt_alkis.py:292) und die
Container-Erkennung gegen die 7.1-DQ-Struktur (ISO 19157) prüfen; Containername kann sich ändern.
F. Endpunkte konsolidieren und neu sondieren
Die URLs stehen als Literale in vier Dateien (gemarkung_alkis.py, flurstueck_alkis.py,
grenzpunkt_alkis.py, verfahrensgebiet_alkis.py). In ein Modul ziehen, dann klären,
ob GeoSN den Pfad behält. WAF-Verhalten (POST, KVP-BBOX, ResourceId, COUNT-Limit) gegen die
neue Instanz mit den Skripten in referenz/wfs/ neu testen.
G. Tests (Projektregel: zuerst der Test, der den Bruch zeigt)
- Für den manuellen GML-Parser gibt es aktuell offenbar keinen direkten Test (die Testdateien enthalten kein GML). Fixtures mit je einem 6.0- und einem 7.1-Namespace-GML anlegen und parametrisieren.
python scripts/run_tests.py sn_verfahrensgebiet --baseline+python scripts/testkatalog.py.- QGIS-Test gegen den echten ALKIS-7-Dienst im PR dokumentieren.
H. Doku nachziehen
../wissen/wfs_dienste.md,
../wissen/alkis_objektarten.md,
../wissen/externe_dienste.md,
../wissen/fallstricke.md; ADR unter ../entscheidungen/ für die
Umstellungsstrategie.
Strategie
GeoSN fährt ALKIS 6 und 7 vermutlich eine Zeit lang parallel — daher tolerant umsetzen (Namespace aus der Antwort, tolerante Feldsuche), nicht hart umschalten.
Offen / nur am echten ALKIS-7-Dienst klärbar
- exakte abgeflachte Feldnamen in GID 7.1 (
DescribeFeatureTypeje Objektart) - genauer Namespace-Suffix (
7.1vs. Unterversion) - ob GeoSN den WFS-Endpunkt / -Pfad wechselt (
GetCapabilities) - ob der vereinfachte Dienst (
ave:KatasterBezirk) mitgezogen wird - aktualisiertes WAF-Verhalten der neuen Deployment-Instanz
Nächste Schritte
- Gitea-Issue in
Plugin_SN_Verfahrensgebietanlegen (Entwurf vorbereiten). - Sobald ALKIS-7-Testdienst erreichbar:
GetCapabilities+DescribeFeatureTypesichern, Abschnitt B mit echten Feldnamen füllen. - Umsetzung als eigener
feature/-Branch, Namespace-Toleranz zuerst (Abschnitt A).