Le bucket GCS gs://alphaearth_foundations contient des fichiers COG (Cloud Optimized GeoTIFF) qui constituent l'ensemble de données annuel Satellite Embedding d'AlphaEarth Foundations. Il contient les embeddings annuels pour les années 2017 à 2025, incluses.
Google s'engage à produire en continu des calques d'intégration satellite annuels et fournira un préavis d'au moins un an pour toute modification prévue de la diffusion, sous réserve de la disponibilité continue des flux de données d'entrée de l'USGS et de l'ESA sur lesquels repose la production de l'ensemble de données.
Licence
Cet ensemble de données est concédé sous licence CC-BY 4.0 et nécessite le texte d'attribution suivant : "L'ensemble de données AlphaEarth Foundations Satellite Embedding est produit par Google et Google DeepMind."
Ce bucket est configuré avec l'option de paiement par le demandeur. Par conséquent, le téléchargement de données peut entraîner des frais de sortie et autres frais.
Structure des répertoires
Ils sont divisés en répertoires par année. Chaque répertoire annuel est divisé en 120 sous-répertoires, un par zone UTM, dont les noms reflètent le numéro de zone et l'hémisphère (N ou S).
Chaque répertoire contient un certain nombre de fichiers COG. Ces fichiers contiennent toutes les données de pixels pour cette zone UTM.
Structure des fichiers
Chaque fichier mesure 8 192 x 8 192 pixels et comporte 64 canaux. La magnitude de chaque pixel, après l'application du mappage de déquantification (voir ci-dessous), a été normalisée de sorte qu'elle ait une longueur euclidienne de 1.
Les fichiers contiennent des calques d'aperçu de 4 096 x 4 096 pixels, 2 048 x 2 048 pixels, etc., jusqu'à un calque d'aperçu de premier niveau de 1 x 1 pixel. Ces calques de vue d'ensemble sont construits de sorte que chaque pixel de vue d'ensemble soit la moyenne des pixels de résolution la plus élevée sous ce pixel de vue d'ensemble, où la magnitude de la moyenne a été normalisée pour avoir une longueur de 1.
Les canaux correspondent, dans l'ordre, aux axes A00 à A63 de l'ensemble de données Satellite Embedding. Les COG contiennent également cette dénomination pour les canaux.
La valeur de chaque pixel pour chaque canal est un entier signé de 8 bits. La façon dont ces valeurs sont mappées aux valeurs natives (dans la plage [-1, 1]) des embeddings est expliquée dans Déquantification.
La valeur -128 correspond à un pixel masqué. Si elle est présente dans un canal, elle le sera dans tous les canaux. Les COG reflètent cela (c'est-à-dire que la valeur NoData est définie sur -128).
Le nom de chaque fichier contient également des informations. Prenons l'exemple du fichier nommé gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff.
Comme l'indique le nom du fichier, celui-ci fait partie de l'intégration annuelle de 2019 pour la zone UTM 1S (zone 1, hémisphère sud). Le nom de fichier de base, x8qqwcsisbgygl2ry-0000008192-0000000000, permet d'associer ce fichier au nom de l'image d'intégration satellite Earth Engine correspondante. Dans cet exemple, ce fichier correspond à une partie de l'image Earth Engine GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry. Les deux parties décimales du nom de fichier spécifient où se trouvent les valeurs de ce COG par rapport à cette image Earth Engine, sous la forme d'un décalage en Y suivi d'un décalage en X. Dans ce cas, l'origine des pixels du COG est à (0, 8192) par rapport à l'origine de l'image Earth Engine.
En effet, il était nécessaire de subdiviser chaque image Earth Engine (qui fait 16 384 x 16 384 pixels) pour que les COG obtenus ne soient pas trop difficiles à manipuler.
Déquantification
Pour transformer la valeur brute signée de 8 bits (comprise entre -127 et 127, car -128 est réservé à la valeur "aucune donnée") dans chaque canal de chaque pixel en valeur à virgule flottante prête à l'analyse (comprise entre -1 et 1), le mappage à effectuer est le suivant :
- diviser par 127,5
- carré
- multiplier par le signe de la valeur d'origine.
Dans NumPy, cela s'exprimerait comme suit :
# values is a NumPy array of raw pixel values
de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)
Dans Earth Engine, l'opération correspondante serait
var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());
Créer des pyramides sous-échantillonnées
Si vous prévoyez de créer vos propres versions sous-échantillonnées ou aperçus externes à partir du calque de résolution de base de ces COG (par exemple, après avoir mosaïqué plusieurs fichiers), vous devez suivre la procédure ci-dessous. Les techniques de pyramidation raster standards (par exemple, l'utilisation de gdaladdo avec -r average sur les valeurs entières brutes) ne produiront pas de résultats corrects.
- Déquantifier : convertissez les nombres entiers bruts de 8 bits en nombres à virgule flottante à l'aide de la méthode décrite dans Déquantification.
- Somme des vecteurs : effectuez une somme élément par élément des vecteurs déquantifiés.
- Normaliser : calculez la norme euclidienne du vecteur somme obtenu et divisez-la par la norme pour la renormaliser à la longueur d'unité.
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.
Les calques de présentation des COG ont été générés à l'aide de cette procédure. S'ils répondent à vos besoins, vous pouvez les utiliser immédiatement sans aucun calcul supplémentaire.
Manifeste et index
Vous trouverez la liste des fichiers de cet ensemble de données dans gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt.
Comme il est impossible de déterminer la zone géographique couverte par les noms de fichiers, un index est également fourni sous trois formes (GeoParquet, GeoPackage et CSV) dans les fichiers gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet, gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg et gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv. Cet index contient une entrée pour chaque fichier de l'ensemble de données. Les informations fournies pour chaque fichier sont les suivantes :
- la géométrie du fichier au format WGS84 (c'est-à-dire EPSG:4326). Dans le formulaire CSV, cette information se trouve dans la colonne
WKT. Pour en savoir plus sur les calculs, consultez Traitement de la géométrie. crs: CRS de la zone UTM à laquelle appartient cette image sous forme de code EPSG, commeEPSG:32610.year: année couverte par l'image.utm_zone: zone UTM de l'image, par exemple10N.utm_west,utm_south,utm_east,utm_north: limites UTM du tableau de pixels bruts. Cela ne reflète aucun traitement de la géométrie et inclut tous les pixels, qu'ils soient valides ou non.wgs84_west,wgs84_south,wgs84_east,wgs84_north: longitude et latitude minimales et maximales de la géométrie WGS84.
Traitement de la géométrie
Le tableau de pixels est nativement dans une zone UTM. Dans cette zone UTM, le cadre de sélection du tableau de pixels est un simple rectangle. Ce cadre de délimitation est transformé en polygone dans WGS84. Ce polygone inclut un certain nombre de points supplémentaires afin que ses bords suivent de près les lignes courbes dans WGS84 dans lesquelles les lignes droites dans UTM se transforment. Ce polygone ne tient pas compte de la validité des pixels dans l'image, mais uniquement des limites du tableau de pixels de l'image.
Le polygone est ensuite coupé aux longitudes minimales et maximales de la zone UTM de l'image. En pratique, il peut arriver que l'outil n'inclue pas quelques pixels valides qui dépassent les limites de la zone UTM. L'omission de ces pixels dans l'index ne devrait pas poser de problème : une image de la zone UTM voisine devrait couvrir cette zone.
Notez que le clipping à la longitude minimale et maximale de la zone UTM signifie qu'aucun polygone ne traverse l'antiméridien, ce qui devrait simplifier un peu le traitement de ce fichier.