Dann darf ich als dritten Redner Jakob Mix begrüßen, er geht jetzt zurück zum Geo-Server, die ist mal fertig eingerichtet, in einer Applikation eingebettet. So, vielen Dank, ja, willkommen, ich stelle euch heute das Projekt Malawi Atlas vor,

das ist eine recht klassische Web-GIS-Applikation, der Source-Code ist auch offen, das zeige den Link, und es ist eine Kooperation mit ZGIS, wo ich arbeite, und den Hilfsorganisation Kopi

und Concern Worldwide. Und das Projekt, das gab es schon fünf Jahre vorher, und wir haben das jetzt eben neu aufgesetzt. Ich werde jetzt einen Überblick geben, welche Technologien wir benutzt haben, und am Schluss auch noch einen kurzen Ausblick geben, welche alternativen Technologien möglich gewesen wären. Kurz zu mir, genau, ich bin wissenschaftlicher

Mitarbeiter am ZGIST in Salzburg, Fachbereich für Geoinformatik, ich bin hauptsächlich der Programmierer bei uns in der Arbeitsgruppe und mache eben die ganzen geoinformatischen Fragestellungen, die eben anfallen. Zudem organisiere ich auch noch das Meetup MAP-Time

Salzburg, was wir heute noch vorstellen werden, und sonst, wie gesagt, ich mache alles, was mit Open Source Geoinformatik zu tun hat. Dann kurz zum ZGIS, wir sind eben ein

Fachbereich an der Universität Salzburg, es gibt 18.000 Studierende, 3.000 Mitarbeiter, und ZGIS ist sehr stark mittelfinanziert, wir bieten einen Master angewandten Geoinformatik an, es gibt etwa 35 Studierende jährlich, und wir haben auch ein sehr großes PhD-Programm

mit etwa 45 Doktoranden. Es gibt 7 Arbeitsgruppen, ich bin in der Arbeitsgruppe GI Science Lab, und das Projekt Malawi Atlas war in Kooperation mit der Arbeitsgruppe Integrated Spatial

Indicators. Erstmal zum Vergleich, 2014 und 2019 von der Oberfläche hat sich jetzt nicht sonderlich viel geändert, vielleicht links ist alles noch ein bisschen mit durchsichtig und lauter Windows, die so rumfliegen, und rechts alles ein bisschen kompakter, aber das ist eigentlich gar nicht so der große Punkt, sondern es geht eher drum,

was im Hintergrund passiert ist, und wie sich der Source Code geändert hat, weil es war, in der ersten Version war es im Prinzip ein paar lange JavaScript-Files, wo alles auch hervorragend funktioniert hat, und jetzt haben wir das alles ein

bisschen komponentenbasierter gemacht, sodass wirklich jeder Teil der Webseite eine eigene JavaScript-Datei ist, können wir kurz hinschauen. Genau, also hier ist der Source Code, könnte ich anschauen, und jetzt nur als groben Überblick, wie das aussieht,

hier sind eben halt die sichtbaren Komponente, und jedes Chart, das Layer, Feature Info, die Map, Sprinter, Layout, alles hat seine eigene Klasse und kann theoretisch wieder

verwendet werden und ist auch einigermaßen leicht zu maintainen. Dann gleich mal ein Überblick, und zwar wie das aussieht, es ist im Prinzip der Klassiker vom Open-Source-GIS, also wir haben eine Post-GIS-Datenbank, wo die ganzen Vektor-Daten gespeichert sind,

dann im File-System liegen die Rastadateien, und alles wird eben vom Geo-Server mittels WMS und WFS geteilt, und die Webseite liegt im ganz normalen Apache-Web-Server, und mit QGIS oder auch mit jedem anderen Client kann man eben auch diesen WMS und

WFS direkt einbinden. Und jetzt zeige ich euch einfach mal, wie das aussieht. Genau, also hier ist eben Malawi-Atlas, auf der linken Seite sieht man eben die ganzen Layers

sind insgesamt über 100, und die sind eben erstmal strukturiert nach Regionen, aber man kann sich hier auch vordefinierte Karten anschauen, der wird dann gleich hingezoomt und genau eben gezeigt. Man kann auf einzelne Features klicken,

