So, nun zum Vortrag von Emmanuel. Es geht, und das muss ich wirklich vorlesen, um eine Inspire GDI, die basiert auf den besten Open Source Komponenten. Das ist ein starkes Statement und da bin ich mal gespannt, was du dazu sagst. Ja, danke Jan. Willkommen zu meinem Vortrag zur G-Orchestra,

zur Open Source GDI. Ich habe letztes Jahr schon einen Vortrag gemacht zum Stern von

der G-Orchestra. Ich werde die Version 17.12, die gerade Ende letztes Jahr veröffentlicht wurde, vorstellen. Zu meiner Person, ich heiße Emmanuel Belot, ich bin Leiter der Geospatial Abteilung bei Camp2Camp. Camp2Camp ist ein Open Source Hersteller und Integrator auf drei Länder,

das heißt in der Schweiz, in Frankreich und auch in Deutschland mit der Niederlassung in München. Wir sind 80 Mitarbeiter und wurden 2001 gegründet, das heißt mehr als 15 Jahre Open Source Erfahrung jetzt. Zu den Abteilungen, Geospatial ist die größte Abteilung,

wir machen traditionelle Web-Giz, Webmapping, GDI, Mobile Anwendung für Geospatial, 3D Virtual Globus, Business und Infrastruktur. Und vielleicht, was interessant ist, die Konstellation von Camp2Camp ist die Zusammenarbeit zwischen Geospatial und

Infrastruktur. Das ist heutzutage eine wesentliche Herausforderung, eine skalierbare georderte Infrastruktur zu planen, zu installieren, zu warten, zu skalieren und dank der Zusammenarbeit schaffen wir das, denke ich gut.

Zur GDI. Was ist der Konzept hinter einer GDI wie G-Orchestra? Man hat eigentlich mehrere GDI, wie in Deutschland, föderalistische Länder. Wir haben mehrere GDI, die Dienste und Daten austauschen. Das heißt, wir entwickeln auf Basis von OGC-Diensten.

Natürlich in einer GDI gibt es auch Fachanwendungen, die auf diese Dienste zugreifen und externe Anwendungen, die auch auf diese Dienste zugreifen.

So den Kernpunkt, dass die Interoperabilität funktioniert auf Basis von OGC-Standards, das ist sehr wichtig, weil das ermöglicht die Zusammenarbeit sämtliche Komponenten. So G-Orchestra, wir haben das als Grundsatz genommen und auf Basis von bestimmten

Komponenten, wie Geo-Server, Geo-Network und weitere, wir haben so eine modulare Interoperabilität, georderte Infrastruktur entwickelt. Das hat man im Jahr 2009 gemacht, das war für Region Bretagne in Frankreich. Ich war damals Projektleiter und es wurde als Open Source Lösung veröffentlicht und jetzt hat sich

eigentlich das Ganze gewachsen, dass eigentlich ein Drittel der französischen Regionen nutzen diese GDI für deren Plattformen, aber auch Großunternehmen wie Deutsche Telekom in Deutschland nutzen auch Geo-Orchestra für deren

Glasfaserausbauplanung zum Beispiel. So wie sieht es aus? Es ist modular, das heißt, das erste zentrale Punkt, das ist die obenrechte der CAS-Zentrale Operation, das heißt alles

geht über ein Proxy, der ermöglicht den Benutzer sich anzumelden und dieser CAS gibt weiter Username-Rollen an den unterschiedlichen Komponenten. Man sieht, dass es gibt Geo-Server oben links, das heißt in der letzten Release, die letzte Release von Geo-Server drin, es gibt Geo-Network als Metadaten-Katalog

auch mit der letzten Version von Geo-Network, das heißt, wenn man Geo-Orchestra installiert, man bekommt auch Geo-Network 3.4 mit. Es gibt einen Viewer, es gibt ein Modul, um Daten zu extraieren, Download, Datenvorbereitung, es gibt

ein Caching-Mechanismus mit Geo-Webcache, auch ein berühmtes Open-Source-Komponent, es gibt eine Konsole, um seine Benutzer zu verwalten oder Rechte zuzuweisen, ein Atlas-Modul für Print-Reporting und so weiter und Geo-Fans auch für Webdienste zu sichern. Man sieht, es gibt eigentlich alle Modulen, um eine

vollständige DI, die vollständige Funktionität anzubieten. Und den modularen Aufbau von Geo-Orchestra erlaubt, dass man regelmäßig die Versionen der unterliegenden Komponenten upgradet mit jedes neuen

