Jetzt geht es weiter mit David Arndt über OJZ, Diensteverwaltung, über SVN, los geht's. Ja, hallo, mein Name ist David Arndt, ich arbeite beim Regionalverband Ruhr in Essen.

Bin dort im Referat Geo-Information und Raumplanung, im Teamleiter für das Team Geo-Datentechnik. Und wir haben uns schon länger mal Gedanken gemacht, wie wir vernünftig unsere Map-Server-Konfiguration und QGIS-Konfiguration einfach versionssicher halten und auch vielleicht noch mehr Informationen

daraus generieren können, damit man sozusagen eine vernünftige Struktur einfach von dem Ganzen hat. Ich hab den falsch rum, so.

Angefangen ist es damit, dass wir gesagt haben, okay, wir haben in unserem lokalen Fallsystem die Konfiguration für die Map-Server, Map-Dateien oder für die QGIS-Dateien und wir wollen die eigentlich publizieren. Das lief früher so, wir haben die einfach auf unsere Server geschoben. Das Problem war da schon, dass wir nicht nur einen Map-Server haben, sondern mehrere Map-Server.

Das heißt, wir mussten die dann immer auf mehrere Server gleichzeitig raufschieben. Das hat man dann vergessen, dann funktionierten die Dienste nicht richtig. Da musste man noch eine Metadaten dazu erzeugen. Da hat man die einmal erzeugt, den Dienst aktualisiert, aber die Metadaten nicht mehr aktualisiert und dann blieb es dabei.

Dementsprechend haben wir uns überlegt, wie können wir das besser machen. Wir haben jetzt zu jeder Konfiguration nicht nur die Konfiguration des Map-Files, wie man da oben sieht, Metropole-Map und FBK.QGIS, sondern wir haben auch noch eine Metadatendatei dazu. In dieser Metadatendatei stehen zusätzliche Informationen.

Wenn ich die dann erstellt habe, dann werden die bei uns in ein Software-Repository committed über eine SVN, weil das bei uns in der Projektentwicklung einfach so drin ist, dass wir das haben schon. Und wir können dann am Ende, wenn wir das committed haben, sogenannte Post-Commit-Hooks starten.

Das sind einfach Skripte, die laufen und Sachen ausführen. Und als erstes führen die auf, dass die einfach unsere Map-Dateien, QGIS-Projekte auf die verfügbaren Server, die wir haben, verteilen. So dass überall die gleiche Konfiguration ist.

Das zweite, was wir machen ist, wir haben in der Metadatendatei die Möglichkeit, Regeln einzugeben, wer überhaupt auf die Daten zugreifen kann. Das heißt, welche Benutzergruppe darf die Daten zugreifen. Dann kommt eine HTTP-Authentifizierung. Welche IP-Addessen dürfen darauf zugreifen.

Da gibt es dann die IP-Regeln. Die können wir in den Metadatendatei mit angeben. Die wird dann angewendet und auf unseren Reverse-Proxys wird diese Konfiguration dann in eine Apache-Konfiguration umgewandelt und dort sofort angewendet. Das heißt, dann wird der Apache-Server einmal ein Reload gemacht und die Regeln werden angewendet, die Dienste sind abgesichert

oder eben auch nicht, je nachdem, wie man das braucht und haben möchte. Das Schöne daran ist, es kann natürlich jetzt jeder machen. Bis jetzt war ich immer derjenige dran, der immer die Apache-Konfiguration anpassen muss. Jetzt kann es auch derjenige machen, der die Konfiguration für die Maps-Dateien erstellt, weil er einfach nur eine IP-Adresse eintragen muss oder eine Gruppe. Das nächste, was wir uns gedacht haben mit der ganzen Inspire-Sache oder sowas,

muss man natürlich auch damit rechnen, dass man die Metadaten erzeugen muss. Für die Metadaten ist es natürlich zwingend notwendig, dass wir eine vernünftige Datenservice-Kopplung haben. Die Datenservice-Kopplung muss auch stimmen. Diese Datenservice-Kopplung haben wir eigentlich schon im MAP-Datei beschrieben.

Da stehen die Links auf die Metadaten drin. Das heißt, wir generieren jetzt aus den Capabilities des Dienstes und zusätzlichen Informationen, die wir im Metadaten-File in dieser MD-Datei haben,

generieren wir jetzt unsere ISO-Metadaten. Die sind dann sofort erreichbar auch. Sobald der Dienst publiziert ist, sind die Metadaten dazu auch publiziert. Sie können dann direkt auch genutzt werden. Sobald ich den Dienst wieder lösche, sind die Metadaten auch wieder weg, sodass ich auch keine toten Links habe.

Ich habe hier wirklich die Möglichkeit, dass es immer auf dem gleichen Stand ist. Und den nächsten, den wir haben, man möchte natürlich auch gucken, ob die Dienste laufen und wie sie laufen. Da probieren wir gerade mit der Software GeoHealth-Check herum.

Das ist ja auch ein OS-Geo-Projekt, auf Python basierend, was im Grunde die Dienste überprüft auf ihre Verfügbarkeit. Dort werden die Dienste dann auch direkt eingetragen, beziehungsweise wenn der Dienst wieder gelöscht wird, fliegt der auch wieder raus aus der Datenbank. So habe ich dann wirklich die Möglichkeit, auch dort immer alles zu überprüfen

und ich bekomme dann eben auch die Nachrichten, wenn ein Dienst nicht läuft. Der große Vorteil an dieser Sache ist natürlich, wir haben an einer Stelle die Konfiguration und bedienen von da aus alle Systeme und die sind immer konsistent, also immer in einem konsistenten Zustand.

Wenn ich hintenrum einen neuen Mapserver anschaffe, muss ich in der Konfiguration das nur mit angeben und dann werden sofort alle Dienste dort auch publiziert. Dementsprechend vereinfacht das bei uns sehr viel in der Konfiguration von den Diensten. Und damit wäre ich durch. Danke.