Artikel aangeleverd door Chris Holmes, gastonderzoeker bij OGC –
In mijn vorige bericht heb ik de visie voor cloud-native georuimtelijke toepassingen uiteengezet , maar in dit bericht wil ik dieper ingaan op wat er nodig is. Ik zal de belangrijkste gebieden schetsen waar fundamentele standaarden nodig zijn en vervolgens de huidige status van elk gebied bespreken. Deze variëren van redelijk goed ingeburgerd tot nogal speculatief, maar ze zijn allemaal zeer goed haalbaar. Daarna zal ik dieper ingaan op het gebied waar ik me de afgelopen maanden als gastonderzoeker bij OGC het meest op heb gericht.
Benodigde componenten
Er zijn een paar belangrijke componenten nodig om diverse locatie-informatie in de cloud weer te geven. Deze zitten 'onder' een API – het zijn gewoon bronnen en formaten. Samen vormen deze componenten een solide basis om de meeste georuimtelijke informatie in de cloud weer te geven. Ze moeten compatibel zijn met API's; ze kunnen dienen als antwoorden op verzoeken, als JSON-bronnen of streamingformaten. Maar het zou ook volledig mogelijk moeten zijn om deze gewoon op te slaan in een cloudopslagobjectstore (S3, GCP, etc.). Die worden op hun beurt vaak gelezen door capabelere API's om coole bewerkingen uit te voeren, maar dat hoeft niet.
De kern die ik zie is:
- Kernrasterformaat: Een solide cloud-native formaat voor het verwerken van satellietbeelden, DEM's, dataproducten die voornamelijk zijn afgeleid van satellietbeelden, etc.
- Multidimensionaal rasterformaat: Een cloudformaat dat grote hoeveelheden data kan verwerken, zoals de resultaten van weersvoorspellingen, temperatuur over tijd en hoogte, klimaatmodellering, etc. Dit is de traditionele ruimte van NetCDF/HDF.
- Belangrijkste vectorformaten: Vectorgegevens die gelijkwaardig zijn aan Cloud Optimized GeoTIFF zouden ideaal zijn, maar de uiteenlopende vereisten van snelle weergave en directe, diepgaande analyse zijn mogelijk niet eenvoudig te combineren. Hierdoor kunnen we hier met meer dan één formaat eindigen.
- Puntenwolkformaat: Een cloudformaat dat werkt als COG, maar streamingweergave en directe analyse van puntenwolken mogelijk maakt.
- Collectie- en datasetmetadata: De titel, beschrijving, licentie, ruimtelijke en temporele grenzen, trefwoorden, etc. die zoeken mogelijk maken. Voor de cloud-native georuimtelijke basislijn moet dit gericht zijn op 'crawlbaar' zijn en linken naar daadwerkelijke formaten. Het moet diverse gegevenstypen ondersteunen - vectorgegevens, rastergegevens, puntenwolken, multidimensionale datakubussen, geo-gelokaliseerde video, 3D-weergaven, etc. - en moet flexibel genoeg zijn om met alle gegevens te werken. Het moet fundamenteel georuimtelijk gericht zijn en niet proberen om alle gegevens generiek te beschrijven.
- Granule / Scène niveau / 'asset' Metadata: Een flexibel metadata-object met algemene velden voor het beschrijven van specifieke gegevensvastleggingsdomeinen en het koppelen aan de daadwerkelijke gegevensbestanden.
De meeste hiervan hebben in ieder geval een begin van een antwoord in onze wereldwijde georuimtelijke gemeenschap, of zelfs een robuuste oplossing:
- Kernrasterformaat: Vandaag is dit Cloud-geoptimaliseerde GeoTIFF (COG). Het is bezig om een officiële OGC-standaard te worden en is al op een groot aantal plekken enorm populair geworden. Het is echt het fundamentele cloud-native geo-formaat dat heeft bewezen wat mogelijk is. Het is het vermelden waard dat het misschien niet het einde is voor cloudrasterformaten, omdat er een meer geoptimaliseerde afbeeldingsindeling zou kunnen zijn die kleiner en sneller is. Maar het zou waarschijnlijk een algemener afbeeldingsformaat zijn waaraan onze community 'geo' toevoegt, zoals we met TIFF deden. COG's zullen nog een tijdje de dienst uitmaken, omdat de achterwaartse compatibiliteit met oudere tools moeilijk te verslaan is terwijl we nog vroeg in de overgang naar cloud-first georuimtelijke infrastructuur zitten.
- Multidimensionaal rasterformaat: Er is hier ook al een geweldig antwoord met zarHet is in het proces van wordt aangenomen als een OGC-communitystandaard, waarbij de stemming over de adoptie binnenkort begint. Het wordt ook omarmd door NetCDF, en is aanzienlijk overgenomen door de klimaatgemeenschap.
- Belangrijkste vectorformaten: Er is hier nog geen geweldig antwoord. Ik zal het landschap en de verschillende mogelijkheden in een toekomstige blogpost bespreken.
- Puntenwolkformaat: Howard Butlers nieuwe COPC-formaat is een 'bereik-leesbare, gecomprimeerde, georganiseerde LASzip-specificatie' die aan alle eisen voldoet van Cloud-Optimized GeoTIFF en waarschijnlijk snel zal worden overgenomen.
- Collectie- en datasetmetadata: heeft een solide kern met de OGC API – Features 'Collection' constructie. De STAC-collectie breidt dat vervolgens uit, en de OGC API – Record biedt een GeoJSON-equivalent dat kan worden gebruikt als een return in zoekopdrachten. Maar deze onderdelen zijn niet allemaal op een coherente manier met elkaar verbonden, en het volledige 'statische' (alleen uploaden naar S3) gebruik was nog niet volledig uitgewerkt. Dit was de belangrijkste focus van mijn werk de afgelopen paar maanden, dus ik zal hieronder dieper ingaan.
- Granule / Scène niveau / 'asset' Metadata: is waar de Spatio-temporele activacatalogus (STAC) De specificatie waar ik me de afgelopen jaren vooral op heb gericht, heeft een grote rol gespeeld en wordt nu, na het bereiken van versie 1.0.0, goed ontvangen.
Hoe zit het met tegels?
Wat mij betreft is het nog niet helemaal duidelijk of een specificatie voor webtegels wel echt thuishoort in een echte cloud-native geospatiale basislijn. Ik denk dat ze voor rastertegels (png, jpeg, enz.) niet zinvol zijn, omdat een cloud-geoptimaliseerde GeoTIFF eenvoudig on-the-fly kan worden omgezet in webtegels met behulp van serverloze tegelgeneratoren zoals Titiler . Het patroon is dus om een goed cloud-native formaat te gebruiken dat on-the-fly rendering en verwerking mogelijk maakt in de vorm die clients nodig hebben. Tegels zijn essentieel voor browsergebaseerde clients, maar andere tools zijn beter af met directe toegang tot de data. Zodra de OGC API – Tiles-standaard is afgerond, zal het waarschijnlijk zinvol zijn om een 'bouwsteen voor tegelmetadata' te creëren die kan dienen als een cloud-native formaat om clients naar tegels te verwijzen.
Voor vectortegels beschouw ik zowel MVT 's als PBF 's als cloud-native geospatiale formaten, omdat ze in een cloudopslagbucket kunnen worden opgeslagen en door verschillende applicaties kunnen worden gebruikt. Ik denk echter dat er potentie is voor een goed cloud-native vectorformaat dat vergelijkbaar is met COG's, met een serverloze tegelserver die vectortegels dynamisch kan genereren. Ik zal dit idee in een toekomstig bericht over vectorformaten verder uitdiepen.
Hoe passen OGC API's hierbij?
Het OGC API-initiatief is een heruitvinding van de OGC W*S-baseline naar modernere JSON/REST API's. Over het algemeen bevindt het zich een niveau 'boven' de cloud-native geospatiale constructies die hier worden besproken, en definieert het API-interfaces voor services die de cloud-native formaten gebruiken (maar ook meer traditionele formaten en ruimtelijke databases kunnen gebruiken). Ze bieden veel meer mogelijkheden, zoals dynamisch zoeken of het on-the-fly verwerken van gegevens, maar vereisen ook meer. De meeste cloud-native metadata-constructies zijn uit de API's gehaald, dus de cloud-native varianten zouden compatibel moeten zijn met de OGC API's, alleen met veel minder mogelijkheden (hoewel ook veel gemakkelijker te implementeren).
Een ideaal ecosysteem zou de meeste data opslaan in cloud-native geospatiale formaten, en dan een breed scala aan services daarbovenop, waarvan de meeste OGC API-interfaces implementeren. In de toekomst zal het hopelijk triviaal zijn om een server of zelfs een serverloze functie te installeren die de rijkere OGC API-querying biedt bovenop de cloud-native metadata en formaten.
Op weg naar cloud-native geospatiale verzamelingsmetadata
Zoals hierboven vermeld, is het grootste deel van mijn OGC Visiting Fellow-tijd de afgelopen maanden besteed aan het uitzoeken van een 'cloud-native geospatial collection'. Hier zitten een paar verschillende aspecten aan.
Een statische OGC-collectie
Een van de krachtigste concepten die in de evolutie van STAC is ontstaan, is de 'statische STAC'. Zie het artikel 'Static Spatiotemporal Asset Catalogs in Depth' voor een uitstekende samenvatting van wat ze zijn en hoe ze werken. Om de ' best practices ' van versie 1.0.0 van de specificatie te citeren :
Een statische catalogus is een implementatie van de STAC-specificatie die niet dynamisch reageert op verzoeken. Het is simpelweg een verzameling bestanden op een webserver die op een manier met elkaar verbonden zijn die door zoekmachines kan worden geïndexeerd. Deze bestanden worden vaak opgeslagen in een cloudopslagservice zoals Amazon S3 , Azure Storage en Google Cloud Storage . Een statische catalogus kan in principe alleen worden geïndexeerd door zoekmachines en actieve catalogi; hij kan niet reageren op zoekopdrachten. Maar hij is ongelooflijk betrouwbaar, omdat er geen bewegende onderdelen, clusters of databases zijn die onderhouden moeten worden.
Het is een zeer populaire manier gebleken om STAC-gegevens te publiceren en sluit aan bij de visie in mijn vorige blogpost, namelijk dat u gegevens naar de cloud kunt uploaden en dat het 'gewoon werkt'.
Hoewel STAC baanbrekend werk verrichtte met duidelijke statische opties voor zowel individuele beeldelementen als andere spatiotemporele gegevens, en ook voor verzamelingen van dat type data, ontbrak er een equivalent 'statische verzameling' voor vectordata. De OGC API – Feature Collection (die STAC uitbreidt voor zijn Collection ) is, zoals gespecificeerd, slechts een onderdeel van een API-respons en geen onafhankelijke JSON-bron die zelfstandig kan worden gebruikt. Het was echter een goed ontworpen modulair onderdeel, en Clemens Portele en Peter Vretanos, de redacteuren van de Features-specificatie, waren er altijd voorstander van om het te behouden.
ik heb een ... gemaakt ruwe poging in een experimentele github-repository. Maar toen kwam Clemens met een ander idee dat we hadden bedacht: het maken van echte kleine, gedetailleerde bouwstenen van de OGC API-baseline (ik zal proberen om daar in de toekomst een volledige post over te schrijven). Dit resulteerde in een zeer schone 'Collectie', geëxtraheerd uit OGC API – Features, maar geschreven als een onafhankelijke JSON-bron die in elke context opnieuw gebruikt kan worden. En zo hebben we een echte 'statische OGC-collectie', die statisch op cloudopslag kan leven. Dit kan wijzen op een GeoJSON, GeoPackage, Shapefile of een nieuw, meer cloud-native formaat. U kunt zien Een voorbeeld hiervan in een repository die ik maakte om te experimenteren met voorbeelden van statische collecties. Die heeft meerdere representaties van dezelfde data als verschillende formaten, maar het zou er makkelijk maar één kunnen hebben.
Records + STAC-uitlijning
Een ander groot deel van mijn tijd ging op aan werk dat niet direct cloud-native is: het volledig afstemmen van STAC op de OGC API – Records . Velen waren onzeker over de precieze relatie tussen de twee specificaties, hoewel ik daar altijd duidelijke (maar niet goed gecommuniceerde) ideeën over had. De afgelopen maanden hebben me de tijd gegeven om volledig af te stemmen met het kernteam van Records en overeenstemming te bereiken over de te volgen koers. Kort gezegd speelt de Records API een belangrijke rol in STAC, omdat we de implementatie van ' zoeken op collectieniveau ' hebben uitgesteld, aangezien we dat eerst volledig wilden afstemmen op Records. Het verwarrende is echter dat een Records API ook gebruikt kan worden om te zoeken naar STAC-achtige items, en in feite is ontworpen voor het zoeken naar vrijwel alles.
Het 'aha'-moment was het besef dat de auteurs van de Records-specificatie altijd al een 'Data Record' voor ogen hadden, wat precies is wat STAC nodig heeft. Dat is iets specifieker dan een volledig algemene, flexibele Record. De Collection-constructie van STAC is eigenlijk alleen gericht op wat OGC als 'datasets' beschouwt, alleen was er nog geen duidelijke specificatie van die constructie in de opkomende OGC API-baseline. Ik heb een pull request ingediend in de Records- repository om dit toe te voegen en zal vervolgens ook een 'Data Collection' voorstellen die de kern OGC Collection uitbreidt met extra velden. Een STAC Collection zou hopelijk aansluiten op die Dataset Collection-constructie. En in de toekomst zullen we samenwerken aan een 'STAC Record' die een STAC Item volledig afstemt op de meer algemene recordvereisten.
Een ander positief gevolg van deze synchronisatie is de zeer fraaie herstructurering van de kernspecificatie van de Records API door Peter Vretanos. Het idee was altijd al dat de Records API een Features API is, maar dan met extra functionaliteit (zoals sorteren en uitgebreidere querymogelijkheden) en een beter gestructureerd datamodel. De nieuwe versie maakt dit veel duidelijker, met de nadruk op de onderdelen die verschillen van de kern-OGC API's, en zou het veel gemakkelijker moeten maken om deze af te stemmen op STAC.
Statische records
Dit werk heeft een mooie basis gelegd voor de volgende cloud-native geospatiale component: een crawlbare catalogus met webtoegankelijke statische records! Peter heeft een voorbeeld van een crawlbare catalogus gemaakt (en ik heb een pull request ingediend die het voorbeeld uitbreidt met een 'statische OGC-collectie' met vectorgegevens). Deze catalogus moet nog wat worden aangepast om te voldoen aan STAC, maar past wel bij al onze cloud-native geospatiale principes. We hebben nu dus vrijwel alle benodigde onderdelen voor de juiste metadata voor een cloud-native geospatiale basis. Records en collecties zijn in principe twee alternatieve implementaties van dezelfde kerndatamodellen: de ene is GeoJSON, waardoor het gemakkelijk is om veel records tegelijk te visualiseren, en de andere komt overeen met de veelgebruikte OGC API-collectiestructuur. Op korte termijn is het waarschijnlijk het beste om beide te gebruiken, maar na verloop van tijd zullen er waarschijnlijk tools beschikbaar komen die gemakkelijk van de ene naar de andere converteren, vooral als we de kerndatamodellen volledig compatibel krijgen.
Brengen het allemaal samen
We zijn dus verleidelijk dicht bij de volledige reeks statische metadata die nodig is om de meeste cloud-native geospatiale data te verwerken. De belangrijkste taak die voor ons ligt, is om het werk in OGC API – Records en – Features volledig af te stemmen op de compatibiliteit met STAC, en om alle benodigde metadatavelden beter te beschrijven. Er zijn een paar manieren waarop de zaken nu een beetje anders zijn, dus het zou fijn zijn om de zaken tussen de twee benaderingen een beetje te vereenvoudigen.
Om te laten zien hoe alles samen kan werken, heb ik een repository met ' statische ogc-voorbeelden ' aangemaakt . Deze laat zien hoe je een aantal verschillende datasets en formaten beschikbaar kunt hebben vanuit een volledig statische structuur. Ik zal de repository blijven uitbreiden en de voorbeelden verder ontwikkelen, en de README-bestanden aanvullen om te laten zien wat er gebeurt. In de toekomst zal ik proberen een blogpost te schrijven waarin ik dieper op de details inga.
Toekomstige berichten zullen dieper ingaan op de status van daadwerkelijke cloud-native geospatiale formaten. Vectordata is waar ik de laatste tijd het meeste tijd aan heb besteed, omdat er geen superduidelijk antwoord is. Ik hoop ook meer tijd te besteden aan het benadrukken van zarr en copc, omdat dat twee echt geweldige inspanningen zijn die goed passen en een compleet ecosysteem van formaten echt compleet maken.
