En la actualidad, los cubos de datos geoespaciales se utilizan con frecuencia para permitir el acceso y el análisis de datos geoespaciales de alto rendimiento y compatibles con la nube. Sin embargo, las diferencias en su diseño, interfaces y manejo de características temporales están generando desafíos de interoperabilidad para cualquiera que interactúe con más de una solución. Estos desafíos están desperdiciando tiempo y dinero innecesariamente y, desde una perspectiva científica, afectando la reproducibilidad.
Para abordar estos desafíos, el Consorcio Geoespacial Abierto (OGC) y la Grupo de Observación de la Tierra (GEO) invitó a expertos globales en cubos de datos para discutir el "estado del arte" y encontrar una manera de avanzar en el Taller Hacia la interoperabilidad de Data CubeEl taller de dos días, que se llevó a cabo a fines de abril de 2021, comenzó con una serie de declaraciones de posición pregrabadas por parte de proveedores y usuarios de cubos de datos. Estos videos sirvieron como punto de partida para intensos debates que no solo produjeron una nueva definición del término "cubo de datos", sino que también subrayaron la necesidad de un enfoque basado en API "centrado en el usuario" que exponga no solo los datos disponibles para el usuario, sino también los algoritmos de procesamiento que se pueden ejecutar en ellos y que permitan al usuario agregar los suyos propios. Los resultados del taller se han publicado en Página web del taller OGC y GEO Towards Data Cube Interoperability.
Cubos de datos desde la perspectiva del usuario
Las definiciones existentes de cubos de datos a menudo se centran en el aspecto de la estructura de datos tal como se utiliza en la informática. En contraste con esto, el Taller Hacia la interoperabilidad de Data Cube Se hizo hincapié en la necesidad de dejar atrás estas definiciones y centrarse en la perspectiva del usuario. A los usuarios no les importa si los datos están almacenados en una base de datos relacional, en un almacén de objetos basado en la nube o en un servidor de archivos. Lo que les interesa a los usuarios es cómo pueden acceder a los datos y los algoritmos de procesamiento que pueden aplicarles. Cualquier estándar de acceso de este tipo debería reflejar esto.
Esto dio lugar a un interesante replanteamiento de lo que es y puede ser un cubo de datos. Aunque no se llegó a un consenso formal al respecto, los participantes del taller en general consideraron que una definición centrada en el usuario de un cubo de datos geográficos sería:
“Un cubo de datos geográficos es un modelo discretizado de la Tierra que ofrece los valores estimados de ciertas variables para cada celda. Idealmente, un cubo de datos es denso (es decir, no incluye celdas vacías) con una distancia de celda constante para sus dimensiones espaciales y temporales. Un cubo de datos describe su estructura básica, es decir, sus características espaciales y temporales y sus variables admitidas (también conocidas como propiedades), como metadatos. Se define además mediante un conjunto de funciones. Estas funciones describen los métodos de descubrimiento, acceso, visualización, análisis y procesamiento disponibles mediante los cuales el usuario puede interactuar con el cubo de datos”.
Como vemos, el cubo de datos se describe para el usuario, no para los datos. No importa si el cubo de datos contiene una, dos o tres dimensiones espaciales, si el tiempo tiene sus propias dimensiones o si es solo parte de los metadatos de una observación, o si no es relevante para los datos en absoluto. De manera similar, no importa cómo se almacenan los datos. Lo que unificará estos cubos de datos heterogéneos es el uso de una API estandarizada basada en HTTP como método de acceso e interacción.
La principal preocupación del usuario es qué funciones ofrece la instancia del cubo de datos para aplicar a los datos. Estas funciones son las que diferencian principalmente la definición del cubo de datos centrada en el usuario de otras definiciones. Un usuario debe comprender qué preguntas se pueden realizar para acceder a los datos que cumplen con criterios de filtro específicos, cómo visualizar conjuntos (sub) específicos de datos o cómo ejecutar funciones analíticas y otros procesos en el cubo de datos. Si es compatible, el usuario también debe comprender cómo agregar sus propios procesos al cubo de datos para que se puedan ejecutar directamente en el cubo de datos sin la necesidad de transferir grandes cantidades de datos fuera de la nube.
Esto no quiere decir que todas las demás características, como los detalles espaciales y temporales (por ejemplo, si son densos o dispersos, si se superponen o están perfectamente alineados, si las distancias son constantes o inconstantes) y los detalles de las propiedades (escalas de medición, datos incompletos, métodos de interpolación, valores de error, etc.), no sean de interés para el usuario: aún así, es necesario conocerlos. Por ello, se proporcionarán a través de la API del cubo de datos como metadatos, para que el usuario pueda tenerlos en cuenta al evaluar la mejor manera de procesar los datos.
Interoperabilidad a través de una API de Data Cube
¿En qué situación deja esto a OGC? Creemos que un enfoque flexible y basado en API para los estándares brindará a los usuarios finales, desarrolladores de software y operadores de cubos de datos la mejor experiencia.
Para usuarios finales: Una única API HTTP simple y estandarizada para aprender y/o codificar, sin importar dónde se encuentren los datos, significará que una mayor selección de software disponible (incluidas plataformas de poco o ningún código) respaldará una mayor elección de proveedores de cubos de datos y un mayor número de algoritmos de procesamiento. Desde una perspectiva científica, esto significa que el científico atmosférico no tiene que ser también un experto en Python, potencialmente usando una interfaz gráfica de usuario de plataforma de poco o ningún código para crear un algoritmo que procese los datos para su estudio de olas de calor en Alemania. Otro científico atmosférico podría entonces tomar ese mismo algoritmo de procesamiento y aplicarlo al Reino Unido con cambios mínimos, incluso si los datos requeridos están en poder de un proveedor de datos que cumpla con los estándares diferentes. Este enfoque aumenta enormemente la transparencia y repetibilidad de los estudios científicos y otras tareas de análisis valiosas.
Para desarrolladores de software: Una única API HTTP simple y estandarizada significa que los desarrolladores de software no tienen que diseñar sus propios métodos específicos de proveedor para proporcionar acceso a los cubos de datos en su software. En cambio, interactúan con los cubos de datos a través de llamadas HTTP, lo que les permite beneficiarse de una comunicación web estándar simple, en lugar de interacciones a nivel programático. Al codificar según un estándar acordado, los desarrolladores pueden trabajar con cualquier cubo de datos compatible y minimizar las adaptaciones específicas del cubo. Esto aumenta la usabilidad del software y reduce los costos de desarrollo y mantenimiento.
Para los operadores de cubos de datos: El uso de una única API HTTP simple y estandarizada reduce los costos de desarrollo y mantenimiento, al mismo tiempo que amplía la base de clientes. El cumplimiento de los estándares permite a los proveedores acceder a clientes que utilizan cualquier paquete de software compatible, en lugar de solo aquellos que utilizan una lista seleccionada de software codificado para funcionar con su instancia específica. Esto significa que más personas codificarán para su cubo de datos, incluso si no saben que existe su servicio.
¿Qué sigue para OGC?
Aún es pronto, pero podemos esperar ver una API relacionada con el cubo de datos que se convertirá en parte de nuestra familia de Estándares API de OGCEl trabajo para lograr una API de cubo de datos de este tipo se basa en el trabajo de nuestra Plataforma de explotación de observación de la Tierra (consulte Una tienda de aplicaciones para Big Data, en GeoConnexion International, julio/agosto de 2020), y actualmente está en marcha como parte de Banco de pruebas OGC-17.
Si está interesado en aprender sobre el enfoque de OGC para estandarizar el acceso a los cubos de datos, los miembros de OGC pueden seguir su desarrollo inicial como Observadores en el banco de pruebas 17 de OGCAlternativamente, los miembros de OGC pueden unirse a Grupo de trabajo sobre el dominio de la plataforma de explotación de la observación de la TierraLos resultados detallados del taller están disponibles en Página web del taller OGC y GEO Towards Data Cube Interoperability.
Una versión de este artículo apareció originalmente en el Edición de julio/agosto de 2021 de la revista GeoConnexion International.
