Beitrag von Chris Holmes, OGC Visiting Fellow –
In meinem vorherigen Beitrag habe ich die Vision für Cloud-native Geodaten dargelegt . In diesem Beitrag möchte ich nun auf die notwendigen Details eingehen. Ich werde die wichtigsten Bereiche aufzeigen, in denen grundlegende Standards erforderlich sind, und anschließend den aktuellen Stand jedes Bereichs beleuchten. Dieser reicht von recht etabliert bis hin zu spekulativ, ist aber in allen Fällen durchaus realisierbar. Abschließend werde ich mich ausführlich mit dem Bereich befassen, auf den ich mich in den letzten Monaten als OGC Visiting Fellow am stärksten konzentriert habe.
Benötigte Komponenten
Es sind einige Schlüsselkomponenten erforderlich, um verschiedene Standortinformationen in der Cloud darzustellen. Diese befinden sich „unter“ einer API – es handelt sich lediglich um Ressourcen und Formate. Zusammen bilden diese Komponenten eine solide Grundlage für die Darstellung der meisten georäumlichen Informationen in der Cloud. Sie sollten mit APIs kompatibel sein; sie können als Antworten auf Anfragen, als JSON-Ressourcen oder als Streaming-Formate dienen. Es sollte aber auch völlig möglich sein, diese einfach in einem Cloud-Speicherobjektspeicher (S3, GCP usw.) zu speichern. Diese wiederum werden oft von leistungsfähigeren APIs gelesen, um coole Operationen durchzuführen, aber das müssen sie nicht.
Der Kern, den ich sehe, ist:
- Core Raster-Format: Ein solides Cloud-natives Format zur Verarbeitung von Satellitenbildern, DEMs, hauptsächlich aus Satellitenbildern abgeleiteten Datenprodukten usw.
- Mehrdimensionales Rasterformat: Ein Cloud-Format, das große Datenmengen verarbeiten kann, wie etwa die Ergebnisse von Wettervorhersagen, Temperaturverläufe im Zeitverlauf und in der Höhe, Klimamodellierung usw. Dies ist der traditionelle Bereich von NetCDF/HDF.
- Wichtige Vektorformate: Ideal wären Vektordaten, die Cloud Optimized GeoTIFF entsprechen, aber die unterschiedlichen Anforderungen an eine schnelle Anzeige und eine sofortige gründliche Analyse lassen sich möglicherweise nicht so einfach kombinieren, sodass wir am Ende möglicherweise mehr als ein Format haben.
- Punktwolkenformat: Ein Cloud-Format, das wie COG funktioniert, aber die Streaming-Anzeige und die sofortige Analyse von Punktwolken ermöglicht.
- Sammlungs- und Datensatzmetadaten: Titel, Beschreibung, Lizenz, räumliche und zeitliche Grenzen, Schlüsselwörter usw., die die Suche ermöglichen. Für die Cloud-native Geodaten-Grundlinie sollte der Schwerpunkt darauf liegen, „durchsuchbar“ zu sein und auf tatsächliche Formate zu verweisen. Sie sollte verschiedene Datentypen unterstützen – Vektordaten, Rasterdaten, Punktwolken, mehrdimensionale Datenwürfel, geolokalisierte Videos, 3D-Darstellungen usw. – und flexibel genug sein, um mit allen Daten zu arbeiten. Sie sollte grundsätzlich auf Geodaten ausgerichtet sein und nicht versuchen, alle Daten generisch zu beschreiben.
- Granule/Szenenebene/'Asset'-Metadaten: Ein flexibles Metadatenobjekt mit gemeinsamen Feldern zur Beschreibung bestimmter Datenerfassungsdomänen und zur Verknüpfung mit den eigentlichen Datendateien.
Für die meisten dieser Fragen gibt es in unserer weltweiten Geodaten-Community zumindest eine ansatzweise Antwort, wenn nicht sogar eine robuste Lösung:
- Core-Raster-Format: Heute ist dies Cloud-optimiertes GeoTIFF (COG). Es ist dabei, ein offizieller OGC-Standard zu werden und hat bereits an den verschiedensten Orten eine unglaubliche Akzeptanz erfahren. Es ist wirklich das grundlegende Cloud-native Geoformat, das bewiesen hat, was möglich ist. Es ist erwähnenswert, dass es möglicherweise nicht das Ende aller Cloud-Rasterformate ist, da man sich ein optimierteres Bildformat wünschen könnte, das kleiner und schneller ist. Aber es wäre wahrscheinlich ein allgemeineres Bildformat, dem unsere Community „Geo“ hinzufügt, wie wir es mit TIFF getan haben. COGs werden noch eine Weile dominieren, da die Abwärtskompatibilität mit älteren Tools kaum zu übertreffen ist, während wir uns noch in der frühen Phase des Übergangs zu einer Cloud-First-Geodateninfrastruktur befinden.
- Mehrdimensionales Rasterformat: Es gibt auch schon eine tolle Antwort hier mit zarr. Es ist dabei als OGC-Gemeinschaftsstandard übernommen, die Abstimmung über die Annahme beginnt bald. Außerdem wird von NetCDF übernommen, und hat in der Klima-Community erhebliche Resonanz erfahren.
- Wichtige Vektorformate: Darauf gibt es bisher noch keine gute Antwort. Ich werde die Situation und die verschiedenen Möglichkeiten in einem zukünftigen Blogbeitrag besprechen.
- Punktwolkenformat: Howard Butlers neuer COPC-Format ist eine „bereichslesbare, komprimierte, organisierte LASzip-Spezifikation“, die dieselben Merkmale aufweist wie Cloud-Optimized GeoTIFF und wahrscheinlich eine schnelle Akzeptanz erfahren wird.
- Sammlungs- und Datensatzmetadaten: hat einen soliden Kern mit dem OGC API – Features 'Collection' Konstrukt. Die STAC-Kollektion erweitert das dann, und die OGC API – Record bietet ein GeoJSON-Äquivalent, das als Rückgabe in Suchanfragen verwendet werden kann. Aber diese Teile sind noch nicht alle auf kohärente Weise miteinander verbunden, und die vollständige „statische“ Verwendung (nur Hochladen auf S3) wurde noch nicht vollständig ausgearbeitet. Dies war der Hauptschwerpunkt meiner Arbeit in den letzten Monaten, daher werde ich weiter unten tiefer darauf eingehen.
- Granule/Szenenebene/'Asset'-Metadaten: ist, wo die Räumlich-zeitlicher Asset-Katalog (STAC) Die Spezifikation, auf die ich mich in den letzten Jahren hauptsächlich konzentriert habe, hat eine große Rolle gespielt und erfreut sich seit dem kürzlichen Erreichen der Version 1.0.0 einer sehr großen Akzeptanz.
Was ist mit Fliesen?
Für mich ist noch nicht entschieden, ob eine Web-Tiles-Spezifikation wirklich zu einer echten Cloud-nativen Geodaten-Basis gehört. Für Rasterkacheln (PNG, JPEG usw.) halte ich sie für überflüssig, da sich ein Cloud-optimiertes GeoTIFF mithilfe serverloser Tiler wie Titiler problemlos in Web-Tiles umwandeln lässt . Daher empfiehlt sich ein geeignetes Cloud-natives Format, das die Echtzeit-Darstellung und -Verarbeitung in der von Clients benötigten Form ermöglicht. Tiles sind für browserbasierte Clients unerlässlich, andere Tools profitieren jedoch vom direkten Datenzugriff. Sobald der OGC API – Tiles-Standard finalisiert ist, dürfte es sinnvoll sein, einen „Tile-Metadaten-Baustein“ zu entwickeln, der als Cloud-natives Format dient, um Clients auf die entsprechenden Tiles zu verweisen.
Für Vektorkacheln würde ich sowohl MVT- als auch PBF- Dateien als Cloud-native Geodatenformate betrachten, da sie in einem Cloud-Speicher abgelegt und von verschiedenen Anwendungen genutzt werden können. Ich denke jedoch, dass ein gutes Cloud-natives Vektorformat, das ähnlich wie COGs funktioniert, Potenzial hat – mit einem serverlosen Kachelserver, der Vektorkacheln dynamisch rendern kann. Ich werde diese Idee in einem zukünftigen Beitrag über Vektorformate genauer beleuchten.
Wie passen OGC-APIs dazu?
Die OGC-API-Initiative ist eine Weiterentwicklung der OGC W*S-Basislinie hin zu moderneren JSON/REST-APIs. Sie ist im Allgemeinen eine Ebene höher angesiedelt als die hier beschriebenen Cloud-nativen Geodatenstrukturen und definiert API-Schnittstellen für Dienste, die Cloud-native Formate nutzen (aber auch traditionellere Formate und Geodatenbanken verwenden können). Sie ermöglichen deutlich mehr Funktionen, wie dynamische Suche oder die Echtzeitverarbeitung von Daten, erfordern aber auch mehr Ressourcen. Die meisten Cloud-nativen Metadatenstrukturen wurden aus den APIs extrahiert, sodass die Cloud-nativen Varianten mit den OGC-APIs kompatibel sein sollten, jedoch deutlich weniger leistungsfähig (aber auch wesentlich einfacher zu implementieren).
In einem idealen Ökosystem würden die meisten Daten in Cloud-nativen Geodatenformaten gespeichert und dann eine breite Palette von Diensten darauf aufbauen, von denen die meisten OGC-API-Schnittstellen implementieren. In Zukunft wird es hoffentlich trivial sein, einen Server oder sogar eine serverlose Funktion zu installieren, die die umfangreicheren OGC-API-Abfragen zusätzlich zu den Cloud-nativen Metadaten und Formaten bereitstellt.
Auf dem Weg zu Cloud-nativen Metadaten für die Geodatensammlung
Wie oben erwähnt, habe ich in den letzten Monaten den Großteil meiner Zeit als OGC Visiting Fellow damit verbracht, eine „Cloud-native Geodatensammlung“ zusammenzustellen. Dabei gibt es mehrere verschiedene Aspekte.
Eine statische OGC-Sammlung
Eine der leistungsstärksten Entwicklungen im Rahmen der STAC-Entwicklung ist der „statische STAC“. Eine hervorragende Zusammenfassung seiner Funktionsweise finden Sie im Beitrag „Static Spatiotemporal Asset Catalogs in Depth“. Um die „ Best Practices “ der Spezifikationsversion 1.0.0 zu zitieren:
Ein statischer Katalog ist eine Implementierung der STAC-Spezifikation, die nicht dynamisch auf Anfragen reagiert. Er besteht aus einer Reihe von Dateien auf einem Webserver, die so miteinander verknüpft sind, dass sie durchsucht werden können. Häufig werden sie in einem Cloud-Speicher wie Amazon S3 , Azure Storage oder Google Cloud Storage gespeichert . Ein statischer Katalog kann nur von Suchmaschinen und aktiven Katalogen durchsucht werden; er kann keine Anfragen beantworten. Dafür ist er äußerst zuverlässig, da keine beweglichen Teile, Cluster oder Datenbanken gewartet werden müssen.
Es hat sich als eine sehr beliebte Methode zum Veröffentlichen von STAC-Daten erwiesen und macht die Vision aus meinem vorherigen Blog-Beitrag wahr, Daten in die Cloud hochladen und dort „einfach funktionieren“ zu lassen.
Während STAC als Pionier klare statische Optionen sowohl für einzelne Bilddateien und andere raumzeitliche Daten als auch für Sammlungen solcher Daten entwickelte, fehlte eine entsprechende „statische Sammlung“ für Vektordaten. Die OGC-API – Feature Collection (die STAC für seine Collection erweitert ) ist in ihrer Spezifikation lediglich Teil einer API-Antwort und keine eigenständige JSON-Ressource, die unabhängig verwendet werden kann. Sie war jedoch ein gut konzipierter, modularer Bestandteil, und Clemens Portele und Peter Vretanos, die Herausgeber der Features-Spezifikation, befürworteten stets deren Herausarbeitung.
Ich machte eine grober Versuch in einem experimentellen GitHub-Repository. Aber dann kam Clemens mit einer anderen Idee, die wir schon lange im Kopf hatten, nämlich wirklich kleine granulare Bausteine aus der OGC-API-Baseline zu erstellen (ich werde versuchen, in Zukunft einen ausführlichen Beitrag dazu zu schreiben). Das Ergebnis war ein sehr sauberes „Kollektion', extrahiert aus OGC API – Features, aber als unabhängige JSON-Ressource geschrieben, die in jedem Kontext wiederverwendet werden kann. Und so haben wir eine echte „statische OGC-Sammlung“, die statisch im Cloud-Speicher leben kann. Dies kann auf ein GeoJSON verweisen, GeoPackage, Shapefile oder jedes neue, cloudnative Format. Sie können sehen ein Beispiel davon in einem Repository, das ich erstellt habe, um mit Beispielen statischer Sammlungen zu experimentieren. Dieses hat mehrere Darstellungen derselben Daten in unterschiedlichen Formaten, aber es könnte auch einfach nur eine haben.
Datensätze + STAC-Ausrichtung
Ein weiterer großer Teil meiner Zeit ging für Aufgaben drauf, die nicht direkt mit Cloud-nativen Technologien zusammenhängen: die vollständige Angleichung von STAC an die OGC-API – Records . Viele waren sich über die genaue Beziehung zwischen den beiden Spezifikationen unsicher, obwohl ich immer klare (wenn auch nicht gut kommunizierte) Vorstellungen dazu hatte. Die letzten Monate haben mir daher die Möglichkeit gegeben, mich vollständig mit dem Kernteam von Records abzustimmen und eine Einigung über das weitere Vorgehen zu erzielen. Kurz gesagt: Die Records API spielt eine wichtige Rolle in STAC, da wir die Suche auf Sammlungsebene bisher zurückgestellt haben , weil wir diese vollständig mit Records abstimmen wollten. Verwirrend ist jedoch, dass eine Records API auch zur Suche nach STAC-ähnlichen Elementen verwendet werden kann und tatsächlich für die Suche nach nahezu allem konzipiert ist.
Der entscheidende Moment war die Erkenntnis, dass die Autoren der Records-Spezifikation von Anfang an einen „Datensatz“ im Sinn hatten, genau das, was STAC benötigt – etwas spezifischer als ein völlig allgemeiner, flexibler Datensatz. Das Collection-Konstrukt von STAC konzentriert sich im Grunde nur auf das, was OGC als „Datensätze“ definiert. Allerdings gab es in der entstehenden OGC-API-Baseline noch keine klare Spezifikation dieses Konstrukts. Ich habe einen Pull Request im Records- Repository erstellt, um dies hinzuzufügen, und werde anschließend auch eine „Datensammlung“ vorschlagen, die die OGC-Kernsammlung um zusätzliche Felder erweitert. Eine STAC-Sammlung sollte dann idealerweise mit diesem Datensatz-Sammlungskonstrukt übereinstimmen. Zukünftig werden wir gemeinsam an einem „STAC-Datensatz“ arbeiten, der ein STAC-Element vollständig mit den allgemeineren Datensatzanforderungen in Einklang bringt.
Ein weiterer positiver Effekt dieser Synchronisierung war die gelungene Überarbeitung der Kernspezifikation der Records API durch Peter Vretanos. Die Vision war stets, dass die Records API eine Features-API ist, jedoch mit zusätzlichen Funktionen (z. B. Sortierung und erweiterte Abfragemöglichkeiten) und einem kontrollierteren Datenmodell. Die neue Version verdeutlicht dies deutlich, indem sie die Unterschiede zu den Kern-OGC-APIs hervorhebt und die Angleichung an STAC wesentlich erleichtert.
Statische Datensätze
Diese Arbeit legte den Grundstein für die nächste Cloud-native Geodatenkomponente: einen durchsuchbaren Katalog mit webzugänglichen statischen Datensätzen! Peter hat einen Beispielkatalog erstellt (und ich habe einen Pull Request, der das Beispiel um eine „statische OGC-Sammlung“ mit Vektordaten erweitert). Dieser Katalog muss noch etwas an STAC angepasst werden, entspricht aber all unseren Cloud-nativen Geodatenprinzipien. Damit haben wir nun so gut wie alle Bausteine für die benötigten Metadaten einer Cloud-nativen Geodatenbasis. Datensätze und Sammlungen sind im Grunde zwei alternative Instanziierungen desselben Kerndatenmodells: GeoJSON, wodurch sich viele Datensätze einfach zusammen visualisieren lassen, und die Sammlung entspricht dem weit verbreiteten OGC-API-Konstrukt „Collection“. Kurzfristig empfiehlt es sich, beide zu verwenden. Langfristig werden jedoch Tools verfügbar sein, die eine einfache Konvertierung ermöglichen, insbesondere wenn die Kerndatenmodelle vollständig kompatibel sind.
Bringing sie alle zusammen
Wir sind also verlockend nah an der vollständigen Suite statischer Metadaten, die für die Verarbeitung der meisten Cloud-nativen Geodaten erforderlich sind. Die wichtigste Aufgabe besteht darin, die Arbeit in OGC API – Records und – Features vollständig anzupassen, um sie mit STAC kompatibel zu machen und alle erforderlichen Metadatenfelder besser zu beschreiben. In einigen Punkten ist dies derzeit etwas anders, daher wäre es schön, die Dinge zwischen den beiden Ansätzen ein wenig zu vereinfachen.
Um zu veranschaulichen, wie alles zusammenwirkt, habe ich ein Repository mit statischen OGC-Beispielen erstellt . Darin zeige ich, wie man verschiedene Datensätze und Formate in einer vollständig statischen Struktur bereitstellen kann. Ich werde das Repository kontinuierlich erweitern, die Beispiele verbessern und die Readme-Dateien detaillierter beschreiben. Zukünftig plane ich außerdem einen ausführlichen Blogbeitrag.
Zukünftige Beiträge werden tiefer auf den Stand aktueller Cloud-nativer Geodatenformate eingehen. In letzter Zeit habe ich die meiste Zeit mit Vektordaten verbracht, da es keine ganz klare Antwort gibt. Ich hoffe, dass ich auch mehr Zeit darauf verwenden kann, Zarr und Copc hervorzuheben, da dies zwei wirklich großartige Ansätze sind, die gut zusammenpassen und ein komplettes Ökosystem von Formaten abrunden.
