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

Aus kvwmap
Wechseln zu: Navigation, Suche
(→‎Einspielen der NAS-Daten)
(→‎Migration von kvwmap Version 2.7 auf Version 2.8)
 
(28 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
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==
+
Das von kvwmap verwendete PostNAS-Datenmodell 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 und bildet das ALKIS-Datenmodell vollständig ab.
 +
Bei der Erstellung des alkis-Schemas für kvwmap wurden folgende Konstanten eingestellt:
 +
* GEOMETRY_COLUMN_NAME = wkb_geometry
 +
* GEOMETRY_EPSG_CODE = 25833
 +
* LINESTRING_AS_GEOMETRY = true
 +
* WITH_UUID_OSSP = true
 +
* RENAME_OPTIONAL_FIRST = true
 +
* RENAME_ZEIGT_AUF_EXTERNES = false
 +
* WITH_CODE_LISTS = true
  
 +
Das in kvwmap verwendete alkis-Schema und die gfs-Datei entspricht der Ausgabe von xmi2db vom 16.11.2017.
  
 +
Das Datenbankschema heißt "alkis" und wird bei Aktivierung des Plugins ALKIS durch Ausführung von Migrationsdateien bei der Aktualisierung der Datenbank automatisch angelegt.
 +
Bei dieser DB-Aktualiserung werden neben dem Basisschema außerdem weitere Tabellen, Sichten und Indizes angelegt, die von kvwmap benötigt werden.
  
−
== Erstellung eines PostNAS-Schemas ==
 
  
−
Das in dieser Anleitung verwendete PostNAS-Basisschema 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. Bei Bedarf kann mit xmi2db auch selbst ein Schema erzeugt und verwendet werden.
+
=== Migration von kvwmap Version 2.7 auf Version 2.8 ===
−
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.  
+
Wenn ein kvwmap-Server von Version 2.7 auf Version 2.8 umgestellt werden soll und bisher auch schon das alte PostNAS-Schema verwendet wurde, sind mehrere Schritte für die Umstellung notwendig.  
  
−
:*[http://www.kvwmap.de/alkis/complete/1_complete_alkis_schema.sql 1_complete_alkis_schema.sql]     das mit xmi2db erstellte Basisschema - Stand: 17.01.2017
+
Damit die Umstellung eines Produktivsystems möglichst ohne große Ausfallzeit erfolgen kann, wird folgende Vorgehensweise empfohlen:
  
−
:*[http://www.kvwmap.de/alkis/complete/2_alkis_indizes.sql 2_alkis_indizes.sql]     Indizes für die performante Abfrage der Daten - Stand: 20.01.2017
 
  
−
:*[http://www.kvwmap.de/alkis/complete/3_alkis-functions.sql 3_alkis-functions.sql]     Funktionen - Stand: 23.01.2017
+
'''1. Erstellung einer Testumgebung durch Kopieren der kvwmap-Installation'''
  
−
:*[http://www.kvwmap.de/alkis/complete/4_weitere_keytables.sql 4_weitere_keytables.sql]     weitere Schlüsseltabellen - Stand: 23.01.2017
+
Die vorhandene kvwmap-Installation wird kopiert. D.h. das kvwmap-Webverzeichnis, die MySQL-DB und die PostGIS-DB. Diese Kopie wird lauffähig gemacht (Anpassen der config.php, Web-Verzeichnis freigeben). In der weiteren Beschreibung wird von folgendem Beispiel ausgegangen:
  
−
:*[http://www.kvwmap.de/alkis/complete/5_weitere_tables.sql 5_weitere_tables.sql]     weitere Tabellen - Stand: 23.01.2017
+
<table cellpadding="4" border="1" style="border-collapse:collapse">
 +
<tr>
 +
  <td></td><td>'''Produktivsystem'''</td><td>'''Testsystem'''</td>
 +
</tr>
 +
<tr>
 +
  <td>'''Webverzeichnis'''</td><td>kvwmap</td><td>kvwmap_test</td>
 +
</tr>
 +
<tr>
 +
  <td>'''MySQL-DB'''</td><td>kvwmapdb</td><td>kvwmapdb_test</td>
 +
</tr>
 +
<tr>
 +
  <td>'''PostGIS-DB'''</td><td>kvwmapsp</td><td>kvwmapsp_test</td>
 +
</tr>
 +
</table>
  
−
:*[http://www.kvwmap.de/alkis/complete/6_pp_definition.sql 6_pp_definition.sql] &nbsp;&nbsp;&nbsp; Postprocessing-Tabellen - Stand: 23.01.2017
 
  
−
:*[http://www.kvwmap.de/alkis/complete/7_nutzungsart_definition.sql 7_nutzungsart_definition.sql] &nbsp;&nbsp;&nbsp; Postprocessing-Tabellen für die Nutzungen - Stand: 02.10.2015
+
'''2. In kvwmapsp_test: Umbenennung des Schemas "alkis" in "alkis_alt"'''
  
 +
In der Test-DB "'''kvwmapsp_test'''" wird das vorhandene Schema "'''alkis'''" in "'''alkis_alt'''" (oder ähnliches) umbenannt.
  
−
: Sichten todo
 
  
−
== Einspielen der NAS-Daten ==
+
'''3. In kvwmap_test: Update des Quellcodes und der Datenbanken'''
  
−
=== Umbenennungsskript ===
+
In "'''kvwmap_test'''" wird in den develop-Branch gewechselt (git checkout develop). Dieser Branch beinhaltet die Unterstützung für das vollständige PostNAS-Schema.
  
−
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 [https://raw.githubusercontent.com/pkorduan/xmi2db/master/converter/rename_nas.rb 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.
+
Danach werden über die Administratoroberfläche zunächst der Quellcode und danach die Datenbanken aktualisiert. Dadurch wird das neue, vollständige Schema "'''alkis'''" in der PostGIS-DB angelegt.
  
−
=== 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.
+
'''4. In kvwmapsp_test: Einlesen eines neuen Grunddatenbestandes'''
  
−
:[http://www.kvwmap.de/alkis/complete/alkis_template.gfs alkis_template.gfs] &nbsp;&nbsp;&nbsp; GFS-Template - Stand: 02.02.2017
+
Das neue Schema "alkis" wird mit einem neuen Grunddatenbestand befüllt. Siehe [[ALKIS-Daten einlesen]].
  
−
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 ===
+
'''5. In kvwmapsp_test: Anpassung der Sichten, Funktionen, Regeln, usw.'''
  
−
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.
+
Alle Sichten, Funktionen, Regeln, usw., die auf das alte Schema "alkis" zugegriffen haben, müssen angepasst werden.  
  
−
:[http://www.kvwmap.de/alkis/complete/import_nas.sh import_nas.sh] &nbsp;&nbsp;&nbsp; Einleseskript - Stand: 02.02.2017
+
Bei Sichten ist es so, dass diese durch die Umbenennung vom alten Schema "alkis" in "alkis_alt" jetzt auch auf "alkis_alt" zugreifen. Dies muss angepasst werden, so dass sie wieder auf das neue Schema "alkis" zugreifen. Außerdem muss die andere Struktur des neuen Schemas "alkis" berücksichtigt werden.
  
−
*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.
+
Auch Triggerfunktionen, Funktionen und Regeln müssen auf die Struktur des neuen Schemas "alkis" angepasst werden.
−
*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.
+
  
−
+
'''!!! WICHTIG: Alle diese Anpassungen müssen in einem SQL-Skript festgehalten werden, welches man dann später auf der PostGIS-DB "kvwmapsp" des Produktivsystems ausführen kann. !!!'''
  
−
./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
+
'''6. In kvwmapdb_test: Anpassung der Layerdefinitionen'''
−
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...
+
Im Test-System müssen alle Layerdefinitionen, die auf das Schema "alkis" zugreifen, auf die neue Datenstruktur angepasst werden.
  
−
'''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
+
'''!!! WICHTIG: Auch diese Anpassungen müssen in einem SQL-Skript festgehalten werden, welches man dann später auf der MySQL-DB "kvwmapdb" des Produktivsystems ausführen kann. !!!'''
−
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'''<br>
 
−
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:
 
  
−
xmllint --nowarning --noout --schema pfad_zum_schema/NAS_6.0.1/schema/NAS-Operationen.xsd pfad_zu_nas/beispiel.xml
+
'''7. Umstellung des Produktivsystems'''
  
−
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>
+
Wenn alle Anpassungen in der PostGIS-DB "kvwmapsp_test" und der MySQL-DB "kvwmapdb_test" vorgenommen worden sind und das Testsystem mit dem neuen Schema gründlich getestet wurde, kann das Produktivsystem umgestellt werden.
−
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]
+
  
−
Wichtig: Es sollten nur valide Daten eingespielt werden!
+
Dazu werden die Schritte 2 - 4 nun auf dem Produktivsystem in kvmwapsp ausgeführt. Schritt 4 kann auch erfolgen in dem man vom ALKIS-Schema in kvwmapsp_test ein dump ausführt und ein restore in kvwmapsp einspielt oder durch Ausführen der Transaktionsdateien.
  
 +
Danach werden die beiden Änderungsskripte auf der MySQL-DB "kvwmapdb" und der PostGIS-DB "kvwmapsp" ausgeführt.
  
−
Zur Batchverarbeitung mehrer NAS-Dateien in einem Verzeichnis kann folgendes Script eingesetzt werden:
+
Da bei dem restore des alkis-Schemas in kvwmapsp Probleme auftreten können wegen Abhängigkeiten haben wir eine 4 Stufige Lösung:
−
<nowiki>
+
−
#!/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</nowiki>
+
  
−
Anschließend die Datei xml_bath.sh ausführbar machen und ausführen.
+
* Neue Datenbank kvwmapsp_neu anlegen und darin CREATE EXTENSION postgis
−
 
+
* Dann in kvwmapsp_neu alkis Schema aus kvwmapsp_test einlesen mit pg_restore
−
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.
+
* Dump aller Schemata außer alkis (-N alkis) von kvwmapsp und einspielen mit pg_restore in kvwmapsp_neu
−
Hinweise dazu finden sich zahlreich im Netz.
+
* Umbenennen kvwmapsp nach kvwmapsp_alt und kvwmapsp_neu nach kvwmapsp
−
 
+
−
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:
+
−
 
+
−
:*[http://www.kvwmap.de/alkis/pp_laden_ohne_alkis_beziehungen.sql pp_laden_ohne_alkis_beziehungen.sql] Stand 10.03.2016
+
−
:*[http://www.kvwmap.de/alkis/nutzungsart_laden.sql nutzungsart_laden.sql] &nbsp;&nbsp;&nbsp; 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:
+
−
 
+
−
<nowiki>
+
−
$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</nowiki>
+
−
 
+
−
 
+
−
== Layerdefinitionen ==
+
−
 
+
−
[[Gruppen_und_Themen_für_ALKIS|Hier findet man die Gruppen und Themen für ALKIS]]
+
−
 
+
−
== Mapdatei ==
+
−
 
+
−
:*[http://www.kvwmap.de/alkis/alkis.map alkis.map] &nbsp;&nbsp;&nbsp; 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: [http://www.geobasis-bb.de/GeoPortal1/produkte/aaa-testdaten.html]
+
−
 
+
−
*ALKIS®-Beispieldaten Mecklenburg-Vorpommern vom LAiV: [http://www.laiv-mv.de/land-mv/LAiV_prod/LAiV/AfGVK/Projekt_AAA/ALKIS/index.jsp]
+
−
: Hier findet man Beispieldaten zum Testen (kostenlos).
+

Aktuelle Version vom 29. November 2017, 16:26 Uhr

Das von kvwmap verwendete PostNAS-Datenmodell wurde mit dem Tool xmi2db auf Basis des AAA-Implementierungsmodells erzeugt und bildet das ALKIS-Datenmodell vollständig ab. Bei der Erstellung des alkis-Schemas für kvwmap wurden folgende Konstanten eingestellt:

  • GEOMETRY_COLUMN_NAME = wkb_geometry
  • GEOMETRY_EPSG_CODE = 25833
  • LINESTRING_AS_GEOMETRY = true
  • WITH_UUID_OSSP = true
  • RENAME_OPTIONAL_FIRST = true
  • RENAME_ZEIGT_AUF_EXTERNES = false
  • WITH_CODE_LISTS = true

Das in kvwmap verwendete alkis-Schema und die gfs-Datei entspricht der Ausgabe von xmi2db vom 16.11.2017.

Das Datenbankschema heißt "alkis" und wird bei Aktivierung des Plugins ALKIS durch Ausführung von Migrationsdateien bei der Aktualisierung der Datenbank automatisch angelegt. Bei dieser DB-Aktualiserung werden neben dem Basisschema außerdem weitere Tabellen, Sichten und Indizes angelegt, die von kvwmap benötigt werden.


Migration von kvwmap Version 2.7 auf Version 2.8

Wenn ein kvwmap-Server von Version 2.7 auf Version 2.8 umgestellt werden soll und bisher auch schon das alte PostNAS-Schema verwendet wurde, sind mehrere Schritte für die Umstellung notwendig.

Damit die Umstellung eines Produktivsystems möglichst ohne große Ausfallzeit erfolgen kann, wird folgende Vorgehensweise empfohlen:


1. Erstellung einer Testumgebung durch Kopieren der kvwmap-Installation

Die vorhandene kvwmap-Installation wird kopiert. D.h. das kvwmap-Webverzeichnis, die MySQL-DB und die PostGIS-DB. Diese Kopie wird lauffähig gemacht (Anpassen der config.php, Web-Verzeichnis freigeben). In der weiteren Beschreibung wird von folgendem Beispiel ausgegangen:

ProduktivsystemTestsystem
Webverzeichniskvwmapkvwmap_test
MySQL-DBkvwmapdbkvwmapdb_test
PostGIS-DBkvwmapspkvwmapsp_test


2. In kvwmapsp_test: Umbenennung des Schemas "alkis" in "alkis_alt"

In der Test-DB "kvwmapsp_test" wird das vorhandene Schema "alkis" in "alkis_alt" (oder ähnliches) umbenannt.


3. In kvwmap_test: Update des Quellcodes und der Datenbanken

In "kvwmap_test" wird in den develop-Branch gewechselt (git checkout develop). Dieser Branch beinhaltet die Unterstützung für das vollständige PostNAS-Schema.

Danach werden über die Administratoroberfläche zunächst der Quellcode und danach die Datenbanken aktualisiert. Dadurch wird das neue, vollständige Schema "alkis" in der PostGIS-DB angelegt.


4. In kvwmapsp_test: Einlesen eines neuen Grunddatenbestandes

Das neue Schema "alkis" wird mit einem neuen Grunddatenbestand befüllt. Siehe ALKIS-Daten einlesen.


5. In kvwmapsp_test: Anpassung der Sichten, Funktionen, Regeln, usw.

Alle Sichten, Funktionen, Regeln, usw., die auf das alte Schema "alkis" zugegriffen haben, müssen angepasst werden.

Bei Sichten ist es so, dass diese durch die Umbenennung vom alten Schema "alkis" in "alkis_alt" jetzt auch auf "alkis_alt" zugreifen. Dies muss angepasst werden, so dass sie wieder auf das neue Schema "alkis" zugreifen. Außerdem muss die andere Struktur des neuen Schemas "alkis" berücksichtigt werden.

Auch Triggerfunktionen, Funktionen und Regeln müssen auf die Struktur des neuen Schemas "alkis" angepasst werden.

!!! WICHTIG: Alle diese Anpassungen müssen in einem SQL-Skript festgehalten werden, welches man dann später auf der PostGIS-DB "kvwmapsp" des Produktivsystems ausführen kann. !!!


6. In kvwmapdb_test: Anpassung der Layerdefinitionen

Im Test-System müssen alle Layerdefinitionen, die auf das Schema "alkis" zugreifen, auf die neue Datenstruktur angepasst werden.

!!! WICHTIG: Auch diese Anpassungen müssen in einem SQL-Skript festgehalten werden, welches man dann später auf der MySQL-DB "kvwmapdb" des Produktivsystems ausführen kann. !!!


7. Umstellung des Produktivsystems

Wenn alle Anpassungen in der PostGIS-DB "kvwmapsp_test" und der MySQL-DB "kvwmapdb_test" vorgenommen worden sind und das Testsystem mit dem neuen Schema gründlich getestet wurde, kann das Produktivsystem umgestellt werden.

Dazu werden die Schritte 2 - 4 nun auf dem Produktivsystem in kvmwapsp ausgeführt. Schritt 4 kann auch erfolgen in dem man vom ALKIS-Schema in kvwmapsp_test ein dump ausführt und ein restore in kvwmapsp einspielt oder durch Ausführen der Transaktionsdateien.

Danach werden die beiden Änderungsskripte auf der MySQL-DB "kvwmapdb" und der PostGIS-DB "kvwmapsp" ausgeführt.

Da bei dem restore des alkis-Schemas in kvwmapsp Probleme auftreten können wegen Abhängigkeiten haben wir eine 4 Stufige Lösung:

  • Neue Datenbank kvwmapsp_neu anlegen und darin CREATE EXTENSION postgis
  • Dann in kvwmapsp_neu alkis Schema aus kvwmapsp_test einlesen mit pg_restore
  • Dump aller Schemata außer alkis (-N alkis) von kvwmapsp und einspielen mit pg_restore in kvwmapsp_neu
  • Umbenennen kvwmapsp nach kvwmapsp_alt und kvwmapsp_neu nach kvwmapsp
Von „https://kvwmap.de/wiki/index.php?title=das_vollständige_PostNAS-Datenmodell&oldid=11722“