Integration von verteilten Geo-Daten in Forschungsdateninfrastrukturen mit Hilfe von GeoNode
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 88 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/56813 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
16
20
32
34
45
46
67
75
78
79
80
85
00:00
SystemplattformGeodätische LinieBesprechung/Interview
00:29
SoftwareInformationGeoinformatikGebiet <Mathematik>Open SourceGeodätische LinieOpen SourceGeoinformatikDienst <Informatik>Gebiet <Mathematik>MikroarchitekturSoftwareZugbeanspruchungFokalpunktImplementierungErweiterungComputeranimation
02:17
TINA <Telekommunikation>DifferenzierbarkeitAnalysisMetadatenLastSystems <München>InformationsmodellierungAnalysisPunktComputeranimation
03:47
InformationSoftwareLastAPIZugriffBewegungHypermediaTRAMO <Programm>StichprobenumfangVelocity <Framework, Informatik>Dienst <Informatik>Dienst <Informatik>RouterVektor <Datentyp>Maschinelles LernenTraktrixDatensatzPrognoseverfahrenPositionPermanenteStrömungConstraint <Künstliche Intelligenz>Computeranimation
07:40
ARCHIVE <Programm>AnalysisUmweltdatenMaschinelles LernenFRAMEWORK <Programm>DatenformatPILOT <Programmiersprache>Trajektorie <Kinematik>RouterKennzahlComputeranimation
10:43
Umsetzung <Informatik>
11:04
InternetdienstAPITrajektorie <Kinematik>RoutingSystemplattformSkalierbarkeitMechanismus-Design-TheorieDienst <Informatik>Plug inMetadatenWald <Graphentheorie>SkalierbarkeitAnpassung <Mathematik>ErweiterungDatensatzUmsetzung <Informatik>Maschinelles LernenRemote ServiceDienst <Informatik>SystemplattformApp <Programm>MengeVektor <Datentyp>WEBEin-AusgabeAnbindung <Informatik>MetadatenSIMPL <Programmiersprache>ComputeranimationFlussdiagramm
16:22
APIFunktionalitätDienst <Informatik>Mechanismus-Design-TheorieDifferenzierbarkeitAnalysisMetadatenPhysikalische GrößeDienst <Informatik>FokalpunktStreuungsdiagrammMaschinelles LernenDatensatzSystemplattformSkalierbarkeitAnpassung <Mathematik>AnwendungssoftwareSenderSicherungskopieKlumpenstichprobeWeb ServicesAlgebraisch abgeschlossener KörperDatenbankRemote ServiceWEBComputeranimation
21:40
ServerMeterFRAMEWORK <Programm>Maschinelles LernenGeoServerFunktionalitätInterface <Schaltung>MengeLaden <Datenverarbeitung>Keller <Informatik>ZugriffRechenzentrumInstanz <Informatik>Ein-AusgabePlug inDatensatzChatten <Kommunikation>Besprechung/Interview
Transkript: Deutsch(automatisch erzeugt)
00:07
Ja, herzlich willkommen zurück auf Bühne drei. Wir hatten im ersten Vortrag das Thema Wissensmanagement in verteilten Teams und jetzt geht es im Prinzip auch um Wissensmanagement und zwar mit Geodaten und zwar mit der Plattform Geonote.
00:22
Was Geonote ist, was es alles kann, das zeigen uns jetzt Benedikt Greler und Mathis Rieke. Guten Morgen, mein Name ist Mathis Rieke. Ich bin von der Firma 52 North und ich möchte heute über Geonote sprechen, mit einem Blick auf die Integration von verteilten Geodaten eben in diesem, um Forschungsdateninfrastrukturen zu ermöglichen und zu entwickeln.
00:47
Vielleicht ein kurzer Hintergrund zur Firma 52 North. Wir sind eine private Forschungseinrichtung im Bereich der Geoinformatik und wir beteiligen uns an öffentlich finanzierten Forschungsprojekten, bieten aber auch professionelle Dienstleistungen an für die Entwicklung von Softwarelösungen, aber auch Konzeptionierung und Architekturen.
01:10
Wir fördern insbesondere Open Science durch die Bereitschaft von offenen Daten, aber auch eben quelloffener Software. Neben den Projektdurchführungen, die wir machen, unterstützen wir auch die Lehre im Bereich und im Gebiet der Geoinformatik.
01:25
Man kann das recht bei den Gesellschaftern sehen, die sich sowohl aus dem akademischen Bereich als auch aus dem wirtschaftlichen Bereich zusammensetzen. Im letzten Jahr hat sich einiges getan bei 52 North. Zum einen wurde eine neue Geschäftsleitung eingesetzt und im gleichen Zuge auch die Ausrichtung der Firma etwas neu definiert.
01:46
Wir haben unseren Fokus ein bisschen weg von den Open Source Lösungen, die wir selber entwickeln, hin zu Contributions für Major Open Source Softwarelösungen aus dem Bio-Bereich geändert. Zum Beispiel Beiträge zu Geonode, Erweiterungen oder Pi-Geo-API, Implementierungen und auch Arbeiten mit dem Open Data Cube.
02:08
Neben mir sind noch Dr. Simon Jelka und Dr. Benedikt Gräler in der Geschäftsleitung und wir teilen uns entsprechend die Aufgaben. Nun zunächst einen Blick auf die Anforderungen für Forschungsdateninfrastrukturen, wenn man eben eine solche mit Geonode umsetzen möchte.
02:29
Aus den verschiedenen Projektkontexten haben wir einen Satz von Anforderungen definiert oder identifizieren können. Das lässt sich im Prinzip in diesen sieben Punkten zusammenfassen. Die Unterstützung von verteilten Datensätzen, verschiedene Datenquellen und föderalistische Systeme ist sehr wichtig.
02:46
Die Daten müssen referenzierbar sein, aber auch Modelle müssen referenzierbar sein. Es muss möglich sein, eine Prozessierung der Daten möglichst nahe an diesen durchführen zu können. Stichwort Analysis for the Data. Das Management von Large Data ist besonders wichtig, wenn es eben um eine Forschungsdateninfrastruktur betrifft.
03:09
Denn hier sind oft riesige Mengen von Daten schon vorhanden und meistens eben auch verteilt und sehr heterogen. Geodaten, nicht Geodaten, die man hier berücksichtigen muss. Die Integration von In-Situ-Daten ist in den Projekten, wo wir dieses Vorhaben durchführen, auch sehr wichtig gewesen.
03:27
Die Einhaltung der FAIR-Prinzipien ist auch besonders wichtig, gerade mit Blick auf die nationalen Forschungsdateninfrastrukturen, die in den kommenden Jahren etabliert werden. Last but not least, die metadataverwaltung ist auch ein sehr wichtiger Aspekt, um
03:42
Transparenz der Daten zu schaffen und auch diese auffindbar zu machen und zu strukturieren. Nun ein kurzer Blick auf den Kontext, in dem wir das erste Mal eine Forschungsdateninfrastruktur durchgeführt haben. Das war eben oder ist das Forschungsprojekt Maridata.
04:01
Und in dem Forschungsprojekt Maridata geht es darum, den Seeverkehr so zu optimieren oder zumindest eine Route von einem Schiff so zu optimieren, dass man eine Einsparung von Treibstoff erzielen kann und somit eine Verringerung der Emissionen erzielt. Das Projekt ist mit verschiedenen Partnern bestückt aus dem akademischen Bereich, aber auch aus dem wirtschaftlichen Bereich und wird vom BMWI bzw.
04:31
dem Bundesministerium für Wirtschaft und Klimaschutz, wie es jetzt heißt, gefördert. Was war die fachliche Herausforderung in diesem Projekt?
04:40
Hier in dem Schaubild dargestellt, man hat einen Starthafen und einen Zielhafen, den das Schiff in einer bestimmten Zeit erreichen muss. Und für einen bestimmten Bereich der Route stellt sich die Frage, habe ich hier nicht die Möglichkeit effektiver zu fahren, um eben Treibstoff einzusparen. Und die Idee war, verschiedene Datensätze heranzuziehen, um dann diese über die Geoplattform bereitzustellen,
05:06
darauf ein Machine Learning Modell zu trainieren und ausführbar zu machen, um dann entsprechend mehrere Vorschläge für effizientere Routen anbieten zu können. Was spielt da eine Rolle? Zum Beispiel bei den Inputdaten, die Gezeiteninformation und Strömungen, die Schiffseingeschafften, natürlich auch der Zeitplan, an dem sich die Rede reinhalten müssen.
05:24
Und Wettervorhersagen, Verkehr und Vorschriften, da gibt es einige Einschränkungen. Zum Beispiel am Ärmelkanal darf man nicht beliebig navigieren und auch nur eine bestimmte Anzahl von Schiffen dürfen entsprechend im Kanal sein. Solche Vorschriften müssen eingehalten werden. Das ist wichtig. Und die wichtigste Datengrundlage für uns sind die Daten aus dem CMEMS, dem entsprechenden Copernicus-Dienst, den man einbinden kann.
05:51
Was macht oder beeinflusst den Energiebedarf eines Schiffes denn überhaupt? Vielleicht ein kurzer Blick hier rauf. Die wichtigsten Komponenten, die wir identifizieren konnten, mit Hilfe der Partner auch, sind zum einen die
06:01
Schiffsdimensionen, wie viel Wasser verdenkt das Schiff während es fährt und was für einen Tiefgang hat es. Der Trim, sprich der Tiefgang an Bug und Heck und der entsprechende Massenschwerpunkt. Die Wellen, Primära und Sekundära, Seegang, Strömung, permanente Strömung, Strömung und Gezeiten. Wind spielt eine Rolle und auch die Wassertemperatur und der Salzgehalt.
06:24
Und wenn man diese Anforderungen dann identifiziert hat, dann kann man schauen, welche Daten entsprechend eingebunden werden müssen, um so ein Modell vernünftig rechnen zu können. Das sind zum einen die Traktorien in Kombination mit Sensordaten von Schiffen, historische, also aufgezeichnete Daten. Dann die Vektordaten des Schiffes, die aktuelle Position und der Schiffszustand und tabellarische Daten wie der Zielort,
06:47
Charteraufträge, der Fahrplan, der sich daraus ableiten lässt, spielen natürlich auch eine Rolle. Des Weiteren benötigen wir Rasterdaten auf Basis von Earth Observation Daten plus deren abgeleitete Prognosen.
07:01
Und auch Vektordaten, um zum Beispiel so eine Schiffskarte zu haben, um gewisse Routeneinschränkungen mit einrechnen zu können. Und des Weiteren tabellarische Daten, Schiffseigenschaften, Schiffgeometrien, die weitestgehend aber statisch für das jeweilige Schiff sind. Jetzt ein kurzer Blick auf CMEMS. Das hatte ich eben schon erwähnt.
07:20
Das ist besonders wichtig für unsere Datengrundlage des Copernicus Marine Environmental Monitoring Service. Und da gab es vier Datensätze, die bei uns gut eingebunden werden konnten. Einmal die Physics Analysis, die Oceanwind-Daten, die Oceanwaves-Daten und das Global Forecast System.
07:42
Hier sehen wir eine kurze Darstellung einer Schiffstrajektorie. Die Daten werden über die Cyberthings API-Implementierung von 50 to North angeboten. Und in der Software, die wir hier auf dem Screenshot sehen, 50 to North Helgoland visualisiert. Das heißt, wir haben sowohl eine Trajektorie, über die man so gleiten kann, als auch dann eine entsprechende Zeitraindarstellung.
08:07
Die besten Kennwerte für eine effiziente Route wurden von uns identifiziert. Und das sind die Speed- und Course-over-Ground-Variablen, die so eine Schiffstrajektorie aufweisen.
08:21
Und um entsprechend diese optimal modellieren zu können, müssen wir unser verschiedenen Modell trainieren. Und hier haben wir entsprechend über sechs Millionen AES-basierte Datentupel genommen, die mit historischen Umweltdaten verschnitten in das Machine Learning Modell entsprechend reingeworfen. Und so eine Modellierung von SOG und COG auf Basis dieser Datenlage zu ermöglichen.
08:46
Das heißt, mit über sechs Millionen Daten und entsprechend den Umweltdaten wurde das Modell trainiert. Und wir haben auch, wie man sieht, hier eine recht gute Kurve, die immer recht ordentlich in der Mitte liegt, ermitteln können.
09:03
Vielleicht noch ein kurzer Blick auf Analysis Ready Data, mit besonderem Blick auf das Projekt, das wir durchgeführt haben. Unter Analysis Ready Data kann man im Prinzip verstehen, was auch immer notwendig ist, um die Daten für eine Analyse vorzubereiten. Wir sehen hier oben rechts zum Beispiel eine Darstellung, wie das OGC einmal Analysis Ready Data in einem Piloten definiert hat.
09:26
Im Prinzip hat man ein Datenarchiv, ein generisches Datenarchiv. Das müssen keine historischen Daten sein, das kann auch eine Hochzeitdaten sein. Vorverarbeitung, dann hat man entsprechend ein Analytics Optimized Data Store, mit dem man dann entsprechend die Daten abgreifen kann.
09:42
Diese beiden Felder, das sind die besonders wichtigen, die man auch sehr gut mitgehen und auch realisieren kann. Das heißt, Daten sind im Prinzip fit for purpose, aber welcher Zweck mit einer Analyse verfolgt werden will oder werden soll, ist auch immer abhängig davon, wie der Kontext ist. Das heißt, was ist die Anwendung, was ist das Framework oder gegebenenfalls auch, was ist die Präferenz des Analysten,
10:04
möchte der, die Daten hoch aufgelöst haben in einem bestimmten Datenformat usw. Das spielt alles eine Rolle und für Maridata haben wir eben abgeleitet, dass die Bereitstellung von Umweltdaten für die Routing-Anwendung im Space Time-Korridor entlang von Trajektorien für uns bedeutet, dass die Analysis Ready sind. Das heißt, wir stellen nur Daten bereit, die eben relevant sind für eine bestimmte Trajektorie,
10:25
machen also so ein Subsetting schon und reduzieren damit entsprechend die Datenmenge auch. Dadurch lässt sich eben diese Datengrundlage direkt in den Machine Learning AI Verarbeitungsworkflow einbinden mit Hilfe von Python Libraries.
10:45
Nachdem wir jetzt den Kontext aus dem Projekt, das wir durchgeführt haben, kennengelernt haben, möchte ich einen Blick auf Geonaut als Basis-Technologie für die Umsetzung werfen und hier schauen, was muss Geonaut können und wo muss man Geonaut vielleicht noch etwas erweitern, um die Anforderungen zu erfüllen.
11:06
Ein kurzer Blick auf die Gesamtarchitektur des Maridata-Systems. Damit Geonaut mit dem entsprechenden Geo-Server, der die OGC-Dienste bereitstellt. Und unten sieht man die Datenquellen, die eingebunden werden müssen. Grip-Daten, Net-CDF-Daten vom Global Forecasting System, Net-CDF-Daten von CMEMS zum Beispiel.
11:25
Was sind also die Anforderungen an Geonaut in besonderem Projektkontext? Wir haben zum einen eine hohe Anforderung an Skalierbarkeit mit Blick auf das Datenvolumen. Wir haben es mit sehr großen Datenmengen, mehreren Terabytes zu tun, die wir verwalten müssen.
11:40
Und entsprechend die Performance des Datenzuges muss auch gegeben sein, damit das Machine Learning Modell und weitere Externities nicht ausgebremst werden. Des Weiteren haben wir uns vorgenommen, die gesamte Plattform, die gesamte Architektur auf einem Kubernetes-Cluster zu deployen. Und hier waren auch einige Anpassungen notwendig. Da kommen wir später noch zu. Und last but not least brauchen wir eine Art von automatisierten Mechanismus, um neue Datensätze in das System zu importieren.
12:07
Das Ganze ergibt dann eine Plattform für Analysis Ready Data mit diesem sehr speziellen Projektkontext, den ich schon vorgestellt hatte. Ein kurzer Blick auf die Geonaut-Basis-Architektur für diejenigen, die Geonaut noch nicht eingesetzt haben oder gegebenenfalls die Architektur nicht im genauen kennen.
12:24
Wir haben zum einen einen Geo-Server, der zur Verwaltung der Raster- und Vektordaten zuständig ist und das entsprechend in einem Fallsystem für die Rasterdaten und einer Postcast-Datenbank für die Vektordaten erledigt. Darauf ist eine Web Application auf Basis von Django entwickelt oder bereitgestellt,
12:44
die entsprechend zum Beispiel diese Discovery-Plattform-UI anbietet, aber auch den Import von Daten ermöglicht. Und da gibt es noch einige Optimierungen, zum Beispiel Geo-Webcache, um Daten effektiver und schneller ausliefern zu können, wenn diese sich nicht geändert haben. Um Daten auffindbar zu machen, gibt es die PICSW-Komponente. Geonetwork wird, glaube ich, seit einigen Releases nicht mehr unterstützt.
13:08
Und diese PICSW-Komponente dient eben zur strukturierten Metadatenverwaltung, aber auch eben für die Discovery von den Daten. Ist Geonaut denn cloud-ready mit Blick auf die Skalierbarkeit und die
13:23
große Menge an Daten, eben diese mehrere Terabytes, die wir unterstützen müssen? Das ist eine Frage, die wir uns direkt gestellt haben, insbesondere wie funktioniert das mit Geo, TIFF und NetCDF, die wir nicht auf dem Fallsystem speichern wollen, weil das Fallsystem gerade in einem Kubernetes-Cluster zum einen sehr teuer werden kann und auch vom Management-Overhead doch einiges mit sich bringt.
13:44
Unsere Lösung für das Problem war hier eine Anbindung von S3. Das ist der Amazon Simple Storage Service. Im Prinzip ist es ein Protokoll, was auch halböffentlich verfügbar ist und auch zum Beispiel von dem Open-Source-Projekt mit IO implementiert wurde.
14:00
Das heißt, man ist nicht an AWS gebunden. Man kann das auch mit anderen Systemen realisieren. Und in diesem S3, das ist ein Object Storage, da werden entsprechend die Raster dann gespeichert und mit Hilfe des cloud-optimisierten Geo-TIFF-Plugins, des Geo-Servers, eingebunden und können dann entsprechend im Geo-Nord publiziert werden.
14:20
Ein kurzer Blick auf den Workflow. Das ist jetzt entsprechend dieser automatisierte Workflow zu importieren von Daten, die eben in so einem S3-Speicher liegen. Wir haben dafür einen neuen Geo-Nord-Management-Command entworfen, create-legal-from-object, der entsprechend als Input eine Differenz auf ein S3-Objekt entgegennimmt,
14:41
aus dem wir dann in einem ersten Schritt einige Metadaten ableiten, zum Beispiel eine Zeitstempel, wenn entsprechend in dem Dateinamen verhaftet ist. Im nächsten Schritt erstellen wir dann über die Geo-Server REST API ein Coverage. Und hier kommt dann eben das cloud-optimisierten Geo-TIFF-Plugin vom Geo-Server zum Einsatz, das entsprechend Geo-TIFFs einbinden kann mit einer Referenz auf S3-Objekte.
15:05
Wenn diese Daten dann entsprechend im Geo-Server registriert wurden, das Coverage also verfügbar ist, können wir den neuen Layer in Geo-Nord registrieren und danach dann die Möglichkeit, ihn entsprechend in der Plattform zu finden und über die verschiedenen Optis-Schnittstellen auch zugreifbar zu machen.
15:22
Das ist im Prinzip ein wichtiger Aspekt, um große Rasterdatenmengen in Geo-Nord zur Verfügung zu stellen. Wir haben aber auch im Rahmen von weiteren Projekten, im Rahmen von weiteren Forschungsdateninfrastrukturvorhaben weitere Anpassungen und Erweiterungen von Geo-Nord durchgeführt, die ich jetzt
15:40
hier nicht vorenthalten möchte, aber nicht in der Zeit darauf eingehen werde. Da ist zum einen die Integration von Rastamahndatensätzen, die wir für das Julius Kühn-Institut durchgeführt haben. Dann gibt es noch eine Umsetzung für die OGC Thunder Things API als Remote Service in Geo-Nord, die wir für die University of Manitoba realisiert haben.
16:02
Und dann haben wir Geo-Nord auch als Basis für ein Aufforstungen Forest Management Projekt realisiert. Hier ist ein kleiner Screenshot von der Rastamahnd Integration. Hier sieht man also, dass wir einen neuen Remote Service integriert haben und entsprechend hier über die UI von Geo-Nord entsprechende Ressourcen importieren können
16:22
und diese Ressourcen dann entsprechend in Geo-Nord hinterlegt werden. Ähnlich funktioniert das Prinzip für die Thunder Things API, wo man entsprechend die Thunder Things API Instance als Remote Service einstellen kann und entsprechend an die Stationen, die von dieser Thunder Things API angeboten werden, als Layer in Geo-Nord registrieren können.
16:43
In der größeren Community von Geo-Nord gibt es natürlich auch noch viele weitere spannende Arbeiten, die im Kontext Forschungsdateninfrastrukturen durchgeführt werden. Und da möchte ich gerne auch das Thünen-Institut verweisen, die einen besonderen Fokus auf die FAIR-Prinzipien legen.
17:00
Und mein Direktor-Nachredner Florian Hirt vom Thünen-Institut hat dazu auch einen sicherlich sehr spannenden Vortrag vorbereitet. Eine letzte Zusammenfassung, um so langsam zum Ende zu kommen mit der Präsentation, die ich hier geben möchte, ist eine Übersicht von Anpassungen, die wir für Geo-Nord entsprechend realisiert haben.
17:25
Zum einen eben dieser schon beschriebene Datenimport über Cloud Optima S, Geotip und S3. Dann haben wir einige Anpassungen für das Deployment mit kubinentes ASC-Plattformen durchgeführt, die Docker-Struktur etwas entschlackt, zum Beispiel auch den Geo-Server so umstrukturiert, dass keine shared volumes mehr genutzt werden.
17:42
Wer sich mit Kubernetes ein bisschen auskennt, der weiß, wenn man zum Beispiel den Geo-Server dann skalieren will, einen Cluster-Geo-Server betreiben möchte, und die Pods in verschiedenen Kubernetes-Nodes eines Clusters dann laufen, dann funktionieren die shared volumes direkt schon nicht mehr und der Geo-Server wird entsprechend nicht mehr starten. Solche Anpassungen waren eben nötig, um die Plattform auf Kubernetes lauffähig zu bekommen.
18:04
Und wir haben entsprechend Customize-Files dafür angelegt, die ein Deployment auf Minitube, aber auch eben Amazon Web Services erlauben. Des Weiteren haben wir noch das Task-Management etwas entschlackt. Da gab es verschiedene Mechanismen im Geo-Node, die etabliert waren, Cron-Jobs, Salary-Worker, also auch ein Jenkins, zum Beispiel für Backups.
18:25
Und in unseren Augen ist das Backup von Daten eher Aufgabe des Deployments. Da kann man dann zum Beispiel Kubernetes-Jobs anlegen, die regelmäßig eine Datenbank in einem S3-Objekt speichern oder so was. Und das haben wir entsprechend bei unserem Deployment entfernt, um das Ganze auch ein bisschen schlanker zu gestalten.
18:44
Die ganzen Arbeiten, die wir durchgeführt haben, möchten wir natürlich auch zurück in die Community spielen. Und wir haben uns da für ein Schritt-für-Schritt-Vorgehen entschieden und würden in einem ersten Schritt einmal die ganzen Anpassungen, die wir in den Docker-Files gemacht haben, die nicht unbedingt funktional waren, aber die zum Beispiel den Docker-Builden-Mechanismus etwas erleichtern,
19:04
Multistage-Builds zum Beispiel einführen. Das würden wir als erstes zurück spielen, um dann in einem zweiten Schritt eben diese entsprechenden Anpassungen, die ich gerade dargestellt hatte, in der gesamten architektur lockerbasierten Architektur einzubringen, um das System etwas leichtgewichtiger zu machen und eben auch bereit für ein Kubernetes-Deployment.
19:22
Das weitere Schritt wäre dann die Bereitstellung von Customize-Files möglich, um Kubernetes-Deployments leichtgewichtig zu ermöglichen. Wir peilen hier das 4.0-Release von GeoNode an, das wird wahrscheinlich dieses Jahr noch stattfinden und das würde zeitlich also sehr gut passen. Neben diesen Kubernetes-basierten Dingen, die wir durchgeführt haben,
19:43
wollen wir auch noch weitere Contributions zurück in die Community fließen lassen. Diese sind an der fachlicher Natur und das sind im Prinzip die Sachen, die ich eben vorgestellt habe, dieser GeoTip- und S3-Mechanismus, die Integration von Sensor-Daten über die Odyssey Sensor Things API und auch die Coverage-Daten über den Web Coverage Service.
20:02
Am Anfang der Präsentation hatten wir einmal einen kurzen Blick auf die Anforderungen für Forschungsdateninfrastrukturen gelegt und eben einen besonderen Blick auf GeoNode gesetzt und jetzt als Abschluss würde ich gerne einmal schauen, wie weit sind wir denn gekommen in den Arbeiten, die wir für die verschiedenen Projekte durchgeführt haben und für die verteilten Datensätze würde ich so einen Teilhaken setzen,
20:23
das ist noch nicht perfekt ausgereift, aber ich denke, der technologische Durchstich ist erreicht. Wir haben die Möglichkeit, über ein skalierbares System große Datenmengen in GeoNode einzubinden und das Ganze funktioniert auch in der Cloud. Wir haben für unseren spezifischen Projektkontext
20:42
die Möglichkeit, Daten zu processieren und haben eben eine Plattform entwickelt, die Analysis Ready Data anbietet und das Ganze funktioniert sehr effektiv und kann direkt auch in einem Kubernetes-Cluster durchgeführt werden und ermöglicht eben Machine Learning Anwendungen.
21:02
Parallel dazu, das Management von Large Data verteilt und heterogen ist in unseren Augen auch zumindest teilweise erfüllt und erreicht worden, auch zum Beispiel mit der Einbindung von Remote Services, Sender Things API und dem Coverage Service. Die restlichen Anforderungen sind Bestandteile von weiteren Projekten,
21:21
die wir durchführen und wir hoffen auch hier bald Erfolg vermelden zu können und die ganzen Entwicklungen, die wir durchführen, entsprechend in die GeoNode-Community zurückzutragen. Heute bin ich am Ende angekommen. Ich danke für die Aufmerksamkeit und freue mich, wenn es Fragen gibt.
21:41
Vielen Dank, Mathis Rieke und Benedikt Griller, für diesen Einblick in GeoNode. Wir haben auch ein paar Fragen dazu erhalten. Der Mathis Rieke ist hier, um die zu beantworten. Wie werden verschiedene Datensätze zusammengeführt? Ja, ich versuche mein Bestes beim Beantworten der Fragen. Erstmal danke für die vielen Fragen und die Teilnahme im Chat.
22:05
Das freut mich. Ja, zur Frage die verschiedenen Datensätze, die Kombination ist ja besonders wichtig für die Analyse. Das heißt, in dem Machine Learning Modell, was wir gerechnet haben, sind die Daten im Prinzip dann verknüpft worden.
22:24
Einmal die Rasterdaten und die Vektordaten, die als Input genommen werden und auch als Label genutzt werden. Und das Ganze hat natürlich nicht in GeoNode selber stattgefunden, sondern wir haben die Schnittstellen für GeoNode genutzt, um die Daten in einem Python Notebook entsprechend zu beziehen
22:42
und dann da mit verschiedenen Mechanismen zu verschneiden, die man mit den Frameworks dazu zur Verfügung hat. Ich selber bin nicht der Machine Learning Experte. Ich weiß, dass TensorFlow eingesetzt wurde zur Entwicklung des Notebooks. Und ja, das bietet ja letztendlich alle Möglichkeiten,
23:01
auch Under the Hood für Raster.io, X-Array, was es da alles so für Python Libraries gibt. Genau, das ist im Prinzip das. Und GeoNode ist im Prinzip der Datenbereitsteller. Das heißt, wir können die Objectiv-Schnittstellen vom GeoServer nutzen, aber auch die Katalogischen Schnittstellen, um Daten zu finden.
23:23
Noch eine ähnliche Frage. Was sind die Hardware-Anforderungen fürs Training des ML Modells? Wie lange dauert es, das Modell zu trainieren? Ja, das ist in der Tat nicht wenig. Wir haben, wie ich schon gesagt hatte, eine eigene ET2-Maschine in dem AWS Cluster neben dem Kubernetes Cluster dazugestellt.
23:42
Das heißt, wir haben recht nahen Zugriff auch auf die Daten und auch auf die Dienstform GeoNode. Und das ist eine spezielle AWS ET2-Maschine, die CUDA-Cores hat. Das heißt, da laufen wirklich, ja, ich glaube, NVIDIA-Grafikkarten, die man sich dann entsprechend buchen kann.
24:02
Die ist nicht ganz günstig, kann man aber auch dann zum Beispiel einfach wieder abstellen, wenn man das Modell fertig trainiert hat. Und das dauert schon mehrere Stunden, dann mit diesen sechs Millionen Daten setzen, das Modell zu trainieren. Jetzt noch ein paar Fragen direkt zu GeoNode. Hier geht es um verteilte Daten.
24:20
Man kann mit GeoNode die Daten der Projektpartner auf ihren eigenen Servern liegen bleiben und dann in GeoNode referenziert werden. Das geht auf jeden Fall. In GeoNode hat man ja die Möglichkeit, Remote-Services einzubinden und die Integration mit Rastamane, die ich kurz angeschnitten hatte, die ist eben genauso realisiert. Das heißt, es gibt externe Dienste, die auch OTC-Schnittstellen anbieten.
24:42
Und GeoNode hat dann die Möglichkeit, diese per Meter Daten zu referenzieren. Die Daten bleiben dann entsprechend im anderen Rechenzentrum oder auf der inneren Instanz liegen, lassen sich aber über GeoNode finden und entsprechend auch über die gleichen Mechanismen dann einbinden. Also es ist eine sehr charmante Möglichkeit, aber benötigt eben OTC-kompatible Schnittstellen.
25:05
Eine weitere Frage zu verteilten Daten, kann man mit GeoNode andere Metadatenkataloge haarwissen? Das ist eine gute Frage. In der Tat kann ich das nicht selber beantworten. Ich würde auch vielleicht die Frage weiterreichen, also vielleicht eine halbe Stunde nochmal reinhören,
25:21
der selber im Streaming-Komitee von GeoNode ist und sich mit der Funktionalität da ein bisschen besser auskennt. Wir selber haben die Funktionalität nicht genutzt. Durchaus möglich, ja. Gut, dann werden wir die Frage nachher nochmal stellen. Und eine letzte Frage. Ich habe versucht, NetCDFs hinzuzufügen. Das funktioniert nicht. Benötigt man dafür ein Plugin? Ja, es gibt ein Plugin vom GeoServer, das NetCDF Plugin.
25:44
Ich glaube, es gibt aber auch zwei Plugins, ein Input- und ein Output-Plugin, zum Laden von Rasterdaten. Wir selber haben das mit dem GeoServer nicht benutzt, weil es in der Tat aus der Box nicht so gut funktioniert hat. Wir haben die Daten selber vorprozessiert und dann als GeoTIF abgelegt. Das heißt, wir haben die NetCDF-Daten vom CMEMs geladen
26:03
mit einer Python-Library, die entsprechend umgewandelt und dann als GeoTIF abgespeichert, um die dann eben mit dem Cloud-Optimals GeoTIF-Plugin Uber S3 einbinden zu können. Das war für unseren Use-Case effektiver, weil wir eben diesen einen speziellen Datensatz hatten. Wenn es aber wirklich eine große Menge an verschiedenen NetCDF-Daten gibt,
26:22
dann müsste man sich das nochmal genauer anschauen und nochmal in das GeoServer-Plugin reinschauen. Wir haben das auch auf dem Stack liegen, auch in der Tat als Anfrage von anderen Projektpartnern. Aber momentan kann ich da noch nicht sagen, ob das technisch einfach möglich ist. Alles klar. Vielen Dank, Mathis, für deinen Vortrag und auch für deine Antworten.
26:42
Wir sehen uns gleich um 10 Uhr wieder zu einem weiteren Vortrag zu Geonote. Bis gleich. Vielen Dank.