Files
Projektwissen/docs/konzept/09_alkis7_umstellung.md
T
DanielandClaude Sonnet 5 ce795cdc6f Referenzwissen ALKIS/WFS und ALKIS-7-Umstellungscheckliste ergaenzt
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
2026-09-04 15:05:07 +02:00

7.0 KiB
Raw Blame History

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 liefert root.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) und referenz/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 (DescribeFeatureType je Objektart)
  • genauer Namespace-Suffix (7.1 vs. 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

  1. Gitea-Issue in Plugin_SN_Verfahrensgebiet anlegen (Entwurf vorbereiten).
  2. Sobald ALKIS-7-Testdienst erreichbar: GetCapabilities + DescribeFeatureType sichern, Abschnitt B mit echten Feldnamen füllen.
  3. Umsetzung als eigener feature/-Branch, Namespace-Toleranz zuerst (Abschnitt A).