Geodatenwürfel werden heutzutage häufig verwendet, um einen leistungsstarken, Cloud-kompatiblen Zugriff auf und eine Analyse von Geodaten zu ermöglichen. Unterschiede in ihrem Design, ihren Schnittstellen und der Handhabung zeitlicher Merkmale führen jedoch zu Interoperabilitätsproblemen für jeden, der mit mehr als einer Lösung interagiert. Solche Probleme verschwenden unnötig Zeit und Geld und beeinträchtigen – aus wissenschaftlicher Sicht – die Reproduzierbarkeit.
Um diese Herausforderungen zu bewältigen, luden das Open Geospatial Consortium (OGC) und die Group on Earth Observation (GEO) internationale Experten für Datenwürfel ein, um im Rahmen des Workshops „Towards Data Cube Interoperability “ den aktuellen Stand der Technik zu diskutieren und Lösungsansätze zu entwickeln . Der zweitägige Workshop, der Ende April 2021 stattfand, begann mit vorab aufgezeichneten Positionspapieren von Datenwürfelanbietern und -nutzern. Diese Videos bildeten den Ausgangspunkt für intensive Diskussionen, die nicht nur zu einer neuen Definition des Begriffs „Datenwürfel“ führten, sondern auch die Notwendigkeit eines nutzerzentrierten, API-basierten Ansatzes unterstrichen. Dieser Ansatz soll nicht nur die verfügbaren Daten, sondern auch die darauf anwendbaren Verarbeitungsalgorithmen offenlegen und es dem Nutzer ermöglichen, eigene Algorithmen hinzuzufügen. Die Ergebnisse des Workshops wurden auf der Webseite des OGC & GEO „Towards Data Cube Interoperability Workshop“ veröffentlicht.
Datenwürfel aus der Sicht der Anwender
Bestehende Definitionen von Datenwürfeln konzentrieren sich oft auf die Datenstruktur im Sinne der Informatik. Im Gegensatz dazu betonte der Workshop „Towards Data Cube Interoperability“, dass diese Definitionen über Bord geworfen und die Nutzerperspektive in den Mittelpunkt gestellt werden müsse. Nutzern ist es egal, ob die Daten in einer relationalen Datenbank, einem Cloud-basierten Objektspeicher oder auf einem Dateiserver abgelegt sind. Sie interessieren sich vielmehr dafür, wie sie auf die Daten zugreifen und welche Verarbeitungsalgorithmen sie anwenden können. Jeder Zugriffsstandard sollte dies widerspiegeln.
Dies führte zu einem interessanten Umdenken darüber, was ein Datenwürfel ist und sein kann. Obwohl es keine formelle Konsensbasis gab, gingen die Workshop-Teilnehmer im Allgemeinen davon aus, dass eine benutzerzentrierte Definition eines Geodatenwürfels wie folgt lautet:
„Ein Geodatenwürfel ist ein diskretisiertes Modell der Erde, das für jede Zelle die geschätzten Werte bestimmter Variablen bietet. Im Idealfall ist ein Datenwürfel dicht (d. h. enthält keine leeren Zellen) mit konstantem Zellenabstand für seine räumlichen und zeitlichen Dimensionen. Ein Datenwürfel beschreibt seine Grundstruktur, d. h. seine räumlichen und zeitlichen Eigenschaften und seine unterstützten Variablen (auch Eigenschaften genannt), als Metadaten. Er wird weiter durch eine Reihe von Funktionen definiert. Diese Funktionen beschreiben die verfügbaren Methoden zur Entdeckung, zum Zugriff, zur Anzeige, zur Analyse und zur Verarbeitung, mit denen der Benutzer mit dem Datenwürfel interagieren kann.“
Wie wir sehen, wird der Datenwürfel für den Benutzer beschrieben, nicht für die Daten. Dabei spielt es keine Rolle, ob der Datenwürfel eine, zwei oder drei räumliche Dimensionen enthält, ob die Zeit ihre eigene(n) Dimension(en) hat oder nur Teil der Metadaten einer Beobachtung ist – oder für die Daten überhaupt nicht relevant ist. Ebenso spielt es keine Rolle, wie die Daten gespeichert werden. Was diese heterogenen Datenwürfel vereinheitlicht, ist ihre Verwendung einer standardisierten HTTP-basierten API als Zugriffs- und Interaktionsmethode.
Das Hauptanliegen des Benutzers ist, welche Funktionen die Datenwürfelinstanz bietet, um sie auf die Daten anzuwenden. Diese Funktionen sind es, die die benutzerzentrierte Datenwürfeldefinition von anderen Definitionen unterscheiden. Ein Benutzer muss verstehen, welche Fragen gestellt werden können, um auf Daten zuzugreifen, die bestimmte Filterkriterien erfüllen, wie bestimmte (Teil-)Datensätze visualisiert werden oder wie analytische Funktionen und andere Prozesse auf dem Datenwürfel ausgeführt werden. Falls unterstützt, muss der Benutzer auch verstehen, wie er dem Datenwürfel eigene Prozesse hinzufügen kann, damit diese direkt auf dem Datenwürfel ausgeführt werden können, ohne dass große Datenmengen aus der Cloud übertragen werden müssen.
Das bedeutet jedoch nicht, dass alle anderen Eigenschaften – wie räumliche und zeitliche Details (z. B. Dichte oder geringe Dichte, Überlappung oder perfekte Ausrichtung, konstante oder inkonstante Abstände) und Eigenschaftsdetails (Messmaßstäbe, unvollständige Daten, Interpolationsmethoden, Fehlerwerte usw.) – für den Benutzer unwichtig sind: Sie müssen trotzdem bekannt sein. Daher werden sie über die Datenwürfel-API als Metadaten bereitgestellt, damit der Benutzer sie bei der Beurteilung der optimalen Verarbeitung der Daten berücksichtigen kann.
Interoperabilität durch eine Data Cube API
Wo bleibt OGC? Wir glauben, dass ein API-basierter, flexibler Ansatz für Standards Endbenutzern, Softwareentwicklern und Datenwürfelbetreibern die beste Erfahrung bietet.
Für Endnutzer bedeutet eine einheitliche, einfache und standardisierte HTTP-API, die unabhängig vom Speicherort der Daten erlernt und/oder programmiert werden kann, eine größere Auswahl an verfügbarer Software (einschließlich Low-Code- und No-Code-Plattformen). Dies wiederum ermöglicht eine größere Vielfalt an Datenwürfelanbietern und eine größere Anzahl an Verarbeitungsalgorithmen. Aus wissenschaftlicher Sicht bedeutet dies, dass Atmosphärenforscher nicht zusätzlich Python-Experten sein müssen. Sie können beispielsweise mithilfe einer Low-Code- oder No-Code-Plattform und deren Benutzeroberfläche einen Algorithmus erstellen, der die Daten für ihre Hitzewellenstudie in Deutschland verarbeitet. Ein anderer Atmosphärenforscher kann diesen Algorithmus dann mit minimalen Anpassungen auf Großbritannien anwenden – selbst wenn die benötigten Daten von einem anderen standardkonformen Datenanbieter stammen. Dieser Ansatz erhöht die Transparenz und Reproduzierbarkeit wissenschaftlicher Studien und anderer wichtiger Analysen erheblich.
Für Softwareentwickler bedeutet eine einheitliche, einfache und standardisierte HTTP-API, dass sie keine eigenen herstellerspezifischen Methoden für den Zugriff auf Datenwürfel in ihrer Software entwickeln müssen. Stattdessen interagieren sie über HTTP-Aufrufe mit den Datenwürfeln und profitieren so von einfacher, standardisierter Webkommunikation anstatt von Interaktionen auf Programmebene. Durch die Einhaltung eines vereinbarten Standards können Entwickler mit jedem kompatiblen Datenwürfel arbeiten und gleichzeitig würfelspezifische Anpassungen minimieren. Dies erhöht die Benutzerfreundlichkeit der Software und senkt die Entwicklungs- und Wartungskosten.
Für Betreiber von Datenwürfeln: Die Verwendung einer einzigen, einfachen und standardisierten HTTP-API senkt die Entwicklungs- und Wartungskosten und erweitert gleichzeitig den Kundenstamm. Die Einhaltung von Standards ermöglicht es Anbietern, Kunden zu erreichen, die beliebige kompatible Softwarepakete verwenden, und nicht nur solche, die eine ausgewählte Liste von Software nutzen, die speziell für Ihre Instanz entwickelt wurde. Das bedeutet, dass mehr Entwickler für Ihren Datenwürfel programmieren werden, selbst wenn sie Ihren Dienst nicht kennen.
Was kommt als Nächstes für OGC?
Es ist noch zu früh für endgültige Aussagen, aber Sie können davon ausgehen, dass eine API für Datenwürfel Teil unserer OGC-API- Standardfamilie werden wird . Die Entwicklung einer solchen Datenwürfel-API baut auf unserer Earth Observation Exploitation Platform auf (siehe „An App Store For Big Data“ , GeoConnexion International, Juli/August 2020) und wird derzeit im Rahmen von OGC Testbed-17 durchgeführt.
Wenn Sie mehr über den Ansatz des OGC zur Standardisierung des Zugriffs auf Datenwürfel erfahren möchten, können OGC-Mitglieder die frühe Entwicklung als Beobachter im OGC-Testbed-17 verfolgen. Alternativ können OGC-Mitglieder der Arbeitsgruppe „Earth Observation Exploitation Platform Domain Working Group“ beitreten . Detaillierte Ergebnisse des Workshops finden Sie auf der Webseite des OGC & GEO Towards Data Cube Interoperability Workshops.
Eine Version dieses Artikels erschien ursprünglich in der Juli/August-Ausgabe 2021 des GeoConnexion International Magazine.
