[PostNAS Suite] ALKIS2NAS - Konverter

Fr Jan 29 07:53:06 PST 2021

Am 28.01.21 um 22:26 schrieb LWB Ressen - Lindchen:
> Vielen Dank in die Runde!
> 
> Meine wahnwitzige Idee war es, in meiner ALKIS-Datenbank in der 
> ax_flurstueck rumzupfuschen, damit sie die Flurstücke eines Jagdbezirkes 
> enthält.
> Dann wieder in die xml-Datei verpacken, damit die Jagdkatastersoftware 
> dieses frißt und man nicht in mühseliger Kleinarbeit die überflüssigen 
> Flurstücke händisch entfernen muss.
> Das wären dann keine ALKIS - Daten, es wäre NALKIS (nichtamtlich...).
> Aber rein theoretisch müsste doch der norGIS - Import auch analog 
> umgekehrt zu programmieren sein!?!?
> 
> Gruß aus NZL
> Martin

Hallo,

 > Aber rein theoretisch müsste doch der norGIS - Import auch analog 
umgekehrt zu programmieren sein!?!?

Im Prinzip ja, aber ich glaube hier unterschätzt du gewaltig die Menge 
an Arbeit, die in den letzten Jahren in dieses Projekt geflossen ist, 
insbesondere durch Jürgen E. Fischer von NorBIT.
Dies wurde von vielen Auftraggebern und Spendern ermöglicht.

 > ... in meiner ALKIS-Datenbank in der ax_flurstueck rumzupfuschen

Keine Gute Idee!

Wird diese Datenbank durch ein NBA-Verfahren gefüttert?

  Wir haben für einige Jagdgenossenschaften solche NBA-Verfahren 
eingerichtet. Einmal jährlich im Frühjahr, einen Monat vor der 
Hauptversammlung der Genossenschaft, werden die Aktualisierungen 
ausgegeben. Damit wird der Sekundärbestand dann aktualisiert damit er 
zum Zeitpunkt der Versammlung aktuell ist.

Definition: NBA = Nutzerbezogene Bestandsdaten-Aktualisierung

Die abgebende Stelle, also das Katasteramt, merkt sich für einen 
"Bezieher" welchen Stand dieser bekommen hat und generiert beim nächsten 
Abgabe-Termin dazu die passenden Differenzdaten.
Die erste große Lieferung enthält nur "Insert"-Anweisungen, die sind 
relativ einfach zu verarbeiten.
Bei folgenden (kleinen) Aktualisierung sind dann auch Löschanweisungen 
(Delete) und Aktualisierungen (Update/Replace) enthalten. Wenn das zu 
löschende oder das zu ändernde Objekt (Flurstück) aber nicht mehr 
vorhanden ist, dann wird sich der Konverter dabei verschlucken.

In einer Datenbank ist vieles mit einander verbunden. Darum heißt das 
auch "Relationale Datenbank" (Relation = Beziehung).
Ein Flurstück ist z.B. Teil eines Grundstücks (also einer Buchung auf 
einem Grundbuchblatt) und hat daher eine Relation zur "Buchungsstelle". 
Über eine NBA-Aktualisierung werden beide Seiten der Relation 
gleichzeitig aktualisiert. Ein manuelles einseitiges Löschen macht die 
Relation aber kaputt.

 >  man nicht in mühseliger Kleinarbeit die überflüssigen
 > Flurstücke händisch entfernen muss.

Wenn ein manuelles Löschen kurzfristig die einzige Möglichkeit ist, dann 
bitte nur mit einem Script in einer *Kopie* der Datenbank löschen.
Im nächsten Jahr dann die Original-Datenbank mit PostNAS aktualisieren, 
eine neue Kopie machen, diese mit dem gleichen Script wieder ausdünnen. 
Das Script wäre aber auch jährlich zu aktualisieren (siehe unten bei 
"Flurstücksliste").

Beispiel SQL-Script:
  DELETE FROM ax_flurstueck WHERE gml_id IN ('DENWnn0123456789', 
'DENWnn0123456790', 'DENWnn0123456791', ...);

Eine sinnvolle Lösung hängt davon ab, wie diese "Jagdkatastersoftware" 
arbeitet.
Verwendet die auch PostNAS für den Import nach PostGIS?

Das Problem müsste m.E. über sinnvolle *Filter* gelöst werden und das 
ist m.E. genau die Aufgabe, die diese Software erfüllen sollte.

