Dati GCS di AlphaEarth Foundations

Il bucket GCS gs://alphaearth_foundations contiene file COG (Cloud Optimized GeoTIFF) che insieme costituiscono il set di dati annuale Satellite Embedding di AlphaEarth Foundations. Contiene gli incorporamenti annuali per gli anni dal 2017 al 2024, inclusi.

Licenza

Questo set di dati è concesso in licenza ai sensi della licenza CC-BY 4.0 e richiede il seguente testo di attribuzione: "Il set di dati AlphaEarth Foundations Satellite Embedding è prodotto da Google e Google DeepMind".

Questo bucket è configurato come "pagamento a carico del richiedente", pertanto il download dei dati potrebbe comportare costi di uscita e altri addebiti.

Struttura delle directory

Sono suddivisi in directory per anno; la directory di ogni anno è suddivisa in 120 sottodirectory, una per zona UTM, i cui nomi riflettono il numero della zona e l'emisfero (N o S).

All'interno di ogni directory si trovano diversi file COG. Questi file contengono tutti i dati dei pixel per quella zona UTM.

Struttura dei file

Ogni file ha dimensioni di 8192 x 8192 pixel, con 64 canali. La magnitudo di ogni pixel, dopo l'applicazione della mappatura di dequantizzazione (vedi sotto), è stata normalizzata in modo che abbia una lunghezza euclidea pari a 1.

I file contengono livelli di panoramica a 4096 x 4096 pixel, 2048 x 2048 pixel e così via fino a un livello di panoramica di primo livello di 1 x 1 pixel. Questi livelli di panoramica sono costruiti in modo che ogni pixel di panoramica sia la media dei pixel a risoluzione più alta sotto quel pixel di panoramica, dove la magnitudo della media è stata normalizzata in modo da avere lunghezza 1.

I canali corrispondono, in ordine, agli assi da A00 a A63 del set di dati Incorporamento satellitare. Anche i COG contengono questa denominazione per i canali.

Il valore di ogni pixel per ogni canale è un numero intero a 8 bit con segno. Il modo in cui questi valori vengono mappati ai valori nativi (nell'intervallo [-1, 1]) degli incorporamenti è descritto di seguito.

Il valore -128 corrisponde a un pixel mascherato. Se è presente in un canale, sarà presente in tutti i canali. I COG riflettono questo valore (ovvero, il valore NoData è impostato su -128).

Anche il nome di ogni file contiene alcune informazioni. Ad esempio, considera il file denominato gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff. Come descritto sopra, questo file fa parte dell'incorporamento annuale del 2019 e si trova nella zona UTM 1S (zona 1, emisfero australe). Il nome file di base, x8qqwcsisbgygl2ry-0000008192-0000000000, serve a collegare questo file al nome dell'immagine incorporata del satellite Earth Engine corrispondente. In questo esempio, questo file corrisponde a una parte dell'immagine Earth Engine GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry. Le due parti decimali del nome file specificano la posizione dei valori di questo COG rispetto all'immagine di Earth Engine, come offset in Y seguito da un offset in X. In questo caso, l'origine dei pixel del COG si trova in (0, 8192) rispetto all'origine dell'immagine di Earth Engine. Questo perché è stato necessario suddividere ogni immagine di Earth Engine (che sono 16384 x 16384 pixel) in modo che i COG risultanti non fossero troppo difficili da gestire.

De-quantizzazione

Per trasformare il valore non elaborato a 8 bit con segno (che sarà compreso tra -127 e 127 inclusi, in quanto -128 è riservato come valore "nessun dato") in ogni canale di ogni pixel nel valore in virgola mobile pronto per l'analisi (che sarà compreso tra -1 e 1), la mappatura da eseguire è

  • dividi per 127,5
  • quadrato
  • moltiplica per il segno del valore originale

Questo valore verrebbe espresso in NumPy come

  # values is a NumPy array of raw pixel values
  de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)

In Earth Engine, l'operazione corrispondente sarebbe

  var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());

Manifest e indice

Un elenco dei file in questo set di dati è disponibile in gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt.

Poiché dai nomi dei file non è possibile determinare l'area del mondo che coprono, è stato fornito anche un indice in tre formati (GeoParquet, GeoPackage e CSV) nei file gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet, gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg e gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv. Questo indice contiene una voce per ogni file del set di dati. Le informazioni fornite per ogni file sono

  • la geometria del file come WGS84 (ad es. EPSG:4326). Nel modulo CSV, questa informazione si trova nella colonna WKT. Continua a leggere per scoprire i dettagli su come viene calcolata questa geometria.
  • crs: il sistema di riferimento delle coordinate della zona UTM a cui appartiene questa immagine come codice EPSG, ad esempio EPSG:32610.
  • year: l'anno coperto dall'immagine.
  • utm_zone: la zona UTM dell'immagine, ad esempio 10N.
  • utm_west, utm_south, utm_east, utm_north: i limiti UTM dell'array di pixel grezzi. Non riflette l'elaborazione della geometria e include tutti i pixel, indipendentemente dalla loro validità.
  • wgs84_west, wgs84_south, wgs84_east, wgs84_north: la longitudine e la latitudine min/max della geometria WGS84.

Elaborazione della geometria

L'array di pixel si trova in modo nativo in una zona UTM, quindi in questa zona UTM il riquadro di selezione dell'array di pixel è un semplice rettangolo. Il riquadro di delimitazione viene trasformato in un poligono in WGS84. Questo poligono include una serie di punti aggiuntivi in modo che i suoi bordi seguano da vicino le linee curve in WGS84 in cui si trasformano le linee rette in UTM. Questo poligono non tiene conto della validità/invalidità dei pixel nell'immagine, ma solo dei limiti dell'array di pixel dell'immagine.

Il poligono viene quindi ritagliato in base alla longitudine minima e massima della zona UTM dell'immagine. In pratica, ciò potrebbe comportare l'esclusione di alcuni pixel validi che sporgono dal bordo della zona UTM. L'omissione di questi pixel dall'indice non dovrebbe causare problemi: una parte dell'immagine della zona UTM vicina dovrebbe coprire l'area.

Tieni presente che il ritaglio alla longitudine minima/massima della zona UTM significa che nessun poligono attraversa l'antimeridiano, il che dovrebbe semplificare un po' l'elaborazione di questo file.