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 anzugehen, haben das Open Geospatial Consortium (OGC) und das Gruppe für Erdbeobachtung (GEO) lud globale Data Cube-Experten ein, um den „Stand der Technik“ zu diskutieren und einen Weg nach vorne zu finden Workshop „Auf dem Weg zur Data Cube-Interoperabilität“. Der zweitägige Workshop, der Ende April 2021 stattfand, begann mit einer Reihe vorab aufgezeichneter Positionserklärungen von Datenwürfelanbietern und Datenwürfelnutzern. Diese Videos dienten als Ausgangspunkt für intensive Diskussionen, die nicht nur eine neue Definition des Begriffs „Datenwürfel“ hervorbrachten, sondern auch die Notwendigkeit eines „benutzerzentrierten“, API-basierten Ansatzes unterstrichen, der nicht nur die dem Benutzer zur Verfügung stehenden Daten offenlegt, sondern auch die Verarbeitungsalgorithmen, die darauf ausgeführt werden können – und es dem Benutzer ermöglicht, eigene hinzuzufügen. Die Ergebnisse des Workshops wurden auf der OGC & GEO Towards Data Cube Interoperability Workshop-Webseite.
Datenwürfel aus der Sicht der Anwender
Bestehende Definitionen von Datenwürfeln konzentrieren sich häufig auf den Datenstrukturaspekt, wie er in der Informatik verwendet wird. Im Gegensatz dazu Workshop „Auf dem Weg zur Data Cube-Interoperabilität“ betonte die Notwendigkeit, diese Definitionen hinter sich zu lassen und sich auf die Perspektive des Benutzers zu konzentrieren. Den Benutzern ist es egal, ob die Daten in einer relationalen Datenbank, in einem Cloud-basierten Objektspeicher oder auf einem Dateiserver gespeichert sind. Was die Benutzer interessiert, ist, wie sie auf die Daten zugreifen können und welche Verarbeitungsalgorithmen sie darauf anwenden können. Jeder solche Standard für den Zugriff 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 Endbenutzer: eine einzige, einfache, standardisierte HTTP-API zum Lernen und/oder Programmieren, unabhängig davon, wo sich die Daten befinden, bedeutet eine größere Auswahl an verfügbarer Software (einschließlich Low-Code- oder No-Code-Plattformen), unterstützt eine größere Auswahl an Datenwürfelanbietern und eine größere Anzahl von Verarbeitungsalgorithmen. Aus wissenschaftlicher Sicht bedeutet dies, dass der Atmosphärenwissenschaftler nicht zusätzlich ein Python-Experte sein muss und möglicherweise eine Low-Code- oder No-Code-Plattform-GUI verwenden kann, um einen Algorithmus zu erstellen, der die Daten für seine Hitzewellenstudie in ganz Deutschland verarbeitet. Ein anderer Atmosphärenwissenschaftler könnte dann denselben Verarbeitungsalgorithmus mit minimalen Änderungen auf Großbritannien anwenden – selbst wenn die erforderlichen Daten von einem anderen standardkonformen Datenanbieter gespeichert werden. Dieser Ansatz erhöht die Transparenz und Wiederholbarkeit wissenschaftlicher Studien und anderer wertvoller Analyseaufgaben erheblich.
Für Softwareentwickler: Eine einzige, einfache, standardisierte HTTP-API bedeutet, dass Softwareentwickler keine eigenen anbieterspezifischen Methoden entwickeln müssen, um den Zugriff auf Datenwürfel in ihrer Software zu ermöglichen. Stattdessen interagieren sie mit Datenwürfeln über HTTP-Aufrufe und profitieren so von einfacher Standard-Webkommunikation statt von Interaktionen auf Programmebene. Durch die Codierung nach einem vereinbarten Standard können Entwickler mit jedem kompatiblen Datenwürfel arbeiten und gleichzeitig würfelspezifische Anpassungen minimieren. Dies erhöht die Benutzerfreundlichkeit der Software und senkt gleichzeitig die Entwicklungs- und Wartungskosten.
Für Datenwürfeloperatoren: Die Verwendung einer einzigen, einfachen, standardisierten HTTP-API reduziert die Entwicklungs- und Wartungskosten und erweitert gleichzeitig den Kundenstamm. Durch die Einhaltung von Standards können Anbieter Kunden erreichen, die jedes konforme Softwarepaket verwenden, und nicht nur Kunden, die eine ausgewählte Liste von Software verwenden, die für Ihre spezielle Instanz codiert ist. Dies bedeutet, dass mehr Leute für Ihren Datenwürfel codieren werden, selbst wenn sie nicht wissen, dass Ihr Dienst existiert.
Was kommt als Nächstes für OGC?
Es ist noch früh, aber Sie können davon ausgehen, dass eine API für Datenwürfel Teil unserer Familie von OGC-API-StandardsDie Arbeit an einer solchen Datenwürfel-API baut auf der Arbeit unserer Earth Observation Exploitation Platform auf (siehe Ein App Store für Big Data, in GeoConnexion International, Juli/August 2020) und wird derzeit im Rahmen von OGC-Testbed-17.
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 verfolgen als Beobachter im OGC-Testbed-17. Alternativ können OGC-Mitglieder dem Arbeitsgruppe für den Bereich „Plattform zur Nutzung der Erdbeobachtung“Detaillierte Ergebnisse des Workshops finden Sie auf der OGC & GEO Towards Data Cube Interoperability Workshop-Webseite.
Eine Version dieses Artikels erschien ursprünglich in der Ausgabe Juli/August 2021 des GeoConnexion International Magazine.
