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.
Mais, à mesure que les deux spécifications mûrissent et sont de plus en plus adoptées, nous avons reçu de plus en plus de questions sur la relation entre les deux spécifications. Terre radieuse, le gérant du STAC, vient de mettre sur pied un poste moyen expliquant exactement comment les deux spécifications fonctionnent ensemble. Nous voulions réitérer ce qu'il dit et fournir le point de vue de l'OGC. Le principal point à retenir est le suivant :
« 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.
La vision à long terme est celle de Spécification de l'API STAC être simplement un paquet de API de l'OGC blocs de construction pertinents pour les cas d'utilisation STAC, avec Spécifications du noyau STAC fournir le contenu à utiliser avec tout élément pertinent API de l'OGC composant. Pour parvenir à cette vision, il faut beaucoup de travail sur le noyau API OGC, notre plan est donc de continuer à évoluer et à s'aligner API OGC avec STAC, tout en suivant nos processus pour fusionner la communauté STAC avec notre processus de normes 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êt à prendre en charge la maintenance de STAC en tant que norme OGC complète une fois que la communauté des utilisateurs sera prête pour une telle maintenance. Cela se produira probablement lorsque STAC et le noyau API OGC Les solutions STAC sont matures et ne nécessitent qu'une maintenance incrémentielle. Radiant Earth a également convenu que c'était la meilleure voie à suivre : consolider la maintenance standard dans une seule organisation. Radiant Earth continuera de se concentrer sur les cas d'utilisation et les outils autour de STAC, car son objectif a toujours été d'incuber la norme et de jouer son rôle dans l'interopérabilité.
Si vous avez encore des questions sur les relations entre les normes, n'hésitez pas à demanderEt rejoignez-nous pour façonner un avenir géospatial ouvert et interopérable.