Ich habe selbst schon Auswertungen für Zwecke des Jagdkatasters 
programmiert. Die aktuell verwendete Software, ihren Zweck und ihre 
Vorgehensweise kenne ich aber nicht. Daher kann ich hier nur ein 
bisschen ins Blaue hinein raten.

Ein Filter kann bereits bei der Einrichtung des NBA-Verfahrens im 
Katasteramt angewendet werden oder später im Sekundärbestand.

Im Sekundärbestand (PostGIS-Datenbank) würde man das am besten über 
"Views" (Sichten) realisieren und die Tabellen und deren Inhalt aus den 
oben beschriebenen Gründen unangetastet lassen.

Arten von Filtern:

- Filter: Räumlich

Äußere Begrenzung auf das in der Satzung definierte Gebiet der 
Jagdgenossenschaft. Hier ist das oft ein Ortsteil (Gemarkung).

Aussparungen (Löcher im Gebiet) z.B. als ausreichender Abstand von 
"bebauten Gebieten", die als "nicht bejagbar" gelten.
"Bebautes Gebiet" könnte über Gebäude-Objekte definiert werden und/oder 
über die Nutzungsart (Wohngebiet).

- Filter: Nutzungsart

In den 1980er Jahren habe ich mal auf dem IBM-Großrechner eine 
Jagdkataster-Liste programmiert auf Basis des Verfahrens BEDV. BEDV war 
der Vorgänger von ALB welches Vorgänger von ALKIS ist. Da war also nur 
das "Buchwerk" enthalten, keine Geometrie. Die Karte war damals noch 
analog (Tusche auf Karton). Räumliche Kriterien bleiben daher 
unberücksichtigt.

Die Liste diente der Abrechnung der Jagdpacht mit den Eigentümern.
Es wurden dazu alle "bejagbaren" Flächen in einem Jagdbezirk nach 
Eigentümer gruppiert und summiert.
Als Filter diente dabei die Nutzungsart. Jemand mit Kenntnissen des 
Landes-Jagdgesetzes *und* des Katasters hatte die Tabelle der 
Nutzungsarten nach "bejagbar" (ja/nein) qualifiziert. Alles was nicht 
bejagbar war, fiel komplett raus.
Als Vater von 3 Kindern war ich entsetzt, dass auch die Nutzungsart 
"Spielplatz" als bejagbar qualifiziert war. Vor meinem inneren Auge 
erschien jemand mit einer Schrotflinte, der zwischen Wippe und Schaukel 
herum ballerte.
Ein Anruf klärte auf, dass das natürlich verboten ist. Aber da man dort 
Kaninchenfallen aufstellen darf, kann für die Fläche eine Jagdpacht 
abgerechnet werden. Das war ja das Ziel dieser Auswertung.

- Filter: Flurstücksliste

Wenn gar nichts anderes geht, wäre auch das möglich.
Aber diese Liste müsste Jahr für Jahr manuell aktualisiert werden. Das 
ist mühsam und fehleranfällig. Man müsste 
Vorgänger-Nachfolger-Beziehungen recherchieren bei geteilten oder 
verschmolzenen Flurstücken. Das wäre prinzipiell über PostNAS möglich. 
Dazu muss aber in den NAS-Daten die Flurstücks-Historie mit ausgegeben 
werden.

Die Software müsste m.E. eine komfortable Definition dieser Filter 
erlauben, auch für Personen ohne Kenntnisse der ALKIS-Strukturen oder 
der Datenbank-Sprache "SQL".
Was macht denn noch diese Software, wenn man die Filter-Probleme im 
Vorfeld mühsam selbst behandeln muss?

Beispiel "View":
In der Datenbank
  CREATE VIEW flurstueck_gefiltert AS SELECT * FROM ax_flurstueck WHERE 
NOT gml_id IN ('DENWnn0123456789', 'DENWnn0123456790', 
'DENWnn0123456791', ...); -- Liste ausgeschlossener Flurstücke

Dann im QGIS bei der Datenquelle der Flurstücks-Ebene "ax_flurstueck" 
austauschen gegen "flurstueck_gefiltert".

Damit hätte man bestimmte Flurstücke ausgenommen ohne sie gleich 
komplett zu löschen.

-- 
Nomen est omen

Frank Jäger