Données GCS AlphaEarth Foundations

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 à 2024 incluses.

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 mises en correspondance avec les valeurs natives (dans la plage [-1, 1]) des embeddings est décrite ci-dessous.

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 décrit ci-dessus, ce fichier fait partie de l'intégration annuelle de 2019 et se trouve dans 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 résultants 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());

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 le calcul de cette géométrie, consultez la section ci-dessous.
  • crs : CRS de la zone UTM à laquelle appartient cette image sous forme de code EPSG, comme EPSG:32610.
  • year : année couverte par l'image.
  • utm_zone : zone UTM de l'image, par exemple 10N.
  • 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/maximales de la géométrie WGS84.

Traitement de la géométrie

La matrice de pixels se trouve nativement dans une zone UTM. Dans cette zone, le cadre de sélection de la matrice 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 de WGS84 dans lesquelles se transforment les lignes droites d'UTM. Ce polygone ne tient pas compte de la validité/invalidité des pixels de l'image, mais uniquement des limites du tableau de pixels de l'image.

Le polygone est ensuite découpé selon la longitude minimale et maximale de la zone UTM de l'image. En pratique, cela peut entraîner l'exclusion de quelques pixels valides qui dépassent 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/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.