export ORG_GRADLE_PROJECT_dbUriOerebV2="jdbc:postgresql://oereb-db/oereb"
export ORG_GRADLE_PROJECT_dbUserOerebV2="gretl"
export ORG_GRADLE_PROJECT_dbPwdOerebV2="gretl"ÖREB-Kataster richtig gemacht #6 - Quod erat demonstrandum
02 June 2022
Teil 1 - 5 zeigen wie man sich einen ÖREB-Kataster zusammenstöpselt. Dass das funktioniert, ist nicht sonderlich erstaunlich, da es ziemlich 1:1 dem entspricht, was wir und wie es wir im Einsatz haben. Funktioniert es auch mit in anderen Kantonen?
Ja, klar. Man nehme z.B. die KbS des Kantons Schaffhausen im Rahmenmodell. Diese werden direkt aus dem MGDM mittels XSLT hergestellt. Die Idee finde ich interessant, freue mich aber auf die Transformation für Fälle von MGDM, wo man Geodaten filtern muss. Welcome to XPath hell… Zudem natürlich alle Bundesdaten. Benötigt werden insbesondere noch die Konfiguration-INTERLIS-Transferdateien. Das sind:
Zuständige Stellen: Für unsere Gesamtsystem wird zwingend die katasterverantwortliche Stelle benötigt. Sie landet auf dem PDF-Ausdruck und natürlich auch in der XML-Datei.
Optional werden sämtliche zuständigen Stellen des Kantons und der Gemeinden benötigt. Werden diese zentral nachgeführt und verwaltet, kann in den Geodaten nur noch darauf verwiesen werden und sie müssen nicht mitgeliefert werden. Das hat den Vorteil, dass bei Mutationen einfach und schnell reagiert werden kann und dies nur an einer Stelle gemacht werden muss. Zudem ist es einfach «sauberer», wenn im ÖREB-Kataster z.B. die Staatskanzlei nur einmal vorkommt und nicht x-fach. Die Staatskanzlei eines Kantons gibt es in der Realwelt ebenfalls nur einmal.
https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_zustaendigestellen_V2_0.xtf
Gesetze: Eine Transferdatei mit den Gesetzen wird zwingend benötigt, um die kantonalen gesetzlichen Grundlagen verwalten zu können.
Themen: Die Themen-Konfiguration ist ebenfalls zwingend notwendig. Sie wird benötigt, um die kantonalen gesetzlichen Grundlagen den Themen zuzuweisen. Zusätzliche kantonale Themen und Subthemen werden auch in dieser Datei verwaltet.
Verfügbarkeit: Die Verfügbarkeits-Konfiguration wird zwingend für die Steuerung der verfügbaren Themen und Gemeinden benötigt. Ebenfalls wird das Datum des Standes der Daten der amtlichen Vermessung in dieser Konfiguration verwaltet.
Grundbuch: Wird zwingend benötigt, falls es Grundbuchkreise (o.ä.) gibt.
MapLayering: Falls man die Opazität und die Reihenfolge der WMS-Bilder (resp. des Darstellungsdienstes) steuern will, ist diese Konfigruation zwingend.
Logo: Wird zwingend für die Verwaltung der Logos der Gemeinden und des Kantons benötigt.
Texte: Wird zwingend benötigt, falls es neben den Bundestexten noch weitere kantonale Texte für den Glossar gibt. In meinen Beispiel für den Kanton Schaffhausen habe ich keine zusätzlichen Texte eingeführt.
Die Aufsplittung der Konfiguration kann man teilweise (es muss ja immer noch modellkonform sein) selber wählen. Wahrscheinlich macht man das eher themen-/kontextbezogen und abhängig vom Nachführungszyklus.
Im Dockerfile resp. in der docker-compose.yml-Datei sieht man die übriggebliebene Konfiguration, die man nicht mittels INTERLIS-Dateien verwalten kann:
-
Timezone
-
Datenbankverbindung
-
Datenbankschema
-
Minimale Grösse der Geometrien, die berücksichtigt werden beim Verschnitt.
-
URL der katasterverantwortlichen Stelle
-
WMS für die Hintergrundkarte(n)
Pro ÖREB-Webservice-Instanz kann somit nur eine KVS vorhanden sein kann. D.h. es bräuchte im Rahmenmodell noch etwas wie «KVS pro Gemeinde», damit es nicht für jeden Kanton eine eigene Webservice-Instanz braucht.
Auf Stufe Datenbank könnte man bereits heute mehrere Kantone in das gleiche Schema schmeissen und es würde funktionieren.
Die Konfiguration mittels Rahmenmodell ist sehr transparent und man muss für verschiedene Schritte das Rad nicht neu erfinden:
-
Nachführung: Entweder schnell mal von Hand oder mit QGIS.
-
Validierung und Import in das Katastersystem: ilivalidator und ili2pg
Schreiten wir zur Tat und implementieren wir ein ÖREB-Katastersystem für den Kanton Schaffhausen:
docker-compose up (im oereb_stack-Ordner)
Das startet eine leere ÖREB-Datenbank und den ÖREB-Webservice. Die GRETL-Jobs konnte ich mit minimalen Anpassungen aus Teil 3 übernehmen.
Die magischen Env-Variablen müssen wir setzen:
Sämtliche Datenimports werden mit einem Befehl im Ordner oereb_gretljobs angestossen:
./start-gretl.sh --docker-image sogis/gretl:latest --docker-network oereb_stack_default --job-directory $PWD :oereb_av:replaceCadastralSurveyingData :oereb_plzo:importPLZO :oereb_bundesgesetze:importData :oereb_bundeskonfiguration:importBundeskonfiguration :oereb_kantonskonfiguration:importKantonskonfiguration :oereb_bundesdaten:importData :oereb_kbs:importData
Ich habe nur die Gemeinde Schaffhausen freigeschaltet. Aus diesem Grund wird auch nur die amtliche Vermessung dieser Gemeinde heruntergeladen und importiert. Der gesamte Importprozess dauert bei mir circa fünf Minuten, wobei das meiste für die amtliche Vermessung und die PLZ/Ortschaften draufgeht.
Testrequest «KbS ÖV und Baulinien Nationalstrassen»:
Testrequest «KbS (mgdm2oereb)»:
Eine Unschönheit weist der Auszug bei den gesetzlichen Grundlagen auf: Das USG und die USGV erscheinen doppelt. Das rührt daher, weil die gesetzlichen Grundlagen ebenfalls in den Geodaten bei den Dokumenten mitgeliefert werden und dann ebenfalls nochmals in meiner Konfiguration dem Thema zugeordnet werden. Die gesetzlichen Grundlagen sollten nicht mit den Geodaten mitgeliefert werden.
Die Frage, die mich aber nachts fast nicht mehr schlafen lässt: Warum um Herrgottswillen steht da auf dem geodienste.ch-WMS «frei erhältlich»? Habe ich irgendwie falsche WMS-Endpunkte angezapft oder ist das ein spezieller WMS-Layer? Ich habe das Root-Element als Layer-Parameter gewählt.