kriegt dann links unten eine Info, rechts ist eben die Legende, noch ein anderes Beispiel, genau gleiche Region. Hier gibt es dann auch so Funktionen, dass wenn ich hier auf ein

Polygon klicke, dann wird dann direkt aus den Daten von diesem einzelnen Feature, wird dann unten links ein Diagramm erzeugt, das quasi dynamisch gerechnet wird. Dann Funktionen, ich kann jetzt hier auf Malawi zoomen, dann die einzelnen Distrikte,

genau und die einzelnen Regionen, was auch noch ganz nett ist, ich kann auch drucken, jetzt tun wir nur einen schönen Ausschnitt suchen, da kann ich jetzt mir einen

Titel wählen und Inhalt, wird dann erstellt, genau, normalerweise geht es ein bisschen flotter, wir warten einfach mal, genau und dann kann ich mir eben die Karte als PDF her, da kommt sie schon, und habe es dann wirklich zum ausdrucken und genommen. Das wird dann

auch mit einem Geo-Server Plugin gemacht, also am Anschluss zu dem allerersten Vortrag, da werde ich aber gleich noch drauf eingehen. Okay, jetzt haben wir noch eine Dokumentation

gemacht, das ist mit Sphinx, werde ich auch noch später erzählen, was es ist, das ist einfach, man kann damit in Textdokumente eben genau reinschreiben, was dargestellt werden soll, man kann GIFs einfügen und das kann man dann als eine Webseite erstellen, aber man kann es auch als PDF generieren. Okay, dann erkläre ich nochmal ein bisschen

ausführlicher die einzelnen Komponenten, also wie gesagt Postgres und PostGIS nehmen wir, wir nutzen, also Postgresql ist eine sehr mächtige Software, wir nutzen allerdings die relationalen Fähigkeiten nicht wirklich aus, wir haben im Prinzip 100 Layer, die als einzelne

Tabellen drin liegen und auch nicht miteinander verbunden sind, genau, aber es ist auch für diesen Zweck absolut gut. Was wir aber gemacht haben, wir haben 7 PostGIS Schemas, was im Prinzip auch nur Namespace sind und zwar anhand der unterschiedlichen Regionen

und wir haben uns auch überlegt, dass wir die Tabellen einheitlich benennen, weil als ich das Projekt übernommen habe, waren es eben über 100 Tabellen, die sehr einheitlich benannt wurden und da hat man sich irgendwann nicht mehr zurechtgefunden und da haben wir uns einfach ein Benennungsschema überlegt, ob das der Weisheit letzter Schluss ist,

jetzt sei mal dahingestellt, auf jeden Fall für unseren Anwängungsfall war es ganz praktisch, also erst hatten wir ganz am Anfang eben das Schema, wo eben die Layer in der bestimmten Region drin liegen, dann erst eine Grubebezeichnung, dann die genaue Quelle und ganz am Schluss des Jahres, dass man sich so halbwegs zurechtfindet. Dann genau,

von Tio Server haben wir eben ausführlich Gebrauch gemacht, also man kann damit eben die Vektordaten aus PostGIS laden, dann die Rastadaten haben wir einfach ganz normal auf dem Server im Fallsystem abgelegt und wir haben auch teilweise ziemlich große Rastadaten,

weil wir nämlich Befliegungen von Drohnen hatten und da ist es auf jeden Fall wichtig, dass man die Daten etwas vorprozessiert und zum Beispiel Pyramiden rechnet, damit es viel performanter gelesen werden kann. Teilweise haben wir auch unsere Daten

bei einem Service namens OpenArialMap hochgeladen, es ist ganz grob vergleichbar wie OpenStreetMap eben nur für Rastadaten, da kann man seine Daten hochladen und die dann über WMTS zum Beispiel zur Verfügung gestellt und was man machen kann, man kann dann ein Redirect machen, das Tio Server sozusagen diese WMTS Ressource liest und das dann so

aussieht, als ob es zum eigenen Tio Server kommt. Genau, dann das Styling haben wir mit SLD gemacht, davor eben auch mit QGIS, mit QGIS 3 kann man eben auch das meiste Styling vom

