Vor über drei Jahren arbeitete eine kleine Gruppe von OGC-Mitgliedern an der nächsten Version des ehrwürdigen Web Feature Service (WFS)-Standard war der Beginn der nächsten großen Entwicklung unserer Standards-Basislinie. Was seitdem als OGC-API Familie von Standards zielt darauf ab, die besten Praktiken des Webs auf Geodaten anwenden Gleichzeitig erfolgte auch eine Umstellung von monolithischen Diensten auf eine Reihe von „Baustein“-Komponenten, die jeder modernen API räumliche Fähigkeiten hinzufügen können, und zwar schon lange vor STAC.
Was wurde bekannt als OGC API – Features hieß ursprünglich WFS 3.0 und wurde ganz anders von den früheren Versionen des WFS. Das vielleicht Wichtigste war der Wechsel zu einem Modell der offenen Entwicklung, bei dem der gesamte Standard öffentlich auf GitHub entwickelt wurde. Etwa zur gleichen Zeit entwickelte eine Gruppe von Entwicklern aus 14 verschiedenen Organisationen versammelten sich in Boulder, Colorado um an der Interoperabilität von Satellitendaten-APIs zu arbeiten, was den Startschuss für Räumlich-zeitlicher Asset-Katalog (STAC) Spezifikationen. Von Anfang an gab es viele überlappende Ziele zwischen den beiden Gruppen, aber anstatt miteinander zu konkurrieren, nahmen beide die offene Zusammenarbeit an, die GitHub ermöglicht. Jeder, der genau hinschaut, hat also gesehen, dass STAC und OGC API – Features haben sich gemeinsam weiterentwickelt und laufend angepasst. zweite und fünfte STAC-Sprints wurden durchgeführt in Verbindung mit OGC API – Features Team.
Da beide Spezifikationen jedoch immer ausgereifter werden und zunehmend Verbreitung finden, erreichen uns vermehrt Fragen zum Verhältnis zwischen ihnen. Radiant Earth , der Betreiber von STAC, hat kürzlich einen Medium-Beitrag veröffentlicht, der die Funktionsweise der beiden Spezifikationen detailliert erläutert. Wir möchten die Kernaussage dieses Beitrags zusammenfassen und die Sichtweise der OGC darlegen. Die wichtigste Erkenntnis lautet:
„STAC API implementiert und erweitert den OGC API-Features-Standard und unser gemeinsames Ziel ist es, dass STAC API ein vollständiger OGC-Standard wird.“
Aus Sicht des OGC haben wir erkannt, dass STAC eine klare Rolle in unserer Entwicklung spielt. OGC-API Standards Baseline, um die Kernbausteine mit einer Vielzahl von Benutzeranforderungen zu verbinden, insbesondere in den Bereichen Fernerkundung und 'neuer Raum'-Gemeinschaften. OGC API – Features ermöglicht jede räumliche '-Funktion' in einer Web-API dargestellt werden, und alle räumlich-zeitlichen Assets sind Features, bei denen die Geometrie im Allgemeinen ein Fußabdruck der dargestellten Daten ist.
Die langfristige Vision ist, dass die STAC-API-Spezifikation lediglich ein Paket von OGC-API- Bausteinen darstellt, die für die STAC-Anwendungsfälle relevant sind. Die STAC-Kernspezifikationen liefern dabei die Inhalte, die mit jeder relevanten OGC-API- Komponente verwendet werden können. Um diese Vision zu verwirklichen, ist umfangreiche Arbeit an den OGC-Kern-APIs erforderlich. Daher planen wir, die OGC-APIs kontinuierlich weiterzuentwickeln und an STAC anzupassen, während wir gleichzeitig unsere Prozesse zur Integration der STAC-Community in unseren OGC-Standardisierungsprozess fortsetzen.
Der erste Schritt wird die Einbeziehung von STAC als Gemeinschaftsstandard, unser neuer, leichtgewichtiger Prozess, der die Zusammenarbeit mit Standardisierungsarbeiten erleichtert, die außerhalb des OGC beginnen. Wir werden den OGC-API Komponenten in enger Abstimmung mit STAC. OGC API – Aufzeichnungen hat kürzlich seinen Kurs leicht geändert, um sich besser an STAC anzupassen (siehe GitHub-Probleme #58 #62 #22 für weitere Details), während STAC arbeiten, zu ausrichten zu OGC API – Features Teile 3 (CQL) und 4 (Transaktionen) und ihre zukünftige ArbeitUnd die aktuelle STAC API Version 1.0.0-beta.1 Außerdem wurde der Stil der Konformitätsklassen von OGC übernommen, was ebenfalls eine einfachere Ausrichtung ermöglicht.
OGC ist bereit, die Wartung von STAC als vollständigen OGC-Standard zu übernehmen, sobald die Nutzergemeinschaft dafür bereit ist. Dies wird voraussichtlich der Fall sein, wenn STAC und die OGC-Kern-APIs ausgereift sind und nur noch inkrementelle Wartung benötigen. Radiant Earth stimmt dem zu: die Standardwartung in einer Organisation zu bündeln, ist ebenfalls der beste Weg. Radiant Earth wird sich weiterhin auf die Anwendungsfälle und Tools rund um STAC konzentrieren, da es stets das Ziel war, den Standard zu fördern und zur Interoperabilität beizutragen.
Sollten Sie noch Fragen zu den Zusammenhängen zwischen den Standards haben, zögern Sie nicht, diese zu stellen . Und wir laden Sie herzlich ein, mit uns gemeinsam die offene, interoperable Zukunft der Geodaten zu gestalten.
