Il y a plus de trois ans, un petit groupe de membres de l'OGC travaillant sur la prochaine version du vénérable Web Feature Service (WFS) a marqué le début de la prochaine évolution majeure de notre référentiel de normes. Ce qui est depuis devenu connu sous le nom de API de l'OGC La famille de normes vise à appliquer les meilleures pratiques du Web à la géospatiale tout en passant de services monolithiques à un ensemble de composants « de base » qui peuvent ajouter des capacités spatiales à toute API moderne, bien avant STAC.
Ce qui est devenu connu sous le nom de OGC API – Features s'appelait à l'origine WFS 3.0, et c'était assez différent des versions antérieures de WFS. La chose la plus importante qu'il a fait a peut-être été de passer à un modèle de développement ouvert, avec l'ensemble de la norme évoluant dans le public, sur GitHub. À peu près au même moment, un groupe de développeurs de 14 organisations différentes réunis à Boulder, Colorado travailler sur l'interopérabilité des API de données satellitaires, ce qui a donné le coup d'envoi Catalogue d'actifs temporels et spatiaux (STAC) spécifications. Dès le début, les objectifs des deux groupes se chevauchaient, mais au lieu de se faire concurrence, ils ont tous deux adopté la collaboration ouverte permise par GitHub. Ainsi, quiconque y prête une attention particulière a vu que STAC et OGC API – Features ont évolué ensemble et se sont continuellement alignés. En effet, seconde et cinquième Les sprints STAC ont été réalisés en collaboration avec OGC API – Features Équipe.
Cependant, à mesure que ces deux spécifications gagnent en maturité et sont de plus en plus adoptées, nous recevons de plus en plus de questions concernant leur relation. Radiant Earth , responsable de la spécification STAC, vient de publier un article sur Medium expliquant précisément comment elles interagissent. Nous souhaitions réitérer les informations présentées et apporter le point de vue de l'OGC. En résumé :
« L'API STAC implémente et étend la norme OGC API — Features, et notre objectif commun est que l'API STAC devienne une norme OGC complète »
Du point de vue de l'OGC, nous avons identifié que le STAC a un rôle clair à jouer dans notre évolution API de l'OGC normes de base, pour aider à relier les éléments de base à une variété de besoins des utilisateurs, en particulier dans la télédétection et «nouvel espace' communautés. OGC API – Features permet à tout espace 'caractéristique« à représenter dans une API Web, et tous les actifs spatio-temporels sont des entités, où la géométrie est généralement une empreinte des données représentées.
À long terme, notre vision est que la spécification de l'API STAC devienne un simple ensemble de composants d'API OGC pertinents pour les cas d'utilisation de STAC, les spécifications STAC Core fournissant le contenu à utiliser avec tout composant d'API OGC pertinent . La réalisation de cette vision nécessite un travail important sur les API OGC de base ; nous prévoyons donc de poursuivre leur évolution et leur alignement avec STAC, tout en suivant nos processus d'intégration de la communauté STAC à notre processus de normalisation OGC.
La première étape consistera à intégrer le STAC en tant que Norme communautaire, notre nouveau processus léger qui facilite la collaboration avec les travaux de normalisation qui commencent en dehors de l'OGC. Nous continuerons à faire évoluer le API de l'OGC composants en étroite collaboration avec STAC. En effet, API OGC – Enregistrements a récemment légèrement modifié son chemin pour mieux s'aligner sur STAC (voir les problèmes GitHub #58 #62 #22 pour plus de détails), tandis que STAC est de travail à aligner à OGC API – Features Parties 3 (CQL) et 4 (Transactions) et leurs travail futur. Et la récente API STAC Version 1.0.0-beta.1 a également adopté le style de classes de conformité de l'OGC, ce qui permet également un alignement plus facile.
L'OGC est prête à prendre en charge la maintenance de STAC en tant que norme OGC à part entière dès que la communauté des utilisateurs sera prête à assumer cette responsabilité. Cela se produira probablement lorsque STAC et les API OGC principales seront matures et ne nécessiteront plus qu'une maintenance incrémentale. Radiant Earth partage cet avis : centraliser la maintenance de la norme au sein d'une seule organisation. Radiant Earth continuera de se concentrer sur les cas d'utilisation et les outils liés à STAC, son objectif ayant toujours été de favoriser l'émergence de la norme et de contribuer à son interopérabilité.
Si vous avez encore des questions concernant les liens entre les normes, n'hésitez pas à les poser . Et rejoignez-nous pour façonner l'avenir géospatial ouvert et interopérable.
