Umstellung auf GeoInfoDok 7.1: Unterschied zwischen den Versionen
Rahn (Diskussion | Beiträge) |
Rahn (Diskussion | Beiträge) (→Testphase mit separater kvwmap-Instanz) |
||
(10 dazwischenliegende Versionen des gleichen Benutzers werden nicht angezeigt) | |||
Zeile 10: | Zeile 10: | ||
'''Was ist dafür zu tun?''' | '''Was ist dafür zu tun?''' | ||
− | Zum einen wird neues DB-Schema benötigt, um die NAS-Daten nach dem neuen Datenmodell einlesen zu können. Dieses neue Schema "alkis" wurde mit Hilfe des Tools xmi2db auf Basis des neuen UML-Modells erzeugt | + | Zum einen wird neues DB-Schema benötigt, um die NAS-Daten nach dem neuen Datenmodell einlesen zu können. Dieses neue Schema "alkis" wurde mit Hilfe des Tools xmi2db auf Basis des neuen UML-Modells erzeugt. |
− | + | Außerdem muss natürlich kvwmap auch korrekt auf dieses neue Schema "alkis" zugreifen können. | |
− | + | Im git-Repository wurde deshalb ein neuer Branch "gid71" angelegt. In diesem Branch wurden zum einen die notwendigen Änderungen am Quellcode vorgenommen und außerdem sind hier auch die Migrationsdateien enthalten um das neue Schema "alkis" anzulegen. Es wird davon ausgegangen, dass kein Schema "alkis" vorhanden ist. Außerdem gibt es hier eine neue GFS-Datei, um die NAS-Daten mit OGR einlesen zu können. | |
− | + | ||
'''Damit OGR alle Daten korrekt einlesen kann, wird mindestens die GDAL-Version 3.8 benötigt. Wir haben deshalb eine neue Version des gdal-Docker-Images erstellt (0.5.0).''' | '''Damit OGR alle Daten korrekt einlesen kann, wird mindestens die GDAL-Version 3.8 benötigt. Wir haben deshalb eine neue Version des gdal-Docker-Images erstellt (0.5.0).''' | ||
Zeile 28: | Zeile 27: | ||
====Testphase mit separater kvwmap-Instanz==== | ====Testphase mit separater kvwmap-Instanz==== | ||
− | Unsere Empfehlung ist, dass man sich für die Testphase eine zweite kvwmap-Instanz (mit eigenen Datenbank-Kopien) anlegt | + | Unsere Empfehlung ist, dass man sich für die Testphase eine zweite kvwmap-Instanz (mit eigenen Datenbank-Kopien) anlegt. |
Dann geht es darum das alte Schema "alkis" zu löschen. Alle Sichten, die auf dieses Schema zugreifen, müssen vorher als Dump gesichert werden, um sie später wieder anzulegen. | Dann geht es darum das alte Schema "alkis" zu löschen. Alle Sichten, die auf dieses Schema zugreifen, müssen vorher als Dump gesichert werden, um sie später wieder anzulegen. | ||
− | Wenn man das alte Schema gelöscht hat, kann man das neue Schema anlegen. Danach kann man die gesicherten Sichten anlegen und muss dabei notwendige Änderungen auf Grund des neuen Datenmodells im Sichten-Dump speichern. | + | Mit dieser Abfrage lassen sich die Sichten ermitteln, die auf das Schema alkis zugreifen: |
+ | |||
+ | <nowiki>SELECT distinct | ||
+ | dependent_ns.nspname as dependent_schema, | ||
+ | dependent_view.relname as dependent_view, | ||
+ | source_ns.nspname as source_schema, | ||
+ | format('%s %s AS | ||
+ | %s', | ||
+ | CASE WHEN dependent_view.relkind = 'm' THEN 'DROP MATERIALIZED VIEW ' || dependent_ns.nspname||'.'||dependent_view.relname || '; CREATE MATERIALIZED VIEW ' | ||
+ | ELSE 'CREATE OR REPLACE VIEW' | ||
+ | END, | ||
+ | dependent_ns.nspname||'.'||dependent_view.relname, | ||
+ | pg_get_viewdef(dependent_ns.nspname||'.'||dependent_view.relname)) || ' | ||
+ | ' | ||
+ | FROM | ||
+ | pg_depend | ||
+ | JOIN pg_rewrite ON pg_depend.objid = pg_rewrite.oid | ||
+ | JOIN pg_class as dependent_view ON pg_rewrite.ev_class = dependent_view.oid | ||
+ | JOIN pg_class as source_table ON pg_depend.refobjid = source_table.oid | ||
+ | JOIN pg_namespace dependent_ns ON dependent_ns.oid = dependent_view.relnamespace | ||
+ | JOIN pg_namespace source_ns ON source_ns.oid = source_table.relnamespace | ||
+ | WHERE | ||
+ | source_ns.nspname = 'alkis' | ||
+ | ORDER BY 1,2;</nowiki> | ||
+ | |||
+ | Wenn man das alte Schema gelöscht hat, kann man in den Branch "gid71" wechseln und das neue Schema anlegen. Danach kann man die gesicherten Sichten anlegen und muss dabei notwendige Änderungen auf Grund des neuen Datenmodells im Sichten-Dump speichern. | ||
Dann kann man die NAS-Daten mit dem Import-Skript "import_nas.sh" einlesen. | Dann kann man die NAS-Daten mit dem Import-Skript "import_nas.sh" einlesen. | ||
Wurden die Daten erfolgreich eingelesen, kann man mit dem Testen beginnen. Neben den kvwmap-Funktionalitäten geht es, wie schon erwähnt, auch um die Layerdefinitionen sowie alle Zugriffe außerhalb von kvwmap wie Mapdateien, Skripte, Conjobs, Dienste usw. Alle Anpassungen werden dabei dokumentiert. | Wurden die Daten erfolgreich eingelesen, kann man mit dem Testen beginnen. Neben den kvwmap-Funktionalitäten geht es, wie schon erwähnt, auch um die Layerdefinitionen sowie alle Zugriffe außerhalb von kvwmap wie Mapdateien, Skripte, Conjobs, Dienste usw. Alle Anpassungen werden dabei dokumentiert. | ||
− | |||
− | |||
====Umstellung des Produktivsystems==== | ====Umstellung des Produktivsystems==== | ||
Zeile 46: | Zeile 68: | ||
Im Prinzip muss man hierfür "nur" 4 Sachen machen: | Im Prinzip muss man hierfür "nur" 4 Sachen machen: | ||
− | # kvwmap auf den Branch "gid71" umstellen, | + | # das alte Schema "alkis" löschen |
− | + | # kvwmap auf den Branch "gid71" umstellen, und das neue Schema "alkis" über die Migrationsdateien anlegen | |
− | + | ||
# Alle vorher abgespeicherten Anpassungen vornehmen (Layer, Mapdateien, DB-Sichten, Skripte, Dienste usw.) | # Alle vorher abgespeicherten Anpassungen vornehmen (Layer, Mapdateien, DB-Sichten, Skripte, Dienste usw.) | ||
+ | # die neue Grundausstattung einlesen |
Aktuelle Version vom 28. Oktober 2024, 12:12 Uhr
Das AFIS-ALKIS-ATKIS-Anwendungsschema wird vom bisherigen Datenmodell GeoInfoDok 6.0.1 auf die GeoInfoDok NEU (Referenzversion 7.1) umgestellt.
Die Version 7.1 wird zum 31.12.2023 zur neuen Referenzversion der AdV (Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland).
Mecklenburg-Vorpommern beabsichtigt die Umstellung bereits zu Beginn des 4. Quartals 2023 durchzuführen.
Das bedeutet, dass die NAS-Daten ab einem bestimmten Zeitpunkt über ein neues NBA-Verfahren, als neue Grundausstattung in der Version GeoInfoDok 7.1 geliefert werden.
Was ist dafür zu tun?
Zum einen wird neues DB-Schema benötigt, um die NAS-Daten nach dem neuen Datenmodell einlesen zu können. Dieses neue Schema "alkis" wurde mit Hilfe des Tools xmi2db auf Basis des neuen UML-Modells erzeugt.
Außerdem muss natürlich kvwmap auch korrekt auf dieses neue Schema "alkis" zugreifen können.
Im git-Repository wurde deshalb ein neuer Branch "gid71" angelegt. In diesem Branch wurden zum einen die notwendigen Änderungen am Quellcode vorgenommen und außerdem sind hier auch die Migrationsdateien enthalten um das neue Schema "alkis" anzulegen. Es wird davon ausgegangen, dass kein Schema "alkis" vorhanden ist. Außerdem gibt es hier eine neue GFS-Datei, um die NAS-Daten mit OGR einlesen zu können.
Damit OGR alle Daten korrekt einlesen kann, wird mindestens die GDAL-Version 3.8 benötigt. Wir haben deshalb eine neue Version des gdal-Docker-Images erstellt (0.5.0).
Alle Layer, Mapdateien, DB-Sichten, Skripte, Dienste usw., die auf das Schema "alkis" zugreifen, müssen auf das neue Datenmodell angepasst werden.
Vorgehensweise der Umstellung
Da natürlich nicht alle Layer, Mapdateien, DB-Sichten, Skripte, Dienste usw. von einem Tag auf den anderen umgestellt werden können, muss es eine Testphase geben um alle diese Sachen auf das neue Modell anpassen zu können. Alle Änderungen, die dafür notwendig sind, müssen so aufgeschrieben bzw. vorbereitet werden, dass sie beim Tag der Umstellung automatisch ablaufen können.
Testphase mit separater kvwmap-Instanz
Unsere Empfehlung ist, dass man sich für die Testphase eine zweite kvwmap-Instanz (mit eigenen Datenbank-Kopien) anlegt.
Dann geht es darum das alte Schema "alkis" zu löschen. Alle Sichten, die auf dieses Schema zugreifen, müssen vorher als Dump gesichert werden, um sie später wieder anzulegen.
Mit dieser Abfrage lassen sich die Sichten ermitteln, die auf das Schema alkis zugreifen:
SELECT distinct dependent_ns.nspname as dependent_schema, dependent_view.relname as dependent_view, source_ns.nspname as source_schema, format('%s %s AS %s', CASE WHEN dependent_view.relkind = 'm' THEN 'DROP MATERIALIZED VIEW ' || dependent_ns.nspname||'.'||dependent_view.relname || '; CREATE MATERIALIZED VIEW ' ELSE 'CREATE OR REPLACE VIEW' END, dependent_ns.nspname||'.'||dependent_view.relname, pg_get_viewdef(dependent_ns.nspname||'.'||dependent_view.relname)) || ' ' FROM pg_depend JOIN pg_rewrite ON pg_depend.objid = pg_rewrite.oid JOIN pg_class as dependent_view ON pg_rewrite.ev_class = dependent_view.oid JOIN pg_class as source_table ON pg_depend.refobjid = source_table.oid JOIN pg_namespace dependent_ns ON dependent_ns.oid = dependent_view.relnamespace JOIN pg_namespace source_ns ON source_ns.oid = source_table.relnamespace WHERE source_ns.nspname = 'alkis' ORDER BY 1,2;
Wenn man das alte Schema gelöscht hat, kann man in den Branch "gid71" wechseln und das neue Schema anlegen. Danach kann man die gesicherten Sichten anlegen und muss dabei notwendige Änderungen auf Grund des neuen Datenmodells im Sichten-Dump speichern.
Dann kann man die NAS-Daten mit dem Import-Skript "import_nas.sh" einlesen.
Wurden die Daten erfolgreich eingelesen, kann man mit dem Testen beginnen. Neben den kvwmap-Funktionalitäten geht es, wie schon erwähnt, auch um die Layerdefinitionen sowie alle Zugriffe außerhalb von kvwmap wie Mapdateien, Skripte, Conjobs, Dienste usw. Alle Anpassungen werden dabei dokumentiert.
Umstellung des Produktivsystems
Wenn die Testphase abgeschlossen ist und man die neue Grundausstattung bekommen hat, kann man die Produktivinstanz auf das neue Datenmodell umstellen.
Im Prinzip muss man hierfür "nur" 4 Sachen machen:
- das alte Schema "alkis" löschen
- kvwmap auf den Branch "gid71" umstellen, und das neue Schema "alkis" über die Migrationsdateien anlegen
- Alle vorher abgespeicherten Anpassungen vornehmen (Layer, Mapdateien, DB-Sichten, Skripte, Dienste usw.)
- die neue Grundausstattung einlesen