jährlichen Release. Wenn man baut zusammen so viele Komponenten, es muss auch sehr viel getestet werden, sondern man hat etwas Unstabiles. Das heißt, ich denke, das ist ein wichtiger Element. Wir haben auch zahlreiche Jenkins

oder continuous integrations und Tests, die ermöglichen und die laufen täglich und das ermöglicht zu identifizieren, falls es gibt ein Geo-Server, Geo-Network zum Beispiel, aber auch um

den reinen Geo-Orchestra-Projekt, der macht die Verbindung zwischen den Komponenten. So zahlreiche Tests laufen auf eine reguläre Basis und bei jedem neuen Commit oder Pull Request. Und diese CI, continuous integration,

die bildet auch Debian Packages, RPM Packages, Docker Images, so dass man diese GDI auf zahlreiche unterschiedliche Umgebungen installieren kann. Und natürlich auch Website und weitere Elemente sind auch mit dieser CI verwaltet. Ich habe schon gesagt, dass Interoperabilität ist

ein wichtiger Aspekt. Natürlich um die OGC Standards wie WMS, WFS, WFS Transaktional, WMTS, CSW, WCS und weitere, so dass zum Beispiel QGIS, ArcGIS

als Client diese nutzen können. Es gibt auch ein Vector-Tiles Endpoint, das heißt, man kann die Vector-Tiles mit Geo-Server, mit der letzten API, wie zum Beispiel die Geo-Server-Rest-API oder die Geo-Network-Rest-API, die

ermöglichen, für bestimmte Fälle einfacher oder schneller an den Daten zuzukommen. Und der Komponent der Swiss Army Knife in dieser Geo-Orchester-Plattform, auf dieser Java-Plattform, ist natürlich Geo-Tools,

die Abstraction Library, die ermöglicht zahlreiche Datenformate und zahlreiche Dienste zu lesen oder zu schreiben. Das heißt, hier hat man Zugriff auf ein sehr breites Datenformat. Ich habe gesagt,

Interoperabilität, es ist natürlich mit den externen Elementen, aber auch Modularität innerhalb der Komponenten. Geo-Orchester ist auf was ist von Spring Framework aufgebaut. Und das heißt, wir haben hier ein Projekt gemacht, wo wir in Zusammenarbeit mit der Firma Terrestris, wo wir Shogun als

Komponent oder in Zusammenarbeit mit Geo-Orchester eingebaut haben. Das heißt, mit diesen Modulen, es ist durchaus möglich, die Geo-Orchester- Basis zu nehmen, Sicherheits, Geo-Server, Geo-Network und noch den Viewer von Shogun zu benutzen, anstatt den Viewer von Geo-Orchester. Oder

ein Teil der Administration-Möglichkeiten von Shogun anstatt der Elementen von Geo-Orchester. Diese Modularität ermöglicht in dieser Java- Welt auch eine sehr breite Einsatzmöglichkeit. Und das ist eigentlich uns gelungen sehr schnell. Es war kein langes Projekt, um dieses

modulare Zusammenbau zu machen. Ich denke, es ist ein Weg, das sehr interessant ist, auch für die Zukunft. Ich habe am Anfang gesagt, dass die Zusammenarbeit der Infrastrukturteam bei Camp2Camp ist uns wichtig und

bietet einen großen Vorteil. Und ein Element dieser GDI Geo-Orchester ist diese Möglichkeit, auf zahlreiche unterschiedliche Plattformen die zu deployen. Das heißt, üblicherweise, oder man hat die eigentlich auf Debian, unten rechts, mit Debian Packages installiert. Dann hat jemand in der

Community eine Ansible Recipes bereitgestellt, sodass man das auch mit Ansible installieren kann. Dann haben wir auch Docker-Containers vorbereitet, sodass man auf einen Entwicklungsrechner zum

Beispiel die GDI installieren kann. Dann mit einer bestimmten Composition, die ermöglicht, in zehn Minuten einfach die GDI zu installieren und zu starten. Sehr, sehr effizient. Zurzeit laufen zahlreiche Regionen auf Basis von Rancher. Das ist ein Orchestrierungssystem, das ermöglicht,

mehrere Docker-Containers auf mehreren Hosts zu verteilen. Und wir haben auch letztlich in den letzten Monaten Geo-Orchester auf Basis von OpenShift deployed und installiert. Das heißt, wir haben jetzt auch Helm-Packages,

sodass man schnell Geo-Orchester auf OpenShift installieren kann. Man sieht, es gibt wie eine, vielleicht hätte ich es auf die andere Richtung darstellen, aber man hat wie eine, vielleicht langsam alte Welt mit den Debian-traditionellen Installationen und die ganzen Mechanismen jetzt, die eigentlich viel Momentum haben.

