El bucket gs://alphaearth_foundations de GCS contiene archivos COG (GeoTIFF optimizado para la nube) que, en conjunto, conforman el conjunto de datos anual de AlphaEarth Foundations Satellite Embedding. Contiene las incorporaciones anuales de los años 2017 a 2025, inclusive.
Google se compromete a producir capas anuales de Satellite Embedding de forma continua y proporcionará un aviso con al menos un año de anticipación sobre cualquier cambio previsto en la entrega, sujeto a la disponibilidad continua de las transmisiones de datos de entrada del USGS y la ESA en las que se basa la producción del conjunto de datos.
Licencia
Este conjunto de datos se otorga bajo la licencia CC-BY 4.0 y requiere el siguiente texto de atribución: "El conjunto de datos de AlphaEarth Foundations Satellite Embedding es producido por Google y Google DeepMind."
A partir de julio de 2026, este bucket se configurará como "el proveedor paga".
Estructura del directorio
Se dividen en directorios por año. El directorio de cada año se divide en 120 subdirectorios, uno por zona UTM, cuyos nombres reflejan el número de zona y el hemisferio (N o S).
Dentro de cada directorio, hay varios archivos COG. Estos archivos contienen todos los datos de píxeles de esa zona UTM.
Estructura de archivos
Cada archivo tiene 8,192 x 8,192 píxeles, con 64 canales. La magnitud de cada píxel, después de que se aplicó la asignación de desantización (consulta a continuación), se normalizó para que tenga una longitud euclidiana de 1.
Los archivos contienen capas de resumen de 4,096 x 4,096 píxeles, 2,048 x 2,048 píxeles, y así sucesivamente, hasta una capa de resumen de nivel superior de 1 x 1. Estas capas de resumen se construyen de modo que cada píxel de resumen sea la media de los píxeles de mayor resolución que se encuentran debajo de ese píxel de resumen, en la que la magnitud de la media se normalizó para que tenga una longitud de 1.
Los canales corresponden, en orden, a los ejes A00 a A63 del conjunto de datos de Satellite Embedding. Los COG también contienen esta denominación para los canales.
El valor de cada píxel para cada canal es un número entero de 8 bits con signo. La forma en que estos valores se asignan a los valores nativos (en el rango [-1, 1]) de las incorporaciones se explica en Desantización.
El valor -128 corresponde a un píxel enmascarado. Si está presente en un canal, estará presente en todos los canales. Los COG reflejan esto (es decir, tienen el valor NoData establecido en -128).
El nombre de cada archivo también contiene información. Por ejemplo, considera el archivo llamado gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff.
Como se evidencia en el nombre del archivo, este archivo forma parte de la incorporación anual de 2019 para la zona UTM 1S (zona 1, hemisferio sur). El nombre de archivo base, x8qqwcsisbgygl2ry-0000008192-0000000000, sirve para vincular este archivo al nombre de la imagen de Satellite Embedding de Earth Engine correspondiente. En este ejemplo, este archivo corresponde a una parte de la imagen de Earth Engine GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry. Las dos partes decimales del nombre del archivo especifican dónde se encuentran los valores de este COG en relación con esa imagen de Earth Engine, como un desplazamiento en Y seguido de un desplazamiento en X. En este caso, el origen de píxeles del COG está en (0, 8192) en relación con el origen de la imagen de Earth Engine.
Esto se debe a que fue necesario subdividir cada imagen de Earth Engine (que son de 16,384 x 16,384 píxeles) para que los COG resultantes no fueran demasiado difíciles de manejar.
Desantización
Para transformar el valor sin procesar de 8 bits con signo (que estará entre -127 y 127 inclusive, ya que -128 se reserva como el valor "sin datos") en cada canal de cada píxel al valor de punto flotante listo para el análisis (que estará entre -1 y 1), la asignación que se debe realizar es la siguiente:
- dividir por 127.5
- cuadrado
- multiplicar por el signo del valor original
Esto se expresaría en NumPy de la siguiente manera:
# values is a NumPy array of raw pixel values
de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)
En Earth Engine, la operación correspondiente sería la siguiente:
var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());
Crea pirámides con muestreo reducido
Si deseas crear tus propias versiones con muestreo reducido o resúmenes externos a partir de la capa de resolución base de estos COG (por ejemplo, después de unir varios archivos), debes usar el siguiente procedimiento. Las técnicas estándar de piramidización ráster (p.ej., usar gdaladdo con -r average en los valores enteros sin procesar) no producirán resultados correctos.
- Desantiza: Convierte los números enteros sin procesar de 8 bits en números de punto flotante con el método que se describe en Desantización.
- Suma vectores: Realiza una suma por elementos de los vectores desantizados.
- Normaliza: Calcula la norma euclidiana del vector de suma resultante y divídela por la norma para volver a normalizarla a la longitud de la unidad.
import numpy as np
# Assuming 'raw_values' is a NumPy array of shape (N, 64)
# containing the raw signed 8-bit integers from N pixels.
# N = 4 for a 2x2 aggregation, for example.
# 1. De-quantize
de_quantized_values = ((raw_values / 127.5) ** 2) * np.sign(raw_values)
# 2. Sum the de-quantized vectors
sum_vec = np.sum(de_quantized_values, axis=0) # Shape (64,)
# 3. Normalize the sum vector
norm = np.linalg.norm(sum_vec)
# Add epsilon to prevent division by zero
pyramided_vec = sum_vec / (norm + 1e-9)
# 'pyramided_vec' is the correctly downsampled 64-dimensional unit vector.
Las capas de resumen de los COG se generaron con este procedimiento. Si se adaptan a tus necesidades, puedes usarlas de inmediato sin realizar cálculos adicionales.
Manifiesto e índice
Puedes encontrar una lista de los archivos de este conjunto de datos en gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt.
Como no es posible determinar a partir de los nombres de los archivos qué área del mundo abarcan, también se proporcionó un índice en tres formas (GeoParquet, GeoPackage y CSV) en los archivos gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet, gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg y gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv. Este índice contiene una entrada para cada archivo del conjunto de datos. La información proporcionada para cada archivo es la siguiente:
- la geometría del archivo como un polígono WGS84 (es decir, EPSG:4326). En el formato CSV, se encuentra en la columna
WKT. Consulta Procesamiento de geometría para obtener detalles de los cálculos. crs: El CRS de la zona UTM a la que pertenece esta imagen como un código EPSG, comoEPSG:32610.year: El año que abarca la imagen.utm_zone: La zona UTM de la imagen, como10N.utm_west,utm_south,utm_east,utm_north: Los límites UTM del array de píxeles sin procesar. Esto no refleja ningún procesamiento de geometría e incluye todos los píxeles, ya sean válidos o no.wgs84_west,wgs84_south,wgs84_east,wgs84_north: La longitud y la latitud mínimas y máximas de la geometría WGS84.
Procesamiento de geometría
El array de píxeles está de forma nativa en alguna zona UTM, por lo que, en esa zona UTM, el cuadro de límite del array de píxeles es un rectángulo simple. Ese cuadro de límite se transforma en un polígono en WGS84. Este polígono incluye varios puntos adicionales para que sus bordes sigan de cerca las líneas curvas en WGS84 en las que se transforman las líneas rectas en UTM. Este polígono no tiene en cuenta la validez de los píxeles de la imagen, solo los límites del array de píxeles de la imagen.
Luego, el polígono se recorta a la longitud mínima y máxima de la zona UTM de la imagen. En la práctica, esto puede hacer que no incluya algunos píxeles válidos que se extienden más allá del borde de la zona UTM. Omitir estos píxeles del índice no debería causar ningún problema: alguna imagen de la zona UTM vecina debería cubrir esa área.
Ten en cuenta que el recorte a la longitud mínima y máxima de la zona UTM significa que ningún polígono cruza el antimeridiano, lo que debería simplificar un poco el procesamiento de este archivo.