GRASS GIS in der Cloud: Actinia-Geoprozessierung
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 | 77 | |
| 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/46480 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
1
11
12
13
16
18
19
23
24
30
34
41
43
46
65
69
70
72
77
00:00
Grass (card game)Point cloudAlgorithmEstimationHTTPEnterprise resource planningAPIZugriffRollbewegungFunktionalitätHTTPPoint cloudGeodesicVector graphicsInternet service providerAlgorithmAsset <Informatik>Module (mathematics)Lecture/Conference
03:42
Grass (card game)Process modelingDatabaseGeodesicDiagram
04:43
Noten <Programm>Process modelingComputer animation
05:53
Grass (card game)Point cloudNoten <Programm>HTTPComputer animation
06:16
CodeElectronic design automationParameter (computer programming)Level (video gaming)TestdatenComputer animation
06:40
Number theoryWeb browserGeodesicFunction (mathematics)Computer animation
07:16
Grass (card game)Version <Informatik>Module (mathematics)Scripting languageComputer animation
08:28
Uniform resource locatorCurl <Programmiersprache>Engineering drawing
08:54
AlgorithmDownloadPoint cloudGoogleAPIWEBProcess modelingFunction (mathematics)Musical ensembleAlgorithmEngineering drawingDiagramComputer animationLecture/Conference
09:50
GeometryDiagram
10:24
Process modelingAlgebraBerechnungAPIComputer animation
11:02
Process modelingGrass (card game)Anbindung <Informatik>Mechanism designMoment (mathematics)Computer animation
11:55
Plug-in (computing)BerechnungRow (database)Process modelingOpen sourceStatement (computer science)Scripting languageAutomatonOverhead (computing)Parallel computingAlgorithmComputer fileData structureNoten <Programm>Lecture/Conference
17:57
DDE
Transcript: German(auto-generated)
00:07
Okay, ich fange nochmal von vorne an. Also herzlich willkommen zum nächsten Vortrag. Es geht um Krass in der Cloud und ja, viel Spaß. Dankeschön. Genau, jetzt geht es noch mal ein bisschen detaillierter um Actinia und wie wir Krasskiss eigentlich in die Cloud gebracht
00:23
haben und wie Actinia entstanden ist. Das überspringe ich jetzt mal. Für die, die neu dazugekommen sind, sage ich es vielleicht doch noch schnell. Wir sind eine kleine Firma aus Bonn, auch eng verpartnert mit Terrestris. Wir heißen Mundialis, ich bin Carmen und wir machen viel Geodatenprozessierung
00:43
und nutzen auch sehr viel Krasskiss dafür. Wie viele gute Dinge fängt alles mit einer Idee an. Als die Sentinel-Daten aufkamen und immer mehr wurden, kam irgendwann das Paradigma auf, die Algorithmen zu den Daten zu
01:01
fangen und nicht mehr alles lokal zu rechnen, sondern da zu rechnen, wo die Daten sind. Außerdem müsste man es irgendwie vielleicht schaffen, die Krasskiss-Funktionalitäten per HTTP nutzen zu können. Und das Ganze wurde dann genannt Krass, Krass Asset Service. Das waren die Anfänge damals noch. Und das alles führt dann dazu, dass man Krasskiss in die Cloud
01:25
bringt. Um zu verstehen, wie man das machen kann, muss man erst mal ein Krasskiss verstehen. Und zwar, wie das Krass-Format funktioniert. Erst mal gibt es die Krass-DB, das ist die Krass-Datenbank, wo die ganzen
01:41
Daten liegen, die ganzen Geodaten. Die ist aufgeteilt in mehrere Locations. Das ist dann an einen EPSG-Code gebunden und innerhalb einer Location kann ich mehrere Mapsets anlegen. Für jedes Projekt würde ich dann eine einzelne Mapset anlegen und dann darin arbeiten. Und innerhalb einer Mapset gibt es dann ganz viele verschiedene Geodaten, Rastadaten,
02:00
Vektordaten oder auch raumzeitliche Geodaten. Außerdem arbeitet man mit Krasskissen mit verschiedenen Modulen. Da gibt es, ich glaube, um die 400 verschiedene. Und es gibt ganz einfache sozusagen, wie zum Beispiel vClip, wo man wirklich einfach nur einen Clip ausführt. Und es gibt
02:21
aber auch viel komplexere, wo viel mehr Sachen hintereinander ausgeführt werden und das eigentlich schon fast eine Prozesskette ist. Und dabei stehen die Buchstaben immer, also V zum Beispiel für Vektordaten, eher für Rastadaten, G sind generelle Krasskommandos. So kann man sich das so ein bisschen einordnen. So, und wie haben wir das jetzt gemacht?
02:44
Wir haben eine Rest-API oben draufgesetzt. Und diese Rest-API, die verwaltet Locations, Mapsets und Geodaten als Ressourcen, auch raumzeitliche Daten. Und außerdem ermöglicht sie die Verwendung von diesen ganzen Krassmodulen, die man gesehen hat, so dass man die auch per
03:03
Rest aufrufen kann. Außerdem, das hatte ich eben auch schon im Vortrag gesagt, braucht man irgendwie ein User-Management. Wenn man lokal mit Krasskiss am PC arbeitet, dann ist man der eigenen User und rechnet und hat vielleicht noch ein paar andere User. Aber wenn man das in
03:21
die Cloud bringt, braucht man eben ein richtiges User-Management dafür. Und außerdem, ihr wisst ja jetzt, was ein Mapset ist, ist es problematisch, wenn mehrere User gleichzeitig auf ein Mapset zugreifen und darauf arbeiten wollen. Deshalb haben wir auch ein Mapset-Locking eingebaut. Und irgendwie muss man diese ganze Krass-Datenbank auch noch managen können. Das sieht dann so
03:44
aus. Links sieht man die Daten, die Krass-DB. Das ist aufgeteilt einmal in die persistente Datenbank, die read-only eingemartet wird. Da werden so grundlegende Geodaten schon von Anfang an reingeladen, die man eben für das Projekt generell braucht. Und außerdem gibt es noch die User-Datenbank,
04:04
wo wirklich userspezifisch, in dem Fall ist das gruppenspezifisch, eine Datenbank angelegt wird, wo dann User-Daten reingeschrieben werden. Und wenn ein Prozess gestartet wird, dann wird das in eine sogenannte Actinia-Note eingemontet. Das sieht man
04:21
rechts. Das ist im Prinzip auch Krasskiss und obendrauf oder obendrauf. Und wenn man das ein bisschen abstrahiert, dann hat
04:45
man die Krass-Datenbank und hat Krasskiss mit Actinia obendrauf. Und damit diese ganzen Nodes, nicht unabhängig von der Art und Weise, dass die Nodes miteinander existieren. Gibt es noch eine Redestatenbank dahinter, die zentral alles verwaltet, zum Beispiel die User. Wenn ich mich
05:02
authentifizieren will, weiß ich ja nicht, mit welcher Note ich spreche und das ist ja auch egal. Aber dann wird in der Redestatenbank nachgeguckt, ob ich jetzt ein richtiger Nutzer bin oder nicht. Außerdem wird da auch Prozessmanagement abgelegt. Das heißt, wenn ein Prozess gestartet wird und rechnet und ich möchte anfragen, wie weit ist denn dieser Prozess, dann habe ich keine Garantie,
05:22
dass ich wieder bei der gleichen Note lande. Deshalb guckt einfach jede Note in dieser Redestatenbank nach, wo dann abgelegt wird, ob der Prozess gerade läuft, ob es ein Problem gab oder ob er schon fertig ist. Drumherum haben wir dann auch Docker gepackt und auch die eben im vorherigen Vortrag schon erwähnten Komponenten. Und
05:44
da haben wir auch schon verschiedene Erfahrungen gesammelt und verschiedene Sachen ausprobiert. Und ist es wirklich oft projektabhängig, was da am besten zupasst? Das Ganze führt dann dazu, dass Kraskis in der Cloud gelandet ist. Wenn jetzt ein
06:01
Nutzer damit kommunizieren möchte, das habe ich eben schon ein bisschen erklärt, fragt er einfach eine HTTP-Adresse an und irgendein Note antwortet und das kann dem Nutzer auch egal sein, welcher das ist und bekommt eine Antwort zurück. Das sind jetzt mal ein paar Beispielanfragen. Also links
06:21
sieht man ein Get auf die Locations, dann bekommt man alle Krass-Locations zurück. Rechts sieht man ein Get auf die Mapsets, die in der Location NC SBM 08 sind. Das ist so eine Standard-Krass-Location, wo ganz viele Testdaten schon existieren. Und man kommt dann eben in Jason zurück, wo eine Liste drin steht. Ich trinke mir gerade einen Schluck.
06:58
Jetzt kann ich auch noch einzelne Geodaten
07:01
anfragen, zum Beispiel Rasterlayer und bekommen dann alle Rasterlayer in einer bestimmten Mapsette aufgelistet. Und es gibt auch noch verschiedene einzelne Funktionen, zum Beispiel Renderfunktionen, sodass man direkt über den Browser sehen kann, wie das Raster aussieht. Das hatte ich eben auch schon
07:24
bereits erwähnt, dass man auch prozessieren kann. Man kann flüchtig und persistent rechnen und je nachdem wird das Ergebnis dann zurückgeschrieben in die Krass-Datenbank oder auch nicht. Und wenn es nicht zurückgeschrieben wird, dann wird das verschoben auf einen Storage und dann kann
07:41
sich das Ergebnis runterladen. Und wie man prozessieren möchte, da gibt es auch verschiedene Varianten. Das ist jetzt die Variante, wie man Nutzer definiert prozessieren möchte. Da kann man diese ganzen Krass-Module, die ich vorhin schon erklärt hatte, aneinanderketten und hintereinander ausführen und auch
08:00
zum Beispiel Pysonskripte einbauen oder auch Kommandozeilen-Tools einbauen. Also das ist nicht nur auf Krass beschränkt, sondern ziemlich erweitert, sodass man auch seine eigenen Skripte schreiben kann und da einbauen kann. Und rechts sieht man jetzt ein Beispiel. Da wurde das Modul R-Slope Aspect aufgerufen und das wird flüchtig gerechnet und
08:22
anschließend sieht man den Exporter, wie das dann als Geotiff exportiert wird, dass man dann das Ergebnis runterladen kann. Und so sieht dann ein Beispielrequest aus, in dem Fall jetzt mit Curl. Ich poste das Jason, was wir eben gesehen haben, gegen einen Actinia-Endpunkt. Actinia antwortet mit
08:40
einem Jason mit dem Status. Ich polle den Status und irgendwann sagt Actinia okay, ich habe alles erfolgreich berechnet. Hier sind URLs, da kannst du das Ergebnis angucken und dann frage ich diese URLs an und bekomme das Ergebnis. Das ist eine Möglichkeit. Die andere Möglichkeit ist, einen Webhook direkt mitzuschicken,
09:00
wenn man den Prozess startet und dann wird man benachrichtigt, wenn der Prozess fertig gerechnet wurde. Dann gibt es noch, wenn man nicht nutzerdefiniert rechnen will, eine ganze Reihe von vorbereiteten Endpunkten, hauptsächlich Sentinel-Prozessier-Endpunkte und das hat eben auch verschiedene Vorteile. Vorhin habe ich ja gesagt,
09:22
dieses neue Paradigma, die Algorithmen zu den Daten zu bringen, dass eben schon vorgefertigte Importer- Funktionen da sind, die dann zum Beispiel an das ESA-Appi-Hub angeschlossen sind oder auch an verschiedene andere. Es gibt auch welche, wo man noch einen Vorteil hat, dass man nur ein einzelnes Band runterlädt und nicht irgendwie die
09:41
ganze Szene runterladen muss oder auch zum Beispiel die Dias-Plattform, wo man dann wirklich die Daten einmounten kann, wenn der Actina jetzt zum Beispiel da deployed wäre. Und das ist jetzt ein Beispiel für so einen vorgefertigten Endpunkt. Oben sieht man, dass man Sentinel-2 prozessieren möchte und einen NDVI rechnen möchte von einer ganz bestimmten Szene. Und dann geht
10:02
das Spiel wieder von vorne los und am Ende kann man sich auch das Ergebnis dann angucken. Da gibt es auch zwei Ergebnisse. Das ist jetzt nur so ein Quick Look Vorschau-Bild mit einer Legende. Man kann aber auch dann das riesige Geotiff runterladen. So gibt es noch mehr
10:23
Features. Ja, gibt es. Ich werde jetzt nicht alle im Detail erklären, aber mal ein paar Beispiele rauspicken. Zum Beispiel ACE, das ist die Actina Command Execution. Das ist ganz praktisch für Menschen, die krass schon
10:40
kennen und auch schon viel damit arbeiten und über die Kommandozeile bedienen, weil man sich dann nicht diese ganzen Prozessketten-Jasins selbst schreiben muss, sondern man kann seine Krassbefehle wie gewohnt eingeben. Und damit wird das automatisch dann an Actina geschickt und nicht am eigenen Rechner, sondern an eine entfernte Installation. Und ein
11:04
Ausblick, was wir jetzt noch weitermachen wollen. Also wir sind noch dabei, so eine Art Prozesskettenmanagement zu entwickeln, dass man eben nicht seine Prozessketten lokal beweichern kann, sondern dass das auch Actina selbst übernimmt und dass man die auch vielleicht mit anderen Nutzern teilen kann. Und
11:21
außerdem, was auch noch recht wichtig ist, momentan ist der Mechanismus so, dass die Prozesskette analysiert wird und dann wirklich nur die Daten eingemauntet werden, die gebraucht werden. Und das führt im Moment dazu, dass wir nicht reprojizieren können innerhalb von einer Prozesskette, was aber eigentlich auch noch ein ganz wichtiges Feature wäre, was wir auch bald entwickeln wollen.
11:43
So, dann gibt es noch Neuigkeiten, nicht mehr ganz so neu, aber Actina wurde letztes Jahr auch zum OSGio Community Projekt gewählt und man findet schon verschiedene Dinge auf GitHub, also den eigentlichen Code oder auch Docker
12:01
Beispiele, die man ausprobieren kann, weil sich lokal testen kann und auch verschiedene Plugins für Satellitenplugin oder Statistikplugin, die eben dann besondere Berechnungsendpunkte bereitstellen. Jetzt war ich ziemlich schnell, aber
12:21
vielleicht gibt es ja dafür umso mehr Fragen. Ja, ich hätte schon mal eine Frage. Kann man da auch externe Tools mit
12:41
einbauen sozusagen? Also wenn ich jetzt zum Beispiel an eine Atmosphärenkorrektur denke, da würde ich jetzt vielleicht nicht die von Grasfe nehmen, sondern vielleicht die neueren Sachen, die gerade in Entwicklung sind oder so was. Könnte ich so was damit einbauen oder müsste ich das irgendwie extern machen? Das geht, das kann man einbauen. Also wir haben zum
13:01
Beispiel auch Snappy selbst eingebaut und verschiedene andere Dinge. Das müsste man dann alles in das Docker Image reinbringen, aber das liegt ja alles auf Github. Das kann man dann einfach abgucken, wie wir das mit Snappy zum Beispiel gemacht haben und reinbringen und über diese Prozesskette kann man eben auch
13:20
Kommandozeilen Tools aufrufen. Sind jetzt nicht alle erlaubt aus Sicherheitsgründen, aber das könnte man dann auch freischalten und alternativ kann man auch seinen eigenen Python Skripte schreiben und aufrufen, wenn sie in der Installation dann drin liegen. Genau. Und was wir oft machen ist, dass wir irgendwie Prozesse schreiben und dann
13:40
das als Gras add-on rappen, sozusagen, weil es dann einfach sehr gut in unsere Architektur passt und dann können wir es einfach irgendwo hinlegen auf Github und dann beim Bauen auch einfach da runterladen und dann ist das integriert.
14:07
Ja, vielen Dank. Die Idee mit den Algorithmen zu den Daten bringen, ist ja super und wir bei uns in Abteilung haben da auch schon ein bisschen mit rum experimentiert und hauptsächlich aber mit Google Earth Engine und da ist ja schon so, dass
14:21
die Datensätze komplett vorbereitet sind. Man hat eine API, mit der man auf diese Datenstruktur zugreifen kann, mit dem MapReduce kann man da auch kontinentale, globale oder länderbasierte Berechnungen trägern relativ simpel. Kannst du es vielleicht in Relation setzen zu diesem Ansatz? Wie viel Overhead habe ich mit dem
14:40
File Management? Wenn ich die Prozesse parallelisieren will, muss ich das machen oder kommt es schon über ihre API? Das wäre so für den Anwender, glaube ich. Also warum sollte ich von Earth Engine wechseln? Was ist so der Haupt Seller bei Ihnen? Das ist coole, sympathische Open Source.
15:02
Nein, also natürlich. Also die Daten halten wir schon hauptsächlich in der Krass-Datenbank vor. Das stimmt schon. Das müsste man dann am Anfang mal importieren, wobei man das auch irgendwie skripten kann. Das muss jetzt nicht alles manuelle Arbeit sein. Und dann ist das aber auch sehr performant, wenn das eben alles in der Krass-Datenbank liegt. Das setzt natürlich voraus,
15:20
dass man auch Krass-Module benutzt und nicht irgendwie viele seine eigenen Tools da einsetzt. Ja, und alternativ wäre dann oder nicht alternativ parallel dazu der große Vorteil, wenn man zum Beispiel mit Sentinel-Daten rechnet, dass man die Installation so hat, dass man wirklich bei den Daten installiert und das eingemautet ist und nicht
15:40
noch extra runtergeladen werden muss. Vielleicht nochmal zur Orchestrierung. Geht das auch mit externen Tools? Also Prozessierungsketten sind jetzt angedacht, dass in Aktinia auch vorzusehen,
16:02
dass man das definieren kann. Aber könnte man jetzt auch irgendwie das drumherum bauen mit vorhandenen Tools, die irgendwie so orchestrieren und sagen, wenn der eine Prozess fertig ist, dann den nächsten? Stimmt, das war noch eine Frage, die ich vergessen habe zu beantworten, mit dem Parallelrechnen. Das muss man auch manuell
16:20
machen, es sei denn, man hat jetzt den gleichen Prozess für verschiedene Gebiete, dann kann man eben auch 100 Anfragen stellen und das wird dann automatisch alles verteilt. Das kommt natürlich auch immer darauf an, wie es jetzt deployed ist. Also wenn ich jetzt das irgendwie mit Kubernetes deploye, dann gibt es ja einen automatischen Load Balancer, der halt gerade guckt, welcher
16:41
Note ist frei, wo kann ich rechnen? Ja, antwortet das die Frage auch? Gibt es noch Fragen? Dann hätte ich noch eine und zwar würde mich interessieren, wie es quasi so dann eigentlich im Alltag aussieht, wenn
17:00
man das verwenden will. Also tut man dann quasi sich zuerst irgendwie den kleinen Tatensatz runterladen, es dann lokal mit krass machen und dann erst mal, also wenn man so eine Prozess Sache so führt, muss man erst mal probieren, ob das funktioniert und blau und blub und tut man sich dann diese JSON Datei bauen und dann hochladen. Also wie sieht es so aus im Alltag? Wenn ich jetzt wirklich irgendwie, also bei dir quasi, wenn du jetzt was an der Düse machst,
17:21
wie sieht das Workflow so aus? Ich mache es tatsächlich ja lokal im Docker auch direkt und wenn ich jetzt nicht genau weiß, wie der Prozess aussehen soll, dann würde ich das auch erst mit krass Befehlen machen und das dann auch in dann so einen JSON umwandeln und das dann abschicken.
17:44
Gut, wenn keine weiteren Fragen mehr sind, dann ist es ein bisschen früher fertig, aber ist auch okay. Okay.