Se você trabalha com imagens de satélite, ortofotos, modelos digitais de elevação ou qualquer outro tipo de dado raster, provavelmente já encontrou arquivos GeoTIFF.

O problema aparece quando esse arquivo começa a ficar grande.

Um raster de alguns gigabytes pode funcionar perfeitamente no seu computador. Mas quando colocamos esse mesmo arquivo em um servidor ou em um armazenamento em nuvem e queremos acessá-lo pela internet, surge uma pergunta:

Eu realmente preciso baixar o arquivo inteiro para visualizar apenas uma pequena área dele?

A resposta, com um Cloud Optimized GeoTIFF (COG), é: não.

Um COG é, de forma simplificada, um GeoTIFF organizado de uma maneira que permite acessar apenas as partes necessárias do raster, sem precisar baixar o arquivo inteiro.

E é justamente essa organização que torna o COG tão interessante para aplicações geoespaciais modernas.

O que é um Cloud Optimized GeoTIFF?

COG significa:

Cloud Optimized GeoTIFF

Em português, podemos traduzir livremente como:

GeoTIFF otimizado para a nuvem.

Mas existe um detalhe importante:

COG não é um novo formato de arquivo completamente diferente do GeoTIFF.

Ele continua sendo um GeoTIFF.

A diferença está principalmente na forma como os dados são organizados dentro do arquivo.

Um COG utiliza recursos como:

• armazenamento em tiles;
• compressão;
• overviews;
• organização interna do arquivo;
• acesso parcial via HTTP Range Requests.

Essa combinação permite que softwares compatíveis solicitem somente os bytes necessários de um arquivo remoto.

Imagine uma imagem de satélite de 20 GB cobrindo todo o estado de São Paulo.

Você está interessado em uma área de apenas 5 km × 5 km.

Em um arquivo tradicional, dependendo da organização do raster e do software utilizado, pode ser necessário transferir uma quantidade enorme de dados para conseguir acessar aquela pequena região.

Em um COG, o software pode identificar quais tiles contêm a região desejada e solicitar somente aqueles pedaços do arquivo.

É aí que está a grande vantagem.

Mas como isso funciona?

Existem três conceitos fundamentais para entender um COG:

1. Tiles
2. Overviews
3. HTTP Range Requests

Vamos por partes.

1. Tiles: dividindo a imagem em pequenos blocos

Imagine uma imagem com:

20.000 × 20.000 pixels

Se ela estiver organizada como uma grande sequência contínua de pixels, acessar uma pequena região pode exigir a leitura de uma quantidade muito maior de dados do que realmente precisamos.

Um COG divide a imagem em pequenos blocos, chamados de tiles.

Por exemplo:

Se precisamos acessar uma região que está em apenas dois tiles, o software pode buscar somente esses dois blocos.

O princípio parece simples, mas ele muda completamente a forma como um raster pode ser acessado remotamente.

O tamanho do tile importa — e muito

Aqui existe uma escolha que costuma passar despercebida:

Qual deve ser o tamanho dos tiles?

É comum encontrar valores como:

128 × 128
256 × 256
512 × 512
1024 × 1024

E não existe um tamanho universalmente perfeito para todos os dados.

O tamanho do tile representa um compromisso entre:

quantidade de requisições × quantidade de dados transferidos.

Tiles muito pequenos

Imagine que você escolha: 128 × 128

A imagem será dividida em uma quantidade muito grande de pequenos blocos.

Isso pode ser interessante quando as consultas são extremamente localizadas.

Porém, existe um problema.

Para acessar uma determinada região, o software pode precisar fazer muitas requisições HTTP.

Se cada requisição possui um pequeno custo de latência, milhares de pequenas requisições podem acabar sendo mais lentas do que algumas requisições maiores.

Ou seja:

Tile pequeno demais pode reduzir a quantidade de dados transferidos, mas aumentar o número de requisições.