QGIS als SLD exportieren und dann auch wieder in Tio Server laden und da ist es auch enorm wichtig, dass man die SLD-Files, die dann immer zum jeweiligen Layer gehören, auch ordentlich benennt, weil als ich das Projekt z.B. auch übernommen habe, waren auch die SLDs oft ganz anders benannt als wiederum die Layer in Posgis und auch wiederum anders benannt als

der Layer dann in Tio Server heißt und genau nur als Botschaft, wenn ihr irgendwann viele Daten habt, macht euch frühzeitig Gedanken über ordentliche Benennung, weil das schlussig eben auszahlt. Genau, noch ein Tipp für Tio Server und zwar kann man einen externen

Ordner angeben, in dem alle Daten liegen sollen und das macht absolut Sinn, weil wenn man den Tio Server updatet, dann bleibt der externe Ordner einfach an seinem Ort und Tio Server wird neu abgedatet und das trennt eben die Programmlogik von den eigentlichen Daten. Genau und wir

haben eben noch mehrere Plugins benutzt, einmal, das habe ich jetzt vorher nicht gezeigt, aber man kann jeden einzelnen Layer auch exportieren und ich habe jetzt als Standard Geo-Package genommen, also normalerweise, wenn man was exportiert, dann ist es immer Shapefile, aber ich habe jetzt bewusst nur Geo-Package angeboten und auch noch keine Rückfrage für Shapefile bekommen, also ein kleiner Schritt eben,

langfristig eben das Shapefile abzulösen. Dann, genau, Druck ist eben eigenes Plugin und was ich vorher gezeigt habe, vielleicht habe ich es eh gerade noch offen, genau, z. B. diese Pie-Charts oder die Kuchendiagramme, die werden auch direkt von Tio Server gerendert

und das ist eben auch ein eigenes Plugin. Genau, dann für die Webseite haben wir das Framework XJS genommen, das ist ein hervorragendes Framework für den Anwendungsfall,

es hat eine Dual-License, also wenn man den kompletten Source Code der Webseite auch Open Source macht, dann ist es unter der Lizenz GPL verfügbar, ansonsten muss man sich das kaufen, aber genau, wir haben eben die Open Source Version genommen und es gibt eine sehr starre Struktur vor, aber wenn man sich eben dieser Struktur eben anpasst,

dann hat man ein recht leichtes Leben und ist eben gerade praktisch für sehr datenintensive Sachen, z. B. ich kann es nochmal zeigen, was hier passiert bei Zoom,

das hier wird direkt von WFS, von dem Tio Jason gelesen und wenn ich eben, ich musste eben einen sogenannten X-Data-Store definieren und ich habe eben halt diesen Data-Store für die Regionen und für die Subregionen definiert und wenn ich das einmal gemacht habe, dann kann ich mir aus einer Vielzahl von Komponenten mir meine

Web-Applikation zusammenstellen und habe dann relativ viel geschenkt bekommen, also muss ich eben nur einmal anpassen und dann ist es relativ leicht seine Webseite quasi mit den vorgefertigten Komponenten quasi zu erweitern.

Zum Kartendarstellen haben wir Open Layers genommen und es gibt eine Library GeoX, die sozusagen die Schnittstelle zwischen XJS und Open Layers definiert und da, was es im Prinzip tut, ist die Open Layers eben in diese spezielle Struktur von XJS zu

verbinden, z. B. alle Layer, die eben in einer Karte angezeigt werden, werden dann als XJS-Data-Store genommen und genau das macht eben das Leben sehr viel einfacher. Insgesamt haben wir die Web-Applikation war damals auf Open Layers 2,

mittlerweile ist es ja, wo ich das Projekt neu gemacht habe, war es Open Layers 4, mittlerweile ist es Open Layers 5 und bald kommt wieder Open Layers 6 raus und es war auch kurz die Idee, ob wir jetzt einfach die Web-App selber updaten, also einfach nur die Version ändern, aber der Sprung zwischen Open Layers 2 und Open Layers 3 ist sehr

groß und deswegen ist es im Prinzip ein komplettes Rewrite geworden. Genau, dann, man kann, wie gesagt, mit XJS kann man sehr leicht Diagramme machen, wenn eben die Daten in diesem XData-Store vorhanden sind, hat man eine Vielzahl von Diagrammen und mit vielen Darstellungsmöglichkeiten, genau, kann man ganz leicht machen. Dann die

