Geospatiale datakubussen worden tegenwoordig veelvuldig gebruikt vanwege hun performante, cloud-compatibele geospatiale datatoegang en -analyse. Maar verschillen in hun ontwerp, interfaces en verwerking van temporele kenmerken veroorzaken interoperabiliteitsuitdagingen voor iedereen die met meer dan één oplossing werkt. Zulke uitdagingen verspillen onnodig tijd en geld en beïnvloeden – vanuit een wetenschappelijk perspectief – de reproduceerbaarheid.
Om deze uitdagingen aan te pakken, nodigden het Open Geospatial Consortium (OGC) en de Group on Earth Observation (GEO) wereldwijde data cube-experts uit om de "stand van zaken" te bespreken en een weg voorwaarts te vinden tijdens de workshop 'Towards Data Cube Interoperability' . De tweedaagse workshop, die eind april 2021 plaatsvond, begon met een reeks vooraf opgenomen standpunten van data cube-aanbieders en -gebruikers. Deze video's dienden als uitgangspunt voor intense discussies die niet alleen een nieuwe definitie van de term 'data cube' opleverden, maar ook de noodzaak benadrukten van een 'gebruikersgerichte' API-gebaseerde aanpak die niet alleen de beschikbare data aan de gebruiker blootlegt, maar ook de verwerkingsalgoritmen die erop kunnen worden uitgevoerd – en de gebruiker in staat stelt om zelf algoritmen toe te voegen. De resultaten van de workshop zijn gepubliceerd op de webpagina van de OGC & GEO 'Towards Data Cube Interoperability Workshop'.
Datakubussen vanuit het perspectief van de gebruiker
Bestaande definities van datakubussen richten zich vaak op de datastructuur zoals die in de informatica wordt gebruikt. De workshop 'Towards Data Cube Interoperability' benadrukte daarentegen de noodzaak om deze definities los te laten en te focussen op het perspectief van de gebruiker. Gebruikers geven er niet om of de data is opgeslagen in een relationele database, een cloudgebaseerde objectopslag of een bestandsserver. Waar gebruikers wel in geïnteresseerd zijn, is hoe ze toegang krijgen tot de data en welke verwerkingsalgoritmen ze erop kunnen toepassen. Elke standaard voor toegang tot data moet dit weerspiegelen.
Dit leidde tot een interessante heroverweging van wat een datakubus is en kan zijn. Hoewel er geen formele consensus over was, namen de deelnemers aan de workshop over het algemeen een gebruikersgerichte definitie van een geodatakubus als volgt:
“Een geodatakubus is een gediscretiseerd model van de aarde dat de geschatte waarden van bepaalde variabelen voor elke cel biedt. Idealiter is een datakubus dicht (d.w.z. bevat geen lege cellen) met een constante celafstand voor zijn ruimtelijke en temporele dimensies. Een datakubus beschrijft zijn basisstructuur, d.w.z. zijn ruimtelijke en temporele kenmerken en zijn ondersteunde variabelen (ook wel eigenschappen genoemd), als metadata. Het wordt verder gedefinieerd door een set functies. Deze functies beschrijven de beschikbare methoden voor ontdekking, toegang, weergave, analyse en verwerking waarmee de gebruiker met de datakubus kan communiceren.”
Zoals we zien, wordt de datakubus beschreven voor de gebruiker, niet voor de data. Het maakt niet uit of de datakubus één, twee of drie ruimtelijke dimensies bevat, of dat tijd zijn eigen dimensie(s) krijgt of slechts deel uitmaakt van de metadata van een observatie – of helemaal niet relevant is voor de data. Evenzo maakt het niet uit hoe de data wordt opgeslagen. Wat deze heterogene datakubussen zal verenigen, is hun gebruik van een gestandaardiseerde HTTP-gebaseerde API als hun methode van toegang en interactie.
De belangrijkste zorg van de gebruiker is welke functies de data cube-instantie biedt om toe te passen op de data. Deze functies zijn wat de op de gebruiker gerichte data cube-definitie primair onderscheidt van andere definities. Een gebruiker moet begrijpen welke vragen kunnen worden gesteld om toegang te krijgen tot data die voldoet aan specifieke filtercriteria, hoe specifieke (sub-)sets van data te visualiseren of hoe analytische functies en andere processen op de data cube uit te voeren. Als dit wordt ondersteund, moet de gebruiker ook begrijpen hoe hij zijn eigen processen aan de data cube kan toevoegen, zodat deze rechtstreeks op de data cube kunnen worden uitgevoerd zonder dat er grote hoeveelheden data uit de cloud hoeven te worden overgebracht.
Dit wil niet zeggen dat alle andere kenmerken – zoals ruimtelijke en temporele details (bijvoorbeeld dicht of schaars, overlappend of perfect uitgelijnd, constante of onregelmatige afstanden) en eigenschapsdetails (meetschalen, onvolledige gegevens, interpolatiemethoden, foutwaarden, enz.) – niet van belang zijn voor de gebruiker: ze moeten nog steeds bekend zijn. Als zodanig worden ze via de data cube API als metadata verstrekt, zodat de gebruiker er rekening mee kan houden bij het beoordelen van de beste manier om de gegevens te verwerken.
Interoperabiliteit via een Data Cube API
Wat betekent dit voor OGC? Wij denken dat een API-gebaseerde, flexibele benadering van standaarden eindgebruikers, softwareontwikkelaars en data cube-operators de beste ervaring zal bieden.
Voor eindgebruikers: één eenvoudige, gestandaardiseerde HTTP API om te leren en/of te programmeren, ongeacht waar de data zich bevindt, betekent een grotere selectie aan beschikbare software (inclusief low-code of no-code platforms) die een grotere keuze aan data-cube-aanbieders en een groter aantal verwerkingsalgoritmen ondersteunt. Vanuit wetenschappelijk oogpunt betekent dit dat een atmosferisch wetenschapper geen Python-expert hoeft te zijn en mogelijk een low-code of no-code platform met een grafische gebruikersinterface kan gebruiken om een algoritme te creëren dat de data verwerkt voor zijn of haar hittegolfstudie in Duitsland. Een andere atmosferisch wetenschapper zou datzelfde verwerkingsalgoritme vervolgens met minimale aanpassingen kunnen toepassen op het Verenigd Koninkrijk – zelfs als de benodigde data bij een andere, aan de standaarden voldoenende data-aanbieder wordt bewaard. Deze aanpak verhoogt de transparantie en reproduceerbaarheid van wetenschappelijke studies en andere waardevolle analysetaken aanzienlijk.
Voor softwareontwikkelaars: een enkele, eenvoudige, gestandaardiseerde HTTP API betekent dat ze geen eigen, leverancierspecifieke methoden hoeven te ontwerpen om toegang te bieden tot datakubussen in hun software. In plaats daarvan communiceren ze met datakubussen via HTTP-aanroepen, waardoor ze profiteren van eenvoudige, standaard webcommunicatie in plaats van interacties op programmatisch niveau. Door te coderen volgens een overeengekomen standaard kunnen ontwikkelaars met elke compatibele datakubus werken en tegelijkertijd kubusspecifieke aanpassingen minimaliseren. Dit verhoogt de gebruiksvriendelijkheid van de software en verlaagt de ontwikkelings- en onderhoudskosten.
Voor beheerders van datakubussen: het gebruik van één eenvoudige, gestandaardiseerde HTTP API verlaagt de ontwikkelings- en onderhoudskosten en vergroot het klantenbestand. Door te voldoen aan de standaarden kunnen aanbieders klanten bereiken die elk compatibel softwarepakket gebruiken, in plaats van alleen klanten die een selecte lijst met software gebruiken die specifiek voor uw instantie is ontwikkeld. Dit betekent dat meer mensen voor uw datakubus zullen programmeren, zelfs als ze niet weten dat uw service bestaat.
Wat is de volgende stap voor OGC?
Het is nog vroeg, maar je kunt verwachten dat een API voor datakubussen onderdeel zal worden van onze OGC API-standaarden . De ontwikkeling van zo'n datakubus-API bouwt voort op het werk aan ons Earth Observation Exploitation Platform (zie An App Store For Big Data in GeoConnexion International, juli/augustus 2020) en vindt momenteel plaats als onderdeel van OGC Testbed-17.
Als u meer wilt weten over de aanpak van OGC om de toegang tot datakubussen te standaardiseren, kunnen OGC-leden de eerste ontwikkelingen volgen als waarnemer in OGC's Testbed-17 . Als alternatief kunnen OGC-leden zich aansluiten bij de Earth Observation Exploitation Platform Domain Working Group . Gedetailleerde resultaten van de workshop zijn beschikbaar op de webpagina van de OGC & GEO Towards Data Cube Interoperability Workshop.
Een versie van dit artikel verscheen oorspronkelijk in de editie van juli/augustus 2021 van GeoConnexion International Magazine.