E tiles muito grandes?

Agora imagine: 1024 × 1024 ou até maiores.

Nesse caso, cada requisição traz uma quantidade muito maior de dados.

Se você precisa de apenas uma pequena área dentro daquele tile, pode acabar baixando muitos pixels que não serão utilizados.

Portanto:

Tile grande demais pode reduzir o número de requisições, mas aumentar a quantidade de dados transferidos.

E isso também pode deixar determinadas operações mais lentas.

Então qual tamanho usar?

Um valor muito comum e um excelente ponto de partida é: 256 × 256 ou 512 × 512.

O GDAL utiliza 512 pixels como valor padrão de BLOCKSIZE para o driver COG em versões atuais, mas o tamanho adequado depende do tipo de dado e do padrão de acesso.

Na prática, vale pensar assim:

Não existe uma regra dizendo que 512 é sempre melhor que 256, ou vice-versa.

O melhor tamanho depende de como o raster será utilizado.

Se os usuários acessam pequenas áreas aleatórias, tiles menores podem fazer sentido.

Se o uso envolve grandes regiões ou processamento sequencial, tiles maiores podem ser mais eficientes.

2. Overviews: o “zoom out” do raster

Agora imagine que você esteja visualizando uma imagem de satélite de alta resolução.

A imagem original possui: 20.000 × 20.000 pixels

Mas você está visualizando o estado inteiro na tela.

Não faria muito sentido carregar os 400 milhões de pixels originais para mostrar uma imagem de apenas 1.000 pixels de largura.

Por isso existem as overviews.

Uma overview é uma versão reduzida da imagem.

Por exemplo:

Quando você está afastado da imagem, o software pode utilizar uma overview em vez do raster original.

Isso reduz drasticamente a quantidade de dados que precisa ser lida.

As overviews aumentam um pouco o tamanho final do arquivo, mas podem tornar a visualização remota muito mais eficiente.

3. HTTP Range Requests

Aqui está a terceira peça do quebra-cabeça.

Imagine que o COG tenha: imagem.tif com 5 GB.

Ele está hospedado em um servidor: https://servidor.com/imagem.tif

Um software compatível não precisa necessariamente baixar 5GB.

Ele pode fazer uma requisição solicitando apenas uma determinada faixa de bytes do arquivo.

Por exemplo, conceitualmente: “Me envie os bytes 10000000 até 12000000”

O servidor retorna somente aquela parte.

Esse mecanismo é conhecido como HTTP Range Request.

O COG foi organizado justamente para que o cliente consiga localizar onde estão os dados que precisa e fazer essas requisições parciais.

Portanto, podemos resumir:

COG não significa simplesmente “GeoTIFF na nuvem”

Esse é um erro bastante comum.

Colocar: imagem.tif em um bucket S3, Google Cloud Storage ou qualquer servidor web não transforma automaticamente o arquivo em COG.

Você precisa criar o GeoTIFF seguindo uma organização apropriada.

Além disso, para aproveitar o acesso remoto, o servidor precisa suportar as requisições HTTP Range.

Por isso existem duas partes:

1. Organizar corretamente o GeoTIFF

e

2. Disponibilizá-lo em um ambiente que permita acesso parcial ao arquivo.

Criando um COG com GDAL

A partir do GDAL 3.1, existe um driver específico para criação de COG.

Isso tornou o processo bastante simples.

Imagine que temos: imagem.tif

Podemos gerar: imagem_cog.tif

com:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE

O próprio driver COG cuida de vários aspectos da organização necessária, incluindo tiling e criação de overviews.

Escolhendo o tamanho dos tiles

Podemos definir o tamanho do tile com:

-co BLOCKSIZE=512

Por exemplo:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=512

Ou:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=256

Para começar, eu testaria: 256 e 512, principalmente em rasters grandes.

Depois compararia:

• tamanho do arquivo;
• tempo de criação;
• tempo de leitura;
• número de requisições;
• comportamento no QGIS;
• comportamento no processamento remoto.

Escolhendo a compressão

Outro parâmetro importante é:

-co COMPRESS=DEFLATE

O DEFLATE é uma opção interessante quando queremos compressão sem perdas.

Para dados científicos, como:

• modelos digitais de elevação;
• índices espectrais;
• classificações;
• dados de reflectância;

é importante tomar cuidado com compressões com perdas.

Para imagens RGB, ortofotos e determinados produtos de visualização, JPEG pode ser uma opção interessante.

Por exemplo:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=JPEG \
    -co QUALITY=90

Aqui existe uma diferença importante:

JPEG é uma compressão com perdas.

Portanto, ela pode diminuir bastante o tamanho do arquivo, mas modifica os valores dos pixels.

Para uma ortofoto utilizada principalmente para visualização, isso pode ser aceitável.

Para uma análise científica, pode não ser.

E para um raster Float32?

Imagine um modelo digital de elevação:

dem.tif

com pixels Float32.

Uma opção comum seria:

gdal_translate dem.tif dem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=512

Para determinados dados, também pode fazer sentido testar:

-co COMPRESS=ZSTD

por exemplo:

gdal_translate dem.tif dem_cog.tif \
    -of COG \
    -co COMPRESS=ZSTD \
    -co BLOCKSIZE=512

O importante é testar com os seus dados.

A melhor compressão depende bastante do conteúdo do raster.

E se eu já tiver um GeoTIFF com overviews?

Também é possível trabalhar a partir de um raster que já possui overviews.

O driver COG possui opções para controlar como elas serão utilizadas ou geradas.

Em muitos casos, porém, é mais simples deixar o driver COG fazer esse trabalho.

Por exemplo:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=512 \
    -co OVERVIEWS=AUTO

O AUTO permite ao driver decidir os níveis de overview necessários.

O GDAL também oferece opções para controlar a compressão e a qualidade das overviews.

Como verificar se o arquivo é realmente um COG?

Não basta olhar para a extensão:

.tif

Existem ferramentas específicas para validar a organização do arquivo.

Uma opção bastante conhecida é:

rio cogeo validate imagem_cog.tif

quando o rio-cogeo está instalado.

Também podemos utilizar as ferramentas do próprio GDAL para inspecionar o arquivo:

gdalinfo imagem_cog.tif

Procure principalmente informações relacionadas a:

• tamanho dos blocos;
• overviews;
• compressão;
• número de bandas;
• sistema de referência;
• tamanho do raster.

Por exemplo:

gdalinfo imagem_cog.tif

pode mostrar algo semelhante a:

Size is 20000, 20000

Band 1 Block=512x512 Type=UInt16
  Overviews: 10000x10000, 5000x5000, 2500x2500, ...

Isso já nos dá uma boa indicação de como o arquivo está estruturado.

Como abrir um COG remoto com GDAL?

Agora vem uma das partes mais interessantes.

Imagine que nosso arquivo esteja em:

https://meuservidor.com/imagem_cog.tif

O GDAL pode acessar o arquivo através do /vsicurl/.

Por exemplo:

gdalinfo /vsicurl/https://meuservidor.com/imagem_cog.tif

O /vsicurl/ permite que o GDAL trate uma URL HTTP como uma fonte de dados.

Isso é extremamente útil para trabalhar com COGs sem necessariamente baixar o arquivo inteiro.

Extraindo apenas uma área de um COG remoto

Suponha que exista um COG gigantesco na internet.

Queremos apenas uma pequena área dele.

Podemos utilizar:

gdal_translate \
    /vsicurl/https://meuservidor.com/imagem_cog.tif \
    recorte.tif \
    -projwin xmin ymax xmax ymin

Por exemplo:

gdal_translate \
    /vsicurl/https://meuservidor.com/imagem_cog.tif \
    recorte.tif \
    -projwin -48.50 -27.40 -48.30 -27.60

