Hace más de tres años, un pequeño grupo de miembros de OGC trabajaba en la próxima versión del venerable Web Feature Service El estándar (WFS) inició la siguiente evolución importante de nuestra línea de estándares. Lo que desde entonces se conoce como API de OGC La familia de normas tiene como objetivo Aplicar las mejores prácticas de la web a la geoespacialidad. al mismo tiempo que se pasa de servicios monolíticos a un conjunto de componentes de "bloques de construcción" que pueden agregar capacidades espaciales a cualquier API moderna, mucho antes de STAC.
Lo que se conoció como OGC API – Features Originalmente se llamaba WFS 3.0 y era bastante diferente de las versiones anteriores de WFS. Quizás lo más importante que hizo fue cambiar a un modelo de desarrollo abierto, con todo el estándar evolucionando en público, en GitHub. Casi al mismo tiempo, un grupo de desarrolladores de 14 organizaciones diferentes reunidos en Boulder, Colorado para trabajar en la interoperabilidad de las API de datos satelitales, lo que dio inicio a la Catálogo de activos temporales espaciales (STAC) especificaciones. Desde el principio hubo muchos objetivos superpuestos entre los dos grupos, pero en lugar de competir, ambos adoptaron la colaboración abierta que permite GitHub. Así que cualquiera que preste atención habrá visto que STAC y OGC API – Features han ido evolucionando juntos y alineándose continuamente. De hecho, second y fifth Los sprints STAC se realizaron en conjunto con OGC API – Features .
Pero, a medida que ambas especificaciones maduran y se adoptan más, hemos recibido cada vez más preguntas sobre la relación entre ambas. Tierra radiante, el administrador de STAC, acaba de armar un publicación mediana Explicando exactamente cómo funcionan juntas las dos especificaciones. Queríamos reiterar lo que dice y brindar la perspectiva de OGC. La conclusión principal es:
'STAC API implementa y extiende el estándar OGC API — Features, y nuestro objetivo compartido es que STAC API se convierta en un estándar OGC completo'
Desde la perspectiva de OGC, hemos identificado que STAC tiene un papel claro que desempeñar en nuestra evolución API de OGC línea base de estándares, para ayudar a unir los componentes básicos con una variedad de necesidades de los usuarios, especialmente en la teledetección y 'nuevo espacio' comunidades. OGC API – Features permite cualquier espacio 'característica' para ser representado en una API web, y todos los activos espacio-temporales son características, donde la geometría es generalmente una huella de los datos representados.
La visión a largo plazo es que Especificación de la API de STAC ser simplemente un manojo de API de OGC bloques de construcción que son relevantes para los casos de uso de STAC, con Especificaciones del núcleo STAC Proporcionar el contenido que se utilizará con cualquier contenido relevante. API de OGC componente. Llegar a esa visión requiere mucho trabajo en el núcleo API de OGC, por lo que nuestro plan es seguir evolucionando y alineándonos API de OGC con STAC, mientras seguimos nuestros procesos para fusionar la comunidad STAC con nuestro proceso de estándares OGC.
El primer paso será incorporar a STAC como Estándar comunitario, nuestro proceso más nuevo y liviano que facilita la colaboración con el trabajo de estándares que comienza fuera de OGC. Continuaremos desarrollando el API de OGC componentes en estrecha alineación con STAC. De hecho, API de OGC: registros Recientemente ha cambiado ligeramente su ruta para alinearse mejor con STAC (ver problemas de GitHub) #58 #62 #22 para más detalles), mientras que STAC es trabajando a alinear a OGC API – Features Partes 3 (CQL) y 4 (Transacciones), y sus trabajo futuro. Y la reciente API de STAC Versión 1.0.0-beta.1 También adoptó el estilo de clases de conformidad de OGC, lo que también permite una alineación más fácil.
OGC está listo para asumir el mantenimiento de STAC como un estándar OGC completo una vez que la comunidad de usuarios esté lista para dicho mantenimiento. Esto probablemente será cuando STAC y el núcleo API de OGC Son maduros y solo requieren un mantenimiento incremental. Radiant Earth ha acordado que este es también el mejor camino: consolidar el mantenimiento estándar en una organización. Radiant Earth seguirá centrándose en los casos de uso y las herramientas en torno a STAC, ya que su objetivo siempre fue incubar el estándar y desempeñar su papel en la habilitación de la interoperabilidad.
Si tiene alguna pregunta restante sobre las relaciones entre las normas, no dudes en preguntar. Y únase a nosotros para dar forma a un futuro geoespacial abierto e interoperable.
