Artikel verfasst von Chris Holmes, OGC Visiting Fellow -
In meinem vorherigen Beitrag habe ich dargelegt die Vision für Cloud-Native Geospatial, aber mit diesem Beitrag möchte ich ins Detail gehen, was benötigt wird. Ich werde die wichtigsten Bereiche darlegen, in denen grundlegende Standards benötigt werden, und dann den aktuellen Status jedes Bereichs untersuchen. Sie reichen von ziemlich gut etabliert bis ziemlich spekulativ, aber alle sind durchaus erreichbar. Und dann werde ich tief in den Bereich eintauchen, auf den ich mich in den letzten Monaten als OGC Visiting Fellow am meisten 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 klar, ob eine Web-Kacheln-Spezifikation wirklich zu einer echten Cloud-nativen Geodaten-Baseline gehört. Ich glaube, für Rasterkacheln (png, jpeg usw.) machen sie keinen Sinn, da ein Cloud-optimiertes GeoTIFF mithilfe von serverlosen Kacheln wie Titel. Das Muster besteht also darin, ein gutes Cloud-natives Format zu verwenden, das eine schnelle Darstellung und Verarbeitung in der von den Clients benötigten Form ermöglicht. Kacheln sind für browserbasierte Clients unerlässlich, aber andere Tools greifen besser direkt auf die Daten zu. Sobald der OGC API – Tiles-Standard fertiggestellt ist, wird es wahrscheinlich sinnvoll sein, einen „Kachel-Metadatenbaustein“ zu erstellen, der als Cloud-natives Format dienen kann, um Clients auf Kacheln zu verweisen.
Für Vektorkacheln würde ich beides in Betracht ziehen MVTs und PBFs sind Cloud-native Geodatenformate, da sie in einem Cloud-Speicher-Bucket gespeichert und von verschiedenen Anwendungen verwendet werden können. Ich denke jedoch, dass es Potenzial für ein gutes Cloud-natives Vektorformat gibt, das wie COGs funktioniert, mit einem serverlosen Kachelserver, der Vektorkacheln im Handumdrehen rendern kann. Ich werde diese Idee in einem zukünftigen Beitrag zu Vektorformaten ausführlicher untersuchen.
Wie passen OGC-APIs dazu?
Die OGC-API-Initiative ist eine Neuentwicklung der OGC W*S-Baseline in modernere JSON/REST-APIs. Generell liegt es eine Ebene über den hier besprochenen Cloud-nativen Geodatenkonstrukten und definiert API-Schnittstellen für Dienste, die die Cloud-nativen Formate verwenden würden (aber auch traditionellere Formate und räumliche Datenbanken verwenden könnten). Sie ermöglichen viel mehr, wie dynamische Suche oder die Verarbeitung von Daten im laufenden Betrieb, erfordern aber auch mehr. Die meisten Cloud-nativen Metadatenkonstrukte wurden aus den APIs extrahiert, daher sollten die Cloud-nativen Varianten mit den OGC-APIs kompatibel sein, nur viel weniger leistungsfähig (aber auch viel 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
Eines der leistungsfähigsten Konstrukte, das in der Entwicklung von STAC entstanden ist, ist das „statische STAC“. Siehe die Statische räumlich-zeitliche Asset-Kataloge im Detail Beitrag für eine großartige Zusammenfassung dessen, was sie sind und wie sie funktionieren. Um den 'Best Practices' der Version 1.0.0 der Spezifikation:
Ein statischer Katalog ist eine Implementierung der STAC-Spezifikation, die nicht dynamisch auf Anfragen reagiert. Es handelt sich einfach um eine Reihe von Dateien auf einem Webserver, die auf eine Weise miteinander verknüpft sind, die gecrawlt werden kann. Sie werden häufig in einem Cloud-Speicherdienst wie Amazon S3, Azure-Speicher mit einem Google Cloud Storage…Ein statischer Katalog kann eigentlich nur von Suchmaschinen und aktiven Katalogen gecrawlt werden; er kann nicht auf Anfragen reagieren. Aber er ist unglaublich zuverlässig, da es keine beweglichen Teile, keine Cluster oder Datenbanken gibt, die gepflegt 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.
Doch während STAC klare statische Optionen sowohl für einzelne Bildelemente und andere räumlich-zeitliche Assets als auch für Sammlungen dieser Art von Daten entwickelte, fehlte eine entsprechende „statische Sammlung“ für Vektordaten. Die OGC API – Feature Kollektion (das STAC erweitert für seine Kollektion) ist wie angegeben nur Teil einer API-Antwort und keine unabhängige JSON-Ressource, die unabhängig verwendet werden kann. Aber es war ein gut konzipierter modularer Teil, und Clemens Portele und Peter Vretanos, die Herausgeber der Features-Spezifikation, waren immer dafür, es herauszuziehen.
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 floss in Arbeiten, die keine direkte Cloud-native Aufgabe sind: die vollständige Ausrichtung von STAC mit OGC API – Aufzeichnungen. Viele waren sich über die genaue Beziehung zwischen den beiden Spezifikationen nicht sicher, obwohl ich immer klare (aber nicht gut kommunizierte) Gedanken hatte. Die letzten Monate haben es also ermöglicht, sich vollständig mit dem Kernteam von Records abzustimmen und eine Einigung über den weiteren Weg zu erzielen. Die Kurzfassung ist, dass Records API in STAC eine echte Rolle spielen wird, da wir uns mit „Suche auf Sammlungsebene', da wir dies vollständig mit Records abstimmen wollten. Der verwirrende Teil ist jedoch, dass eine Records-API auch zum Suchen nach STAC-ähnlichen Elementen verwendet werden kann und tatsächlich für die Suche nach fast allem konzipiert ist.
Der „Aha“-Moment war also, als ich erkannte, dass die Autoren der Records-Spezifikation immer einen „Datensatz“ im Sinn hatten, was genau das ist, was STAC braucht, und der etwas spezifischer ist als ein völlig allgemeiner, flexibler Datensatz. Die Collection-Konstruktion von STAC konzentriert sich eigentlich nur auf das, was OGC als „Datensätze“ betrachtet, es gibt nur keine klare Spezifikation dieser Konstruktion in der entstehenden OGC-API-Baseline. Ich habe begonnen, Pull Request in den Records repo, um es hinzuzufügen, und wird dann auch eine „Datensammlung“ vorschlagen, die die zentrale OGC-Sammlung um zusätzliche Felder erweitert. Eine STAC-Sammlung wiederum sollte hoffentlich mit dieser Dataset-Sammlungskonstruktion übereinstimmen. Und in Zukunft werden wir zusammenarbeiten, um einen „STAC-Datensatz“ zu haben, der ein STAC-Element vollständig mit den allgemeineren Datensatzanforderungen in Einklang bringt.
Der andere coole Effekt dieser Synchronisierung war ein wirklich schönes Refactoring der Kernspezifikation der Records API von Peter Vretanos. Die Vision war immer, dass die Records API eine Features API ist, aber mit einigen zusätzlichen Funktionen (z. B. Sortieren und umfangreichere Abfragen) und einem kontrollierteren Datenmodell. Die neue Version macht das viel deutlicher, indem sie die Teile hervorhebt, die sich von den Kern-OGC-APIs unterscheiden, und es sollte viel einfacher sein, sie mit STAC abzustimmen.
Statische Datensätze
Diese Arbeit legte den Grundstein für die nächste Cloud-native Geodatenkomponente, einen crawlbaren Katalog, der aus webzugänglichen statischen Datensätzen besteht! Peter hat eine Beispiel eines crawlbaren Katalogs (und ich habe eine PR, die expandiert das Beispiel mit einer „statischen OGC-Sammlung“ mit Vektordaten), die etwas mehr Arbeit erfordert, um sie mit STAC abzustimmen, aber zu all unseren Cloud-nativen Geodatenprinzipien passt. Wir haben jetzt also so ziemlich alle Teile, die wir für alle richtigen Metadaten brauchen, die wir für eine Cloud-native Geodaten-Basislinie brauchen. Datensätze und Sammlungen sind im Grunde zwei alternative Instanziierungen derselben Kerndatenmodelle, eine ist GeoJSON, wodurch es einfach ist, viele davon zusammen zu visualisieren, und die andere entspricht der Kernkonstruktion der OGC-API-Sammlung, die häufig verwendet wird. Kurzfristig wird es wahrscheinlich die beste Vorgehensweise sein, beide zu verwenden, aber mit der Zeit wird es wahrscheinlich Tools geben, die problemlos von einem in das andere übertragen werden können, insbesondere wenn wir die Kerndatenmodelle vollständig kompatibel machen.
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 zeigen, wie alles zusammen funktionieren könnte, habe ich ein 'statische OGC-Beispiele'-Repository, um zu demonstrieren, wie Sie eine Reihe unterschiedlicher Datensätze und Formate aus einer vollständig statischen Struktur heraus verfügbar machen können. Ich werde es weiter ausbauen und die Beispiele weiterentwickeln und die Readmes ausarbeiten, um zu zeigen, was passiert. Und in Zukunft werde ich versuchen, einen Blog-Beitrag zu verfassen, der tief in die Details geht.
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.
