geOrchestra als Unternehmens-GDI
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 88 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/56724 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
16
20
32
34
45
46
67
75
78
79
80
85
00:00
MARKUS <Unternehmensspiel>Meeting/Interview
00:36
Meeting/Interview
00:56
Open sourceCodeServer (computing)CLOU <Programm>Stack (abstract data type)Spatial data infrastructureGeoServerZugriffskontrolleAuthenticationProxy serverDownloadLink (knot theory)InternetdienstForestYAML <Framework, Informatik>ScalabilityGraphical user interfaceComputer programmingProxy serverDownloadLösung <Mathematik>Route of administrationPoint cloudZugriffskontrolleVersion <Informatik>BerechnungComponent-based software engineeringData streamFibonacci numberComputer fileSlide ruleInstanz <Informatik>Link (knot theory)GeometryScalabilityMobile appServer (computing)Factory (trading post)MetadataFile viewerModule (mathematics)Complete metric spaceAtomic nucleusComputer animation
09:45
Server (computing)ScalabilityGraphical user interfaceComputer programmingZugriffAuthenticationProxy serverGateway (telecommunications)LoginGoogleHTTPAuthorizationProviderMathematical optimizationService (economics)Windows AzureModule (mathematics)MetadataOpen sourceServer (computing)UntermodulInstanz <Informatik>DiagramPlane (geometry)GeometryComputer programmingModule (mathematics)User interfaceScalabilityHand fanParsingSingle sign-onFactory (trading post)AuthenticationMobile appProxy serverZugriffAtomic nucleusRestriktion <Mathematik>Gateway (telecommunications)Gebiet <Mathematik>Point cloudPasswordSanitary sewerLink (knot theory)Spoke-hub distribution paradigmAttribute grammarOnline chatVersion <Informatik>GeoServerYouTubeComputer animation
18:34
Open sourceInterface (computing)Version <Informatik>AuthenticationPoint cloudConfiguration spaceUser interfaceSpatial data infrastructureLink (knot theory)File viewerPressureInternetdienstComponent-based software engineeringLevel (video gaming)Online chatJSONXML
Transcript: German(auto-generated)
00:08
So, wir kommen zurück aus der Pause. Nach unserem letzten Vortrag über den Web-Mapping-Server DECREE geht es jetzt zu dem Projekt GEO Orchestra bzw. der
00:23
Titel des Vortrags heißt GEO Orchestra als Unternehmens-GDI. Das ist ein spannendes Projekt, das ganz viele verschiedene Open-Source-Projekte verbündelt und dazu wird uns jetzt Andreas Jobst und Emmanuelle Bilot was
00:43
erzählen. Wir hören jetzt erstmal den Vortrag an und Fragen dürfen gern im Fragentapp gestellt werden und werden am Schluss dann beantwortet und dann freuen wir uns jetzt auf den Vortrag. Herzlich willkommen zu diesem Vortrag
01:05
zum Thema GEO Orchestra als Unternehmens-GDI. Mein Name ist Andreas Jobst und ich bin Projektleiter bei Camp2Camp. Wir starten mit einer Vorstellung von Camp2Camp. Danach gibt es einen Überblick über das Open-Source-
01:21
Projekt GEO Orchestra und dann gehen wir direkt zum Einsatz bei Unternehmen. Am Schluss gibt es noch einen Ausblick auf die Version 22.0. Camp2Camp ist ein Open-Source-Dienstleister seit 2001. Wir haben über 140 Angestellte und
01:45
davon sind über 40 im GEO Spatial Bereich tätig. Wir haben nicht nur Lösungen im GEO Spatial Bereich, sondern auch in den Bereichen Business und Infrastruktur. Auf der GIS-Seite decken wir viele Anwendungen ab in
02:06
unserem Open-Source-GIS-Stack. Viele Anwendungen und Technologien dazu zählen im Bereich Frontend, Open-Layers und GEO Mapfish. Als Drucklösung verwenden wir Mapfish Print, was wir aktuell halten und
02:27
weiterentwickeln. Und eben bei den Metadaten und GEO-Dateninfrastrukturen setzen wir auf GEO Network und GEO Orchestra. So, dann beginnen wir mit
02:42
dem Open-Source-Projekt GEO Orchestra. Was ist GEO Orchestra? Es ist eine modulare und interoperable Open-Source-GEO-Dateninfrastruktur. Auf der rechten Seite sehen Sie schematisch den Modularen Aufbau mit den einzelnen Apps oder Modulen. GEO Orchestra wurde vor mehreren Jahren
03:04
als Inspire-konforme GDI ins Leben gerufen und ist wirklich als eine komplette, vollständige GDI zu verstehen. Zentrale Elemente sind der OGC-konforme Kartenserver, Geo-Server. Für die Zugangskontrolle kann auch
03:27
ein GEO-Fans dazugeschalten werden und als Metadatenkatalog fungiert eben das GEO Network. Es hat einen eigenen Karten-Viewer, den Mapfish und noch weitere Komponenten. Dazu zählen unter anderem ein im Kern installierter
03:47
Security-Proxy. So, genau, also was macht GEO Orchestra besonders geeignet für den Einsatz bei Unternehmen? Nun, es ist einmal das zugrunde liegende
04:04
Spring-Framework. Das ermöglicht die vereinfachte Integration von externen Anwendungen oder Apps. Will man zum Beispiel einen alternativen Karten- Viewer einbinden, dann ist es relativ einfach umsetzbar mit dem
04:21
Spring-Framework. Bei einer Unternehmens-GDI ist auch die Sicherheit sehr wichtig. Dafür liefert GEO Orchestra einen ausgereiften Proxy. Und der erfüllt die Sicherheitsanforderungen insbesondere von größeren Unternehmen. Man braucht einen performanten
04:44
Datenlieferant. Dafür verwenden wir den GEO-Server und der Metadaten- Katalog läuft dann über GEO Network. Da kann man eben einmal schon den direkten Download von kleinen Dateien bekommen oder zumindest bei größeren
05:03
Dateien einen Link. Zum Beispiel zu einem WFS-Dienst, der dann vom GEO-Server bereitgestellt wird. Aber am besten kann man, glaube ich, den Anwendungsfall Enterprise-GDI an einem realen Projekt zeigen. Und dafür
05:23
verwende ich heute das Deutsche Telekom-Projekt, in dem wir seit dieser Slide kommen, von der Deutschen Telekom. Er zeigt aber gut die verschiedenen Daten, die in diesem Projekt verwendet werden und die
05:41
verschiedenen Datenströme. Und da wären wir auch schon bei der Berechtigung der GDI. Also es braucht natürlich eine gute Infrastruktur, wo diese ganzen Daten eingepflegt werden können und zugänglich gemacht werden können. Um was geht es in dem Projekt? Das Projekt läuft unter
06:06
dem Namen FTTH Factory. FTTH steht für Fiber to the Home. Und es geht im Wesentlichen um den Glasfaserausbau in Deutschland. Und dieser
06:21
Glasfaserausbau soll möglichst automatisiert ablaufen. Dafür werden terrestrische Daten genutzt. Die kommen von sogenannten Surface Cars. Sehen sie oben links. Surface Cars zeichnen Punktwolken auf. Und man bekommt dadurch eine relativ genaue Darstellung der Oberflächen
06:48
und Surface-Daten durch diese Befahrungen. Dazu gibt es dann noch Ortofotos und viele weitere Daten. Diese ganzen Daten werden verrechnet,
07:01
zusammengebracht und sollen im Endeffekt die Berechnung von potenziellen Trassen ergeben. Und mit Hilfe von diesen potenziellen Trassen kann man möglichst kostengünstig neue Glasfaserleitungen verlegen. So, die
07:22
GDI basiert auf G.O. Orchestra im FTTH Factory Projekt. Sie hat die Standardaufgaben einer GDI, also die Bereitstellung von Kartendiensten. Es braucht diverse Suchdienste, um nach den Daten suchen zu können.
07:41
Und man kann auch sagen, dass sämtliche Module genutzt werden, also sämtliche Standardmodule von G.O. Orchestra, bis auf die MAPFISH App, die Atlas Druck App und die Extractor App. Und was wir vorher gesagt haben,
08:02
dass man aufgrund des Spring Frameworks bestimmte Module sehr leicht durch ein anderes alternatives Produkt ersetzen kann. Das ist jetzt hier beispielhaft aufgezeigt mit Shogun, der MAPFISH GizViewer wurde da ersetzt
08:22
mit dem Shogun GizViewer. Man kann also G.O. Orchestra als Gesamtlösung einsetzen oder modular. Aber im Factory Projekt werden so gut wie alle Module eingesetzt. Noch kurz zum Punkt Deployment. Das ist
08:43
hochgradig automatisiert. Die gesamte GDI lässt sich somit automatisiert wieder ausrollen und skalieren. Jetzt gehen wir ein auf ein paar dieser Module und wie sie im FTTH Factory Projekt genau eingesetzt werden.
09:04
Fangen wir an mit dem Geo Server. Aktuell wird mit zwei redundanten Geo Server Instanzen gearbeitet. Diese sind aufgesetzt worden, um eine bessere Skalierbarkeit zu bekommen. Man überlegt aber aktuell, den Einsatz vom
09:26
Geo Server noch weiter zu optimieren und auf Geo Server Cloud umzusteigen. Das hat noch nicht gestartet, aber ich dachte mir, es ist trotzdem interessant, das kurz aufzuzeigen. Geo Server Cloud ist auch bekannt als
09:42
Cloud Native Geo Server. Unten finden Sie einen Link zum Projekt und der Geo Server Cloud ist im Endeffekt, er ist eine identische Anwendung zur monolithischen Geo Server, unterscheidet sich aber im Aufbau und
10:04
insbesondere in der Zerteilung der Hauptkomponenten in Microservices. Das ist unten in dem Diagramm veranschaulicht. Da sehen wir das Runtime Modul des traditionellen Geo Servers. Da haben wir die User
10:23
Interface, REST und die einzelnen Kartendienste alle in einem Runtime Modul und beim Geo Server Cloud sind die eben zerteilt in Microservices oder Teilmodule. Dadurch haben wir eine deutlich vereinfachte Skalierbarkeit.
10:43
Wir müssen nicht mehrere Instanzen von Geo Server ins Leben rufen. Einzelne BFS oder WMS können wirklich servicebasiert skaliert werden und man hat dadurch auch eine bessere Ausfallsicherheit. Wenn zum Beispiel die User Interface einfriert, dann hat es keine Auswirkungen auf die
11:03
Kartendienste. Das wäre jetzt noch eine weitere Optimierung im FTTH Factory Projekt. Aktuell wird eben der monolithische Geo Server noch
11:20
eingesetzt in Zusammenarbeit mit Geo Fans. Das sieht dann so aus, dass verschiedenste Planer auf die GDI und deren Apps zugreifen und die Daten nur für ein bestimmtes Gebiet sehen oder editieren dürfen. Während man
11:42
eben schon mit Geo Server Restriktionen auf Attribute eines WFS festlegen kann, können räumliche Restriktionen über Geo Fans gemacht werden. Das wird dann verwendet für komplexere Restriktionen, insbesondere
12:00
für den Zugriff der Planer auf diverse Layer, die sie für die Glasfaserplanung brauchen. Nächster Punkt, der Car Server und der Security Proxy. Aktuell verwenden wir den Car Server für die Authentifizierung
12:21
und den im Kern von Geo Orchestra integrierten Security Proxy. Der funktioniert gut. Drittkomponenten werden auch durch den Security Proxy geschützt und der lenkt einfach eingehende Requests zur jeweiligen App um. Aktuell wird am Car Server gearbeitet. Oauth2
12:46
und OpenID sollen auch unterstützt werden. Wir entwickeln gerade auch einen neuen Security Proxy. So, der alte funktioniert, aber mit dem neuen wollen wir noch ein Stück weiter gehen. Er basiert auf dem
13:05
Spring Cloud Gateway und würde dann eben als ein komplettes Gateway funktionieren mit Single Sign-On und könnte sich dann eben zum Beispiel über GitHub oder Google Konto einwählen, unterstützt und Websockets. Und ein wichtiger Punkt ist, der Proxy soll auf OpenID
13:25
Connect basieren. Hier einige Vorteile von OpenID Connect. Erstmal bei der Authentifizierung. Sie läuft dann über einen externen ID-Provider. Sicherheitsrisiken werden minimiert bei Passwörtern zum Beispiel.
13:43
Idealerweise erhält man einen schnelleren Registrierungsprozess und man verwendet einen Industriestandard für das ID-Management. Dann haben wir provided von dem OpenID Connect leichter lesbare oder wirklich
14:03
standardisierte ID-Tokens. Also wird die ganze Info von einer UserID in einem sicheren JSON Web-Token transportiert und bereit gestellt und dadurch werden unterschiedliche Verschlüsselungsalgorithmen unterstützt.
14:21
Er basiert, OpenID Connect basiert auf OAuth 2.0 auf dem Protokoll und läuft dann eben auch über einen standardisierten Prozess, unterstützt Web- anwendungen und ist dann eben dafür sehr gut geeignet. Bei komplexen
14:42
Enterprise-Umgebungen oder einfachen Apps. Und hier in diesem Fall haben wir verschiedenste Zugänge, die von außen auf die GDI zugreifen möchten und glauben eben, dass OpenID diesen Prozess deutlich vereinfachen könnte.
15:06
Noch kurz zum Thema Deployment. Wir haben in der Vergangenheit viele G-Orchester-Instanzen über Rancher deployed. So zum Beispiel das Portal der Stadt Rennes, das Portal von Gio2Frons oder GioRena. Und mit dem deutschen
15:24
Telekom-Projekt fing es eben an, auch ein Deployment von G-Orchester über Kubernetes zu machen. Und bis jetzt hat es sich als eine sehr gute Entscheidung erwiesen. Wir haben nur noch einen einzigen Entry Point für
15:41
das Deployment von den einzelnen Apps. Und wenn die einzelnen Apps einmal paketiert sind, dann können sie auch auf alternativen Cloud-Lösungen deployed werden. Also ein Umzug von der eigenen Cloud auf AKS oder EKS
16:05
kann dann eben mit den paketierten Apps relativ problemlos gemacht werden. Gut, das war es zum Thema FTTH Factory und G-Orchester. Jetzt eben noch
16:22
ein kurzer Ausblick zur Version 22.0, die bald released werden soll. Da drinnen haben wir GeoNetwork 406. Die größte Neuerung von GeoNetwork 406, dem Metadatenkatalog, wäre die verbesserte Suche über Elasticsearch.
16:45
Wir haben auch zwei neue Module im G-Orchester 22. Das eine ist der DataFeeder. Der erleichtert es Nutzern, Daten in die GDI hochzuladen. Es kann also über eine einfache User Interface Daten hochgeladen werden.
17:04
Die gehen dann direkt in eine PostGIS Datenbank, werden als Layer über GeoServer publiziert und ein Metadatersheet wird erzeugt. Mehr dazu finden Sie auf einem YouTube Video, wenn Sie nach GeoOrchester und DataFeeder suchen. Das weitere Modul ist dann noch das Data Hub. Das Data Hub ist
17:27
für die Öffentlichkeit gedacht, die keine komplizierte kategoriebasierte Suche braucht und liefert über die Eingabe von Schlagwörtern auch eben
17:41
die ganzen Records aus dem Katalog zu einem gewissen Schlagwort oder einer namenbasierten Suche. Hier ist ein Beispiel von Geo2Franz. Der Link ist auch auf dem Slide angegeben. Gut, damit sind wir am Ende dieser
18:04
Präsentation. Wenn Sie noch Fragen haben, dann können wir die gerne versuchen, jetzt im Anschluss über den Chat zu beantworten. Sonst können Sie aber auch gerne zu uns in den Exporaum kommen und der Link dazu finden Sie auf Ihrer Foskes Seite, wenn Sie bei uns suchen im Menü links
18:26
unter Kanäle. Herzlichen Dank. Vielen Dank Andreas für deinen spannenden
18:42
Vortrag. GeoOrchester hat wirklich sehr viele Features und da gibt es sicher einige Fragen vom Publikum, die jetzt gerne im Fragentapp gestellt werden können. Eine Frage, die ich jetzt gleich im Vornherein schon mal habe, muss man denn alle Features benutzen oder kann
19:02
man auch einfach Features, die man nicht braucht, irgendwie ausschalten direkt bei der Konfiguration? Ja genau, also das ist eben gut möglich. Das ist eigentlich auch der Grundgedanke von dem modularen Aufbau und was wir da gezeigt hatten vom Deutsche Telekom Projekt, sind eben auch einige
19:24
Module nicht im Einsatz oder man kann eben auch, wie in dem Fall bei dem Map Viewer, hatten wir noch diesen Mapfish Viewer drinnen, dann konnte man den ersetzen durch den Shogun Viewer und dort zum Beispiel, wir haben ja
19:43
dann noch dieses Atlas-Modul, wo man auch so Drucke erstellen kann, das wird dort nicht genutzt und noch so ein Extractor-App, wo man automatisiert einfach so, wo es um Pakete von Daten geht und genau, aber
20:07
im Wesentlichen kann man wirklich das Ganze auch nur mit Geo-Network, Geo-Server, Security-Proxy, Authentifizierung laufen lassen. Das wären vielleicht so die Grundmodule. Meistens braucht man ja
20:23
auch einen Viewer, also im Endeffekt werden dann doch mindestens so zwei Drittel aller Module genutzt. Okay, denke ich mir, wenn man ja so eine GDI hat, die hat ja häufig ähnliche Grundfunktionalitäten, sind nur noch mal im Detail unterschiedlich. Du hast jetzt noch Geo-Server erwähnt, dass man einmal die klassische
20:43
Variante benutzt und einmal gibt es das Geo-Server Cloud. Da würde mich jetzt noch mal interessieren, wie der Unterschied ist, jetzt das Geo-Server Cloud zu konfigurieren im Gegensatz zu dem klassischen Geo-Server, ob man das dann auch über so eine Benutzeroberfläche machen kann oder ob man das über eine Rest-Schnittstelle machen kann oder wie man den
21:03
Geo-Server Cloud dann einstellen kann. Genau. Ja, also im Wesentlichen ist die Konfiguration wirklich gleich. Die einzelnen Layer werden wirklich über die Benutzeroberfläche
21:20
erstellt vom Geo-Server, aber es gibt dann auf, ja, müssten wir im Detail noch mal, könnten wir auch noch mal auf dem Expo-Stand besprechen, aber was ich weiß, dass es eben eine Konfigurationsebene gibt, über der man dann einfach die einzelnen Dienste steuern kann, also wo man
21:44
WMS-Dienste skalieren kann, aber für den Nutzer, wenn es einmal aufgesetzt ist, es braucht so ein paar Tage eben, dann ist aber die Bedienung wirklich gleich. Also es ist wie beim klassischen Geo-Server.
22:04
Alles klar, also hat sich dann quasi nur der Unterbau ein bisschen verändert. Genau, genau. Okay, dann eine Frage, die sich da mir auftränkt, wenn jetzt mal ganz viele verschiedene Projekte miteinander orchestriert, wie ihr das macht, dann kann ich mir vorstellen, dass wenn jetzt ein Projekt abgedatet wird und das andere
22:22
nicht und dann neue Schnittstellen sind oder so, wie wird es dann gemacht wird, dass die synchron gehalten werden oder kann ich jetzt irgendwie auch sagen, ich möchte bei einem Projekt jetzt noch eine alte Version benutzen, weil die aus irgendeinem Grund eben noch benutzen will und bei den anderen schon weiter nach vorne eine neue Version nehmen, also ist
22:43
das so vorgesehen oder wie handhabt ihr die? Meinst du beim Geo-Server oder beim Geo-Orchester? Bei Geo-Orchester, also jetzt bei den gesamten Projekten. Ja, genau, also das ist ein guter Punkt. Ich schaue nochmal genau, also es wird schon immer so, der Hintergedanke
23:05
ist schon, dass man genau weiß, wenn man jetzt zum Beispiel sagt, die neueste Version, die bald zugänglich sein soll, 22.0, dass man genau sagt, okay, es macht Sinn, dass die, dass die Komponenten
23:22
teilweise auch Abhängigkeiten haben untereinander, dass man dann wirklich was mit dem Paket quasi mitkommt, benutzt. Es gibt aber Beispiele, ich glaube in Frankreich sind es mindestens über zehn Instanzen, die in den Regionen laufen, wo sicher auch mal
23:41
eine ältere Geo-Network-Version drinnen ist, wo es trotzdem läuft. Aber es kann natürlich sein, dass es dann schon zu Problemen kommt, wenn man jetzt zum Beispiel einfach eine ganz alte Geo-Network-Version hat.
24:01
Und im Idealfall bleibt man bei den Versionen, wie sie dann auf der GitHub-Seite angeboten werden. Okay, verstehe, macht Sinn, also außen macht jetzt wahrscheinlich etwas ganz Spezielles vor, dann muss man da selber Hand anlegen. Jetzt kam gerade noch eine Frage rein, nochmal zu Geo-Server Cloud,
24:24
und zwar wird der Geo-Server Cloud parallel zu der normalen Version von Geo-Server entwickelt? Genau, ich kann hier auch gleich nochmal den Link in den Chat
24:41
schreiben vom Repository, vom Cloud, das heißt dann Cloud-Native Geo-Server auf der Seite. Aber der Gedanke war die aktuellste Version, ich muss gleich nochmal nachschauen, vom Geo-Server zu nehmen und dann auch, wenn der Geo-Server in die nächste Version geht, dass man wirklich immer
25:05
auch mit der aktuellsten Version vom klassischen Geo-Server arbeitet. Und soweit ich das verstanden habe, einer der Hauptentwickler dahinter ist Gabriel Rolldahn und soweit ich das verstanden habe, ist es auf jeden Fall
25:26
das Ziel, die beiden immer aktuell zu halten. Also es wird jetzt kein separater Geo-Server-Vorgang sein beim Cloud. Und wenn sich nichts grundlegend das ändert im Geo-Server, dann ist es anscheinend auch
25:41
nicht zu aufwendig, die beiden so gemeinsam fortzuführen. Alles klar. Dann würde ich sagen, haben wir jetzt schon einen super Eindruck gewonnen. Also vielen Dank an Andreas und Camp2Camp für den Vortrag.