Durante muitos anos, trabalhar com imagens de satélite e grandes rasters seguia praticamente o mesmo roteiro: localizar o arquivo em algum portal, baixar centenas de megabytes ou alguns gigabytes, descompactar, organizar as pastas e finalmente abrir os dados no QGIS ou ArcGIS e ai começar o fusionamento e tudo mais.
Esse modelo ainda existe, mas começa a ficar ultrapassado para muitos tipos de dados.
Duas tecnologias vêm mudando bastante essa rotina nos últimos anos: COG, ou Cloud Optimized GeoTIFF, e STAC, ou SpatioTemporal Asset Catalog.
Os nomes parecem complicados, mas a ideia é simples:
STAC ajuda a encontrar o dado. COG permite usar o dado diretamente onde ele está armazenado.
E ambos já podem ser usados em ferramentas comuns como QGIS, ArcGIS Pro, GDAL e diversas aplicações WebGIS.
O que é um COG?
Um Cloud Optimized GeoTIFF continua sendo um arquivo GeoTIFF (com extensão .tif.)
A diferença está em como o conteúdo é organizado internamente.
Um GeoTIFF tradicional geralmente foi pensado para ser lido como um arquivo local. Se ele tem vários gigabytes e está disponível em um servidor, normalmente fazemos o download antes de trabalhar com ele.
O COG organiza a imagem internamente em blocos e inclui níveis de visualização reduzidos, conhecidos como overviews. Além disso, ele foi projetado para funcionar com requisições HTTP que permitem buscar somente determinadas partes do arquivo.
Na prática, um programa compatível pode solicitar apenas os blocos correspondentes à região que está sendo visualizada, em vez de baixar a imagem inteira.
Imagine uma imagem de cobertura da terra cobrindo um país inteiro.
O arquivo pode ter vários gigabytes, mas você quer analisar apenas uma propriedade de 500 hectares. Com um COG disponível em um servidor adequado, o software pode acessar somente os trechos necessários para aquela área.
Esse conceito faz muita diferença quando trabalhamos com mosaicos continentais ou globais.
Mas então o COG fica “na nuvem”?
Não necessariamente em alguma plataforma específica.
Um COG pode estar em:
Amazon S3, Microsoft Azure, Google Cloud Storage, servidores HTTP comuns ou outros sistemas capazes de atender corretamente às solicitações de partes do arquivo.
A grande vantagem é que o usuário não precisa conhecer toda essa infraestrutura.
Para o GIS, muitas vezes o arquivo simplesmente aparece como um raster remoto.
E como ele continua sendo um GeoTIFF, programas GIS tradicionais conseguem tratá-lo praticamente da mesma maneira que um TIFF local.
E onde entra o STAC?
O problema seguinte é descobrir onde esses arquivos estão.
Imagine um arquivo Landsat para cada data, órbita, sensor e região do planeta. São milhões de objetos.
É aí que entra o STAC.
STAC é um padrão aberto para catalogar dados geoespaciais associados a uma localização e a um período no tempo.
Um registro STAC pode dizer, por exemplo:
Existe uma imagem Landsat 9 adquirida em 15 de julho de 2025, cobrindo esta área, com determinada porcentagem de nuvens, e os arquivos correspondentes estão nestes endereços.
Um STAC Item é essencialmente uma feição GeoJSON acompanhada de informações como data, área coberta, propriedades e links para os arquivos relacionados. Os itens podem ser agrupados em Collections, e uma STAC API permite pesquisar esses dados por área, data e outros atributos.
Ou seja, não precisamos mais navegar manualmente por milhares de pastas procurando arquivos.
Podemos perguntar ao catálogo:
Quais imagens Sentinel-2 existem para esta propriedade entre junho e agosto de 2025?
O catálogo retorna os itens correspondentes.
STAC + COG é onde a coisa fica interessante
As duas tecnologias resolvem problemas diferentes.
O STAC organiza e localiza os dados.
O COG entrega os pixels necessários.
Esse conjunto permite um fluxo de trabalho bastante diferente do tradicional:
GIS → pesquisa no catálogo STAC → encontra a imagem → acessa o COG remotamente → lê somente a área necessária.
Não é preciso obrigatoriamente baixar a cena inteira.
Esse modelo já é usado por grandes catálogos de dados geoespaciais e está ficando cada vez mais comum em sensoriamento remoto. Inclusive o INPE está usando como falamos aqui.
Como usar COG no QGIS
O QGIS utiliza GDAL para leitura de boa parte dos formatos raster e já consegue trabalhar com rasters disponíveis através de HTTP e serviços de armazenamento remoto.
No Gerenciador de Fontes de Dados, a opção de raster permite usar fontes do tipo Protocol: HTTP(S), cloud, etc., dependendo da versão instalada.
Se você tiver a URL direta de um COG público, pode usá-la como fonte raster sem necessariamente salvar o arquivo inteiro no computador.
Por exemplo, em vez de:
C:\imagens\landsat_2025.tifa origem pode estar em algo como:
https://servidor.exemplo.org/imagens/landsat_2025.tifSe o arquivo for um COG corretamente preparado e o servidor aceitar acesso parcial, o QGIS solicita apenas os blocos necessários.
Ao mover ou ampliar o mapa, novos trechos são carregados conforme necessário.
Isso é especialmente útil para DEMs, mosaicos de cobertura da terra e grandes coleções de imagens.
Como acessar STAC no QGIS
Para trabalhar diretamente com catálogos STAC existe o plugin STAC API Browser, disponível no repositório oficial de plugins do QGIS.
Ele permite conectar a uma STAC API, pesquisar os recursos disponíveis, aplicar filtros e carregar os ativos encontrados diretamente no QGIS.
O procedimento básico é abrir o gerenciador de plugins, procurar por STAC API Browser, instalar o plugin e cadastrar o endereço de uma STAC API.
Dois exemplos conhecidos são o Earth Search, da Element 84:
https://earth-search.aws.element84.com/v1e o Microsoft Planetary Computer:
https://planetarycomputer.microsoft.com/api/stac/v1O Earth Search disponibiliza uma API STAC para pesquisa de grandes coleções de observação da Terra.
O Planetary Computer também mantém uma STAC API pública com coleções como Landsat, Sentinel, NAIP e diversos outros conjuntos ambientais.
A disponibilidade do catálogo não significa necessariamente que todos os arquivos tenham exatamente as mesmas regras de acesso. Alguns provedores podem exigir autenticação, assinatura temporária da URL ou outras condições.
STAC no ArcGIS Pro
O suporte também chegou de forma bastante direta ao ArcGIS Pro.
No ArcGIS Pro 3.6, por exemplo, é possível criar uma conexão STAC pelo próprio Catalog.
O caminho é:
Insert → Connections → STAC Connection → New STAC Connection
A conexão fica armazenada em um arquivo .astac.
É possível usar conexões predefinidas ou informar a URL de uma STAC API personalizada. Depois disso, o ArcGIS Pro permite navegar pelas Collections, pesquisar Items e adicionar os ativos encontrados ao mapa, à cena ou a um Mosaic Dataset.
Isso representa uma mudança importante.
O catálogo de imagens deixa de ser uma etapa externa ao GIS e passa a fazer parte do próprio projeto.
E os COGs no ArcGIS Pro?
O ArcGIS Pro também trabalha com rasters armazenados em serviços de nuvem.
Para repositórios como Amazon S3, Azure e outros serviços suportados, podem ser criadas Cloud Storage Connections, armazenadas em arquivos .acs.
No caso de uma conexão STAC, arquivos armazenados publicamente podem ser acessados sem uma conexão .acs. Quando o armazenamento exige autenticação, a conexão com o serviço de nuvem pode ser necessária.
Assim como no QGIS, o objetivo é evitar que o usuário precise transformar seu computador em um depósito de imagens apenas para realizar uma análise.
Também podemos criar nossos próprios COGs
COG não serve apenas para consumir dados públicos.
Uma empresa ou órgão que publica rasters pode converter seus próprios GeoTIFFs para COG.
Com GDAL, por exemplo, a conversão pode ser feita de forma bastante simples:
gdal_translate input.tif output.tif -of COGNas versões mais novas do QGIS 4.x, o provedor GDAL também possui a ferramenta Create Cloud Optimized GeoTIFF, permitindo criar COGs pela interface gráfica.
Depois, esses arquivos podem ser armazenados em um servidor HTTP ou serviço de objetos e disponibilizados para outras aplicações.
Por que isso importa para quem trabalha com GIS florestal?
Sensoriamento remoto sempre trabalhou com volumes grandes de informação.
Uma única propriedade pode ter dezenas de anos de imagens Landsat. Se adicionarmos Sentinel-2, modelos digitais de elevação, mapas anuais de cobertura da terra, dados de fogo e outras fontes, o volume cresce rapidamente.
O modelo tradicional seria baixar tudo.
Com STAC e COG, podemos inverter a lógica.
Primeiro pesquisamos quais dados realmente existem para aquela área e período. Depois acessamos somente os pixels necessários.
Para análises florestais, isso abre caminhos interessantes para séries históricas Landsat, acompanhamento de propriedades rurais, comparação de cobertura da terra, análise de relevo, monitoramento de grandes áreas e sistemas automatizados de processamento.
COG não é simplesmente “um TIFF na internet”
Esse é um detalhe importante.
Colocar um GeoTIFF comum em um servidor Web não o transforma automaticamente em COG.
O arquivo precisa ter uma organização interna apropriada, normalmente com blocos, compressão e overviews.
Da mesma forma, o servidor precisa permitir solicitações parciais do arquivo.
É essa combinação que permite ao programa pedir algo equivalente a:
envie apenas estes blocos do raster.
em vez de:
envie os 8 GB inteiros.
E STAC não é um formato de imagem
Outra confusão comum é pensar que STAC substitui GeoTIFF.
Não substitui.
STAC é o catálogo.
O item STAC aponta para os dados reais, chamados de assets. Esses ativos podem ser COGs, arquivos JSON, metadados, thumbnails ou outros formatos.
Por isso a combinação STAC + COG funciona tão bem: um resolve a descoberta, o outro resolve o acesso eficiente ao raster.
Isso vai substituir o download de imagens?
Não completamente.
Existem situações em que ainda é melhor baixar os dados: processamento intensivo repetitivo, trabalhos offline, arquivamento, análises que percorrem praticamente todos os pixels ou situações em que a conexão de internet é limitada. Tente pesquisar a sua propriedade aqui
Também existe uma diferença grande entre abrir uma pequena área de um COG e processar milhares de imagens completas remotamente.
COG reduz transferências desnecessárias. Ele não elimina o custo de movimentar dados.
Mas para consulta, análise localizada e aplicações que trabalham com áreas pequenas dentro de grandes bases raster, a mudança é significativa.
O GIS está deixando de ser baseado somente em arquivos locais
Talvez essa seja a parte mais importante.
Durante décadas, um projeto GIS começava pela pergunta:
Onde está o arquivo?
Agora começa a ser perfeitamente normal perguntar:
Onde está o catálogo?
O software pesquisa os dados disponíveis, escolhe o que interessa e acessa apenas a parte necessária.
Para quem trabalha com QGIS ou ArcGIS Pro, STAC e COG já não são apenas tecnologias de infraestrutura para programadores. Elas estão chegando diretamente ao ambiente de trabalho do usuário GIS.
E provavelmente veremos cada vez mais bases públicas sendo distribuídas dessa maneira.
O velho GeoTIFF não está desaparecendo.
Na verdade, ele está apenas aprendendo a trabalhar muito melhor pela internet.