das vollständige PostNAS-Datenmodell: Unterschied zwischen den Versionen

Version vom 2. Februar 2017, 15:32 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.

Voraussetzungen

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: 17.01.2017

• 2_alkis_indizes.sql     Indizes für die performante Abfrage der Daten - Stand: 20.01.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

Sichten todo

Einspielen der NAS-Daten

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.

./ogr2ogr -f "PostgreSQL" --config PG_USE_COPY YES -skipfailures -nlt CONVERT_TO_LINEAR -append PG:"dbname=<POSTNASDB> active_schema=alkis user=<DBUSER> host=localhost port=5432" -a_srs EPSG:25833  /PFAD/ZU/DEN/NASDATEN.XML 2>> postnas_err.log

wobei <POSTNASDB> durch den Datenbanknamen, <DBUSER> durch den Datenbanknutzer und /PFAD/ZU/DEN/NASDATEN durch den Pfad zu den NAS-Daten ersetzt werden muss, die Option PG_USE_COPY YES bringt erhebliche Performance Vorteile durch Verwendung von copy stattt insert-Kommandos.

Läuft kvwmap im docker Container wird ogr2ogr auch in einem separaten Container ausgeführt. Das erspart die aufwendige Nachinstallation von ogr2ogr mit den neuesten Bibliotheken. Verwendet wird hier das Image geodata/gdal Das Image wird beim installieren des kvwmap containers mit runtergeladen und steht, wenn das Datenverzeichnis gemountet und die Datenbank gelinkt ist direkt zur Verfügung. ogr2ogr im Container wird wie folgt aufgerufen:

docker run --rm --volumes-from wwwdata --link pgsql-server:pgsql geodata/gdal /bin/bash -c "ogr2ogr -f PostgreSQL --config PG_USE_COPY YES -skipfailures -nlt CONVERT_TO_LINEAR -append PG:\"dbname=<POSTNASDB> active_schema=alkis user=<DBUSER> host=pgsql\" -a_srs EPSG:25833  /PFAD/ZU/DEN/NASDATEN.XML 2>> /var/www/logs/postnas_err.log"

Der ogr-Befehl ist identisch, nur dass alle doppelten Anführungsstrichte mit Backslash escaped werden müssen, weil der ganze Befehl ja schon in doppelten Anführungsstrichen ist.

Damit Bogen-Geometrien (<gml:Arc>) in lineare Geometrien umgewandelt werden, ist auf manchen Servern der Paramter "-nlt CONVERT_TO_LINEAR" notwendig, auf anderen Servern macht ogr2ogr das offenbar standardmäßig. Bei der Umwandlung wird der Bogen durch einen Linienzug approximiert. Leider geht dadurch aber die Topologie verloren, d.h. 2 angrenzende Objekte haben nun kleine Lücken und überlappen sich teilweise...

Achtung: Falls es auf dem Server bereits ein anderes gdal gibt, kann es beim Ausführen von ogr2ogr zu Fehlern kommen. Ist auf dem Server z.B FGS installiert, so kann es sein, dass das gdal von FGS benutzt wird, was dann natürlich nicht funktioniert. Man kann das auch nachprüfen, indem man

ldd /pfad_zu_meinem_gdal/gdal-trunk/bin/ogr2ogr

ausführt und sich anschaut, auf welches gdal gelinkt wird. Falls dort nicht auf das PostNAS-gdal gelinkt wird, muss man, bevor man ogr2ogr aufruft, den Library-Path entsprechend setzen:

export LD_LIBRARY_PATH=/pfad_zu_meinem_gdal/gdal-trunk/lib64

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!

Zur Batchverarbeitung mehrer NAS-Dateien in einem Verzeichnis kann folgendes Script eingesetzt werden:

#!/bin/sh
liste=`find /pfad_zu_nas_dateien/*.xml`
set $liste
>xml_batch.sh
for i do :
string='/pfad_zu_gdal/ogr2ogr -f PostgreSQL --config PG_USE_COPY YES -skipfailures -append PG:"dbname=kvwmapsp active_schema=alkis user=kvwmap host=localhost port=5432" -a_srs EPSG:25833 '${i}' '
echo $string
echo $string >>xml_batch.sh
done

Anschließend die Datei xml_bath.sh ausführbar machen und ausführen.

Die Verarbeitung des Grunddatenbestandes ist sehr zeitaufwändig und rechenintensiv. Es ist ratsam vorher die postgres DB zu "tunen", falls das noch nicht erfolgt ist. Hinweise dazu finden sich zahlreich im Netz.

Der Grunddatenbestand eines ganzen Landkreises (hier LUP) kann durchaus ein Datenvolumen von 20 GB NAS ergeben. Bei einer Verarbeitungsgeschwindigkeit von ca. 400 bis 500 MB pro Stunde ist der Server schon mal zwei ganze Tage beschäftigt. Bei einem Test mit vier OGR2OGR Prozessen parallel sind keine Probleme aufgetreten und die Verarbeitung lief etwa in der Hälfte der Zeit, wobei der Server aber schon deutlich belastet war. Die Parallelverarbeitung sollte noch eingehend gestestet werden.

Es ist wichtig die Log-Dateien nach der Verarbeitung eingehend zu prüfen! Die zahlreichen Warnungen wie z.B.:

"Warning 1: NAS: Overwriting other geometry (DEMVAL76000EjGty)" 

sind wohl nicht relevant (???).

Nach dem Einlesen der Daten müssen die folgenden beiden Skripte ausgeführt werden:

• pp_laden_ohne_alkis_beziehungen.sql Stand 10.03.2016
• nutzungsart_laden.sql     Stand 02.10.2015

Zugriff mit kvwmap

Umstellung von ALB/ALK auf ALKIS

Um in kvwmap alle katasterbezogenen Komponenten von ALK/ALB auf ALKIS umzustellen, muss man nur einige Parameter in der config.php setzen:

$pgdbname='kvwmapsp';                                 // muss auf die DB gesetzt werden, die das Schema "alkis" enthält
define('ALKIS', true);                                // muss auf true gesetzt werden
define("LAYERNAME_FLURSTUECKE",'Flurstuecke_Alkis');  // muss auf den neuen ALKIS-Flurstückslayer gesetzt werden
define('EPSGCODE_ALKIS','25833');                     // muss auf 25833 gesetzt werden

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).