O exemplo acima é apenas ilustrativo: as coordenadas precisam estar no sistema de referência utilizado pelo raster.

O ponto importante é que um COG permite que o GDAL busque somente as partes necessárias para realizar a operação, em vez de obrigatoriamente transferir o arquivo inteiro.

COG e QGIS

Uma das vantagens do COG é justamente a compatibilidade com ferramentas GIS existentes.

Um COG continua sendo um GeoTIFF.

Portanto, em muitos casos, basta adicionar o arquivo ao QGIS como você faria com qualquer outro raster.

Se o arquivo estiver hospedado remotamente e o fluxo utilizado pelo QGIS/GDAL suportar acesso HTTP ao COG, é possível trabalhar com os dados sem fazer um download tradicional do arquivo inteiro.

Isso abre possibilidades interessantes para:

• catálogos de imagens;
• servidores de dados;
• plataformas de sensoriamento remoto;
• processamento em nuvem;
• grandes mosaicos;
• infraestrutura de dados geoespaciais.

O COG é justamente interessante porque combina uma estrutura moderna de acesso remoto com um formato tradicional e amplamente suportado.

Quais são as vantagens de um COG?

1. Acesso parcial ao arquivo

Essa é provavelmente a principal vantagem.

Você não precisa necessariamente baixar um raster de vários gigabytes para acessar uma pequena área.

2. Excelente para armazenamento em nuvem

COGs funcionam muito bem em serviços de armazenamento de objetos, como:

• Amazon S3;
• Google Cloud Storage;
• Azure Blob Storage.

Esses ambientes normalmente suportam o mecanismo de Range Requests necessário para esse tipo de acesso.

3. Menor transferência de dados

Se você precisa de apenas uma pequena região, pode transferir somente uma fração do arquivo.

Isso pode significar:

menos dados → menos tempo → menos banda utilizada.

Em ambientes de nuvem, isso também pode representar economia dependendo da arquitetura e dos custos de transferência.

4. Overviews aceleram a visualização

Quando você está olhando uma área muito grande, o software pode utilizar uma overview em vez do raster original.

Isso evita ler milhões ou bilhões de pixels desnecessariamente.

5. Continua sendo GeoTIFF

Essa talvez seja uma das características mais interessantes.

Você não precisa abandonar completamente o ecossistema GeoTIFF.

Softwares tradicionais podem continuar tratando o COG como um GeoTIFF.

Softwares preparados para COG podem aproveitar as vantagens do acesso remoto.

Mas COG também tem desvantagens

Nenhum formato resolve todos os problemas.

1. Criar o COG pode exigir processamento

Para gerar:

• tiles;
• compressão;
• overviews;

o GDAL precisa processar o raster.

Em imagens muito grandes, isso pode consumir bastante:

• CPU;
• memória;
• tempo;
• armazenamento temporário.

2. O arquivo pode ficar maior

As overviews ocupam espaço.

Portanto:

GeoTIFF original
↓
COG + overviews

não significa necessariamente:

COG = arquivo menor

O arquivo pode ficar maior em alguns casos.

O ganho principal do COG não é simplesmente “diminuir o tamanho do arquivo”.

É:

diminuir a quantidade de dados que precisa ser transferida para realizar determinada operação.

Essa diferença é fundamental.

3. Compressão com perdas pode ser perigosa

Usar:

COMPRESS=JPEG

pode reduzir bastante o tamanho do arquivo.

Mas JPEG é uma compressão com perdas.

Isso pode ser perfeitamente aceitável para visualização de uma ortofoto, mas pode ser inadequado para dados analíticos.

Por isso, sempre pense primeiro:

Esse raster é para visualização ou para análise?

4. Tiles mal dimensionados podem prejudicar o desempenho

Esse é um dos detalhes mais importantes.

Não adianta simplesmente pensar:

