El bucket de GCS gs://alphaearth_foundations contiene archivos COG (GeoTIFF optimizado para la nube) que, en conjunto, conforman el conjunto de datos anual de Incorporación de satélites de AlphaEarth Foundations. Contiene los embeddings anuales de los años 2017 a 2024, inclusive.
Licencia
Este conjunto de datos se publica bajo la licencia CC-BY 4.0 y requiere el siguiente texto de atribución: "El conjunto de datos de incorporación de satélites de AlphaEarth Foundations es un producto de Google y Google DeepMind".
Este bucket está configurado como "pago por solicitud", por lo que la descarga de datos puede generar cargos de salida y otros cargos.
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 × 8,192 píxeles y 64 canales. La magnitud de cada píxel, después de que se aplicó la asignación de desantificación (consulta a continuación), se normalizó para que tenga una longitud euclidiana de 1.
Los archivos contienen capas de vista general de 4096 x 4096 píxeles, 2048 x 2048 píxeles, y así sucesivamente hasta una capa de vista general de nivel superior de 1 x 1. Estas capas de vista general se construyen de modo que cada píxel de vista general sea la media de los píxeles de mayor resolución que se encuentran debajo de ese píxel de vista general, en la que la magnitud de la media se normalizó para tener 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 nomenclatura para los canales.
El valor de cada píxel para cada canal es un número entero de 8 bits con signo. A continuación, se describe la forma en que estos valores se asignan a los valores nativos (en el rango [-1, 1]) de las incorporaciones.
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 describió anteriormente, este archivo forma parte de la incorporación anual de 2019 y se encuentra en la zona UTM 1S (zona 1, hemisferio sur). El nombre de archivo base, x8qqwcsisbgygl2ry-0000008192-0000000000, sirve para vincular este archivo con el 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 de 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 del píxel del COG se encuentra 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 tiene 16384 x 16384 píxeles) para que los COG resultantes no fueran demasiado difíciles de manejar.
Descuantizació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 en el valor de punto flotante listo para el análisis (que estará entre -1 y 1), la asignación que se debe realizar es
- Dividir por 127.5
- cuadrado
- multiplicar por el signo del valor original
En NumPy, esto se expresaría 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
var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());
Manifiesto e índice
Puedes encontrar una lista de los archivos en 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 formatos (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 que se proporciona para cada archivo es la siguiente:
- la geometría del archivo como WGS84 (es decir, Polígono (EPSG:4326). En el formulario CSV, se encuentra en la columna
WKT. A continuación, se incluyen detalles sobre cómo se calcula esta geometría. crs: CRS de la zona UTM a la que pertenece esta imagen como código EPSG, comoEPSG:32610.year: Año que abarca la imagen.utm_zone: Es la zona UTM de la imagen, como10N.utm_west,utm_south,utm_east,utm_north: Son los límites de UTM del array de píxeles sin procesar. Esto no refleja ningún procesamiento de geometría y, además, incluye todos los píxeles, ya sean válidos o no.wgs84_west,wgs84_south,wgs84_east,wgs84_north: Son la longitud y la latitud mínimas y máximas de la geometría WGS84.
Procesamiento de geometría
El array de píxeles se encuentra de forma nativa en alguna zona UTM, por lo que, en esa zona, el cuadro delimitador 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 una cantidad de 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 o invalidez de los píxeles en la imagen, solo los límites del array de píxeles de la imagen.
Luego, el polígono se recorta según la longitud mínima y máxima de la zona UTM de la imagen. En la práctica, esto puede hacer que no se incluyan algunos píxeles válidos que sobresalen del borde de la zona UTM. Omitir estos píxeles del índice no debería causar ningún problema, ya que alguna imagen de la zona UTM vecina debería cubrir esa área.
Ten en cuenta que el recorte a la longitud mínima o 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.