Und ich denke, dass wir da weiterhin so wachsen. So, ich werde jetzt noch einige Folien zeigen zum eigentlichen Benutzeroberflächen von Geo-Orchester. Vielleicht noch ganz kurz. Sie sehen im Header, es gibt Katalog-Viewer,

Extractor-Service und Verwaltung. Das ist auch eine Neuigkeit von der letzten Version. Das ist auch die eigentliche Übersetzung von diese, nicht die Komponenten unterhalb, aber die georchester-spezifischen Elementen.

Und das ist ein Beitrag von der Region Alsace in Frankreich, wo wir Geo-Orchester installiert haben. So, ganz schnell, es basiert auf Geo-Network 3.4. Das heißt, Sie können mit dem Inspire-View die Dienste und die Daten dort beschreiben. Das heißt,

die Dienste und die Metadaten, die einmal beschrieben sind, kann man die dann veröffentlichen. Da hat man für den Benutzer eine Darstellung der Elementen. Man kann das auf einer Karte darstellen oder per CSW oder per API veröffentlichen.

Die Daten der GDI werden in eine PostgreSQL-Postgeist-Datenbank oder als zum Beispiel Geo-TIF-Files. Vielleicht auch mit einer cloud-optimierten Struktur, sodass man diese Files auf einem S3-Bocket zum Beispiel speichern kann und über den

Geo-Tools herauslesen können. Dann natürlich gibt es Geo-Server. Das ist der bekannte Geo-Server, der in zahlreichen Einsatz ist. Für die WMS, WFS-Veröffentlichung.

Natürlich gibt es die Möglichkeit, Daten zu suchen über die Geo-Network-Benutzer über Fläche, über Keywords oder weitere Dienste zu suchen. Und dann in den Viewer, das heißt in der Map-Fish-App. Es ist möglich, da über mehrere Zugänge auf eine Datei oder auf

den Katalog, wo man da vielleicht einen freien Text angibt. Und da findet man dann ein Layer mit einer Vorschau, das man dann laden kann. Oder über einen Tesorus, wo man auf bestimmte Keywords dann suchen kann. Oder über einen OG-Server, wo man einfach

den Get-Capabilities gibt. Und da sucht man innerhalb von Get-Capabilities auf bestimmte Elemente. Oder man kann natürlich auch eine Datei, ein KML, ein Shape als Zipper, kann man das auch hochladen und auf dem Viewer darstellen. Einmal, dass man seine

Karte vorbereitet hat. Es ist auch möglich, die Karte zu teilen, indem man einen Permalink vorbereitet und weiterleitet. Und man kann das auch als Map-Kontext,

als WMC, Webmap-Kontext, kann man das auch speichern und dann wieder eröffnen als Datei. Es basiert auf OGC-Standards. Das heißt, einmal, dass man auf ein WMS liest, dann kann man es dann auch stilisieren oder filtrieren, wie man es möchte. Das heißt,

hier nutzt man in Geo-Orchestra die Vorteile und den kartografischen Motor, der unterhalb von Geo-Orchestra liegt. Das ist dann den modularen Aufbau, so Styling, aber auch WFS-Styling, wenn man das möchte. Man kann natürlich abfragen

mit bestimmten alphanumerischen Kriterien und da hat man unterhalb von der Tabelle die Filtrierung, indem man ein Polygon zeichnet und dann sagt, ok, ich möchte alles, was drin ist, zum Beispiel, oder in Zusammenarbeit mit den Attributen.

Wir können Buffer rund um Objekte machen, Erfassung und Objekte editieren ist dank WFST auch möglich für alle Daten, die per Geo-Server so veröffentlicht sind. Und dann der Administrator oder die Plattform, die kann noch weitere Elemente implementieren,

wie hier zum Beispiel eine Street-View-Integration, indem man klickt auf diese Kreuzung und das ermöglicht genau zu sehen, wie es aussieht, zum Beispiel. Oder die Möglichkeit hier so Atlas zu drucken, indem man zum Beispiel sagt, ich möchte die

Gemeinde zu diesem Maßstab drucken mit dieser Legende und dann ein Folio Atlas wird vorbereitet und als PDF zum Download angeboten. Natürlich Data Extraction. Wir

haben gesehen, dass heute Morgen es wichtig ist, Files eigentlich als Download anzubieten, neben den Diensten, aber auch den Weg hier mit Extraction ist auch interessant. Das heißt, der Benutzer, der kann wählen, für welchen Ausdehnung er seine Datei möchte, in welchen