Druckfunktion, die ich vorher gezeigt habe, die heißt Geo-Server Print Plugin und da ist im Prinzip basiert auf MapFish Print in der Version 2 und funktioniert auch einwandfrei und recht flott. Das Einrichten ist nicht ganz trivial, aber ist im Prinzip

auch möglich, also muss man sich vielleicht mal einen halben Tag hinsetzen. Mittlerweile gibt es schon MapFish 3, was ein komplettes Rewrite ist mit Chesape Reports, aber es ist nicht in Geo-Servers als Plugin direkt noch nichts drin, aber wie gesagt,

meine Erfahrung mit dem Geo-Server Print Plugin ist einwandfrei und wenn man so die bestehenden Möglichkeiten nimmt, dann hat man ein recht leichtes Leben und wie das erstellt wird, dieses PDF erstellt einfach im Client ein JSON, das eben definiert, welchen Ausschnitt genommen wird und welche Layer genommen werden und dann schickt

man dieses JSON an den Server und der Server schickt das PDF zurück, also relativ simpel. Genau, nochmal die Dokumentation. Früher war die Dokumentation eben nur als PDF und es liest, lesen wahrscheinlich nicht so viele Leute und jetzt haben wir es eben auf Sphinx genommen und Sphinx ist eben ein Dokumentationsengine, der in

ganz vielen Open Source Projekten, wie z.B. auch QGIS, genommen wird und eine wirklich Vielzahl an verschiedenen Funktionen hat. Wir haben da eh nur die allereinfachsten Funktionen genommen und man schreibt eben die Dokumentation in RST-Dateien, die ähnlich wie Markdown sind, ein bisschen weniger intuitiv,

aber im Prinzip ist man auch recht schnell drin und hat eben halt den super Vorteil, dass man sofort, man kann die Dokumentation als Webseite eben publizieren, man gibt einen Befehl mit der Kommando-Zeile, die dann den Source Code der Webseite generiert, aber man kann auch genauso guten PDF

draus erzeugen und man kann, wenn man z.B. neue Features einbaut, das dann direkt auch in die Dokumentation reinbauen und automatisch dann immer die aktuellste Version neu bauen, also kann ich sehr weiter empfehlen. Was ein bisschen problematisch ist, also was auf jeden Fall geht, ist der

Upload von Daten, aber es ist eben nicht super trivial. Wenn ich jetzt Daten uploaden will, dann nehmen wir das Beispiel von Vector-Daten, dann muss ich erst die Vector-Daten in die Postgres-Datenbank reinladen, das kann man mit QGIS relativ einfach machen, dann muss ich im Geo-Server in der Admin-Oberfläche auswählen, dass ein Layer publiziert werden soll, dann

muss ich ein Styling, entweder bin ich mit dem Styling zufrieden oder ich muss das Styling eben noch mal separat mit SLD erzeugen oder mit QGIS vorprozessieren lassen und auch dem Geo-Server wieder dann das Styling mitteilen und dann als schlussendlichen Schritt muss ich den

neu publizierten Layer in der Web-App einfügen, da haben wir eine JSON-Datei, wo alle Layer drinstehen und genau, also kann man alles machen, man kann neue Layer einfügen, aber es ist nicht so einfach und da habe ich jetzt z.B. auch gelernt, auf der Konferenz gibt

bei Geo-Server ein Import-Plugin, wo man scheinbar relativ leicht Daten importieren kann. Gut, nur ganz kurz als Ausblick, was für Alternativen möglich gewesen wären, das ist nur eine Infografik über Backend- und Frontend-Technologien, was möglich ist, nur erstmal das Backend, es gibt neben Geo-Server eben auch

noch QGIS-Server, Map-Server, Decree, was speziell an QGIS-Server spannend ist, ist, dass man eben das Styling über die GUI machen kann, also über das Programm und nicht in SLD exportieren und so weiter, das ist ein Vorteil und man kann eben PDF-Karten auch

Print Composer von QGIS direkt erstellen, das ist auch ein bisschen leichter. Metadaten haben wir jetzt z.B. direkt in den Source-Code reingeschrieben, was zwar pragmatisch ist und einwandfrei funktioniert, aber es wäre vielleicht schöner, wenn das jetzt in Zukunft über den CSW-Service, also den Catalog-Server for Web eben publiziert und noch als letzten

