STAC - Einführung und Neuigkeiten
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 | 119 | |
Autor | ||
Mitwirkende | ||
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/67722 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
| |
Schlagwörter |
14
45
50
55
67
69
72
75
78
87
95
00:00
SoftwareentwicklungSkript <Programm>BrowserEditorEreignishorizontKeller <Informatik>Sound <Multimedia>Profil <Strömung>MultiplikationsoperatorSoftwareentwicklerOffene MengeXMLUMLComputeranimation
01:34
ZahlenbereichReiheVorlesung/KonferenzComputeranimation
02:03
ZeichenketteMultiplikationsoperatorStreuungsdiagrammInformationKeller <Informatik>SoftwareDatenbankDateiElektronische PublikationHydrostatikOnline-KatalogInformationsspeicherungPunktwolkeCASE <Informatik>UmwandlungsenthalpieMomentenproblemElement <Gruppentheorie>Computeranimation
03:55
FokalpunktSoftwareOpen SourceAPIFokalpunktKeller <Informatik>JavaScriptActive Server PagesErweiterungUmwandlungsenthalpieWeb-SeiteRechenschieberMaßerweiterungDynamisches SystemClientKartesische KoordinatenDatenflussProgrammierungAnwendungsdienstanbieterIdentifizierbarkeitHydrostatikOpen SourceSoftwareStandardabweichungServerVerschlingungXML
05:50
GruppierungKerndarstellungProviderMetadatenKeller <Informatik>UmwandlungsenthalpieElement <Gruppentheorie>VererbungshierarchieHierarchische StrukturMagnetbandlaufwerkOnline-KatalogDatensatzPunktMultiplikationsoperatorMaßerweiterungInformationHypermediaElektronische PublikationMAPTopologieSatellitensystemGrenzschichtablösungTeilbarkeitWurzel <Mathematik>ZahlenbereichMetadatenAdditionWeb-SeiteUntergruppeRechenwerkFormation <Mathematik>DifferenteVerschlingungEinfache GenauigkeitObjekt <Kategorie>TypentheorieService providerAsset <Informatik>KerndarstellungDateiErweiterungEbeneComputeranimation
10:15
APIUmwandlungsenthalpieMereologieFunktionalMailing-ListeVerschlingungMaßerweiterungCASE <Informatik>DifferenteDatensatzLanding PageNichtlinearer OperatorErweiterungFunktionalitätComputeranimation
11:51
RechenschieberVerschlingungOnline-KatalogMailing-ListeImplementierungComputeranimationVorlesung/Konferenz
12:18
APIAsset <Informatik>MetadatenDatenfeldEndliche ModelltheorieIdentifizierbarkeitUmwandlungsenthalpieFormation <Mathematik>BitVersionsverwaltungVerschlingungEinfach zusammenhängender RaumBitmap-GraphikNormalvektorInformationAdditionDifferentePunktspektrumE-MailKategorie <Mathematik>BrowserKonstruktor <Informatik>Offene MengeAuthentifikationMaßerweiterungProzess <Informatik>Umsetzung <Informatik>MathematikSpannweite <Stochastik>Bildgebendes VerfahrenFokalpunktKeller <Informatik>ValiditätVirtuelle MaschineQuick-SortSpieltheorieVollständigkeitRuhmasseFilter <Stochastik>AdressraumGruppenoperationMultiplikationsoperatorOnline-KatalogHydrostatikViewerTransaktionHierarchische StrukturAlgorithmusTaskQuaderVisualisierungFreewareCASE <Informatik>Front-End <Software>ClientAuswahlaxiomArray <Informatik>ServerDatentypFahne <Mathematik>Mailing-ListeDownloadingErweiterungUmfangNetzadressePhysikalische GrößeAsset <Informatik>MongoDBVersion <Informatik>SoftwareFunktion <Mathematik>ValidierungComputeranimation
19:13
GoogleIndexWeb-SeiteCASE <Informatik>ImplementierungDatenfeldFormation <Mathematik>MereologieDatensatzMultiplikationsoperatorFunktionalVerschlingungAdditionp-BlockBitKeller <Informatik>SchnittmengeDimension 3VektorraumDatentypOnline-KatalogMailing-ListeBasis <Mathematik>TesselationKartesische KoordinatenMAPInternetworkingAbstimmung <Frequenz>UmwandlungsenthalpiePunktOrtsoperatorMaßerweiterungFlächeninhaltDifferenteOffene MengeTermBitmap-GraphikAutomatische IndexierungMetadatenSpezifisches VolumenÄußere Algebra eines ModulsElektronische PublikationZeitstempelVollständiger VerbandGruppenoperationPunktwolkeAsset <Informatik>Vektor <Datentyp>InternetErweiterungGoogleFunktionalitätComputeranimation
Transkript: Deutsch(automatisch erzeugt)
00:07
Guten Morgen, herzlich willkommen hier zu FOSKIS, zu unserer ersten Veranstaltung. Ist der Ton okay? Hier zu unserer ersten Veranstaltung im Hörsaal 2. Unsere Session dreht sich um den Spatial Temporal Asset Catalog.
00:23
Wir haben zwei Vorträge. Sehr interessant. Der erste Einführung und Neuigkeiten, vorgetragen von Matthias Mohr. Er ist freiberuflicher Software-Entwickler und Berater, hat auch viel sich mit OpenIO beschäftigt. Und ja, herzlich willkommen und wir sind gespannt auf deinen Vortrag.
00:41
Kurze Zwischenbemerkung noch. Sie finden an der Seite QR-Text. Da ist eine Seite, da können Sie Fragen stellen, falls Sie die haben, können Sie natürlich nachher auch mit Mikrofon stellen, aber wer es Ihnen einfällt, das lesen wir dann zum Schluss ab in den letzten fünf Minuten und stellen Sie dann die Fragen. Gut, danke für die Einführung. Ich glaube, hier sagt man Moin Moin.
01:02
Machen wir das mal so. Genau, ich habe das Ganze in zwei Teile geteilt, Einführung und Neuigkeiten. Die erste Frage ist natürlich, wer braucht überhaupt eine Einführung? Von daher, wer hat denn schon mal mit Stack gearbeitet? Okay, gut, dann ist es gut, dass wir eine Einführung haben.
01:21
Das letzte Mal stand ich vor so einem Hörsaal, da war das Klausuraufsicht noch an der Uni Münster. Von daher heute ist Spicken erlaubt und bitte immer Fragen stellen auch. Gut, die Folie hier überspringe ich, das wurde gerade schon angekündigt. Also fangen wir direkt an. Warum brauchen wir Stack? Oder wieso sind wir da eigentlich darauf gekommen, dass wir das spezifizieren?
01:44
Naja, das kennen vermutlich die meisten von euch. Es gibt eine Reihe an Portalen, Hunderte, Tausende, wer weiß wie viel. Alle sehen sie anders aus, alle funktionieren sie anders, überall braucht man einen Account. Katastrophe, da findet ja keiner seine Daten wieder, die er braucht.
02:03
Und dann funktionieren sie auch noch alle anders. Einmal ist die Cloud Cover von 0 bis 1, einmal ist sie von 0 bis 100. Alles durcheinander und jedes Mal muss man sich erst einarbeiten, wie das Ganze funktioniert und wie es definiert ist. Darum kam die Idee auf Stack zu spezifizieren.
02:21
Wie gerade schon gesagt, das heißt ein langen Spatial Temple Asset Katalog. Und was ist Stack? Nun, Stack ist im Endeffekt eine Sammlung von Spezifikationen und Software. Wir sagen das explizit so, das ist nicht nur eine Spezifikation, sondern das ist wirklich das gesamte Ökosystem.
02:42
Und das besteht daraus, das woraus es besteht, kommen wir gleich noch zu. Aber was es macht, die Spezifikation selber, die beschreibt geografische und oder zeitliche Daten. Das heißt eigentlich haben fast alle Daten irgendeinen zeitlichen oder räumlichen Bezug, darum funktioniert das für fast alles.
03:01
Aber es ist nicht immer unbedingt klar, was der Raumzeitbezug ist. Denkt man zum Beispiel an eine Rechnung, hat nicht unbedingt einen Raumbezug, aber natürlich einen Zeitbezug. Ob das nun die besten Daten für Stack sind, ist die andere Frage. Aber Raumzeitdaten im Normalfall können wir verwalten und beschreiben. Und das wird gemacht durch miteinander verlinkte statische Dateien, Jason-Dateien in diesem Fall.
03:26
Die kann man einfach auf einen Cloud-Speicher legen zu den Daten, die schon da sind, als zusätzliche Informationen. Der nächste Schritt wäre dann eine API dazu zu bauen, damit man das Ganze auch nicht nur lesen, sondern auch durchsuchen kann. Und diese Stack-API-Spezifikation fügt die dynamischen Elemente zu diesen statischen Dateien hinzu,
03:47
damit man suchen kann, aggregieren kann, Sachen über die API in die Datenbank schreiben kann, durch Transaktionen etc. Das ist das noch mal in kurz, was ich eben gerade schon beschrieben habe in diesen Übersichtsfolien.
04:01
Der Fokus der Spezifikation ist darauf, Daten suchbar und auffindbar zu machen. Die Spezifikation ist von Grund aus relativ simpel gehalten, dass es halt ein leichter Einstieg ist und dann allerdings einfach erweiterbar ist. Das werden wir gleich sehen, es ist relativ wenig, was in der Spezifikation selber steht.
04:21
Dafür gibt es 70 plus Erweiterungen, mit denen man das Ganze noch wertvoller machen kann. Und wie gesagt, das schließt durch die statische Stack-Spezifikation, es gibt dynamische Stack-API-Spezifikation. Das sind unterschiedliche Repositories, da muss man ein bisschen durchgucken und beide haben auch ihre eigenen Erweiterungen.
04:40
Links kommen am Ende der Folie, die Folien könnt ihr euch herunterladen. Dann habt ihr die ganzen Links auf einer Seite und könnt euch da durchklicken. Das Ganze ist mittlerweile auch als OGC-Community-Standard eingereicht, noch nicht akzeptiert, aber es ist eingereicht. Das geht gerade durch den OGC-Flow und dann ist es hoffentlich bald akzeptiert als Community-Standard. Das Ökosystem besteht natürlich erstmal ganz wichtig aus den Daten.
05:03
Ohne Daten ist nichts da, was wirklich wertvoll wäre. Also das ist das Wichtigste eigentlich da zu haben. Dann als zusätzlichen Punkt gibt es natürlich noch die ganzen Software-Anwendungen, die dafür geschrieben werden. Viele davon sind open source, die Spezifikation ist ja auch offen, als GitHub quasi verfügbar.
05:22
Dementsprechend sind die meisten Tools, die dafür entstehen, auch open source. Das geht über Klienten in verschiedensten Programmiersprachen, C-Sharp, ASP.NET, R, Python, JavaScript und und und. Dann gibt es natürlich noch ein paar Server-Anwendungen, mit denen man das Ganze dann als API verfügbar machen kann.
05:40
Und Hilfsmittel wie Validatoren, Sachen, um Stack in X-Array zu verwandeln und und und. Und natürlich dann Lernmaterial und alles, was da oben zugehört und geschrieben wird. Die Stack-Spezifikation selber besteht aus drei Hauptentitäten, die noch mal zwei Unterentitäten haben. Die gucken wir uns jetzt genauer an. Das ist einmal das Item.
06:03
Item ist die Haupteinheit, wenn man zum Beispiel eine Satellitenaufnahme hat. Eine einzelne Satellitaufnahme ist dann im Normalfall ein Item. Das sind die Dateien für eine Aufnahme zu einer bestimmten Datum und zu einer bestimmten Zeit. Das ist ein erweitertes GeoJSON.
06:22
Und ein Beispiel wäre zum Beispiel eine Sennel-2-Aufnahme und davon dann alle Bänder in einer Datei. Oder man kann ja Bänder in mehrere Geotiff-Dateien zum Beispiel aufteilen oder alle in einer haben. Das wäre ein Item, egal wie es aufgeteilt ist anhand der Bänder. Dann gibt es den Katalog, weil natürlich, wenn wir jetzt Satellitenauf...
06:43
Jetzt wird es auch immer viel lauter. Wenn ein Item, wir haben ganz viele Aufnahmen von den Satelliten, wird natürlich irgendwann unfassbar viel, kann man nicht mehr wirklich gut verwalten. Dann fängt man an, das Item in Kataloge zu unterteilen.
07:02
Kataloge sind relativ primäre, primär-statische Sachen, die als quasi virtuelle Ordner fungieren. Und ist quasi einfach nur da, um Items, Kataloge und Collections wiederum zu subgruppieren. Das kann man sich vorstellen wie so eine Art Seite.
07:21
Wenn man in einer API ist, da kann man durch navigieren anhand der Seiten. Das gibt es halt auf statischer Ebene nicht, das sind dann die Kataloge. Und häufig ist das dann zum Beispiel aufgeteilt, dass man anfängt Sennel-2, dann Jahreszahl ist ein Katalog, Monat ist ein Katalog, Tag ist ein Katalog. Und dann sind da die ganzen Items für diesen Tag drin.
07:43
Damit man dann noch eine Überentität hat, die diese ganzen Items beschreibt, gibt es noch die Collection. Das ist quasi dann im Kern ein Katalog mit zusätzlichen Metadaten. Da stehen dann so Sachen drin wie die Ausdehnung der ganzen Items, die Lizenz, die Provider-Information, Schlagwörter, Beschreibung, Titel-ID und so weiter und so fort.
08:04
Das könnten dann zum Beispiel die ganzen Sennel-2 Level-2A-Daten sein. In den Collections und den Items gibt es noch einen weiteren Typ, das sind die Assets. Das ist in dem Item oder in den Collections nochmal ein Objekt, wo einzelne Dateien quasi verlinkt werden.
08:23
Wenn man jetzt zum Beispiel Sennel-2 in verschiedene Bänderdateien aufteilt, also Band 1 in einer Datei, Band 2 in der anderen Datei und so weiter, dann wären das einzelne Assets. Und diese Assets haben dann noch mal zusätzliche Informationen wie die Dateigröße, eine Checksum
08:40
oder die Bänder, die in dieser Datei sind und so weiter und so fort. Den Mediatypen natürlich. Unten links sind quasi die Sachen, die die Stack-Entitäten miteinander verknüpfen und auch zusätzliche Informationen in diese Dateien bringen. Also externe Links wie Dokumentation und Co.
09:01
Dadurch wird diese Hierarchie in Stack auch gemacht. Dann kann man sagen, das ist das Elternelement, das ist das Kind-Element und so weiter. Das wird durch Links gemacht. Und dann gibt es natürlich noch Erweiterungen. Wie gesagt, da gibt es sehr viele von. Zum Beispiel für multispektale Daten gibt es eine Erweiterung für Punktwolken, für Saar, Wettervorhersagen, Mehrsprachigkeit und und und.
09:26
Das sind die Hauptentitäten. Ein Katalog kann dann, je nachdem, wie man das strukturieren will, sehr unterschiedlich aussehen. Also es fängt meistens mit einem Route-Katalog an oben und dann geht man so langsam da durch. Dann kann man zum Beispiel auf 1. Level die Collections haben oder man unterteilt noch
09:41
mal in Untertypen, in multispektale und dann hat man die einzelnen Satelliten wie Landsat und Sentinel. Das ist einem immer selber überlassen. Das ist auch die größte Frage, die ich immer bekomme, wie strukturiere ich meinen Katalog. Das ist natürlich sehr flexibel, wie es ist. Allerdings bringt es dann auch viele Fragen auf, wie das Ganze dann hinterher zu strukturieren ist.
10:02
Genau, dann hat man Kataloge und im Endeffekt ist immer am Ende dieses Baum, es muss nicht unbedingt ein Baum sein, kann auch noch untereinander verknüpft sein, sind halt die Items und die haben dann immer noch Assets. Die Stack-API Spezifikation ist, naja, HTTPS und JSON, wie jetzt
10:21
momentan die meisten APIs, OGC-APIs sind dementsprechend auch spezifiziert neuerdings. Stack-API selber ist basierend auf OGC-API Features und ist angeglichen mit OGC-API Records. Records ist ja noch nicht ganz fertig, aber das kommt so langsam und das ist alles etwa miteinander kompatibel schon.
10:45
Der Unterschied zu Features ist, in der Stack-API sind die Features Metadaten, das ist halt der Footprint von den Daten, die man anzeigt. In OGC-API Features sind die Features die Daten, das ist ein kleiner Unterschied, wo man sich bewusst sein muss, dass das so ist.
11:02
Die Stack-API besteht in der Spezifikation aus mehreren Teilen, man hat die Score-Spezifikation, das ist im Grunde nur eine Landing-Page, die die ganzen Funktionalitäten ankündigt und sagt, wie das Ganze funktioniert. Und dann gibt es unterschiedliche Unterteile, die man implementieren kann, wie zum Beispiel die globale Suche nach Items, also nicht anhand von Collections, sondern über den gesamten Katalog hinaus, über die gesamte API.
11:26
Dann gibt es den OGC-API Features kompatiblen Part der Collections und Features. Und Erweiterungen wie dann die Suche zum Beispiel nach Intercollection und Erweiterungen für die Suche wie CQL, dass man verschiedenste Operatoren noch hinzufügen kann, Transaktionen, Aggregationen und so weiter.
11:46
Hier hinter dem etc-Link befindet sich ein Link zu der Liste der Erweiterungen. Ökosystemimplementierung gehe ich jetzt aus Zeitgründen nicht weiter drauf ein, was wir da alles haben. Wir können einfach stack-index.org eingeben, da gibt es eine Liste mit Katalogen und Tools, die man sich angucken kann.
12:04
Link ist auch noch mal am Ende der Folien. Einfach mal durchklicken und gucken, was so da ist, was man gebrauchen kann. Jetzt geht es zum zweiten Teil, die Neuerungen. Das ist jetzt mehr für die Leute, die es quasi schon kennen, vielleicht interessanter.
12:20
Momentan ist Stack verfügbar in der Version 1.0. Wir arbeiten momentan an der 1.1. Das sind vor allem Sachen, wo wir gelernt haben aus 1.0, was gut funktioniert, was schlecht funktioniert, was sich in der Zwischenzeit entwickelt hat. Als 1.0 kam zum Beispiel gab es Bänder für Spektraldaten, aber noch keine Bänder für allgemeine Rasterdaten.
12:40
Das wird jetzt verknüpft, da haben wir zwei Erweiterungen gehabt, EO und Raster. Die werden jetzt zusammengefügt in ein Bandkonzept, da kommt gleich noch eine kleine Kurzerklärung zu. Dann werden mehr Felder in das Common Metadata Model eingefügt. Das ist quasi unsere Beschreibung, dass Felder, die im Common Metadata Model sind, können in allen von den Entitäten, die ich eben beschrieben habe, verwendet werden,
13:04
ohne dass sie weiterhin spezifiziert werden müssen, sodass man eine Spezifikation hat, sie aber an verschiedensten Stellen benutzen kann. Keywords auch vorher nicht da rollen und so weiter, da kommen ein paar neue Sachen hinzu. Dann haben wir daran gearbeitet, uns mit OGC API Rackets einzugleichen.
13:20
Da hat sich vor allem was getan bei den Lizenzen. Das war vorher ein bisschen komisch, dass da erlaubt waren SPDX Lizenz Identifiers und Proprietary und Various. Das kam immer ein bisschen komisch an, weil wenn diese Lizenz, auch wenn sie offen war, nicht in diesem SPDX Katalog war, der primär für Software war,
13:40
dann muss man Proprietary benutzen, was ein bisschen komisch klingt, wenn selbst die Daten offen sind. Also heißt das Ding jetzt Other? Naja. Dann gibt es zusätzliche Informationen für Links. Bisher waren Links immer Get-Links, das heißt ein normaler HTTP Get-Request. Man konnte dann zum Beispiel keinen Postrequest mit den Links auslösen. Das ist jetzt geändert, man kann jetzt Kopfzeilen mit schicken, die verschiedene HTTP-Methoden ausführen.
14:04
Dann wird gearbeitet daran, dass die Item-Eigenschaften und die Asset-Eigenschaften in der Hierarchie stehen. Das heißt, alles was in den Items steht, wird auch auf die Assets vererbt, sodass man da ein bisschen Deduplizierungen betreiben kann. Und da gibt es einen langen Issue-Tracker noch mit Sachen, die noch abzuarbeiten sind.
14:21
Das sind allerdings alles kleinere Teile, ein bisschen Editorial und so weiter. Das ist jetzt nichts Großes. Wegen den Bändern, das sah halt zum Beispiel vorher so aus, dass man Bänder immer doppelt beschreiben musste. Man hatte hier einmal EO-Bands für die spektralen Daten und Rastabands für alle Daten, die spektral waren, unzusätzlich.
14:44
Also zum Beispiel Quality Flex oder so weiter waren dann in den Rastadaten verfügbar, aber nicht in EO-Bands, weil sie nicht spektral sind. Und dann hatte man zwei Arrays mit diesen ganzen Band-Informationen, aber der Name stand zum Beispiel nur in EO-Bands und in Rastabands fehlte er. Also war die Verknüpfung quasi einfach nur das Array-Index nicht so ideal.
15:05
Das Ganze wird jetzt gemerged in einen Band-Construct. Da sind dann globale Daten wie Name, Beschreibung, Datentyp, sind dann da drin schon spezifiziert. Und die EO, also Spektralen und rasterspezifischen Sachen, kriegen hier diesen Prefix wieder, aber in dem Konstrukt und nicht davor.
15:24
Das heißt, man hat das dann hinterher schön miteinander verknüpft und muss das Ganze nur einmal machen. Es gibt diverse neue Stack-Erweiterungen. Accuracy Authentication zum Beispiel fehlte ganz viel. Wie sagt man, wie die Authentifizierung funktioniert?
15:41
ARD INSAR als neue Domain, spezifische Erweiterung. Wir hatten schon über Raster EO-Verbinder gesprochen. Das ist natürlich ein Umbauprozess in den Erweiterungen. Stereobilder werden mittlerweile unterstützt. Es gibt einen großen gerade Umfang an Änderungen für Machine Learning, Labeling und so weiter.
16:01
In diesen Extensions und auch noch in den Extensions, die schon da waren, gibt es viele Änderungen. Also einfach mal reingucken. Stack-API ist momentan der Fokus nach dem Release letztes Jahr, die Erweiterungen fertigzustellen. Da warten wir längst viel auf die OGC-API-Spezifikation, dass die fertig werden.
16:20
Ein paar Sachen sind jetzt mittlerweile fertiggestellt, wie Fields und Sword. Filtering wartet auf OGC-API. Fertigstellung ist aber relativ stabil schon. Da erwarten wir nicht mehr groß viele Änderungen. Das ist eigentlich nur noch ein formaler Prozess in der OGC und Transaktionen ebenso. Neu hinzugekommen ist die Suche nach Kollektionen.
16:41
Vorher war Stack primär globale Suche oder Suche in einer spezifischen Kollektion. Die Frage war, wie finde ich gerade in größeren Katalogen überhaupt eine Kollektion? Das ist jetzt neuerdings auch spezifiziert und kann benutzt werden. Gerade in, so sagen wir mal, ESA, NASA, so weiter.
17:02
In den alten Katalogen war es häufig so, dass man eine zweistufige Suche hatte. Miterst Kollektionssuche und dann da drin die Items suchen. Das wäre jetzt hier auch wieder möglich, wenn man das denn möchte. Zusätzlich kann man jetzt auch Transaktionen auf Kollektionen ausführen. Das war vorher auch nur definiert für Items. Und Freiteckssuche ist neuerdings auch spezifiziert. Im Ökosystem habe ich mir eine Auswahl genommen, weil sonst hätte das den Vortrag gesprengt.
17:25
PyStack, das ist der Python Client, um Kataloge zu erstellen. Da gibt es eine Neuerung. Da kann man jetzt die Extensions, die Erweiterung, einfacher nutzen. Das ist ganz nett. Stack Browser 3.1 und 3.2 hat diverse neue Funktionen hinzugefügt,
17:41
wie die Suche für die Kollektion zum Beispiel, Validierung von Daten, Aktionen für Assets und Links, sodass man zusetzt, also wenn man einen Asset hat, konnte man bisher mal drauf drücken, Download und Copy der Adresse. Jetzt kann man sagen, zum Beispiel anhand der Adresse, noch öffne mir das in einem externen Tool wie einem Viewer oder irgendwie anderen Dingen.
18:01
Das kann man sich jetzt dazu konfigurieren. R Stack hat Version 1.0 bekommen, konnte vorher nur mit APIs arbeiten, kann jetzt auch noch mit statischen Katalogen arbeiten. Neu hinzugekommen sind ein paar Tools wie zum Beispiel Stack Asset, was vorher relativ kompliziert war, war das Laden der eigentlichen Daten. Man konnte gut mit den Katalogen arbeiten,
18:21
aber massenweise Daten dann auch runterladen anhand von Suchkriterien war relativ schwierig, auch weil Authentifizierung häufig noch im Spiel war. Das ist jetzt mit Stack Asset vereinfacht worden. OL Stack und Stack Layer sind quasi so magische Stack Visualisierungstools für Open Layers und Leaflet. Da gibt man einfach einen Stack rein und versucht das Beste daraus zu machen,
18:41
zum Beispiel die Daten, die drin sind, zu visualisieren, die Bounding Box anzuzeigen und so weiter und so fort. Stack Task ist ein Tool, um Algorithmen auf einer Liste von Stack Item Collections auszuführen. Dann haben wir noch einen neuen Klienten für Julia bekommen, stack.jl.
19:00
Und die Serveranwendung Stack Fast API hat zwei weitere Backends bekommen. Jetzt kann man auch MongoDB benutzen und Open Search als, ich glaube das ist eine API, die zusätzlich verfügbar gemacht wird. Das war es dann auch schon. Links die meisten leider in Englisch,
19:20
aber wenn ihr euch die Folien einfach von der Seite runterladen könnt, die anklicken entsprechend. Zusätzlich dann in den nächsten Tagen noch, bzw. morgen, Ask Me Anything Stacked, wenn also Fragen ruhig geblieben sind, die wir jetzt auch in dem Nachgang von diesem Vortrag nicht lösen können. Einfach morgen um 16.15 Uhr in H4, das ist hier gegenüber glaube ich,
19:41
vorbeikommen, dann können wir noch ein bisschen länger über alles Offene reden. Und um 11.10 Uhr Open EO, falls das jemandem was sagt und da zu fragen bestehen auch, da bin ich auch verfügbar. Ansonsten, wenn Interesse besteht, da ein bisschen rein zu horchen, wir haben alle zwei Wochen montags um 17 Uhr einen Community Call,
20:02
bei dem man teilnehmen kann, einfach dieser Google Gruppe hier unten einen Beitrittsantritt, Beitrittsanträge stellen, dann kriegt man eine Einladung zu den Meetings und kann immer gerne zuhören oder auch was sagen, wenn man möchte oder Fragen stellen oder was vorstellen wollen, wenn man arbeitet und so weiter und so fort. Genau, das war der Vortrag, jetzt bin ich gespannt auf Fragen.
20:32
Vielen Dank, ich habe sogar noch eine Minute gehabt. Gibt es Fragen hier im Auditorium? Dann gibt es eine von mir.
20:42
Und zwar, kann ich Stack eigentlich auch nutzen um ganz klassisch die einzelne Fernerkundungsdatei, die bei mir auf dem USB Stick oder sonst wo liegt, zu beschreiben, was ich sonst vielleicht mit GEDAL machen würde und die Metadatendatei? Auf jeden Fall, das mache ich häufig so, wenn ich Tutorials gebe, dann nummiere ich mir einfach von irgend wem, von Open Arial Map eine Datei,
21:02
die mit einer Drohne aufgenommen wurde und beschreibe die quasi beispielhaft als Daten und mache sie verfügbar. Da habe ich jetzt schon einen kleinen Katalog mit Open Arial Map Daten, die in Stack beschrieben sind, das ist unproblematisch. Klar, die kann man dann verfügbar machen auf Stack Index Listen und dann finden Leute, die das sind, können die verwenden, für was auch immer sie das brauchen.
21:23
Und meine zweite Frage wäre, kann ich damit auch Zeit sehr in Stacks, also ein Raster-Bild mit ganz vielen Bändern, wo jedes Band einem unterschiedlichen Datum zugehört, kann ich die damit auch beschreiben? Ist das vorgesehen? Prinzipiell geht es wohl, ist allerdings nicht, was üblicherweise gemacht wird.
21:42
Da würde man die Zeitenstempel aufteilen, damit man sie besser finden kann über die API. Weil wenn sie versteckt sind in den Asset, selber kann man schlecht suchen, so wie die Implementierungen zumindest gerade sind. Das heißt, es würde nur als ein großer Block an Zeitdaten verfügbar sein und dementsprechend schwer zu finden sein, die einzelnen Teile davon.
22:00
Das heißt eigentlich würde man das aufteilen in verschiedene Zeitpunkte und dann so verfügbar machen, ja. Dann habe ich hier noch Fragen aus dem Internet. Was ist zum Beispiel für eine Kommune der Anwendungsfall für Stack, eher Datenbereitstellung oder Datenkonsum? Na ja, Datenkonsum wird vereinfacht natürlich dadurch,
22:22
dass man eine standardisierte API hat und auch das ganze Tooling drum herum. Datenbereitstellen macht dann hoffentlich das Konsumieren der Benutzer einfacher, weil man eben das Gleiche wieder hat. Ich denke, da haben wir dann auch gleich einen guten Vortrag zu. Das wird gleich in den nächsten 30 Minuten, 20 Minuten,
22:42
auch dann nochmal sehr gut an Beispiel Niedersachsen gezeigt. Da haben wir direkt die beste Antwort. Dann die nächste Frage. Können in Vector-Daten auch Lebensspannen kodiert werden? Noch mal. Können in Vector-Daten auch Lebensspannen kodiert werden, Zeitspannen?
23:02
Vector-Daten, gut, wir haben jetzt, wir kümmern uns ja nicht um spezielle Datentypen hier. Das heißt, wie Vector-Daten selber kodiert werden, ist eine andere Frage, die wir uns nicht stellen. Wir sind ja nur die Metadaten dazu. Die Metadaten selber sind natürlich Vector-Daten in diesem Fall.
23:22
Und dort lassen sich quasi für Items auch Zeitspannen definieren. Ja, es muss nicht ein Zeitpunkt sein, genauer. Man kann auch sagen, es geht von Mai bis Juni 23. Die nächste Frage bezieht sich zur OGC-ARPi. Wie steht Stack zu OGC-ARPi Records?
23:43
Alternative oder Ergänzung? Na ja gut, das Problem war, dass Stack vor Records angefangen hat. Dementsprechend haben wir da ein bisschen nachträglich Arbeit reinfließen lassen müssen. Im Endeffekt ist es so gedacht, wir sind noch nicht 100 Prozent da, aber sagen wir mal 99 Prozent. Dass Record quasi die Grundlage ist und Stack ein Profil davon quasi.
24:04
Stack wäre eine Erweiterung. Records ist ja relativ allgemein gehalten. Stack ist spezifischer. Dementsprechend im Idealfall haben wir es dann irgendwann so. Und wir sind nah dran, dass man eine Records-API hosten kann. Und ein Teil davon ist halt Stack einfach. Dass das nur zusätzliche Felder hinzufügt oder ein bisschen zusätzliche Funktionalitäten.
24:23
Aber die Grundlage Records ist plus Stack. Dann habe ich eine Frage, die sehr viele Votes bekommen hat. Das hört sich für mich ohne vordere Belastung so an, als würde es nur um Map-Tiles oder Rasterdaten mit Ausdehnungen und Positionen gehen. Ist Stack aber auch für Punktfahrt- und volumenförmige Geo-Features ausgelegt?
24:44
Durchaus ist es das. Also da ist auf Features basiert und auf Records ist das durchaus möglich. Wir haben auch die dritte Dimension, da kann man spezifizieren, wird nicht viel gemacht. Wir haben auch Daten, Punktwolkendaten, die in Stack spezifiziert sind.
25:01
Prinzipiell schon, ist allerdings auch noch ein Bereich, der relativ wenig erkundet ist, sagen wir mal so. Da stößt man momentan immer noch so. Wir haben Sachen, die sind gut mit Erweiterungen auch versorgt. Ein paar Sachen noch nicht so. Da muss man teilweise noch ein bisschen in den Erweiterungen arbeiten und auch selber noch ein bisschen Hand anlegen. Aber so wächst das Ganze halt mit der Zeit auch voran.
25:22
Dass wir halt neue Sachen finden, die noch nicht so gut erkundet sind. Und dann einfach die Erweiterungen dafür gemeinschaftlich schreiben. Dann die vorletzte Frage. Können Felder von Vector-Datensätzen beschrieben werden? Prinzipiell schon, ja. Es ist natürlich jetzt in Stack so, dass wenn man ein einzelnes Feature beschreiben will und das als Item macht, dann macht das nicht viel Sinn.
25:45
Da hat man dann zwei Features, die sich selber beschreiben, das ist nicht so sinnvoll. Was mehr gemacht wird, wenn man zum Beispiel eine lange Liste an Vektordaten hat. In einer Geo-Paket-Datei, in einem Shapefile, in einem Geo-Package oder sonst was, CSV-Datei.
26:02
Dann beschreibt man diese Daten entsprechend in Stack, linkt zu denen und sagt dann, das hier ist meine Spalte für Geo-Daten. Das sind die anderen Spalten und so weiter. Das wird eher in den Bereich dann gemacht, wo man halt massenweise die Daten verfügbar macht als Asset-Datei. Ok, und jetzt die letzte Frage.
26:23
Asset innerhalb Item-Collection bedeutet, dass Assets transitiv über Items auch in Collections sind? Oder können Assets auch direkt in Katalogen sein? Die Spezifikation macht es so, dass quasi, also ich hatte jetzt eben Item-Collection nochmal genannt. Das ist ein Begriff, der kommt aus der API, den habe ich eben nicht erklärt.
26:43
Also Collections haben Assets, das sind dann Sachen, die normalerweise übergreifend über alle Items verfügbar sind. Das kann zum Beispiel in manchen Katalogen werden die Stack-Items nochmal separat als Geo-Package-Datei verfügbar gemacht. Das ist dann in der Collection einfach, weil es die komplette Collection quasi beinhaltet oder beschreibt.
27:03
In den Items selber sind dann die Daten, die halt zu diesen Items gehören. Und eine Item-Collection ist einfach nur eine Liste an Items, die halt dann selber wieder in den Items natürlich Assets haben. Die Item-Collection selber hat aber keine Assets. Also ich hoffe, das beantwortet die Frage. Gibt es dann jetzt hier im Raum noch weitere Fragen? Nein?
27:23
Ok, dann bedanke ich mich. Applaus nochmal. Gerne, danke.