Formen, in welcher Aufstellung, in welcher Projektion. Und dann der Geo-Tools Backend überarbeitet das auf Basis der Standards, WCS, und packt das in ein Zip und sendet den Link zum Download an den Benutzer. Das heißt, freie Möglichkeit, Daten zu extraieren. Mit der

Möglichkeit für den Platform-Manager, die Jobs zu verwalten. Dann natürlich, es ist erweiterbar, das heißt, in Frankreich, man hat so, wie Alkis, aber die Möglichkeit so, das Kataster herunterzuladen für ein bestimmtes Gebiet oder einen bestimmten Datum. Oder es gibt

die Möglichkeit, innerhalb der GDI, wie an einem Dropbox, das heißt, die Mitarbeiter können sich anmelden an der GDI, mit deren übendem Passwort, und haben auch die Möglichkeit, dort eine Partei hochzuladen, um die dann mit bestimmten Mitarbeitern dann auszutauschen. Das

heißt, es ist auch möglich, zum Beispiel, ich weiß nicht, man könnte sich vorstellen, man macht ein Kugis-Projekt, der nutzt die Dienste von der GDI, und dann teilt man sich das Kugis-Projekt mit weiteren Benutzern der GDI, sodass sie es auch weiter

benutzen können. Und das ist die gleiche Authentification, wie bei der GDI, man hat den gleichen Zugriff auf die Dienste. Und es läuft alles auf deren eigenen Server, wie die anderen Elementen der GDI. Okay, die Community hat weitere Features selbst

entwickelt und zur Verfügung gestellt. Ja, ich habe gesagt, es gibt so einen Single-Signal, das heißt, man kann alle üblichen Elementen sichern, wie ein LDAP für die Benutzermanagement, Metadata-Dienste und Features zum Beispiel. Und man kann auch weitere Elementen hinter dieses Sicherheitsproxy einbauen. Weitere Elemente wie Benutzerverwaltung mit bestimmten

räumlichen Kompetenzen, Zonen zum Beispiel oder ein Tools, das GDI-Konsistenz sieht, das ermöglicht zu überprüfen, dass alle Dienste in einer Metadata vorhanden sind

oder alle Daten, die zur Verfügung gestellt sind, auch dokumentiert sind und umgekehrt, dass die Konsistenz der GDI gecheckt wird. Und es gibt auch einen ganzen Teil von Monitoring, so hier zum Beispiel, welche Benutzer, welche Request zum Beispiel und auch umgekehrt

die System-Monitoring, wo man weiß, für welchen Server, wie viel Load und wie viel Memory und solche Elemente. Das heißt, entweder von den fachlichen Aspekten oder von den System-Administration Aspekten. So, hier die Architektur. Ich werde das

nicht vorstellen, zu sagen, es ist eigentlich alles hinter ein Sicherheitsproxy. Es wird alles über Dienste zur Verfügung gestellt und man stützt sich auf die besten Open-Source-Komponenten, Geo-Network, Geo-Server, Geo-Webcache und weitere Komponenten. Und ja, genau wie ich es schon habe,

es ist auch möglich, so Shogun in oder mit Geo-Request zu benutzen. Das heißt, man kann auch zum Beispiel bestimmte Elemente hier, wie die neue XJS-Viewer von Shogun

benutzen oder den zukünftigen React-Viewer benutzen. Ja, und noch einige Elemente, so hier das Rancher-Katalog. Das heißt, alle diese Komponenten sind zur Verfügung als Composition für die Benutzung der GDI in ein Orchestrierungssystem. Oder hier eine

Open-Shift-View von einigen der Komponenten. Hier zum Beispiel der CAS, die Authentification, die funktioniert auf ein Pod in dieser Deployment. So, die Roadmap, die Community,

die Orchestra-Community trifft sich in Juni in Paris für das nächste Viewer, weil der basiert nur auf Open-Leer 2. Das heißt, es ist ein Thema für dieses Jahr, Neuaufbau von Viewern. Und natürlich, es wird ein responsive Viewer sein,

mit 3D-Möglichkeiten, so State of the Art. Und Sie finden sämtliche Informationen auf Internet, zum Beispiel georgestra.org als Webseite. Alle Komponenten sind dokumentiert und der Code ist auf dem GitHub. Und es gibt auch eine Mailing-Liste, wo man sich

erinnern kann. Und natürlich Camp2Camp als Open-Source-Hersteller steht auch zur Verfügung, um sich zu helfen für die Installation oder für die weitere Entwicklung oder Pflege der GDI. Danke für die Aufmerksamkeit.