Artículo escrito por Chris Holmes, investigador visitante de OGC.
En mi publicación anterior, expuse la visión de la geoespacial nativa en la nube , pero en esta ocasión quiero profundizar en los detalles de lo que se necesita. Describiré las áreas clave donde se requieren estándares fundamentales y luego analizaré el estado actual de cada una. Estas áreas varían desde las bien establecidas hasta las más especulativas, pero todas son perfectamente alcanzables. Finalmente, profundizaré en el área en la que me he centrado principalmente durante los últimos meses como investigador visitante de OGC.
Componentes necesarios
Hay algunos componentes clave necesarios para representar información de ubicación diversa en la nube. Estos se encuentran "debajo" de una API: son simplemente recursos y formatos. Juntos, estos componentes proporcionan una base sólida para representar casi cualquier información geoespacial en la nube. Deben ser compatibles con las API; pueden servir como respuestas a solicitudes, como recursos JSON o formatos de transmisión. Pero también debería ser completamente posible almacenarlos simplemente en un almacén de objetos de almacenamiento en la nube (S3, GCP, etc.). A su vez, estos a menudo serán leídos por API más capaces para realizar operaciones interesantes, pero no es necesario.
El núcleo que veo es:
- Formato ráster principal: Un formato nativo de la nube sólido para manejar imágenes satelitales, DEM, productos de datos derivados principalmente de imágenes satelitales, etc.
- Formato raster multidimensional: Un formato de nube capaz de manejar cubos de datos masivos, como los resultados de pronósticos meteorológicos, temperatura a lo largo del tiempo y la elevación, modelado climático, etc. Este es el espacio tradicional de NetCDF / HDF.
- Formatos vectoriales básicos: Un formato de datos vectoriales equivalente a GeoTIFF optimizado para la nube sería ideal, pero los diversos requisitos de visualización rápida y análisis profundo sobre la marcha pueden no ser fácilmente combinables, por lo que podemos terminar con más de un formato aquí.
- Formato de nube de puntos: Un formato de nube que funciona como COG, pero permite la visualización en tiempo real y el análisis sobre la marcha de nubes de puntos.
- Metadatos de la colección y del conjunto de datos: El título, la descripción, la licencia, los límites espaciales y temporales, las palabras clave, etc. que permiten la búsqueda. En el caso de la base de datos geoespacial nativa de la nube, esto debería centrarse en ser "rastreable" y vincularse a formatos reales. Debería admitir diversos tipos de datos (datos vectoriales, datos raster, nubes de puntos, cubos de datos multidimensionales, video geolocalizado, representaciones en 3D, etc.) y debería ser lo suficientemente flexible para funcionar con cualquier tipo de datos. Debería estar fundamentalmente centrado en la geoespacialidad y no intentar describir de forma genérica ningún dato.
- Metadatos de gránulo/nivel de escena/'activo': Un objeto de metadatos flexible con campos comunes para describir dominios de captura de datos particulares y vincularse a los archivos de datos reales.
La mayoría de estos tienen al menos el comienzo de una respuesta en nuestra comunidad geoespacial mundial, si no una solución sólida:
- Formato ráster básico: Hoy en día esto es GeoTIFF optimizado para la nube (COG). Está en proceso de convertirse en un estándar oficial de OGC y ya ha tenido una adopción increíble en una amplia variedad de lugares. Es realmente el formato geográfico nativo de la nube fundacional que ha demostrado lo que es posible. Vale la pena señalar que puede que no sea el fin de todos los formatos ráster de la nube, ya que se podría ver un formato de imagen más optimizado que sea más pequeño y más rápido. Pero probablemente sería un formato de imagen más general al que nuestra comunidad le agregue "geo" como lo hicimos con TIFF. Los COG dominarán por un tiempo, ya que la compatibilidad con las herramientas heredadas es difícil de superar mientras aún estamos al principio de la transición a la infraestructura geoespacial que prioriza la nube.
- Formato raster multidimensional: También hay una gran respuesta aquí con Zarcero. esta en proceso de siendo adoptado como un Estándar Comunitario OGC, y la votación de adopción comenzará pronto. También se está Adoptado por NetCDF, y ha tenido una aceptación significativa en la comunidad climática.
- Formatos vectoriales básicos: Aún no hay una respuesta clara. Analizaré el panorama y las distintas posibilidades en una próxima entrada del blog.
- Formato de nube de puntos: Lo nuevo de Howard Butler Formato COPC es una 'especificación LASzip comprimida, organizada y legible por rango' que tiene los mismos aspectos que GeoTIFF optimizado para la nube y probablemente será adoptada rápidamente.
- Metadatos de la colección y del conjunto de datos: tiene un núcleo sólido con la construcción 'Colección' de características de la API de OGC. Colección STAC Luego, amplía eso y la API OGC – Record proporciona un equivalente GeoJSON que se puede usar como retorno en las consultas de búsqueda. Pero estas partes no se han conectado todas de manera coherente y el uso "estático" completo (solo subir a S3) no se ha desarrollado por completo. Este fue el foco principal de mi trabajo en los últimos meses, por lo que profundizaré más a continuación.
- Metadatos de gránulo/nivel de escena/'activo': es donde el Catálogo de activos espacio-temporales (STAC) La especificación que ha sido mi principal foco en los últimos años ha tenido muy buena aceptación, y ha alcanzado recientemente la versión 1.0.0.
¿Qué pasa con los Tiles?
Para mí, aún no está claro si una especificación de teselas web realmente pertenece a una base geoespacial nativa de la nube. Creo que para teselas ráster (png, jpeg, etc.) no tienen sentido, ya que un GeoTIFF optimizado para la nube se puede transformar fácilmente sobre la marcha en teselas web, utilizando teseladores sin servidor como Titiler . Por lo tanto, la tendencia es usar un buen formato nativo de la nube que permita la representación y el procesamiento sobre la marcha en el formato que los clientes necesitan. Las teselas son esenciales para los clientes basados en navegador, pero otras herramientas se benefician más al acceder a los datos directamente. Una vez que se finalice el estándar OGC API – Tiles, probablemente tenga sentido crear un "bloque de construcción de metadatos de teselas" que pueda servir como un formato nativo de la nube para dirigir a los clientes a las teselas.
Para teselas vectoriales, considero que tanto MVT como PBF son formatos geoespaciales nativos de la nube, ya que pueden almacenarse en un bucket de almacenamiento en la nube y ser utilizados por diversas aplicaciones. Sin embargo, creo que existe potencial para un buen formato vectorial nativo de la nube que funcione como COG, con un servidor de teselas sin servidor que pueda renderizar teselas vectoriales sobre la marcha. Exploraré esta idea con más detalle en una futura publicación sobre formatos vectoriales.
¿Cómo encajan las API de OGC?
La iniciativa OGC API supone una reinvención de la base OGC W*S, transformándola en API JSON/REST más modernas. En general, se sitúa un nivel por encima de las estructuras geoespaciales nativas de la nube que se analizan aquí, definiendo interfaces API para servicios que utilizarían formatos nativos de la nube (aunque también podrían usar formatos más tradicionales y bases de datos espaciales). Estas API permiten muchas más funcionalidades, como la búsqueda dinámica o el procesamiento de datos en tiempo real, pero también requieren más recursos. La mayoría de las estructuras de metadatos nativas de la nube se han extraído de las API, por lo que las variantes nativas de la nube deberían ser compatibles con las API de OGC, aunque con capacidades mucho menores (si bien también son mucho más fáciles de implementar).
Un ecosistema ideal tendría la mayoría de los datos almacenados en formatos geoespaciales nativos de la nube y, además, una amplia gama de servicios, la mayoría de los cuales implementarían interfaces API de OGC. En el futuro, se espera que sea trivial instalar un servidor o incluso una función sin servidor que proporcione consultas API de OGC más completas sobre los metadatos y formatos nativos de la nube.
Hacia metadatos de recopilación geoespacial nativos de la nube
Como se mencionó anteriormente, la mayor parte de mi tiempo como investigador visitante de OGC durante los últimos meses se ha dedicado a organizar una "colección geoespacial nativa de la nube". Esto tiene varios aspectos diferentes.
Una colección estática de OGC
Una de las construcciones más poderosas que ha surgido en la evolución de STAC es el «STAC estático». Consulte la publicación «Catálogos de activos espaciotemporales estáticos en profundidad» para obtener un excelente resumen de qué son y cómo funcionan. Para citar las « mejores prácticas » de la versión 1.0.0 de la especificación:
Un catálogo estático es una implementación de la especificación STAC que no responde dinámicamente a las solicitudes. Se trata simplemente de un conjunto de archivos en un servidor web que se enlazan entre sí de forma que puedan ser indexados, y que suelen almacenarse en un servicio de almacenamiento en la nube como Amazon S3 , Azure Storage y Google Cloud Storage . Un catálogo estático solo puede ser indexado por motores de búsqueda y catálogos activos; no puede responder a consultas. Sin embargo, es increíblemente fiable, ya que no tiene componentes móviles, ni clústeres ni bases de datos que mantener.
Ha demostrado ser una forma muy popular de publicar datos STAC, haciendo realidad la visión de mi publicación de blog anterior de poder cargar datos a la nube y hacer que "simplemente funcionen".
Si bien STAC fue pionero en ofrecer opciones estáticas claras tanto para elementos individuales de imágenes como para otros recursos espaciotemporales, así como para colecciones de este tipo de datos, faltaba una "colección estática" equivalente para datos vectoriales. La API OGC – Feature Collection (que STAC amplía para su Collection ), tal como se especifica, es solo una parte de la respuesta de la API, no un recurso JSON independiente que pueda usarse por separado. Sin embargo, era una parte modular bien diseñada, y Clemens Portele y Peter Vretanos, los editores de la especificación Features, siempre apoyaron su extracción.
Hice una intento rudo en un repositorio de Github experimental. Pero luego Clemens se le ocurrió otra idea que habíamos estado considerando: crear bloques de construcción granulares pequeños y verdaderos a partir de la línea base de la API de OGC (intentaré hacer una publicación completa sobre eso en el futuro). Esto dio como resultado un 'Colección', extraído de OGC API – Features, pero escrito como un recurso JSON independiente que podría reutilizarse en cualquier contexto. Y así tenemos una verdadera "Colección OGC estática", capaz de vivir estáticamente en el almacenamiento en la nube. Esto puede apuntar a un GeoJSON, GeoPackage, Shapefile o cualquier formato nuevo más nativo de la nube. Puedes ver un ejemplo De esto hay un repositorio que hice para experimentar con ejemplos de colecciones estáticas. Este tiene múltiples representaciones de los mismos datos en diferentes formatos, pero fácilmente podría tener solo una.
Registros + alineación STAC
Otra gran parte de mi tiempo la dediqué a un trabajo que no es una tarea directamente nativa de la nube: alinear completamente STAC con la API de OGC (Registros) . Muchos no estaban seguros de la relación exacta entre las dos especificaciones, aunque yo siempre tuve ideas claras (aunque no bien comunicadas). Así que los últimos meses me han permitido sincronizarme completamente con el equipo principal de Registros y llegar a un acuerdo sobre el camino a seguir. En resumen, la API de Registros tiene un papel importante que desempeñar en STAC, ya que habíamos pospuesto la " búsqueda a nivel de colección " porque queríamos alinearla completamente con Registros. Pero lo confuso es que una API de Registros también se puede usar para buscar elementos similares a STAC, y de hecho está diseñada para buscar casi cualquier cosa.
El momento clave fue darnos cuenta de que los autores de la especificación de Registros siempre habían tenido en mente un "Registro de Datos", que es precisamente lo que STAC necesita, algo más específico que un Registro general y flexible. La estructura de Colección de STAC se centra únicamente en lo que OGC considera "conjuntos de datos", pero no existía una especificación clara de dicha estructura en la API base de OGC. He iniciado una solicitud de extracción en el repositorio de Registros para añadirla y, posteriormente, propondré una "Colección de Datos" que extienda la Colección OGC principal con campos adicionales. Se espera que una Colección STAC, a su vez, se alinee con la estructura de Colección de Conjuntos de Datos. En el futuro, colaboraremos para crear un "Registro STAC" que alinee completamente un Elemento STAC con los requisitos de registro más generales.
Otro efecto positivo de esta sincronización ha sido la excelente refactorización de la especificación principal de la API de Registros, realizada por Peter Vretanos. La idea siempre ha sido que la API de Registros sea una API de Funcionalidades, pero con funcionalidades adicionales (como la ordenación y consultas más avanzadas) y un modelo de datos más controlado. La nueva versión lo deja mucho más claro, haciendo hincapié en las partes que difieren de las API principales de OGC, y debería facilitar enormemente la alineación con STAC.
Registros estáticos
Todo este trabajo sentó las bases para el siguiente componente geoespacial nativo de la nube: un catálogo rastreable compuesto por registros estáticos accesibles a través de la web. Peter publicó un ejemplo de catálogo rastreable (y tengo una solicitud de extracción que amplía el ejemplo con una "colección OGC estática" con datos vectoriales), que necesita un poco más de trabajo para alinearse con STAC, pero se ajusta a todos nuestros principios geoespaciales nativos de la nube. Así que ahora tenemos prácticamente todas las piezas necesarias para los metadatos correctos que necesitamos para una base geoespacial nativa de la nube. Los registros y las colecciones son básicamente dos instancias alternativas de los mismos modelos de datos principales: una es GeoJSON, lo que facilita la visualización de muchos de ellos juntos, y la otra coincide con la estructura de colección de la API OGC principal que se utiliza ampliamente. A corto plazo, la mejor práctica probablemente será usar ambos, pero con el tiempo probablemente habrá herramientas que traduzcan fácilmente de uno a otro, especialmente si logramos que los modelos de datos principales sean completamente compatibles.
Llevar todo junto
Así que estamos muy cerca de tener el conjunto completo de metadatos estáticos necesarios para manejar casi cualquier dato geoespacial nativo de la nube. La principal tarea que tenemos por delante es alinear por completo el trabajo en OGC API – Records and – Features para que sea compatible con STAC y describir mejor todos los campos de metadatos necesarios. Hay algunas cosas que son un poco diferentes en este momento, por lo que sería bueno simplificar un poco las cosas entre los dos enfoques.
Para mostrar cómo todo podría funcionar en conjunto, he creado un repositorio de ejemplos estáticos de ogc que demuestra cómo se pueden tener diversos conjuntos de datos y formatos disponibles desde una estructura completamente estática. Seguiré ampliándolo y mejorando los ejemplos, y completando los archivos README para explicar su funcionamiento. En el futuro, intentaré escribir una entrada de blog que profundice en los detalles.
En las próximas publicaciones, se analizará más a fondo el estado actual de los formatos geoespaciales nativos de la nube. Últimamente, he dedicado la mayor parte de mi tiempo a los datos vectoriales, ya que no hay una respuesta clara. Espero también dedicar más tiempo a destacar zarr y copc, ya que son dos grandes esfuerzos que encajan bien y realmente completan un ecosistema completo de formatos.
