STAC und openEO in der Praxis: Integration in actinia
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/56793 (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
Smart cardStack (abstract data type)Meeting/Interview
00:30
Point cloudGrass (card game)APIZugriffRollbewegungElectronic design automationProjektion <Mathematik>Component-based software engineeringGebiet <Mathematik>GeodesicInstanz <Informatik>Stack (abstract data type)Module (mathematics)InformationTransmitterPoint cloudoutputLecture/Conference
06:56
Asset <Informatik>Row (database)APICodeStreaming mediaDownloadThumbnailLink (knot theory)GeometryCladeMetadataoutputInstanz <Informatik>Source codeTypAPIStack (abstract data type)Instanz <Informatik>Filter <Informatik>Plug-in (computing)MetadataComplete metric spaceLeadInformationGeometryLink (knot theory)Row (database)Conflict (process)CodeAbbildung <Physik>ImplementationComputer animation
15:20
Source codeTypFilter <Informatik>ACT <Programm>Instanz <Informatik>Outline of industrial organizationScripting languageAPIPoint cloudClient (computing)DownloadMetadataRow (database)ImplementationGrass (card game)HTTPEditorTemporal logicClient (computing)Graph (mathematics)Stack (abstract data type)MetadataProcess (computing)Smart cardFunktionalitätSeries (mathematics)Graph (mathematics)TypFilter <Informatik>Kapazität <Mathematik>JavaScriptImplementationComputer animation
23:44
Client (computing)Stack (abstract data type)Direction (geometry)Online chatComponent-based software engineeringComputer animationMeeting/Interview
Transcript: German(auto-generated)
00:08
Gut, dann begrüße ich noch mal alle hinzugekommenen zum letzten Vortrag des Tages mit dem Titel mit dem Titel Stacks und Open EO in der Praxis, Integration in Actina von Karten Taviga
00:25
und wünsche dabei viel Spaß und Film ab. Herzlich willkommen zu meinem Vortrag Stacks und Open EO in der Praxis, Integration in Actina.
00:41
Ich arbeite für die Firma Monialis, sitze in Bonn und wurde 2015 gegründet. Wir spezialisieren uns auf die Verarbeitung von Earth Observation Data hauptsächlich. Ich selbst bin Carmen Taviga und arbeite auch schon seit 2015 in der Firma. Besonders erwähnen möchte ich noch Jorge und links, der sehr viel dazu beigetragen hat,
01:02
im Rahmen seines Praktikums das hier zu implementieren, was ich euch heute vorstellen möchte. In dem Vortrag wird es zunächst einmal eine kleine Einführung in IT ergeben, genauso wie eine kleine Einführung ins Deck, einfach um zu gucken, dass so die Grundlagen klar sind.
01:20
Dann wird praktisch die Kombination von beidem erläutert, wie die Implementierungsvortrags aussehen. Anschließend gibt es noch eine kleine Einführung zu Open EO und dann das Zusammenspiegeln all dieser drei Komponenten. Das ist ein Ausschnitt von einem Vortrag, den ich vor zwei Jahren schon mal gehalten habe,
01:41
also für ausführlichere Informationen, der ist auch noch online verfügbar, kann gerne nochmal angeguckt werden. Was ist Actinia? Um Actinia ein bisschen besser zu verstehen, müssen wir uns erstmal angucken, was Kraskes eigentlich ist, bzw. zwei Hauptkonzepte davon kennenlernen. Das eine ist die sogenannte Krass-Datenbank, wo die ganzen Geodaten liegen,
02:02
die gegliedert ist in Locations und Mapsets. Locations können sich auf unterschiedliche Gebiete auf der Erde beziehen oder auch auf unterschiedliche Projektionen. Mapsets liegen innerhalb einer Location und da kann man dann zum Beispiel seine Projekte strukturieren oder auch verschiedene Daten. In einer Mapset liegen dann die eigentlichen Geodaten.
02:21
Das können Rasterdaten, Vektordaten, Punktwolken oder auch verschiedene raumzeitliche Daten sein. Ein anderes Konzept von Kraskes sind die Kraskes-Module, die verschiedene Prozessierungen darstellen. Sie haben immer Inputs und Outputs und können auch beliebig aneinandergehängt werden. Es gibt davon über 300 Stück und letztlich dazu gibt es auch noch
02:44
viele Kraskes-Addons. Wie kann man da jetzt eine REST-API oben draufbauen? Zum einen kann man sich die Konzepte von Locations, Mapsets und Geodaten nehmen und sie als Ressourcen verstehen, sodass man sie ganz REST-like
03:03
auch managen kann über verschiedene HTTP-Endpunkte. Zum anderen macht das natürlich Sinn, die Krasken-Module, die es ja gibt, auf die Prozessierungen rechenbar machen zu können. Und auch die Nutzerverwaltung ist ein wichtiger Punkt, weil wenn man viele Daten hat und dann auch viele Prozessierungen anbietet,
03:24
dann kann das ja auch sehr rechenintensiv sein, sodass man die Ressourcen ein bisschen besser planen kann, auch wie viel gleichzeitig gerechnet werden soll oder wie lange so ein Prozess überhaupt rechnet. Das macht alles Sinn, dass man das ein bisschen steuern kann. Und auch wichtig ist ein Mapset-Locking, dass man eben Konflikte vermeiden kann,
03:43
wenn verschiedene Nutzer gleichzeitig auf verschiedene Daten zugreifen und prozessieren wollen. Ein bisschen abstrakter verpackt sieht es dann so aus, dass wir links die Kraskdatenbank haben. Dort liegen dann die eigentlichen Geodaten und rechts sind die
04:00
sogenannten Actinia-Pots. Ein Pot ist immer eine laufende Instanz in einer Cloud-Umgebung. Das wird häufig so genannt. Und dort läuft dann Actinia innen drin, Kraskis. Und die Daten, die für Prozessierungen verwendet werden, werden dann dort eingemountet. Diese Pots laufen nebeneinander her und können eben auch
04:22
parallel Dinge ausführen. Damit das Ganze aber doch zusammenspielt, ist noch eine Möglichkeit, dass alle Informationen untereinander austauschen können. Ein Beispielfall wäre, wenn eine Prozessierung gestartet wird, dann läuft diese Prozessierung in einem ganz bestimmten Pot.
04:40
Und wenn der Nutzer anfragen möchte, wie weit der Status ist, wie weit jetzt die Prozessierung vorangeschritten ist, würde er auch an das Cluster eine Anfrage senden, aber nicht zwingend in dem gleichen Pot landen, wo die Prozessierung auch läuft. Deshalb wird der Status in der Redestatenbank gespeichert, sodass jeder Pot aus dem Cluster darauf zugreifen kann und dem Nutzer sagen kann, wie der Status von dem aktuell laufenden Prozess ist.
05:04
Das Ganze haben wir in Docker verpackt, was es ermöglicht oder vereinfacht, das dann auch in verschiedenen Cloud- Umgebungen laufen zu lassen. Wir haben Erfahrungen mit Docker Swarm, OpenShift und Kubernetes und hatten auch schon Berührungspunkte mit Terraform und OpenStack.
05:22
Wie sieht das Ganze denn jetzt konkret aus? Hier sind zwei Restrequests, um Locations und Mapsets da zu fragen. Links sieht man eine Liste der Locations, die der Nutzer sehen und verwenden, da sind Prozessierungen. Und rechts sieht man dann eine Liste von Mapsets innerhalb einer bestimmten Location.
05:44
Man kann auch noch verschiedene andere Ressourcen abfragen. Hier sind jetzt noch mal als Beispiel eine Liste von Rasterlayern, die angezeigt werden können. Und außerdem auch ein Render-Endpunkt, wenn man sich eine bestimmte Karte mal schnell angucken möchte, kann man diesen Endpunkt aufrufen.
06:01
Das Herzstück allerdings ist die eigentliche Prozessierung. Dafür muss man eine Prozesskette formulieren und diese dann an Actinia senden. Die Prozesskette enthält verschiedene Module. Das können Kraskis-Module sein oder auch addons, aber auch GDA-Kommandos oder andere Kommandos.
06:21
Snap hier unterstützen wir zum Beispiel auch. Oder auch verschiedene Python-Skripte. Rechts im Beispiel sieht man eine Prozesskette. Da wird das Modul rslop-aspect aufgerufen mit verschiedenen In- und Output-Parametern. Und bei den Outputs sieht man, dass der Export verwendet wird. Das bedeutet, wir rechnen flüchtig.
06:42
Also die Ergebnisse werden im Gegensatz zur persistenten Prozessierung nicht in die Krasterartenbank zugeschrieben, sondern exportiert. Und in dem Beispiel hier wird ein Geotiff erzeugt, was dann heruntergeladen werden kann. Okay, als nächstes gucken wir uns Stack ein bisschen mehr im Detail an.
07:02
Stack, die Abkürzung steht für Spatial-Temporal-Asset-Katalog und dient als gemeinsame Sprache für Raum- und zeitbezogene Daten, um diese zu beschreiben. Das Hauptziel davon ist, dass in dieser Welt, wo immer mehr Daten entstehen, dass man auch Daten finden kann.
07:21
Und nicht jeder sein eigenes Süppchen kocht und seine Daten irgendwo vorliegen hat, aber niemand sie findet. Sondern, dass man sie registrieren kann, relativ einfach und schnell. Und dass sie dann so auch deutlich besser aufgefunden und auch verwendet werden können. Das bedeutet auch, wenn man irgendwie einen neuen Datensatz hat, den man registrieren will, dann muss nicht erst irgendwie was Neues erfunden werden,
07:44
neuer Code geschrieben werden oder eine neue API entwickelt werden, sondern man kann Stack verwenden, um seine Daten zu registrieren und anderen nutzbar zu machen. Dabei gibt es drei Konzepte. Items, Catalogs und Collections. Und ich habe mich jetzt in dem Vortrag entschieden,
08:01
das nicht in die deutschen Wörter zu übersetzen, sondern die Begriffe so zu lassen, damit man sie auch dann leichter wiedererkennen kann. Ein Stack Item ist quasi die kleinste Einheit und ein Baumblatt. Das heißt, ein Item selbst kann keine weiteren Kinder haben und bezieht sich auf ein Raum-zeitliches Phänomen-Datensatz
08:24
und ist im Prinzip ein GeoJSON. Es sollte also eine Geometrie haben und auch einen Zeitbezug. Das sind so die minimalsten Anforderungen, die es haben muss. Es kann aber auch noch deutlich mehr Felder haben.
08:41
Ein Item braucht außerdem einen Link zu einer übergeordneten Collection. Also es kann nicht einfach nur für sich stehen, sondern muss zu einer Collection gehören und kann dabei auch nicht zu mehreren Collections gehören, sondern immer nur zu einer. Ein Catalog hat eine ID, eine Beschreibung, eine Stackversion und auch Links
09:01
und ist eigentlich ein Zwischenelement, um Dinge zu gruppieren. Also man kann Items und auch Collections gruppieren oder auch Catalogs selber. Und die zwei Hauptanwendungsfälle sind, wenn man recht große Collections hat, die vielleicht schon sehr unübersichtlich werden, dass man die nochmal ein bisschen unterteilt in eigene Gruppen.
09:23
Und der andere Hauptanwendungsfall ist, wenn man mehrere Collections hat, die man anbieten möchte, dass man die zu einem Catalog zusammenfasst. Und das ist dann häufig auch der Haupteinstiegspunkt in einen Stack Catalog. Und als drittes gibt es noch die Collection.
09:42
Das ist im Prinzip ein Catalog, der noch mehr erforderliche Metadaten braucht, um als Collection zu gelten. Und dazu gehört die Lizenz und der Extent. Und eine Collection kann selbst übergeordnet Catalogs und Collections haben und untergeordnet auch Items, Collections und Catalogs wieder selber.
10:06
Und idealerweise kann eine Collection auch noch Metadaten verlinken, die zu ihr passen. Und daran sieht man, finde ich, ganz schön, dass Stack gar nicht den Anspruch hat, ein Metadaten-Sammler zu sein, sondern vielmehr einfach nur als Ziel hat,
10:23
die Aufwendbarkeit von Daten zu erreichen und im Gegensatz dazu dann selbst wieder auf umfassendere Metadaten auch verlinken zu können. So, wie sieht denn jetzt praktisch die Integration von Stack in Actinia aus?
10:43
Dazu gibt es das Actinia Stack Plugin. Das kann man auch auf GitHub finden. Und ein Actinia Plugin ist quasi immer etwas, was man während einer Installation von Actinia Core hinzuinstallieren kann. Und dann bietet es noch mehr Endpunkte zusätzlich zu den Hauptfunktionalitäten an.
11:02
So auch dieses Stack Plugin. Und durch die zusätzlichen Endpunkte wird Actinia selbst zu einem Stack. Und dabei sind wir den Weg gegangen, dass wir vorhandene Collections, die schon existieren, harvesten können. Das bedeutet, wir können sie einbinden in Actinia und Actinia kann sie dann anzeigen.
11:23
Und dadurch können sie dann in Prozessierungen verwendet werden. Und dabei haben wir uns zwei Hauptkonzepte überlegt. Das eine sind die sogenannten Instances. Und das ist eigentlich nichts weiter als einen Namensraum, in dem mehrere Collections zusammengefasst werden können. Und das hat den Grund, wenn man zwei Collections harvesten möchte,
11:45
die zufällig den gleichen Namen haben, aber wir unterschiedlichen Instanzen verfügbar sind, und man die irgendwie unterscheiden können. Und deshalb haben wir uns überlegt, das über diese Instanzen zu machen. Und die eigentlichen Collections sind dann einfach eins zu eins Abbilder von den Collections,
12:01
die harvestet wurden. Zusätzlich haben wir uns allerdings noch eine ID überlegt, die intern dann sehr viel Sinn macht, wo die Instanzen-ID auftaucht und auch die Collection-ID selbst. Falls wir wieder zwei unterschiedliche Instanzen haben, die die gleiche Collection beinhalten, dass es da nicht zu Konflikten führt.
12:22
Und diese ID spielt auch bei unserer Implementierung von der Open EO API eine Rolle, weil die Namensgebung auch so aufgebaut ist, dass die krassen Locations und Mapsets dort auftauchen. Und um einfach dieses Schema beizubehalten, haben wir uns entschieden, diese ID so zu vergeben.
12:41
Dann die angesprochenen Endpunkte, die jetzt hinzukommen, sind unter anderem Instances, wo man ein HTTP-Postrequest gegenmachen kann, um eine neue Instanz zu erzeugen. Das ist auch hier ganz einfach in dem Beispiel mit einfachen Namen vergeben, den man dann gegen diesen Endpunkt posten kann und mit einer neuen Instanz erstellt.
13:02
Bei Collections sieht das sehr ähnlich aus. Allerdings braucht man da zusätzlich die URL von der Collection, die man Harvesten und so integrieren möchte. Zurück kommt dann auch wieder die Information, dass alles gut geklappt hat und die eigentliche URL, von der man Harvestet hat, wird auch gespeichert.
13:25
Da, wo ein HTTP-Postrequest ist, ist auch ein HTTP-Read-Request. Man kann die Instanzen abfragen, entweder alle zusammen, die man hat, oder auch, wenn man die ID dahinter schreibt, die eigentliche einzelne Instanz.
13:43
Was sind noch die Collections, die man auch abfragen kann? Auch hier entweder fragt man alle ab und bekommt dann einen Array zurück von den Collections, die existieren, oder eine einzelne um nur gezielte Information für eine einzelne Collection zu bekommen. Da drin sind dann auch als wichtigstes die ID zu sehen,
14:03
Titel und der räumliche und seitliche Extent. Und ganz wichtig bei Stack die Links, da alle Ressourcen immer gegenseitig oder verlinkt sind. Und hier sieht man auch, dass der Self-Link nicht mehr auf Actinia zeigt, sondern auf die URL, von der Harvestet wurde.
14:23
Und noch die dritte HTTP-Methode, die wir implementiert haben, ist die Lead. Man kann die Instances und auch die Collections löschen. Die Reihenfolge, in der das jetzt hier steht, macht nicht so viel Sinn, weil man über die Instanzlöschung auch schon alle zugehörigen Collections löscht, aber ich habe sie einfach nochmal aufgelistet zur Vollständigkeit halber.
14:44
So, um dann damit auch arbeiten zu können in Prozessierungen, gibt es den Stack Importer. Der ist jetzt nicht mal im Actinia Stack Plugin implementiert, sondern direkt in Actinia Core. Und hier sieht man, wie man den in eine Prozesskette einbauen kann, nämlich über den Importer. Da kann man als Quelle die ID der Stack Collection angeben
15:05
und räumliche und seitliche Filter, um das alles ein bisschen einzuschränken. Und auch die Bänder, die man zur Prozessierung verwenden möchte. Wenn man das dann an Actinia schickt, dann wird sich eben darum gekümmert, dass diese Collection für die Prozessierung zur Verfügung steht und auch die Filter angewendet.
15:26
Und alle folgenden Schritte, wo diese dann importierten Karten quasi referenziert werden, können halt dann darauf zugreifen. Und wenn die Prozessierung durchgelaufen ist, kann man nun auch den Stack Exporter verwenden,
15:41
der auch in Actinia Core direkt implementiert wurde. Hierbei sieht man ein bestimmtes Modul, slob aspect. Da generiert dann eine Outputkarte und hier kann man eben als Output auch Metadaten angeben, vom Typ Stack. Und das führt dann dazu, dass die Ergebniskarte analysiert wird
16:01
und notwendige Metadaten erzeugt werden, die dann in einen Stack-Eintrag geschrieben werden. Und momentan wird der als JSON einfach neben das Output gelegt. Und es soll aber auch noch möglich werden, das dann per HTTT-Post an einen bestehenden Stack zu posten, um dann so die Ergebniskarte dort registrieren zu können.
16:27
Okay, dann kommen wir noch zum letzten Baustein, zur OpenEU. Die OpenEU-API wurde entwickelt, um verschiedene Verse Observation Prozessier-Backends,
16:41
um ihnen quasi eine einheitliche Sprache zu geben, sodass Clients, die OpenEU auch sprechen, auch mit den verschiedenen Backends sprechen können. Das hat eben den großen Vorteil, dass man nicht für jedes Backend einzeln einen Client schreiben muss, sondern dass es alles austauschbar ist und untereinander ist es dann für den Client oder den Benutzer
17:01
gar nicht mehr so wichtig, welches Backend verwendet wird, sondern man kann einfach verschiedene Backends ansprechen. Genau, als Funktionalitäten sind wichtig, dass das Backend sich selbst beschreiben kann. Also es sollte seine Prozesse, die es anbietet, listen können und beschreiben können,
17:21
sodass man sieht, welche Input- und Abparameter notwendig sind und auch die Daten, die im Backend enthalten sind, mit denen protestiert werden kann, die sollten auch aufgelistet werden. Außerdem gibt es sogenannte Process Graphs. Das sind verschachtelte Prozessanweisungen, die ausgeführt werden können
17:42
und das Backend sollte diese halt annehmen und analysieren und dann auch diese Berechnungen durchführen. Außerdem sollte man Zwischenergebnisse oder die eigentlichen Ergebnisse selbst runterladen können. Und auch noch verschiedene nutzerspezifische Dinge verwalten können. Das sind jetzt nochmal so grobe Funktionalitäten.
18:02
Es gibt noch eine Reihe mehr, aber das sind jetzt erstmal so die wichtigsten. Passend dazu die für uns jetzt wichtigsten Endpunkte. Da sind die Collections und auch die Collection ID, dass man quasi die vorhandenen Daten abfragen kann, genauso wie die Processes,
18:22
sodass man die vom Backend vorhandenen Prozesse abfragen kann. Des Weiteren gibt es den Job-Endpunkt, bei dem man einen neuen Job erstellen kann oder auch sich listen kann, was schon alles verfügbar ist. Und einen weiteren Endpunkt, um dann den eigentlichen Job zu starten. Über diesen Endpunkt kann man auch einfach BHTTPGET den Status abfragen
18:44
oder die fertigen Ressourcen dann runterladen. Wer jetzt ein bisschen aufgepasst hat, der hat vielleicht schon gemerkt, dass Stack und Open EODA eine Gemeinsamkeit haben. Nämlich die Bezeichnung für Collections, das ist kein Zufall.
19:01
Also der Endpunkt Collections oder auch Collections und dann die Anfrage nach einer bestimmten ID sind in beiden identisch, haben auch das gleiche Schema und entsprechen auch dem Standard der OGC-Features. Das macht die Sache einfach auch ein bisschen einfacher austauschbar. Und es gibt aber einen Unterschied, und zwar schreibt Stack nicht vor,
19:23
dass nach einer Collection auch bestimmte Items abfragbar sein müssen. Das macht sich Open EO zu Nutze, weil da macht es teilweise mehr Sinn. Wenn man zum Beispiel eine Section 2 Collection hat, dann interessiert den Nutzer nicht unbedingt eine Szenen-ID, mit der er weiter rechnen möchte, sondern vielmehr interessiert ihn eine Ausdehnung und einen Zeitraum,
19:45
der für ihn interessant ist, sodass damit dann gerechnet werden kann. Und Stack selbst empfiehlt für eine volle Implementierung, aber auch noch die Items, die in einer Collection sind, anzeigen zu können. Aber wie gesagt, das muss nicht der Fall sein und bei Open EO ist es auch nicht der Fall.
20:04
Gut, dann haben wir jetzt hier schon zu diesen drei Bausteinen viel Theorie gesammelt und ein bisschen uns praktisch angeguckt, wie Stack in Actinia funktionieren kann. Und jetzt wollen wir uns nochmal angucken, wie Actinia und der Open EO Crosscast Driver oder Actinia und Open EO zusammenspielen,
20:23
nämlich in Form des Open EO Crosscast Drivers. Das ist ein Flask backend, geschrieben in Python, liegt auch auf GitHub, kann man sich auch gerne mal angucken. Und das dient quasi als Brücke zwischen Actinia und Open EO,
20:41
in der Form, dass man einen Open EO konforme API Request stellen kann gegen den Open EO Crosscast Driver und diese übersetzt das dann intern, sodass es Actinia versteht, leitet das weiter an Actinia und Actinia erfüllt dann die Anforderungen. Also gibt entweder eine Liste mit Prozessen zurück oder fängt an,
21:04
diese Prozesskette oder Process Graph zu prozessieren und auszuführen und gibt das dann wiederum zurück an den Open EO Crosscast Driver, der dann wieder an den Nutzer ausgibt, was auch immer die Antwort dafür ist.
21:22
Wenn wir jetzt noch Stack dazu nehmen, dann sieht das Ganze so aus. Und um das Ganze ein bisschen anschaulicher zu machen, habe ich jetzt als Beispiel mal den Open EO Web Editor genommen. Das ist eine Client-Infomentierung in JavaScript. Und da kann man eben ganz schön auch nochmal die ganzen Funktionalitäten sehen,
21:40
die die Open EO API anfordert. Und zum einen sieht man links eine Liste mit Collections, Processes, User Defined Functions und auch Teilformaten. Und das sind quasi alles Anforderungen, die an das Backend gestellt werden. Und diese Anfragen, damit kann das Backend quasi sagen,
22:03
was es für Kapazitäten hat oder für Ressourcen. Und die werden dann zurückgegeben und hier im Client gelistet. Und ich habe jetzt oben als Suchbegriff Stack eingegeben. Deshalb tauchen jetzt nicht überall Ergebnisse auf, aber bei den Collections. Und hier sieht man, dass zwei Collections registriert sind, die mit Stack zu tun haben und auch diese ID entsprechend, die ich vorhin erklärt hatte.
22:25
Zum einen sind hier zwei und zum anderen eine Landsat 8 Collection. Wenn man sich die jetzt näher anguckt, dann wird das ganz schön hier gerendert und nicht mehr im JSON, so dass wir Menschen auch gut damit was anfangen können. Man bekommt schon einige Details über diese Collection.
22:44
Das Wichtigste ist den räumlichen und den zeitlichen Extent und auch verschiedene Bandinformationen, die in der Collection enthalten sind. Und dann jetzt hier in der Mitte sieht man den Model-Bilder. Das ist ein Process Graph, der in JSON geschrieben ist.
23:03
Man kann ihn sich aber auch hier in diesem Web-Editor grafisch anzeigen lassen. Und dann sieht man, dass die Collection verwendet wird und dann verschiedene Prozesse und Filter darauf angewendet werden. Und das Ganze kann man dann als Job anlegen und dann auch ausführen.
23:20
Und dieser Teil ist gerade noch in der Implementierung. Deshalb zeige ich jetzt hier so diesen Stand, wie er bisher so ist. Genau, jetzt haben wir eine kleine Reise unternommen über Ropen.io, Arctinia und Stack. Ich hoffe, das war interessant. Vielen Dank für die Aufmerksamkeit und gibt es irgendwelche Fragen?
23:49
Wenn jetzt keine in den nächsten drei Minuten keine Fragen im Chat auftauchen, dann bleibt mir nur noch allen Zuhörern einen schönen Feierabend zu wünschen, mich für die Vorträge zu bedanken und nochmal an das Postgistia-Basis erinnern
24:06
und sonst den Leuten noch einen schönen Tag in der Sonne zu wünschen. Ah, jetzt taucht die erste Frage auf. Gibt es schon Clients für QGIS oder Kraskis bzw. ist das von eurer Seite geplant?
24:26
Also für Arctinia, ja, ich weiß jetzt nicht genau in welche Richtung das geht. Also für Arctinia ist ein QGIS-Plugin auf jeden Fall schon in Arbeit. Und für Open.io gibt es ja schon diverse Clients.
24:41
Also den Web-Editor, den habe ich ja vorgestellt und auch verschiedene Python-Implementierungen. Und für Stack gibt es meines Wissens auch zum Beispiel ein QGIS-Plugin, wo man dann Stack mit anfragen kann. Also es gibt für alle einzelnen Komponenten Clients, aber so jetzt zusammengesteckt in dem Sinne jetzt nicht.
25:03
Genau, aber ich weiß nicht, ob das die Frage schon beantwortet.