das vollständige PostNAS-Datenmodell: Unterschied zwischen den Versionen
Rahn (Diskussion | Beiträge) (→Erstellung eines PostNAS-Schemas) |
Rahn (Diskussion | Beiträge) |
||
Zeile 27: | Zeile 27: | ||
:*[http://www.kvwmap.de/alkis/complete/7_nutzungsart_definition.sql 7_nutzungsart_definition.sql] Postprocessing-Tabellen für die Nutzungen - Stand: 02.10.2015 | :*[http://www.kvwmap.de/alkis/complete/7_nutzungsart_definition.sql 7_nutzungsart_definition.sql] Postprocessing-Tabellen für die Nutzungen - Stand: 02.10.2015 | ||
− | :*[http://www.kvwmap.de/alkis/complete/8_sichten.sql 8_sichten.sql] Sichten (werden nur für die Layerdefinitionen benötigt) - Stand: 03.04.2017 | + | :*[http://www.kvwmap.de/alkis/complete/8_sichten.sql 8_sichten.sql] Sichten (werden nur für die [[Gruppen_und_Themen_für_ALKIS|Layerdefinitionen]] benötigt) - Stand: 03.04.2017 |
== Einspielen der NAS-Daten == | == Einspielen der NAS-Daten == |
Version vom 3. April 2017, 14:23 Uhr
Auf dieser Seite wird beschrieben, wie man das vollständige PostNAS-Datenmodell erzeugt und einrichtet, NAS-Daten einspielt und mit kvwmap darauf zugreifen kann.
Inhaltsverzeichnis
Voraussetzungen
- ein aktuelles GDAL (Anleitung)
- libxml-ruby
Erstellung eines PostNAS-Schemas
Das in dieser Anleitung verwendete PostNAS-Basisschema wurde mit dem Tool xmi2db auf Basis des AAA-Implementierungsmodells erzeugt. Bei Bedarf kann mit xmi2db auch selbst ein Schema erzeugt und verwendet werden. Für die Verwendung mit kvwmap muss das Schema "alkis" heißen.
- Das Datenbankschema wird erstellt, indem die nachfolgenden SQL-Dateien ausgeführt werden. Diese sind in der nachstehenden Reihenfolge auszuführen.
- 1_complete_alkis_schema.sql das mit xmi2db erstellte Basisschema - Stand: 02.02.2017
- 2_alkis_indizes.sql Indizes für die performante Abfrage der Daten - Stand: 22.03.2017
- 3_alkis-functions.sql Funktionen - Stand: 23.01.2017
- 4_weitere_keytables.sql weitere Schlüsseltabellen - Stand: 23.01.2017
- 5_weitere_tables.sql weitere Tabellen - Stand: 23.01.2017
- 6_pp_definition.sql Postprocessing-Tabellen - Stand: 23.01.2017
- 7_nutzungsart_definition.sql Postprocessing-Tabellen für die Nutzungen - Stand: 02.10.2015
- 8_sichten.sql Sichten (werden nur für die Layerdefinitionen benötigt) - Stand: 03.04.2017
Einspielen der NAS-Daten
Umbenennungsskript
Damit die NAS-Daten mit OGR korrekt in das vollständige PostNAS-Schema eingelesen werden können, müssen vorher bestimmte Attribute in den NAS-Dateien umbenannt werden. Diese Umbenennung erfolgt mit dem Ruby-Skript rename_nas.rb aus dem xmi2db-Projekt. Welche Attribute wie umbenannt werden sollen, wird durch eine Umbenennungsliste definiert. Die zum aktuellen Schema passende Umbennungsliste befindet sich in conf/samples/umbenenn_conf.json. Damit das Umbenennungsskript diese Liste verwenden kann, muss sie einfach einen Ordner höher in conf/ abgelegt werden.
GFS-Template
Damit OGR die Daten aus den NAS-Dateien mit dem korrekten Datentyp in die Datenbank einliest, wird eine gfs-Datei verwendet, die das komplette ALKIS-Schema abbildet. Diese gfs-Datei wurde auch mit xmi2db auf Basis des AAA-Implementierungsmodells erzeugt.
- alkis_template.gfs GFS-Template - Stand: 02.02.2017
Wenn diese GFS-Datei nicht verwendet wird, ermittelt OGR den Datentyp automatisch an Hand der NAS-Daten. Dabei kann es vorkommen, dass z.B. führende Nullen abgeschnitten werden o.ä.
Einleseskript
Hat man das Umbenennungsskript, die Umbenennungsliste und das GFS-Template auf seinem Server abgelegt, kann der Einlesevorgang beginnen. Folgendes einfaches Einleseskript kann dafür verwendet werden.
- import_nas.sh Einleseskript - Stand: 02.02.2017
- Das Einleseskript durchläuft alle NAS-Dateien im angegebenen Ordner und benennt sie mit Hilfe des Umbenennungsskripts um. Die umbenannte Version der NAS-Datei wird als ..._renamed.xml neben der originalen NAS-Datei abgelegt.
- Dann wird eine Kopie des GFS-Templates dort abgelegt. Sie heißt genauso, wie die umbenannte NAS-Datei (..._renamed.gfs).
- Anschliessend wird ogr2ogr aufgerufen, um die umbenannte NAS-Datei einzulesen.
- Danach wird die umbenannte NAS-Datei wieder gelöscht.
Postprocessing
Nach dem Einlesen der Daten müssen die folgenden beiden Postprocessing-Skripte ausgeführt werden:
- pp_laden.sql Postprocessing - Stand: 26.01.2017
- nutzungsart_laden.sql Postprocessing Nutzungen - Stand: 23.01.2017
Prüfung von NAS-Dateien auf Validität mit xmllint
Vor dem Einlesen der Daten ist eine Prüfung der NAS-Dateien mit xmllint auf Validität gegen das Schema NAS 6.0.1 der ADV zu empfehlen.
Beispiel:
xmllint --nowarning --noout --schema pfad_zum_schema/NAS_6.0.1/schema/NAS-Operationen.xsd pfad_zu_nas/beispiel.xml
Das Tool xmllint wird über das Paket libxml2-utils unter linux zur Verfügung gestellt. Es ist eine aktuelle Version ab 2.9 erforderlich.
Das Ergebnis der Prüfung wird mit "validates" oder eine detailierte Fehlermeldung und "fails to validate" ausgegeben.
Das notwendige Schema kann auf den Seiten der ADV als ZIP heruntergeladen und dann lokal entpackt installiert werden.
Link zum Schema: NAS 6.0.1
Wichtig: Es sollten nur valide Daten eingespielt werden!
Zugriff mit kvwmap
Layerdefinitionen
Hier findet man die Gruppen und Themen für ALKIS
Mapdatei
- alkis.map Stand 15.08.2014
Testdaten
Zum Testen eigenen sich NAS-Daten aus der DHK, die aus einem NBA-Verfahren stammen. Wer noch keine eigenen NBA-Daten hat, kann zunächst mit Testdaten arbeiten. Erfolgreich getestet wurden Daten aus MV vom LAiV und Daten aus Brandenburg, die auch in EPSG 25833 liegen.
Testdaten:
- ALKIS®-Beispieldaten Brandenburg: [1]
- ALKIS®-Beispieldaten Mecklenburg-Vorpommern vom LAiV: [2]
- Hier findet man Beispieldaten zum Testen (kostenlos).