Oltre tre anni fa, un piccolo gruppo di membri dell'OGC stava lavorando alla prossima versione del venerabile Web Feature Service (WFS) ha dato il via alla successiva importante evoluzione della nostra baseline di standard. Ciò che da allora è diventato noto come API OGC famiglia di standard mira a applicare le migliori pratiche del web alla geospaziale passando al contempo da servizi monolitici a un set di componenti "building block" in grado di aggiungere funzionalità spaziali a qualsiasi API moderna, ben prima di STAC.
Quello che divenne noto come OGC API – Features originariamente si chiamava WFS 3.0 ed era ben diversa dalle versioni precedenti di WFS. Forse la cosa più importante che ha fatto è stata passare a un modello di sviluppo aperto, con l'intero standard in evoluzione nel pubblico, su GitHub. Più o meno nello stesso periodo un gruppo di sviluppatori di 14 diverse organizzazioni riuniti a Boulder, Colorado per lavorare sull'interoperabilità delle API dei dati satellitari, che ha dato il via al Catalogo delle risorse spazio-temporali (STAC) specifiche. Fin dall'inizio c'erano molti obiettivi sovrapposti tra i due gruppi, ma invece di competere, entrambi hanno abbracciato la collaborazione aperta abilitata da GitHub. Quindi chiunque abbia prestato molta attenzione ha visto che STAC e OGC API – Features si sono evoluti insieme e si sono continuamente allineati. Infatti, il secondo and quinto Gli sprint STAC sono stati effettuati in collaborazione con OGC API – Features squadra.
Tuttavia, con la maturazione e la maggiore adozione di entrambe le specifiche, abbiamo ricevuto sempre più domande sulla relazione tra di esse. Radiant Earth , l'ente responsabile di STAC, ha appena pubblicato un articolo su Medium che spiega esattamente come le due specifiche interagiscono. Volevamo ribadire quanto affermato e fornire il punto di vista di OGC. Il concetto principale è il seguente:
'STAC API implementa ed estende lo standard OGC API — Features, e il nostro obiettivo comune è che STAC API diventi uno standard OGC completo'
Dal punto di vista dell'OGC, abbiamo identificato che STAC ha un ruolo chiaro da svolgere nella nostra evoluzione API OGC standard di base, per aiutare a collegare i componenti fondamentali a una varietà di esigenze degli utenti, in particolare nel telerilevamento e 'nuovo spazio' comunità. OGC API – Features consente qualsiasi spazio 'caratteristicada rappresentare in un'API Web e tutte le risorse spazio-temporali sono feature, in cui la geometria è generalmente un'impronta dei dati rappresentati.
L'obiettivo a lungo termine è che la specifica API STAC diventi semplicemente un insieme di blocchi costitutivi dell'API OGC rilevanti per i casi d'uso di STAC, con le specifiche STAC Core che forniscono il contenuto da utilizzare con qualsiasi componente API OGC pertinente . Raggiungere questa visione richiede molto lavoro sulle API OGC principali , quindi il nostro piano è di continuare a far evolvere e allineare le API OGC con STAC, seguendo al contempo i nostri processi per integrare la comunità STAC con il nostro processo di standardizzazione OGC.
Il primo passo sarà quello di coinvolgere STAC come Standard della comunità, il nostro processo più nuovo e leggero che semplifica la collaborazione con il lavoro di standardizzazione che inizia al di fuori dell'OGC. Continueremo a sviluppare il API OGC componenti in stretto allineamento con STAC. Infatti, API OGC – Record ha recentemente modificato leggermente il suo percorso per allinearsi meglio con STAC (vedere i problemi di GitHub) #58 #62 #22 per maggiori dettagli), mentre STAC è lavoro a allineare a OGC API – Features Parti 3 (CQL) e 4 (Transazioni), e loro lavoro futuro. E la recente API STAC Versione 1.0.0-beta.1 ha adottato anche lo stile delle classi di conformità dell'OGC, che consente anche un allineamento più semplice.
OGC è pronta ad assumersi la manutenzione di STAC come standard OGC a tutti gli effetti, non appena la comunità di utenti sarà pronta per tale gestione. Ciò avverrà probabilmente quando STAC e le API OGC principali saranno mature e richiederanno solo una manutenzione incrementale. Anche Radiant Earth concorda sul fatto che questa sia la strada migliore: consolidare la manutenzione dello standard in un'unica organizzazione. Radiant Earth continuerà a concentrarsi sui casi d'uso e sugli strumenti relativi a STAC, poiché il suo obiettivo è sempre stato quello di promuovere lo standard e svolgere un ruolo attivo nel favorire l'interoperabilità.
Se avete ulteriori domande sulle relazioni tra gli standard, non esitate a chiedere . E unitevi a noi per plasmare un futuro geospaziale aperto e interoperabile.
