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 ellas. Radiant Earth , responsable de STAC, publicó recientemente un artículo en Medium explicando con precisión cómo funcionan ambas especificaciones en conjunto. Queríamos reiterar lo que dice y ofrecer 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 'Imagen a Diseño' 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 la especificación de la API de STAC sea simplemente un conjunto de bloques de construcción de la API de OGC relevantes para los casos de uso de STAC, con las especificaciones principales de STAC proporcionando el contenido para ser utilizado con cualquier componente relevante de la API de OGC . Alcanzar esa visión requiere mucho trabajo en las API principales de OGC , por lo que nuestro plan es continuar evolucionando y alineando las API de OGC con STAC, al tiempo que seguimos nuestros procesos para integrar la comunidad de STAC con nuestro proceso de estandarización de 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á preparada para asumir el mantenimiento de STAC como un estándar OGC completo una vez que la comunidad de usuarios esté lista para ello. Esto probablemente ocurrirá cuando STAC y las API principales de OGC alcancen la madurez y solo requieran mantenimiento incremental. Radiant Earth también ha coincidido en que este es el mejor camino: consolidar el mantenimiento del estándar en una sola organización. Radiant Earth continuará centrándose en los casos de uso y las herramientas relacionadas con STAC, ya que su objetivo siempre ha sido impulsar el estándar y contribuir a la interoperabilidad.
Si aún tiene alguna pregunta sobre la relación entre los estándares, no dude en consultarnos . Le invitamos a unirse a nosotros para dar forma a un futuro geoespacial abierto e interoperable.
