[PostNAS] Metadaten zu Nutzungsarten

[Jäger, Frank (KRZ)]

Hallo,
eine Fehlerquelle im Post-Processing zu den Meta- und Schlüsseldaten der ALKIS-Nutzungsarten habe ich gefunden und beseitigt:

Für die Präsentation der Ebene "alle Nutzungsarten" im WMS werden die Daten aus 26 verschiedenen Tabellen eingesammelt und in einer gemeinsamen Tabelle "nutzung" zusammen gefasst.
Die Verbindung von "nutzung" zur Schlüsseltabelle besteht aus der Spalte "nutz_id", die die Herkunfts-Tabelle nummeriert und der Spalte "class", die aus verschiedenen Spalten der unterschiedlichen Herkunfts-Tabellen gefüllt wird.
Z.B. "nutz_id"=1 ist der Import aus "ax_wohnbauflaeche". Dort wird class aus "Art der Bebauung" gefüllt. Die Info über diese Strukturen findet man in "nutzung_meta".

Um die Inhalte von "nutzung" entschlüsseln zu können, wird die Schlüssel-Tabelle "nutzung_class" per SQL-Script aufgebaut. Dazu wurden die Bedeutungen aus der GeoInfoDok abgeschrieben.
Dort ist z.B. der nutz_id=1 (Wohnbaufläche) und der class=1000 die "Art der Bauung" = 'Offen' zugewiesen.

Bisher nicht berücksichtigt wurde die Tatsache, dass das Feld, aus dem Class gefüllt wird, nicht immer einen der in der GeoInfoDok beschriebenen Werte enthält. Teilweise ist das Quellfeld und somit nutzung.class leer, also "IS NULL".

Wenn man dann in SQL eine Equivalanzabfrage ("FROM nutzung JOIN nutzung_class ON ...") verwendet, werden aus "nutzung" die Fälle unterschlagen, die eine leere "class"-Spalte haben.


Lösung:

1. Da NULL in einem Integer-Feld ungeeignet ist, wird dieser Fall durch den Wert (num.) "0" abgedeckt. 
2. Im SQL-Script wird nun für jeden Tabellen-Typ (nutz_id) in "nutzung_class" auch ein Wert mit "nutzung_class.class"=0 geladen.
3. Beim Kopieren der Inhalte von den 26 Tabellen nach "nutzung" wird "class IS NULL" durch class=0 ersetzt (Function coalesce)
4. (In Zukunft ..) fehlende Werte werden aus den konvertierten Daten in die Schlüsseltabelle geladen damit sie in Equivalenzabfragen erscheinen.

Sauberer wäre ein Foreign-Key-Constraint von nutzung auf nutzung_class. Dies würde bei fehlenden Werten aber zu einem Abbruch des PostProcessing führen.

Die geänderten Scripte für PostgreSQL habe ich ins PostNAS-SVN hoch geladen.

PS
Mein Windows-Arbeitsplatz kommuniziert mit dem PostNAS-SVN über das Tool "TortoiseSVN" Vers. 1.7.7.
Dies hatte ich auf die aktuelle Version 1.8.3 aktualisiert. Das hatte zur Folge, dass keine Kommunikation mehr mit dem PostNAS-SVN zustande kam (https, Schreibrechte). Das GDAL-SVN (http, Leserechte) konnte ich weiter problemlos auschecken.
Die Fehlersuche (Proxy usw.) im Client war erfolglos. Ich habe nun wieder die Version 1.7.7., damit funktioniert es wieder.
Hat jemand ähnliche Erfahrungen gemacht? Wer weiß, woran das liegt?


Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7618 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20131126/2c970dc3/attachment.bin>