“Vou colocar tiles de 128 × 128 porque são pequenos.”

Nem:

“Vou colocar 2048 × 2048 porque quero reduzir o número de requisições.”

Existe um equilíbrio.

Tile pequeno demais

Muitos tiles
       ↓
Muitas requisições
       ↓
Mais overhead e latência

Tile grande demais

Poucos tiles
       ↓
Mais dados por requisição
       ↓
Transferência desnecessária

O objetivo é encontrar um tamanho adequado ao padrão de acesso.

Uma configuração inicial razoável

Se você está começando, uma configuração simples seria:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=512

Para dados em que 256 × 256 seja mais adequado:

gdal_translate imagem.tif imagem_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=256

Depois, compare os resultados.

Não existe uma configuração mágica que seja melhor para todos os rasters.

Um exemplo mais completo

Imagine que temos uma imagem Sentinel-2 já preparada:

sentinel.tif

Queremos criar um COG com compressão DEFLATE e tiles de 512 pixels:

gdal_translate \
    sentinel.tif \
    sentinel_cog.tif \
    -of COG \
    -co COMPRESS=DEFLATE \
    -co BLOCKSIZE=512

Depois:

gdalinfo sentinel_cog.tif

E podemos verificar os blocos e overviews.

Para acessar remotamente:

gdalinfo \
    /vsicurl/https://meuservidor.com/sentinel_cog.tif

E para gerar um recorte:

gdal_translate \
    /vsicurl/https://meuservidor.com/sentinel_cog.tif \
    recorte.tif \
    -projwin xmin ymax xmax ymin

Esse é um fluxo bastante poderoso:

Imagem original
       ↓
     GDAL
       ↓
      COG
       ↓
   Cloud Storage
       ↓
  /vsicurl/
       ↓
 somente os dados
 necessários

COG não é apenas sobre “ficar na nuvem”

Esse é talvez o conceito mais importante para guardar.

O nome Cloud Optimized GeoTIFF pode dar a impressão de que estamos falando apenas de colocar um .tif na nuvem.

Não é isso.

O COG é sobre organizar o GeoTIFF para que ele possa ser acessado eficientemente de forma remota.

Para isso, entram em cena:

E é essa combinação que faz a diferença.

Conclusão

O Cloud Optimized GeoTIFF não é simplesmente um “GeoTIFF menor”.

Ele é um GeoTIFF organizado para ser acessado de maneira eficiente, especialmente quando está armazenado remotamente.

A ideia central é bastante simples:

Em vez de baixar a imagem inteira para obter uma pequena parte dela, o software busca somente os pedaços necessários.

Para isso, o COG combina:

• tiles, para dividir o raster;
• overviews, para trabalhar com versões reduzidas;
• compressão, para diminuir a quantidade de dados;
• organização interna, para facilitar a localização dos dados;
• HTTP Range Requests, para transferir somente partes do arquivo.

E existe um detalhe que merece atenção especial:

O tamanho dos tiles é uma decisão de desempenho.

Tiles muito pequenos podem gerar requisições demais.

Tiles muito grandes podem transferir dados demais.

Por isso, valores como 256 × 256 ou 512 × 512 pixels são bons pontos de partida, mas a escolha deve considerar o tipo de raster e, principalmente, como os dados serão acessados.

No final, a grande mudança de paradigma é esta:

antes:

Tenho um raster → preciso baixar o raster

com COG:

Tenho um raster remoto
        ↓
sei onde estão os dados
        ↓
peço apenas o que preciso
        ↓
processo/visualizo remotamente

É por isso que COG se tornou uma peça importante da moderna infraestrutura de dados geoespaciais.

E talvez a melhor maneira de entender seu potencial seja pensar em uma imagem de 100 GB.

Se você precisa de 1% dela, por que deveria baixar os outros 99%?

Essa é a ideia do Cloud Optimized GeoTIFF.