Ruim drie jaar geleden werkte een kleine groep OGC-leden aan de volgende versie van de eerbiedwaardige Web Feature Service (WFS) standaard startte de volgende grote evolutie van onze standaardenbasislijn. Wat sindsdien bekend is geworden als de OGC-API familie van normen heeft als doel de beste praktijken van het web toepassen op georuimtelijke terwijl er ook een verschuiving plaatsvindt van monolithische services naar een set 'bouwsteen'-componenten die ruimtelijke mogelijkheden kunnen toevoegen aan elke moderne API, lang vóór STAC.
Wat bekend werd als OGC API – Features heette oorspronkelijk WFS 3.0 en was nogal anders van de eerdere versies van WFS. Misschien wel het belangrijkste wat het deed, was de overstap naar een model van open ontwikkeling, waarbij de hele standaard openbaar werd ontwikkeld op GitHub. Rond dezelfde tijd kwam een groep ontwikkelaars van 14 verschillende organisaties verzameld in Boulder, Colorado om te werken aan de interoperabiliteit van satellietdata-API's, waarmee de start werd gegeven Ruimtelijke-temporele activacatalogus (STAC) specificaties. Vanaf het begin waren er veel overlappende doelstellingen tussen de twee groepen, maar in plaats van te concurreren, omarmden beide de open samenwerking die mogelijk werd gemaakt door GitHub. Dus iedereen die goed oplet, heeft gezien dat STAC en OGC API – Features zijn samen geëvolueerd en voortdurend op één lijn gebracht. Inderdaad, de tweede en vijfde STAC-sprints werden uitgevoerd in samenwerking met OGC API – Features team.
Maar naarmate beide specificaties zich verder ontwikkelen en meer worden toegepast, ontvangen we steeds meer vragen over de relatie tussen de twee specificaties. Radiant Earth , de beheerder van STAC, heeft onlangs een artikel op Medium gepubliceerd waarin precies wordt uitgelegd hoe de twee specificaties samenwerken. We wilden de inhoud van dat artikel herhalen en het perspectief van OGC delen. De belangrijkste conclusie is:
'STAC API implementeert en breidt de OGC API uit — Features standaard, en ons gezamenlijke doel is dat STAC API een volledige OGC-standaard wordt'
Vanuit het perspectief van OGC hebben we vastgesteld dat STAC een duidelijke rol te spelen heeft in onze evoluerende OGC-API standaardbasislijn, om de belangrijkste bouwstenen te helpen aansluiten bij uiteenlopende gebruikersbehoeften, met name op het gebied van remote sensing en 'nieuwe ruimte'gemeenschappen. OGC API – Features maakt elke ruimtelijke ' mogelijkkenmerken' moet worden weergegeven in een web-API, en alle SpatioTemporal Assets zijn functies, waarbij de geometrie over het algemeen een voetafdruk is van de weergegeven gegevens.
De langetermijnvisie is dat de STAC API-specificatie simpelweg een bundel OGC API- bouwstenen wordt die relevant zijn voor de STAC-gebruiksscenario's, waarbij de STAC Core-specificaties de inhoud leveren die gebruikt kan worden met elke relevante OGC API- component. Om die visie te realiseren is veel werk aan de kern -OGC API's nodig. Daarom is het plan om de OGC API's te blijven ontwikkelen en afstemmen op STAC, terwijl we onze processen volgen om de STAC-gemeenschap te integreren in ons OGC-standaardisatieproces.
De eerste stap zal zijn om STAC als een Gemeenschapsstandaard, ons nieuwere, lichtgewicht proces dat het makkelijker maakt om samen te werken met standaardwerk dat buiten OGC begint. We zullen de OGC-API componenten die nauw aansluiten bij STAC. Inderdaad, OGC API – Records heeft onlangs zijn pad enigszins gewijzigd om beter aan te sluiten bij STAC (zie GitHub-problemen #58 #62 #22 voor meer details), terwijl STAC is werkzaam naar richten naar OGC API – Features Deel 3 (CQL) en 4 (Transacties) en hun toekomstwerk. En de recente STAC API 1.0.0-beta.1-versie heeft ook de stijl van conformiteitsklassen van OGC overgenomen, wat ook een eenvoudigere uitlijning mogelijk maakt.
OGC is klaar om het onderhoud van STAC als volwaardige OGC-standaard over te nemen zodra de gebruikersgemeenschap daar klaar voor is. Dit zal waarschijnlijk gebeuren wanneer STAC en de belangrijkste OGC-API's volwassen zijn en alleen nog incrementeel onderhoud vereisen. Radiant Earth is het er ook mee eens dat dit de beste aanpak is: het standaardonderhoud consolideren in één organisatie. Radiant Earth zal zich blijven richten op de use cases en tools rondom STAC, aangezien het altijd hun doel is geweest om de standaard te ontwikkelen en hun rol te spelen in het mogelijk maken van interoperabiliteit.
Als u nog vragen heeft over de relaties tussen de standaarden, aarzel dan niet om ze te stellen . En werk samen met ons aan de open, interoperabele toekomst van de georuimtelijke technologie.
