Dados do GCS do AlphaEarth Foundations

O bucket do GCS gs://alphaearth_foundations contém arquivos COG (Cloud Optimized GeoTIFF) que juntos formam o conjunto de dados anual Satellite Embedding do AlphaEarth Foundations. Ele contém os embeddings anuais dos anos de 2017 a 2024, inclusive.

Licença

Esse conjunto de dados está licenciado de acordo com a CC-BY 4.0 e exige o seguinte texto de atribuição: "O conjunto de dados de incorporação de satélite da AlphaEarth Foundations foi produzido pelo Google e pelo Google DeepMind".

Esse bucket está configurado como "pagamento pelo solicitante", então o download de dados pode gerar custos de saída e outras cobranças.

Estrutura do diretório

Eles são divididos em diretórios por ano. Cada diretório anual é dividido em 120 subdiretórios, um por zona UTM, cujos nomes refletem o número da zona e o hemisfério (N ou S).

Em cada diretório, há vários arquivos COG. Esses arquivos contêm todos os dados de pixel dessa zona UTM.

Estrutura do arquivo

Cada arquivo tem 8192 x 8192 pixels, com 64 canais. A magnitude de cada pixel, depois que o mapeamento de desquantização é aplicado (veja abaixo), é normalizada para ter um comprimento euclidiano de 1.

Os arquivos contêm camadas de visão geral em 4096 x 4096 pixels, 2048 x 2048 pixels e assim por diante, até uma camada de visão geral de nível superior de 1 x 1. Essas camadas de visão geral são construídas para que cada pixel seja a média dos pixels de maior resolução abaixo dele, e a magnitude da média é normalizada para ter comprimento 1.

Os canais correspondem, em ordem, aos eixos A00 a A63 do conjunto de dados de incorporação de satélite. O CPV também contém esse nome para os canais.

O valor de cada pixel para cada canal é um número inteiro de 8 bits com sinal. A maneira como esses valores são mapeados para os valores nativos (no intervalo [-1, 1]) das incorporações é descrita abaixo.

O valor -128 corresponde a um pixel mascarado. Se ele estiver presente em um canal, vai estar em todos. O COGs reflete isso (ou seja, tem o valor NoData definido como -128).

O nome de cada arquivo também contém algumas informações. Por exemplo, considere o arquivo chamado gs://alphaearth_foundations/satellite_embedding/v1/annual/2019/1S/x8qqwcsisbgygl2ry-0000008192-0000000000.tiff. Conforme descrito acima, esse arquivo faz parte da incorporação anual de 2019 e está na zona UTM 1S (zona 1, hemisfério sul). O nome de arquivo base, x8qqwcsisbgygl2ry-0000008192-0000000000, vincula esse arquivo ao nome da imagem de incorporação de satélite correspondente do Earth Engine. Neste exemplo, esse arquivo corresponde a uma parte da imagem do Earth Engine GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL/x8qqwcsisbgygl2ry. As duas partes decimais do nome do arquivo especificam onde os valores desse COG estão em relação à imagem do Earth Engine, como um deslocamento em Y seguido por um deslocamento em X. Nesse caso, a origem do pixel do COG é (0, 8192) em relação à origem da imagem do Earth Engine. Isso foi necessário para subdividir cada imagem do Earth Engine (16384 x 16384 pixels) para que os COGs resultantes não ficassem muito grandes.

Desquantização

Para transformar o valor bruto de 8 bits com sinal (que estará entre -127 e 127, já que -128 é reservado como o valor "sem dados") em cada canal de cada pixel no valor de ponto flutuante pronto para análise (que estará entre -1 e 1), o mapeamento a ser realizado é

  • divida por 127,5
  • quadrado
  • multiplicar pelo sinal do valor original

Isso seria expresso em NumPy como

  # values is a NumPy array of raw pixel values
  de_quantized_values = ((values / 127.5) ** 2) * np.sign(values)

No Earth Engine, a operação correspondente seria

  var de_quantized_values = values.divide(127.5).pow(2).multiply(values.signum());

Manifesto e índice

Uma lista dos arquivos nesse conjunto de dados pode ser encontrada em gs://alphaearth_foundations/satellite_embedding/v1/annual/manifest.txt.

Como não é possível determinar pelos nomes dos arquivos qual área do mundo eles abrangem, também foi fornecido um índice em três formatos (GeoParquet, GeoPackage e CSV) nos arquivos gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.parquet, gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.gpkg e gs://alphaearth_foundations/satellite_embedding/v1/annual/aef_index.csv. Esse índice contém uma entrada para cada arquivo no conjunto de dados. As informações fornecidas para cada arquivo são

  • a geometria do arquivo como WGS84 (ou seja, EPSG:4326). No formulário CSV, essa informação está na coluna WKT. Confira abaixo detalhes sobre como essa geometria é calculada.
  • crs: o CRS da zona UTM a que esta imagem pertence como um código EPSG, como EPSG:32610.
  • year: o ano que a imagem abrange.
  • utm_zone: a zona UTM da imagem, como 10N.
  • utm_west, utm_south, utm_east, utm_north: os limites de UTM da matriz de pixels bruta. Isso não reflete nenhum processamento de geometria e inclui todos os pixels, válidos ou não.
  • wgs84_west, wgs84_south, wgs84_east, wgs84_north: a longitude e a latitude mínimas/máximas da geometria WGS84.

Processamento de geometria

A matriz de pixels está nativamente em alguma zona UTM. Portanto, nessa zona, a caixa delimitadora da matriz é um retângulo simples. Essa caixa delimitadora é transformada em um polígono no WGS84. Esse polígono inclui vários pontos extras para que as bordas sigam de perto as linhas curvas no WGS84 em que as linhas retas no UTM se transformam. Esse polígono não considera a validade/invalidade dos pixels na imagem, apenas os limites da matriz de pixels da imagem.

Em seguida, o polígono é cortado para a longitude mínima e máxima da zona UTM da imagem. Na prática, isso pode fazer com que ele não inclua alguns pixels válidos que ficam na borda da zona UTM. Omitir esses pixels do índice não causa problemas: alguma imagem da zona UTM vizinha cobre essa área.

O corte para a longitude mínima/máxima da zona UTM significa que nenhum polígono cruza o antimeridiano, o que simplifica um pouco o processamento desse arquivo.