ALKIS-Daten einlesen: Unterschied zwischen den Versionen

Aus kvwmap
Wechseln zu: Navigation, Suche
(Skript-Ablauf)
 
(15 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Dies ist ein Vorschlag für den Ablauf einer automatischen Fortführung der ALKIS-Daten.
 
  
 +
Zum Einlesen der NAS-Daten kann das Shell-Skript '''import_nas.sh''' im Ordner plugins/alkis/tools verwendet werden. Mit dem Skript werden die NAS-Daten transaktional in die PostGIS-DB eingelesen.
  
Es gibt "irgendwo" auf dem Server einen Ordner mit folgendem Inhalt:
 
  
:/eingang
+
==Voraussetzungen==
:/eingelesen
+
:/postprocessing
+
:/sicherung
+
:/temp
+
:start_ff.sh
+
:ff.log
+
:ff.err
+
  
Im Ordner "eingang" werden die gezippten NAS-Fortführungsdaten, die eingelesen werden sollen, abgelegt (Katalog- und Objektdaten). Dies sollte am besten auch automatisiert ablaufen.
+
* Zum Einlesen des vollständigen ALKIS-Datenschemas muss GDAL mindestens in der Version gdal - Revision 39969 vom /trunk/gdal verwendet werden. ([http://trac.wheregroup.com/PostNAS/wiki/BuildingOgrPostNASDriver Anleitung])  
 +
* Wer zum Einlesen einen Docker-Container verwendet muss das Image
 +
pkorduan/gdal-sshd:2.3.1
 +
in der Version 2.3.1, höher oder latest verwenden. Im Kontext der Docker Container von kvwmap-server wird die Image-Version in der Datei:
 +
/home/gisadmin/etc/gdal/env_and_volumes
 +
im Parameter
 +
GDAL_IMAGE_VERSION
 +
eingestellt. Anschließend kann der Container neu erstellt werden mit dem Befehl:
 +
dcm rerun gdal
  
Wenn das Shell-Skript "start_ff.sh" ausgeführt wird, guckt es im Ordner "eingang" nach, ob dort Zip-Dateien liegen. Diese werden nacheinander abgearbeitet. Jede Zip-Datei wird im Ordner "temp" ausgepackt und die enthaltenen NAS-Dateien werden über ogr2ogr in die PostGIS-DB eingelesen. Das Einlesen wird als Transaktion durchgeführt (kein -skipfailures) und in der Datei "ff.log" geloggt.
+
== Skript-Konfiguration ==
 +
 
 +
Das Skript erwartet eine Konfigurationsdatei '''config.sh''' im Ordner plugins/alkis/config. Diese kann auf Basis der '''config-default.sh''' im selben Ordner erstellt werden.
 +
In der config.sh müssen insbesondere 4 Pfad-Variablen gesetzt werden:
 +
 
 +
DATA_PATH="/var/www/data/alkis/ff/eingang"                      # der Daten-Eingangsordner; hier werden die Zip-Dateien mit den NAS-Daten abgelegt
 +
IMPORT_PATH="/var/www/data/alkis/ff/import"                    # der Import-Ordner; hier befinden sich die ausgepackten NAS-Dateien und die zu importierende SQL-Datei
 +
LOG_PATH="/var/www/data/alkis/ff/logs"                          # der Logs-Ordner; hier findet das Error-Logging statt
 +
POSTPROCESSING_PATH="/var/www/data/alkis/ff/postprocessing";    # in diesem Ordner können Postprocessing-SQL-Skripte abgelegt werden, die nach jedem Einlesevorgang ausgeführt werden sollen
 +
 
 +
== GFS-Template ==
 +
 
 +
Die Variable GFS_TEMPLATE in der config.sh muss nicht angepasst werden. Hier wird die GFS-Datei "../config/alkis-schema.gfs" verwendet. Diese GFS-Datei wird beim Einlesevorgang mit ogr2ogr verwendet. Sie erfüllt 2 Aufgaben:
 +
 
 +
* Durch die Abbildung des komplexen ALKIS-Datenmodells auf das flache PostNAS-Datenmodell kommt es bei einigen Attributen zu doppelten Bezeichnungen. Damit die NAS-Daten mit ogr2ogr korrekt in das vollständige PostNAS-Schema eingelesen werden können, wurden diese Attributnamen im PostNAS-Schema umbenannt. Die GFS-Datei beschreibt für alle Attribute die Abbildung des NAS-Element-Pfades auf den (möglicherweise umbenannten) Attributnamen.
 +
* Außerdem definiert die GFS-Datei für jedes Attribut den Datentyp mit dem ogr2ogr die Daten in die Datenbank einlesen soll. Würde das nicht erfolgen, würde OGR den Datentyp automatisch an Hand der NAS-Daten ermitteln. Dabei kann es vorkommen, dass z.B. führende Nullen abgeschnitten werden o.ä.
 +
 
 +
Die GFS-Datei wurde mit dem Tool [https://github.com/pkorduan/xmi2db xmi2db] auf Basis des [http://gdi-service.de/xmi2db/xmis/2016-04-01_ImplModell_AAA-xmi12-uml14.xmi AAA-Implementierungsmodells] erzeugt.
 +
 
 +
== Ablage der NAS-Dateien ==
 +
 
 +
Wenn die NAS-Dateien gezippt sind, muss man sie im Ordner "eingang" ablegen. Hat man ungezippte NAS-Dateien, müssen diese im Ordner "import" abgelegt werden.
 +
 
 +
== Skript-Aufruf ==
 +
 
 +
Das Einlese-Skript import_nas.sh muss vom gdal-Container aus gestartet werden. D.h. man wechselt zunächst mit "dcm console gdal" in den Container und ruft das Skript dann auf.
 +
Wenn das alkis-Schema schon mit Daten befüllt ist, die man nun mit einer neuen Grundausstattung ersetzen möchte, muss man den Parameter "delete" anhängen. Dadurch wird vor dem Einleseprozess die DB-Funktion alkis.delete_object_tables() ausgeführt, die alle Objekttabellen leert. Dies geschieht auch innerhalb der Transaktion, sodass der Datenbestand nicht verloren gehen kann.
 +
 
 +
== Skript-Ablauf ==
 +
 
 +
Wenn das Shell-Skript "import_nas.sh" ausgeführt wird, prüft es zunächst, ob der Ordner "import" leer ist. Wenn ja, guckt es im Ordner "eingang" nach, ob dort Zip-Dateien liegen. Alle vorhandenen Zip-Dateien werden in den Ordner "import" ausgepackt und danach gelöscht. Jede NAS-Datei im Ordner "import" wird mit ogr2ogr zunächst in eine temporäre SQL-Datei konvertiert. Wenn diese Konvertierung erfolgreich war, wird der Inhalt der SQL-Datei zu einer SQL-Datei "import_transaction.sql" im Ordner "import" hinzugefügt und die NAS-Datei sowie die entstandene SQL-Datei gelöscht. In der SQL-Datei "import_transaction.sql" werden die SQL-Befehle aller NAS-Dateien gesammelt, um sie am Ende transaktional ausführen zu können. Wenn alle NAS-Dateien erfolgreich konvertiert wurden, wird die SQL-Datei "import_transaction.sql" ausgeführt und die Daten in die PostGIS-DB eingelesen. Wenn dies erfolgreich war, wird der Ordner "import" geleert.
 +
 
 +
== Logging der eingelesenen NAS-Dateien ==
  
 
Im Schema "alkis" gibt es eine Tabelle "import" mit folgender Struktur:
 
Im Schema "alkis" gibt es eine Tabelle "import" mit folgender Struktur:
Zeile 30: Zeile 62:
 
  );
 
  );
  
Hier wird jeder Einlesevorgang registriert und das Ergebnis (ok oder Fehler) im Feld "status" abgelegt.
+
Hier wird jede eingelesene NAS-Datei registriert. Diese Tabelle dient einerseits als Übersicht, was alles eingelesen wurde und andererseits wird durch das Einlese-Skript vor der Abarbeitung jeder NAS-Datei auch überprüft, ob eine Datei schon mal eingelesen wurde.
 +
 
 +
== Fehlerbehebung ==
 +
 
 +
Wenn bei der Konvertierung einer NAS-Datei ein Fehler aufgetreten ist, bricht das Einlese-Skript ab. Die Fehlermeldung von ogr2ogr steht in der Datei logs/error.log. Der Fehler kann in der fehlerhaften NAS-Datei behoben werden. Danach kann das Einlese-Skript einfach nochmal gestartet werden. Es beginnt mit der Konvertierung der zuvor fehlerhaften NAS-Datei. Alternativ kann auch der Ordner "import" geleert werden und eine neue, korrigierte Zip-Datei in den Ordner "eingang" gelegt werden.
 +
 
 +
Wenn bei der Ausführung der SQL-Datei "import_transaction.sql" ein Fehler auftritt (Fehlermeldung auch in logs/error.log), kann dieser entweder in "import_transaction.sql" behoben werden oder evtl. auch durch Änderungen am Datenbestand in der Datenbank. Danach kann das Skript einfach nochmal aufgerufen werden. Alternativ kann auch hier der Ordner "import" geleert werden und eine neue, korrigierte Zip-Datei in den Ordner "eingang" gelegt werden.
 +
 
 +
== Post-Processing ==
 +
 
 +
Wenn die SQL-Datei "import_transaction.sql" erfolgreich eingelesen wurde, wird die Funktion "'''alkis.postprocessing()'''" aufgerufen. Diese Funktion füllt die PP-Tabellen im Alkis-Schema. Eigene Post-Processing-Skripte können im Ordner postprocessing abgelegt werden. Diese werden am Ende nacheinander ausgeführt.
 +
 
 +
 
 +
Das Skript "import_nas.sh" wird per Cron-Job einmal täglich automatisch ausgeführt, kann bei Bedarf aber auch händisch gestartet werden.
  
Diese Tabelle dient einerseits als Übersicht, was alles eingelesen wurde und andererseits kann damit verhindert werden, dass eine Datei doppelt eingelesen wird.
 
  
Tritt bei einer Datei ein Fehler auf (ff.err), wird nicht weiter eingelesen, sondern eine "Meldung"(?) an den Administrator gesendet.
 
  
Wenn ein Fehler aufgetreten ist, muss dieser in der fehlerhaften NAS-Datei behoben werden oder bei Bedarf evtl. auch im PostNAS-Schema. Danach muss die Error-Logdatei ff.err gelöscht und das Skript erneut gestartet werden. Bereits eingelesene NAS-Dateien werden übersprungen.
 
  
Wenn alle NAS-Dateien der Zip-Datei fehlerfrei eingelesen wurden, wird die Zip-Datei in den Ordner "eingelesen" verschoben.
+
== 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.<br>
 +
Beispiel:
  
Nachdem alle Zip-Dateien im Ordner "eingang" fehlerfrei eingelesen wurden, werden alle Skripte, die sich im Ordner "postprocessing" befinden, nacheinander ausgeführt.
+
xmllint --nowarning --noout --schema pfad_zum_schema/NAS_6.0.1/schema/NAS-Operationen.xsd pfad_zu_nas/beispiel.xml
  
Optional kann das Skript "start_ff.sh" vor jedem Einlesen auch eine Sicherung des Schemas "alkis" im Ordner "sicherung" ablegen.
+
Das Tool '''xmllint''' wird über das Paket libxml2-utils unter linux zur Verfügung gestellt. Es ist eine aktuelle Version ab 2.9 erforderlich.<br>
 +
Das Ergebnis der Prüfung wird mit "validates" oder eine detailierte Fehlermeldung und "fails to validate" ausgegeben.<br>
 +
Das notwendige Schema kann auf den Seiten der ADV als ZIP heruntergeladen und dann lokal entpackt installiert werden.<br>
 +
Link zum Schema: [http://www.adv-online.de/icc/extdeu/med/704/70425220-0746-2210-3ca0-c0608a438ad1,11111111-1111-1111-1111-111111111111 NAS 6.0.1]
  
Das Skript "start_ff.sh" wird per Cron-Job einmal täglich automatisch ausgeführt, kann bei Bedarf aber auch händisch gestartet werden.
+
Wichtig: Es sollten nur valide Daten eingespielt werden!

Aktuelle Version vom 26. Februar 2021, 09:39 Uhr

Zum Einlesen der NAS-Daten kann das Shell-Skript import_nas.sh im Ordner plugins/alkis/tools verwendet werden. Mit dem Skript werden die NAS-Daten transaktional in die PostGIS-DB eingelesen.


Voraussetzungen

  • Zum Einlesen des vollständigen ALKIS-Datenschemas muss GDAL mindestens in der Version gdal - Revision 39969 vom /trunk/gdal verwendet werden. (Anleitung)
  • Wer zum Einlesen einen Docker-Container verwendet muss das Image
pkorduan/gdal-sshd:2.3.1

in der Version 2.3.1, höher oder latest verwenden. Im Kontext der Docker Container von kvwmap-server wird die Image-Version in der Datei:

/home/gisadmin/etc/gdal/env_and_volumes

im Parameter

GDAL_IMAGE_VERSION

eingestellt. Anschließend kann der Container neu erstellt werden mit dem Befehl:

dcm rerun gdal

Skript-Konfiguration

Das Skript erwartet eine Konfigurationsdatei config.sh im Ordner plugins/alkis/config. Diese kann auf Basis der config-default.sh im selben Ordner erstellt werden. In der config.sh müssen insbesondere 4 Pfad-Variablen gesetzt werden:

DATA_PATH="/var/www/data/alkis/ff/eingang"                      # der Daten-Eingangsordner; hier werden die Zip-Dateien mit den NAS-Daten abgelegt
IMPORT_PATH="/var/www/data/alkis/ff/import"                     # der Import-Ordner; hier befinden sich die ausgepackten NAS-Dateien und die zu importierende SQL-Datei
LOG_PATH="/var/www/data/alkis/ff/logs"                          # der Logs-Ordner; hier findet das Error-Logging statt
POSTPROCESSING_PATH="/var/www/data/alkis/ff/postprocessing";    # in diesem Ordner können Postprocessing-SQL-Skripte abgelegt werden, die nach jedem Einlesevorgang ausgeführt werden sollen

GFS-Template

Die Variable GFS_TEMPLATE in der config.sh muss nicht angepasst werden. Hier wird die GFS-Datei "../config/alkis-schema.gfs" verwendet. Diese GFS-Datei wird beim Einlesevorgang mit ogr2ogr verwendet. Sie erfüllt 2 Aufgaben:

  • Durch die Abbildung des komplexen ALKIS-Datenmodells auf das flache PostNAS-Datenmodell kommt es bei einigen Attributen zu doppelten Bezeichnungen. Damit die NAS-Daten mit ogr2ogr korrekt in das vollständige PostNAS-Schema eingelesen werden können, wurden diese Attributnamen im PostNAS-Schema umbenannt. Die GFS-Datei beschreibt für alle Attribute die Abbildung des NAS-Element-Pfades auf den (möglicherweise umbenannten) Attributnamen.
  • Außerdem definiert die GFS-Datei für jedes Attribut den Datentyp mit dem ogr2ogr die Daten in die Datenbank einlesen soll. Würde das nicht erfolgen, würde OGR den Datentyp automatisch an Hand der NAS-Daten ermitteln. Dabei kann es vorkommen, dass z.B. führende Nullen abgeschnitten werden o.ä.

Die GFS-Datei wurde mit dem Tool xmi2db auf Basis des AAA-Implementierungsmodells erzeugt.

Ablage der NAS-Dateien

Wenn die NAS-Dateien gezippt sind, muss man sie im Ordner "eingang" ablegen. Hat man ungezippte NAS-Dateien, müssen diese im Ordner "import" abgelegt werden.

Skript-Aufruf

Das Einlese-Skript import_nas.sh muss vom gdal-Container aus gestartet werden. D.h. man wechselt zunächst mit "dcm console gdal" in den Container und ruft das Skript dann auf. Wenn das alkis-Schema schon mit Daten befüllt ist, die man nun mit einer neuen Grundausstattung ersetzen möchte, muss man den Parameter "delete" anhängen. Dadurch wird vor dem Einleseprozess die DB-Funktion alkis.delete_object_tables() ausgeführt, die alle Objekttabellen leert. Dies geschieht auch innerhalb der Transaktion, sodass der Datenbestand nicht verloren gehen kann.

Skript-Ablauf

Wenn das Shell-Skript "import_nas.sh" ausgeführt wird, prüft es zunächst, ob der Ordner "import" leer ist. Wenn ja, guckt es im Ordner "eingang" nach, ob dort Zip-Dateien liegen. Alle vorhandenen Zip-Dateien werden in den Ordner "import" ausgepackt und danach gelöscht. Jede NAS-Datei im Ordner "import" wird mit ogr2ogr zunächst in eine temporäre SQL-Datei konvertiert. Wenn diese Konvertierung erfolgreich war, wird der Inhalt der SQL-Datei zu einer SQL-Datei "import_transaction.sql" im Ordner "import" hinzugefügt und die NAS-Datei sowie die entstandene SQL-Datei gelöscht. In der SQL-Datei "import_transaction.sql" werden die SQL-Befehle aller NAS-Dateien gesammelt, um sie am Ende transaktional ausführen zu können. Wenn alle NAS-Dateien erfolgreich konvertiert wurden, wird die SQL-Datei "import_transaction.sql" ausgeführt und die Daten in die PostGIS-DB eingelesen. Wenn dies erfolgreich war, wird der Ordner "import" geleert.

Logging der eingelesenen NAS-Dateien

Im Schema "alkis" gibt es eine Tabelle "import" mit folgender Struktur:

CREATE TABLE alkis.import
(
 id serial NOT NULL,
 datum timestamp without time zone DEFAULT now(),
 datei text,
 status text
)
WITH(
 OIDS=TRUE
);

Hier wird jede eingelesene NAS-Datei registriert. Diese Tabelle dient einerseits als Übersicht, was alles eingelesen wurde und andererseits wird durch das Einlese-Skript vor der Abarbeitung jeder NAS-Datei auch überprüft, ob eine Datei schon mal eingelesen wurde.

Fehlerbehebung

Wenn bei der Konvertierung einer NAS-Datei ein Fehler aufgetreten ist, bricht das Einlese-Skript ab. Die Fehlermeldung von ogr2ogr steht in der Datei logs/error.log. Der Fehler kann in der fehlerhaften NAS-Datei behoben werden. Danach kann das Einlese-Skript einfach nochmal gestartet werden. Es beginnt mit der Konvertierung der zuvor fehlerhaften NAS-Datei. Alternativ kann auch der Ordner "import" geleert werden und eine neue, korrigierte Zip-Datei in den Ordner "eingang" gelegt werden.

Wenn bei der Ausführung der SQL-Datei "import_transaction.sql" ein Fehler auftritt (Fehlermeldung auch in logs/error.log), kann dieser entweder in "import_transaction.sql" behoben werden oder evtl. auch durch Änderungen am Datenbestand in der Datenbank. Danach kann das Skript einfach nochmal aufgerufen werden. Alternativ kann auch hier der Ordner "import" geleert werden und eine neue, korrigierte Zip-Datei in den Ordner "eingang" gelegt werden.

Post-Processing

Wenn die SQL-Datei "import_transaction.sql" erfolgreich eingelesen wurde, wird die Funktion "alkis.postprocessing()" aufgerufen. Diese Funktion füllt die PP-Tabellen im Alkis-Schema. Eigene Post-Processing-Skripte können im Ordner postprocessing abgelegt werden. Diese werden am Ende nacheinander ausgeführt.


Das Skript "import_nas.sh" wird per Cron-Job einmal täglich automatisch ausgeführt, kann bei Bedarf aber auch händisch gestartet werden.



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!