В хранилище GCS по gs://alphaearth_foundations хранятся файлы COG (Cloud Optimized GeoTIFF), которые вместе составляют ежегодный набор данных спутниковых встраиваний AlphaEarth Foundation. Он содержит ежегодные встраивания за период с 2017 по 2025 год включительно.
Компания Google обязуется продолжать ежегодное создание слоев спутниковых данных и будет уведомлять о любых ожидаемых изменениях в сроках их предоставления как минимум за год вперед, при условии постоянной доступности входных потоков данных от USGS и ESA, на которые опирается производство набора данных.
Лицензия
Данный набор данных распространяется под лицензией CC-BY 4.0 и требует указания следующего авторского права: « Набор данных AlphaEarth Foundations Satellite Embedding создан компаниями Google и Google DeepMind».
Данный сегмент настроен по принципу «платит за запрос», поэтому загрузка данных может повлечь за собой исходящие и другие сборы.
Структура каталогов
Они разделены на каталоги по годам; каталог каждого года разделен на 120 подкаталогов, по одному на каждую зону UTM, названия которых отражают номер зоны и полушарие ( N или S ).
В каждой директории находится несколько COG-файлов. Эти файлы содержат все пиксельные данные для данной зоны UTM.
Структура файлов
Каждый файл имеет размер 8192x8192 пикселей и содержит 64 канала. Величина каждого пикселя после применения преобразования в квантовое представление (см. ниже) была нормализована таким образом, чтобы его евклидова длина составляла 1.
Файлы содержат обзорные слои размером 4096x4096 пикселей, 2048x2048 пикселей и так далее, вплоть до верхнего обзорного слоя размером 1x1. Эти обзорные слои построены таким образом, что каждый обзорный пиксель представляет собой среднее значение пикселей с самым высоким разрешением под этим обзорным пикселем, причем величина среднего значения нормализована и имеет длину 1.
Каналы соответствуют, в порядке следования, осям от A00 до A63 набора данных Satellite Embedding. В координатах центра тяжести (COG) также содержится это обозначение для каналов.
Значение каждого пикселя для каждого канала представляет собой знаковое 8-битное целое число. Способ преобразования этих значений в исходные значения (в диапазоне [-1, 1]) эмбеддингов описан в разделе «Деквантизация» .
Значение -128 соответствует замаскированному пикселю. Если он присутствует в одном канале, он будет присутствовать во всех каналах. Это отражают COG (т.е. для них установлено значение NoData -128).
Название каждого файла также содержит некоторую информацию. Например, рассмотрим файл с именем gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff . Как видно из имени файла, этот файл является частью ежегодного встраивания 2019 года для зоны UTM 1S (зона 1, южное полушарие). Базовое имя файла, x8qqwcsisbgygl2ry-0000008192-0000000000 , служит для связи этого файла с соответствующим именем изображения спутникового встраивания Earth Engine. В этом примере этот файл соответствует части изображения Earth Engine GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry . Две десятичные части имени файла указывают положение значений центра тяжести (ЦТ) относительно изображения, полученного с помощью Earth Engine, в виде смещения по оси Y, за которым следует смещение по оси X. В данном случае начало координат пикселя ЦТ находится в точке (0, 8192) относительно начала координат изображения Earth Engine. Это связано с тем, что каждое изображение Earth Engine (размером 16384x16384 пикселей) было необходимо разделить, чтобы результирующие значения ЦТ не были слишком громоздкими.
Деквантизация
Для преобразования исходного знакового 8-битного значения (которое будет находиться в диапазоне от -127 до 127 включительно, поскольку -128 зарезервировано как значение «нет данных») в каждом канале каждого пикселя в готовое к анализу значение с плавающей запятой (которое будет находиться в диапазоне от -1 до 1), необходимо выполнить следующее отображение:
- разделить на 127,5
- квадрат
- умножить на знак исходного значения
В NumPy это можно выразить следующим образом:
# values is a NumPy array of raw pixel values
de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)
В Earth Engine соответствующая операция выглядела бы так:
var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());
Создание пирамид с пониженной дискретизацией
Если вы намереваетесь создать собственные уменьшенные версии или внешние обзоры на основе базового слоя разрешения этих COG (например, после объединения нескольких файлов), необходимо использовать следующую процедуру. Стандартные методы пирамидирования растровых изображений (например, использование gdaladdo с параметром -r average для исходных целочисленных значений) не дадут корректных результатов.
- Деквантизация: преобразование исходных 8-битных целых чисел в числа с плавающей запятой с использованием метода, описанного в разделе «Деквантизация» .
- Суммирование векторов: Выполнить поэлементное суммирование деквантованных векторов.
- Нормализация: Вычислите евклидову норму полученного вектора суммы и разделите её на норму, чтобы повторно нормализовать его до единичной длины.
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.
Обзорные слои в координатах центра тяжести были сгенерированы с использованием этой процедуры; если они соответствуют вашим потребностям, вы можете сразу же использовать эти обзорные слои без каких-либо дополнительных вычислений.
Манифест и указатель
Список файлов в этом наборе данных можно найти по gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt .
Поскольку по именам файлов невозможно определить, к какому региону мира они относятся, был также предоставлен индекс в трех форматах (GeoParquet, GeoPackage и CSV) в файлах gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet , gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg и gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv . Этот индекс содержит одну запись для каждого файла в наборе данных. Информация, предоставленная для каждого файла, включает в себя:
- Геометрия файла представлена в виде полигона WGS84 (т.е. EPSG:4326). В формате CSV она находится в столбце
WKT. Подробности вычислений см. в разделе «Обработка геометрии» . -
crs: Система координат зоны UTM, к которой относится это изображение, в виде кода EPSG, например,EPSG:32610. -
year: Год, который охватывает изображение. -
utm_zone: UTM-зона изображения, например,10N. -
utm_west,utm_south,utm_east,utm_north: Границы UTM исходного массива пикселей. Это не отражает никакой обработки геометрии и включает все пиксели, независимо от того, являются ли они допустимыми или нет. -
wgs84_west,wgs84_south,wgs84_east,wgs84_north: Минимальная и максимальная долгота и широта геометрии WGS84.
Обработка геометрии
Массив пикселей изначально находится в некоторой зоне UTM, поэтому в этой зоне UTM ограничивающий прямоугольник массива пикселей представляет собой простой прямоугольник. Этот ограничивающий прямоугольник преобразуется в многоугольник в системе координат WGS84. Этот многоугольник включает в себя ряд дополнительных точек, так что его края точно следуют криволинейным линиям в системе WGS84, в которые преобразуются прямые линии в системе UTM. Этот многоугольник не учитывает корректность пикселей изображения, а только границы массива пикселей изображения.
Затем многоугольник обрезается по минимальной и максимальной долготе зоны UTM изображения. На практике это может привести к тому, что он не будет включать несколько допустимых пикселей, выходящих за пределы зоны UTM. Исключение этих пикселей из индекса не должно вызывать проблем: какая-либо часть изображения из соседней зоны UTM должна покрывать эту область.
Обратите внимание, что обрезка по минимальной и максимальной долготе зоны UTM означает, что ни один полигон не пересекает антимидий, что должно немного упростить обработку этого файла.