Kommentar zum Frontend, also wir haben auch überlegt, was können wir nehmen, dass man sich nicht alles selber bauen muss, da gibt es eben schon viele vordefinierten Frameworks, zwischen Map-Bender, Map-Store, Map-Fish, Geo-Mos und wir haben uns aber dafür entschieden, eben die

alles selber zu bauen, weil wir eben ein paar Sachen, wie z.B. Diagramma-Stellung, wirklich selber machen wollten, aber prinzipiell kann man fürs Frontend auch einfach vordefinierte Lösungen nehmen und wenn man will, kann man sich auch alles komplett selber bauen, wie Videos gemacht

haben, man nimmt sich ein Web-Framework, extra AS haben wir genommen, aber heutzutage nimmt man oft Angular, React oder Vue und eine Map-Library und kann dann quasi nach Herzenslust alles einbauen, was man will, aber hat relativ viel Aufwand. Dann wäre ich soweit durch und bedanke mich für eure Aufmerksamkeit.

Vielen Dank, da gibt es sicher noch Fragen dazu oder auch nicht.

Super Vortrag, wie funktioniert das mit dem Diagramm, ist das auf einem Canvas-Element oder ist das jetzt, also dieses Diagrammelement, was XJS ist? Ja, also XJS bietet eben viele Komponenten an und es ist eben eine vordefinierte Diagramm-Komponente und man

kann im Prinzip dann einfach sagen, diese spezielle Komponente soll jetzt ein Diagramm sein und kann dann eben mit dem JSON definieren, welche Daten genommen werden und wie die aussehen sollen und genau, also ist sehr framework-spezifisch.

Ist das an? Eine Frage zu dem Sphinx, wenn ich es richtig verstanden

habe, man hat also quasi eine Eingabendatei und kann dann die Ausgabe-Formate generieren, ist das jetzt nur quasi statischer Text, den man machen kann oder könnte man da z. B. auch dynamisch aus Inhalten der Datenbank jetzt irgendeinen Bericht erstellen, der jetzt quasi textlich gefüllt wird an bestimmten

Feldern mit Abfragen aus der Datenbank? Also ich glaube prinzipiell kann man das machen, ich weiß nur nicht, ob Sphinx dafür gebaut wurde, also es hat wirklich für Dokumentation gedacht und jetzt nicht für Report-Erstellung. Ich weiß nicht, wenn es jetzt um, also geht es um

Reports von irgendwie Geodaten speziell, ja genau, also wenn man das machen will, da gibt es eben Chesapeh, das ist eben eine Chava-Lösung, in der man eben generell Report generieren kann und es gibt eben jetzt auch dieses Map für Sprint 3, baut eben auf diesem Chesapeh auf und da erweitert

es eben sozusagen um Kartendokumente und da kann man auch wirklich sich ausgiebige Reports aus den Geodaten generiert machen lassen. Haben wir jetzt noch nicht benutzt, aber genau, ist prinzipiell möglich.

Noch eine kurze Frage zum Inhalt des Portals. Welche Desasterarten werden dort da überhaupt dargestellt, konnte ich von hinten nicht sehen und wie aktuell sind die Informationen? Ja, gute Frage. Also wie gesagt, ich habe es bewusst mich nicht auf den Inhalt fokussiert. Im Prinzip geht es um alle möglichen Naturgefahren

wie Dürre, Überschwemmungen, Stürme, genau und das wurden eben in Kooperation mit den Entwicklungshelfern vor Ort haben, die das eben aufgezeichnet, genau, teilweise ein paar

Jahre alt, teilweise aktueller, aber genau, ich muss ehrlich zugeben, ich habe mich mit den Daten an sich jetzt nicht intensiv beschäftigt, das haben wir andere gemacht. Ich war der Techniker, der das alles implementiert hat. Ja schon, ja, genau, also wir führen jetzt noch ein Training durch mit den Leuten vor

Ort, dass die eben auch ihre Daten hochladen können und das Ziel ist schon, dass es weitergeführt wird. Dankeschön. Gibt es noch Fragen? Sonst bedanke ich mich bei Jakob Micks und

ja, Dankeschön.