Installation von PostNAS und Zugriff mit kvwmap

Aus kvwmap
Wechseln zu: Navigation, Suche

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 nur in wenigen Anpassungen, die z.B. das in MV benutzte Koordinatensystem und den Zugriff von kvwmap betreffen.

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 (mit normalen Benutzerrechten z.B. in /home/fgs/fgs): 
 mkdir postnas
 cd postnas
 wget http://download.osgeo.org/gdal/gdal-1.9.2.tar.gz
 tar -xzf gdal-1.9.2.tar.gz
  • Konfigurieren und kompilieren (hier wird gdal in /home/fgs/fgs/postnas/gdal-1.9.2 installiert) 
cd gdal-1.9.2

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

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

  • Das Schema "alkis" muss nicht vorher angelegt werden, man führt einfach die folgenden SQL-Dateien aus.
Beim Datenbank-Grundschema gibt es momentan 2 Varianten. Einmal die PostNAS-Variante und einmal die NorBIT-Variante. Das NorBIT-Schema ist eine Erweiterung des PostNAS-Schemas, indem es den Objekttabellen zusätzliche Spalten hinzufügt, in denen die Beziehungen zu den anderen Objekten gespeichert sind. Die Tabelle alkis_beziehungen wird darin zwar auch geführt, ist aber überflüssig. Das NorBIT-Schema ist sozusagen die 1:1 Umsetzung der NAS-XML-Struktur in ein relationales Datenmodell. Der Verzicht auf die Tabelle alkis_beziehungen hat mehrere Vorteile. Erstens lassen sich Abfragen einfacher bilden und laufen schneller und außerdem wird dadurch eine Vollhistorisierung der ALKIS-Daten möglich.
Alle kvwmap-Versionen bis einschliesslich der 1.13 verwenden in den Abfragen die Tabelle alkis_beziehungen und setzen auf dem PostNAS-Schema auf. kvwmap 2.0 bzw. die aktuelle develop-Version setzt auf dem NorBIT-Schema auf und benutzt die Tabelle alkis_beziehungen nicht mehr. Man muss sich also für eins der beiden folgende Skripte entscheiden. Zu beachten ist noch, dass für das NorBIT-Schema ein aktuelles GDAL (derzeit Version 2.0dev) nach dieser Anleitung http://trac.wheregroup.com/PostNAS/wiki/BuildingOgrPostNASDriver selbst kompiliert werden muss.
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 für das korrekte Einlesen von NAS-Fortführungen erforderlich sind. Sie sind für die Verwendung mit dem NorBIT-Schema und 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_":

Der Unterschied zu den SQL-Skripten, die unter http://trac.wheregroup.com/PostNAS/browser/trunk/import zu finden sind, besteht nur darin, dass alles im Schema "alkis" angelegt wird, dass das Koordiantensystem EPSG:25833 statt EPSG:25832 verwendet wird und alle Tabellen mit oids angelegt werden.

Einspielen der NAS-Daten

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

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 die Bibliothek libxml2 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 heruntergeladen und dann lokal installiert werden.
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 eine Sammlung der bisherigen Layerdefinitionen, die auf das PostNAS-Schema zugreifen.

Hier findet man die Gruppen und Themen für ALKIS

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]
Beim Einlesen werden Fehlermeldungen folgender Form ausgegeben: 
...
ERROR 1: Did not get 2+ values in <gml:pos>23.1600</gml:pos> tuple.
ERROR 1: Did not get 2+ values in <gml:pos>31.3500</gml:pos> tuple.
ERROR 1: Did not get 2+ values in <gml:pos>25.8700</gml:pos> tuple.
...
  • ALKIS®-Beispieldaten Mecklenburg-Vorpommern vom LAiV: [2]
Hier scheint es Probleme mit den Geometrietypen zu geben. Es werden Fehlermeldungen folgender Form ausgegeben: 
...
Command: INSERT INTO "ax_transportanlage" ("wkb_geometry" , "gml_id", "identifier", "beginnt", "advstandardmodell", "anlass", "bauwerksfunktion") VALUES ('0101000020E9640000F6285C8F6CDC0D412506813D4FCC5641'::GEOMETRY, 'DEMV000000138982', 'urn:adv:oid:DEMV000000138982', '2012-06-04T06:31:41Z', 'DLKM', 0, 1103) RETURNING "ogc_fid"
Warning 1: Geometry to be inserted is of type 3D Line String, whereas the layer geometry type is 3D Point.
Insertion is likely to fail
ERROR 1: INSERT command for new feature failed.
ERROR:  new row for relation "ax_einrichtunginoeffentlichenbereichen" violates check constraint "enforce_geotype_wkb_geometry"

Command: INSERT INTO "ax_einrichtunginoeffentlichenbereichen" ("wkb_geometry" , "gml_id", "identifier", "beginnt", "anlass", "art") VALUES ('0102000020E96400000200000052B81E8540D50D416ABC742366CD56419A99999944D50D415EBA49A460CD5641'::GEOMETRY, 'DEMV000000040186', 'urn:adv:oid:DEMV000000040186', '2012-06-04T06:26:22Z', 0, 1500) RETURNING "ogc_fid"
ERROR 1: INSERT command for new feature failed.
ERROR:  new row for relation "ax_einrichtunginoeffentlichenbereichen" violates check constraint "enforce_geotype_wkb_geometry"
...

Trotz der Fehlermeldungen beim Einlesen funktioniert bei beiden Testdatensätzen die Kartendarstellung als auch die Katasterrecherche in kvwmap.

Von „https://kvwmap.de/wiki/index.php?title=Installation_von_PostNAS_und_Zugriff_mit_kvwmap&oldid=8271“