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 mit einem fünfte STAC-Sprints wurden durchgeführt in Verbindung mit OGC API – Features Team.
Doch mit der Weiterentwicklung und zunehmenden Akzeptanz beider Spezifikationen erhalten wir immer mehr Fragen zur Beziehung zwischen den beiden Spezifikationen. Strahlende Erde, der Verwalter des STAC, hat gerade eine mittlerer Beitrag erklärt genau, wie die beiden Spezifikationen zusammenarbeiten. Wir wollten wiederholen, was dort steht, und die Perspektive von OGC darlegen. Die wichtigste Erkenntnis ist:
„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 die STAC API-Spezifikation einfach ein Bündel von OGC-API Bausteine, die für die STAC-Anwendungsfälle relevant sind, mit STAC Core-Spezifikationen Bereitstellung der zu verwendenden Inhalte mit allen relevanten OGC-API Komponente. Um diese Vision zu erreichen, ist viel Arbeit am Kern erforderlich OGC-APIs, daher ist unser Plan, uns weiterzuentwickeln und anzupassen OGC-APIs mit STAC, während Sie unsere Prozesse befolgen, um die STAC-Community mit unserem OGC-Standardisierungsprozess zu verschmelzen.
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 Benutzergemeinschaft für eine solche Wartung bereit ist. Dies wird wahrscheinlich der Fall sein, wenn STAC und der Kern OGC-APIs sind ausgereift und erfordern nur schrittweise Wartung. Radiant Earth ist sich einig, dass dies auch der beste Weg ist: die Standardwartung in einer Organisation zu konsolidieren. Radiant Earth wird sich weiterhin auf die Anwendungsfälle und Tools rund um STAC konzentrieren, da ihr Ziel immer darin bestand, den Standard zu entwickeln und ihre Rolle bei der Ermöglichung der Interoperabilität zu spielen.
Sollten Sie noch Fragen zu den Zusammenhängen der Normen haben, Zögern Sie nicht zu fragen. Und gestalten Sie mit uns die offene, interoperable georäumliche Zukunft.
