Installation von PostNAS und Zugriff mit kvwmap

Aus kvwmap
Version vom 30. August 2017, 09:13 Uhr von Rahn (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche


! Diese Anleitung bezieht sich auf das alte, unvollständige PostNAS-Schema aus dem PostNAS-Projekt. Ab kvwmap Version 2.8 wird ein anderes, vollständiges Schema verwendet.


Auf dieser Seite wird beschrieben, wie man PostNAS installiert, eine PostNAS-Datenbank einrichtet, NAS-Daten einspielt und mit kvwmap darauf zugreifen kann. Die PostNAS-Anleitung entspricht dabei im Großen und Ganzen der Anleitung der PostNAS-Entwickler und unterscheidet sich aber doch in einigen Punkten, z.B. die Abbildung der Nutzungsarten, und die konsequente Auslegung auf Vollhistorie.

PostNAS installieren

Systemvoraussetzungen

  • gcc, PostgreSQL-devel, Xerces, PROJ und GEOS - kann man unter OpenSuse alles über yast installieren


GDAL/OGR bauen und installieren

  • Code beziehen:

Den aktuellen Code kann man über svn herunterladen. Dazu benötigt man aber subversion. Das Clientprogramm kann man unter Debian mit folgendem Befehl installieren. 

apt-get install subversion

Das Verzeichnis mit der aktuellen Version von gdal bekommt man schließlich mit folgendem Befehl heruntergeladen (ausgechecked) 

 svn checkout http://svn.osgeo.org/gdal/trunk/gdal

Wer kein svn hat bzw. Schwierigkeiten mit subversion das Verzeichnis auszuchecken, kann das auch auf einem beliebigen anderen Rechner machen. Das erhaltene Verzeichnis packen und auf seinen eigenen Server übertragen. SVN macht nichts weiter als die Dateien runterholen und für eine Versionsverwaltung vorbereiten. Wenn man nichts entwickeln will, also nichts am Code ändern will, braucht man die Versionsverwaltung nicht. Mit anderen Worten, wenn man das Verzeichnis mit svn ausgecheckt hat, kann man anschließend das versteckte Verzeichnis ".svn" löschen und ".gitignore" gleich mit. 

rm .svn .gitignore
  • Konfigurieren und kompilieren 
./configure --with-xerces=yes --with-xerces-inc=/usr/include/xercesc/ --with-static-proj4 --with-xerces-lib="-L/usr/include/xercesc -lxerces-c -lpthread"  
make
  • Installation mit root-Rechten: 
 sudo make install
  • Installationsverzeichnis bereinigen 
 sudo make clean

Erstellung eines PostNAS-Schemas

Datenbank

  • Die PostNAS-Tabellen und -Sichten werden in einem extra Datenbank-Schema "alkis" angelegt. Es kann somit die bestehende PostGIS-Datenbank von kvwmap verwendet werden. Oder man legt eine neue PostGIS-Datenbank mit Encoding UTF8 und einem postgis_template als Vorlage an. Zum Testen der verschiedenen Fachschalen und anderen Komponenten mit Katasterbezug empfiehlt es sich aber, eine bestehende kvwmap-Datenbank (oder eine Kopie davon) mit den darin enthaltenen Fachschalen-Tabellen zu verwenden.

Datenbankschema erstellen

  • Ein Datenbankschema für ALKIS-Daten setzt sich derzeit aus verschiedenen Komponenten zusammen. Die Bestandteile des Schemas sind nachfolgend in SQL-Dateien aufgeführt. Diese sind in der nachstehenden Reihenfolge auszuführen. Ggf. kann man Sichten weglassen, wenn man nicht an den Daten oder einer Historie interessiert ist.
  • Für einen schnellen Einstieg kann die zusammengefasste Datei alkis_schema.sql verwendet werden. Sie ist derzeit für EPSG:25832 ausgelegt, beinhaltet nicht alles was nachstehend aufgeführt ist, aber die wesentlichen Teile, damit man NAS einlesen und in kvwmap schon mal benutzen kann.
  • Das Schema "alkis" muss nicht vorher angelegt werden. Bitte bei Bedarf vor der Ausführung der SQL-Dateien den EPSG-Code von 25833 auf 25832 ändern oder umgekehrt.
Das Datenbank-Grundschema entspricht dem NorBIT-Schema bzw. PostNAS 0.8:
Tabellen der Antragsverwaltung AA_xxx (optional):
Die nachfolgenden Skripte vervollständigen das DB-Schema und stammen aus dem PostNAS-Projekt. Einige davon verwenden noch die Tabelle alkis_beziehungen, und müssen in Zukunft noch umgestellt werden.
Diese beiden Skripte legen Funktionen, Triggerfunktionen und Trigger an, die u.a. für das korrekte Einlesen von NAS-Fortführungen erforderlich sind. Sie sind für die Verwendung einer Vollhistorie gedacht.
In diesem Skript sind alle Anpassungen von kvwmap-Nutzern zu finden, die das Schema verändern:
Dies sind Tabellen und Sichten, die von kvwmap-Nutzern erstellt wurden. Sie haben den Prefix "lk_":


!!! ACHTUNG !!!

Alle hier aufgeführten Sichten berücksichtigen bisher nicht den Zeitbezug über die Spalten beginnt und endet. Damit in den darauf aufsetzenden Layern in kvwmap der vom Nutzer gewählte historische Zeitpunkt berücksichtigt werden kann, müssen diese Sichten angepasst werden. Die Wiki-Seite PostNAS-Sichten für Vollhistorie soll zur Bearbeitung der Sichten dienen.

!!! ACHTUNG !!!

Einspielen der NAS-Daten

Beim Einspielen der NAS-Daten ist zu beachten, dass unter Linux ein aktuelles GDAL (derzeit Version 2.0dev) nach dieser Anleitung http://trac.wheregroup.com/PostNAS/wiki/BuildingOgrPostNASDriver selbst kompiliert werden muss. Alternativ kann man auch das OGR aus dem osgeo4w-Projekt unter Windows verwenden. Um die NAS-Daten in die PostNAS-DB einzuspielen wird das aktuelle Programm ogr2ogr aus dem GDAL Trunk verwendet. Man wechselt dazu nach 

/pfad_zu_meinem_gdal/gdal-trunk/bin

und führt folgenden Befehl aus: 

./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:

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

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).
Von „https://kvwmap.de/wiki/index.php?title=Installation_von_PostNAS_und_Zugriff_mit_kvwmap&oldid=11513“