Artículo aportado por Chris Holmes, investigador visitante de OGC –
En mi publicación anterior expuse La visión de la geoespacialidad nativa de la nube, pero con este artículo quiero entrar en detalles sobre lo que se necesita. Expondré las áreas clave en las que se necesitan estándares básicos y luego analizaré el estado actual de cada área. Van desde los que están bastante bien establecidos hasta los que son bastante especulativos, pero todos son eminentemente alcanzables. Y luego profundizaré en el área en la que terminé enfocándome más en estos ú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?
En mi opinión, aún no se ha decidido si una especificación de mosaicos web realmente pertenece a una verdadera línea base geoespacial nativa de la nube. Creo que para los mosaicos 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 mosaicos web, utilizando mosaicos sin servidor como Titular. Por lo tanto, el patrón es utilizar un buen formato nativo de la nube que permita la representación y el procesamiento sobre la marcha en la forma que los clientes necesitan. Los mosaicos son esenciales para los clientes basados en navegador, pero otras herramientas funcionan mejor accediendo a los datos directamente. Una vez que se finalice el estándar OGC API – Tiles, probablemente tenga sentido crear un "bloque de creación de metadatos de mosaico" que pueda servir como un formato nativo de la nube para indicar a los clientes los mosaicos.
Para los mosaicos vectoriales, consideraría ambos MVTs y PBFLos formatos vectoriales nativos de la nube son similares a los formatos geoespaciales nativos de la nube, ya que pueden permanecer en reposo en un depósito de almacenamiento en la nube y ser utilizados por varias aplicaciones. Pero creo que existe el potencial para que un buen formato vectorial nativo de la nube funcione como los COG, con un servidor de mosaicos sin servidor que pueda renderizar mosaicos vectoriales sobre la marcha. Exploraré esta idea con más profundidad en una próxima publicación sobre formatos vectoriales.
¿Cómo encajan las API de OGC?
El Iniciativa API de OGC es una reinvención de la línea base de OGC W*S en API JSON/REST más modernas. En general, se ubica un nivel "por encima" de las construcciones geoespaciales nativas de la nube que se analizan aquí, definiendo interfaces API para servicios que utilizarían los formatos nativos de la nube (pero que también podrían utilizar formatos más tradicionales y bases de datos espaciales). Permiten mucho más, como la búsqueda dinámica o el procesamiento de datos sobre la marcha, pero también requieren más. La mayoría de las construcciones 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, solo que mucho menos capaces (aunque también 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
Uno de los constructos más poderosos que ha surgido en la evolución de STAC es el "STAC estático". Ver el Catálogos de activos estáticos espaciotemporales en profundidad Publicación para obtener un excelente resumen de qué son y cómo funcionan. Para citar el 'y 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. Es simplemente un conjunto de archivos en un servidor web que se vinculan entre sí de manera que se puedan rastrear, a menudo almacenados en un servicio de almacenamiento en la nube como Amazon S3, Almacenamiento de Azure y Google Cloud Storage… Un catálogo estático sólo puede ser rastreado por motores de búsqueda y catálogos activos; no puede responder a consultas. Pero es increíblemente confiable, ya que no hay partes 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".
Pero si bien STAC fue pionero en ofrecer opciones estáticas claras tanto para elementos individuales de imágenes y otros recursos espaciotemporales, como para colecciones de ese tipo de datos, faltaba una "colección estática" equivalente para datos vectoriales. La API de OGC: función Colección (que STAC extiende por su Colección) como se especifica es solo una parte de una respuesta de API, no un recurso JSON independiente que se pueda usar de forma independiente. Pero era una parte modular bien diseñada, y Clemens Portele y Peter Vretanos, los editores de la especificación de características, siempre apoyaron su incorporació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 se dedicó a un trabajo que no es una tarea nativa directa de la nube: alinear completamente STAC con API de OGC: registrosMuchos no estaban seguros de la relación exacta entre las dos especificaciones, aunque siempre tuve ideas claras (pero no bien comunicadas). Por eso, los últimos meses me han permitido sincronizarme completamente con el equipo central de Records y llegar a un acuerdo sobre el camino a seguir. La versión rápida es que Records API tiene un papel real que desempeñar en STAC, ya que hemos estado postergando 'búsqueda a nivel de colección', ya que queríamos alinearlo completamente con Records. Pero la parte confusa es que una API de Records también se puede usar para buscar elementos similares a STAC y, de hecho, está diseñada para buscar casi cualquier cosa.
Entonces, el momento revelador fue darme cuenta de que los autores de especificaciones de Registros siempre habían tenido en mente un "Registro de datos", que es realmente lo que STAC necesita, que es un poco más específico que un Registro totalmente general y flexible. La construcción de Colección de STAC realmente solo se centra en lo que OGC considera "conjuntos de datos", es solo que no ha habido una especificación clara de esa construcción en la línea base de API de OGC emergente. He comenzado una solicitud de extracción en los registros repo para agregarlo y luego también propondrá una 'Recopilación de datos' que amplíe la recopilación principal de OGC con campos adicionales. A su vez, se espera que una recopilación STAC se alinee con esa construcción de recopilación de conjuntos de datos. Y en el futuro trabajaremos juntos para tener un 'Registro STAC' que alinee completamente un elemento STAC con los requisitos de registro más generales.
El otro efecto interesante de esta sincronización ha sido un Muy buena refactorización de la especificación básica de la API de registros de Peter Vretanos. La visión siempre ha sido que la API de registros es una API de características, pero con algunas funciones adicionales (es decir, ordenación y consultas más completas) y un modelo de datos más controlado. La nueva versión lo deja mucho más claro, enfatizando las partes que son diferentes de las API básicas de OGC, y debería ser mucho más fácil alinearla con STAC.
Registros estáticos
Todo este trabajo sentó las bases para el próximo componente geoespacial nativo de la nube: un catálogo rastreable que consta de registros estáticos accesibles desde la Web. Peter publicó un Ejemplo de catálogo rastreable (y tengo una Relaciones públicas que se expanden 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 adapta a todos nuestros principios geoespaciales nativos de la nube. Por lo tanto, ahora tenemos prácticamente todas las piezas necesarias para todos los metadatos correctos que necesitamos para una línea base geoespacial nativa de la nube. Los registros y las colecciones son básicamente dos instancias alternativas de los mismos modelos de datos centrales, uno es GeoJSON, lo que facilita la visualización de muchos de ellos juntos, y el otro coincide con la construcción central de la colección de API de OGC que se usa ampliamente. A corto plazo, la mejor práctica probablemente será hacer uso de ambos, pero con el tiempo probablemente habrá herramientas que se traduzcan fácilmente de uno a otro, especialmente si logramos que los modelos de datos centrales 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 ayudar a mostrar cómo todo podría funcionar en conjunto, he colocado un 'Ejemplos de ogc estáticos' repositorio para demostrar cómo se puede disponer de una serie de conjuntos de datos y formatos diversos, todos ellos disponibles desde una estructura completamente estática. Seguiré ampliándolo y desarrollando los ejemplos, y ampliaré los archivos README para mostrar lo que está sucediendo. Y en el futuro intentaré hacer una publicación en el 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.