Você sabe transformar isso em uma solução acessível na web?

Porque existe uma diferença enorme entre:

Gerar mapas
E entregar uma plataforma que outras pessoas realmente usam

E é exatamente aí que entra o WebGIS.

Hoje, quem se destaca não é só quem analisa dados… É quem consegue:

Centralizar informações
Publicar serviços padronizados (OGC)
Criar aplicações acessíveis via navegador
Controlar acesso e usuários
Escalar o uso dos dados

Em outras palavras: sair do desktop e ir para internet.

Agora vem o ponto que trava muita gente:

“Pra fazer isso eu preciso programar?”

Não.

Com as ferramentas certas, você consegue construir um WebGIS completo usando:

PostgreSQL + PostGIS
GeoServer
GeoNode

Tudo integrado, utilizando tecnologias open source já consolidadas no mercado. E mais importante: você aprende o fluxo completo, não só ferramentas isoladas.

Dado → Serviço → Aplicação → Usuário

Na prática, isso significa que você será capaz de:

Estruturar dados espaciais de forma profissional
Publicar mapas e serviços na web
Criar portais geoespaciais completos
Desenvolver dashboards e GeoStories
Gerenciar permissões e acessos

Esse não é um curso de programação. É um curso para quem quer resultado aplicado, utilizando ferramentas prontas e poderosas. Se você quer parar de entregar arquivos e começar a entregar soluções acessíveis, escaláveis e profissionais…

Esse é o próximo passo.

O curso é ministrado na modalidade EAD Ao Vivo, com aulas síncronas, porém, as aulas são gravadas e ficam disponíveis ao aluno por 12 meses no nosso portal do aluno.

Garanta sua vaga:

https://geocursos.com.br/webgis
https://whats.link/geocursos

Se você trabalha com dados geoespaciais, principalmente rasters, provavelmente já esbarrou em problemas como:

• Dificuldade de organizar grandes volumes de dados
• Falta de padronização na publicação
• APIs pouco eficientes para busca espacial/temporal

É exatamente aqui que entra o STAC (SpatioTemporal Asset Catalog). Mais do que um formato, o STAC é um padrão moderno para organizar, catalogar e acessar dados geoespaciais, permitindo buscas rápidas e interoperáveis.

Neste guia, você vai aprender a montar um ambiente completo para:

• Organizar seus dados no padrão STAC
• Publicar via API moderna
• Integrar com o GeoServer
• Servir dados raster (COG) de forma eficiente

Este post apresenta, passo a passo, como montar um ambiente completo para criação e publicação de um catálogo STAC (SpatioTemporal Asset Catalog), utilizando Docker, PostGIS, GeoServer e uma API intermediária (adapter). O objetivo é permitir que você organize, publique e consuma dados geoespaciais modernos de forma eficiente.

Antes de começar, é importante entender o papel de cada componente:

• PostGIS → Armazena os metadados espaciais
• pgSTAC → Implementa o padrão STAC dentro do PostgreSQL
• STAC FastAPI → Expõe os dados via API REST
• GeoServer → Publica e renderiza os dados
• Adapter (FastAPI) → Traduz STAC para o formato esperado pelo GeoServer

Um ponto importante: o GeoServer ainda não consome STAC “puro” de forma completa, por isso o uso do adapter é essencial.

Antes de instalar qualquer ferramenta, é importante garantir que o sistema esteja atualizado. Isso evita problemas de dependência e incompatibilidade.

> sudo apt update
> sudo apt upgrade -y

O Docker será usado para isolar cada componente da arquitetura, garantindo reprodutibilidade. Isso evita conflitos de versão e facilita deploy em outros ambientes.

2.1 Adicionar chave GPG:

> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
> sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

2.2 Adicionar repositório:

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

2.3 Instalar Docker + Compose:

> sudo apt update
> sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y

Com isso, você terá um ambiente isolado para rodar toda a stack sem conflitos de versão.

Agora vamos organizar os diretórios do projeto:

> sudo mkdir -p /docker/geoserver/plugins
> cd /docker/geoserver/plugins

O plugins que iremos realizar o download adicionam suporte a:

• COG (Cloud Optimized GeoTIFF) via HTTP/S3
• Integração com STAC

Sem esses plugins, o GeoServer não consegue trabalhar corretamente com dados cloud-native.

> wget https://build.geoserver.org/geoserver/2.27.x/community-latest/geoserver-2.27-SNAPSHOT-cog-http-plugin.zip
> wget https://build.geoserver.org/geoserver/2.27.x/community-latest/geoserver-2.27-SNAPSHOT-cog-s3-plugin.zip
> wget https://build.geoserver.org/geoserver/2.27.x/community-latest/geoserver-2.27-SNAPSHOT-stac-datastore-plugin.zip

Criamos um Dockerfile para incluir os plugins:

cd /docker/geoserver
nano Dockerfile

O conteúdo do arquivo:

FROM docker.osgeo.org/geoserver:2.27.2

COPY plugins/*.jar /usr/local/tomcat/webapps/geoserver/WEB-INF/lib/

Aqui estamos estendendo a imagem padrão do GeoServer para suportar STAC e COG.

Agora definimos toda a infraestrutura: Banco de dados (PostGIS), API STAC e GeoServer. Vamos então criar o arquivo docker-compose.yaml:

cd /docker
nano docker-compose.yaml

Esse arquivo é o coração da infraestrutura, ele define como os serviços se comunicam e persistem dados. O conteúdo do arquivo:

volumes:
  postgis-data:
  geoserver-data:

networks:
  internal:
  external:

services:

  db:
    container_name: postgis
    image: postgis/postgis:16-3.4
    volumes:
      - postgis-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=postgis
      - POSTGRES_USER=postgis
      - POSTGRES_PASSWORD=senha_postgis
      - IP_LIST=*
      - ALLOW_IP_RANGE=0.0.0.0/0
      - POSTGRES_MULTIPLE_EXTENSIONS=postgis,hstore,postgis_topology,postgis_raster,pgrouting,btree_gist
      - FORCE_SSL=false
    ports:
      - "5432:5432"
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgis-d postgis"]
      interval: 5s
      timeout: 5s
      retries: 10
    networks:
      - internal

  geoserver:
    container_name: geoserver
    build: ./geoserver
    volumes:
      - geoserver-data:/opt/geoserver/data_dir
      - /docker/geoserver/imagem_raster:/opt/geoserver/data_dir/coverages
    environment:
      - TZ=America/Sao_Paulo
      - GEOSERVER_ADMIN_USER=admin
      - GEOSERVER_ADMIN_PASSWORD=geoserver
      - INSTALL_EXTENSIONS=true
      - EXTRA_JAVA_OPTS=-Xms4G -Xmx6G
      - STABLE_EXTENSIONS=importer,wps,pyramid
      - PROXY_BASE_URL=http://192.168.186.140:8083/geoserver
      - GEOSERVER_CSRF_WHITELIST=192.168.186.140
      - HTTP_SCHEME=http
      - CORS_ENABLED=false
    ports:
      - "8083:8080"
    restart: unless-stopped
    healthcheck:
      test: curl --fail "http://localhost:8080/geoserver/web/wicket/resource/org.geoserver.web.GeoServerBasePage/img/logo.png" || exit 1
      interval: 1m30s
      timeout: 10s
      retries: 3
    networks:
      - internal
      - external

  stac:
    container_name: stac-api
    image: ghcr.io/stac-utils/stac-fastapi-pgstac:latest
    environment:
      - PGHOST=db
      - PGPORT=5432
      - PGDATABASE=postgis
      - PGUSER=postgis
      - PGPASSWORD=senha_postgis
    ports:
      - "8085:8080"
    depends_on:
      db:
        condition: service_healthy
    networks:
      - internal

Agora é subir o ambiente:

> docker compose build
> docker compose up -d

Instalar a ferramenta:

sudo apt install -y pipx
pipx ensurepath
source ~/.bashrc
pipx install "pypgstac[psycopg]"

Configurar conexão:

export PGHOST=127.0.0.1
export PGPORT=5432
export PGDATABASE=postgis
export PGUSER=postgis
export PGPASSWORD=senha_postgis

Rodar migração:

> pypgstac migrate

Esse comando cria toda a estrutura STAC dentro do banco:

• Tabelas de collections
• Tabelas de items
• Índices espaciais e temporais

Sem isso, a API STAC não consegue funcionar.

Collections funcionam como agrupadores lógicos de dados. Exemplos: Sentinel-2, Ortofotos, Modelos de elevação.

Crie o arquivo:

nano collection.json

Conteúdo do arquivo:

{
  "id": "raster-test",
  "type": "Collection",
  "description": "Teste de raster",
  "license": "proprietary",
  "extent": {
    "spatial": { "bbox": [[-180, -90, 180, 90]] },
    "temporal": { "interval": [["2024-01-01T00:00:00Z", null]] }
  }
}

Para inserir no banco, execute o comando abaixo:

pypgstac load collections collection.json

Os Items representam os dados reais. Exemplo: Um raster específico, um ortomosaico, uma cena de satélite.

Crie o arquivo:

nano item.json

Conteúdo do arquivo:

{
  "type": "Feature",
  "stac_version": "1.0.0",
  "id": "paraiso-ortomosaico",
  "collection": "raster-test",
  "geometry": {
    "type": "Polygon",
    "coordinates": [[
      [-48.8961561, -25.0593974],
      [-48.8764276, -25.0593974],
      [-48.8764276, -25.0730781],
      [-48.8961561, -25.0730781],
      [-48.8961561, -25.0593974]
    ]]
  },
  "bbox": [-48.8961561,-25.0730781,-48.8764276,-25.0593974],
  "properties": {
    "datetime": "2024-01-01T00:00:00Z",
    "proj:epsg": 4326
  },
  "assets": {
    "data": {
      "href": "http://SEU_IP:9000/rasters/seu_arquivo.tif",
      "type": "image/tiff",
      "roles": ["data"]
    }
  }
}

Inserir item no banco:

pypgstac load items item.json

Se você precisar editar o conteúdo do json e realizar um update no banco, use o seguinte comando:

pypgstac load items item.json --method upsert

Você ainda tem uma outra opção que é a criação automático do arquivo json através do rio-stac, para isso você precisa:

pipx install rio-stac --include-deps
rio stac orotomosaico_cog.tif > item.json

Dica importante:

O campo “href”: “http://SEU_IP:9000/rasters/seu_arquivo.tif” do JSON, é o link para o dado real (idealmente um COG acessível via HTTP ou S3).

Essa é uma das partes mais importantes da arquitetura, pois o GeoServer não consume STAC de forma totalmente nativa. Então esse adapter vai resolver as incompatibilidades do GeoServer com STAC, ajustando links e headers.

Para o STAC funcionar perfeitamente no GeoServer, é necessário realizar alguns ajustes de:

• Content-Type
• Href
• Navegação interna

Devido a esse problema, foi desenvolvido um adapter em FastAPI que: intercepta requisições, ajusta os links (href), corrige headers e diferencia chamadas internas e externas.

Criar API:

mkdir /docker/api
cd /docker/api
nano adapter.py

Conteúdo do arquivo adapter.py

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
import requests
import os

app = FastAPI()

STAC_URL = "http://stac-api:8080"

# URLs
PUBLIC_URL = os.getenv("PUBLIC_URL", "http://192.168.186.140:8087")
INTERNAL_URL = "http://stac-adapter:8081"


# -------------------------
# Helper para requisições
# -------------------------
def fetch(url, method="GET", json=None):
    if method == "POST":
        r = requests.post(url, json=json)
    else:
        r = requests.get(url)

    r.raise_for_status()
    return r.json()


# -------------------------
# Detecta se é chamada interna (GeoServer)
# -------------------------
def is_internal(request: Request):
    host = request.headers.get("host", "")
    return "stac-adapter" in host or "geoserver" in host


# -------------------------
# Fix links (inteligente)
# -------------------------
def fix_links(data, internal=False):
    base = INTERNAL_URL if internal else PUBLIC_URL

    def fix(obj):
        if isinstance(obj, dict):
            for k, v in obj.items():
                if k == "href" and isinstance(v, str):
                    obj[k] = v.replace("http://stac-api:8080", base)
                else:
                    fix(v)
        elif isinstance(obj, list):
            for item in obj:
                fix(item)

    fix(data)
    return data


# -------------------------
# ROOT
# -------------------------
@app.api_route("/", methods=["GET", "HEAD"])
async def root(request: Request):
    data = fetch(f"{STAC_URL}/")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/json"
    )


# -------------------------
# COLLECTIONS
# -------------------------
@app.api_route("/collections", methods=["GET", "HEAD"])
async def collections(request: Request):
    data = fetch(f"{STAC_URL}/collections")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/json"
    )


# -------------------------
# COLLECTION
# -------------------------
@app.api_route("/collections/{collection_id}", methods=["GET", "HEAD"])
async def collection(collection_id: str, request: Request):
    data = fetch(f"{STAC_URL}/collections/{collection_id}")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )


# -------------------------
# ITEMS
# -------------------------
@app.api_route("/collections/{collection_id}/items", methods=["GET", "HEAD"])
async def items(collection_id: str, request: Request):
    data = fetch(f"{STAC_URL}/collections/{collection_id}/items")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )


# -------------------------
# ITEM ESPECÍFICO
# -------------------------
@app.api_route("/collections/{collection_id}/items/{item_id}", methods=["GET", "HEAD"])
async def item(collection_id: str, item_id: str, request: Request):
    data = fetch(f"{STAC_URL}/collections/{collection_id}/items/{item_id}")
    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )


# -------------------------
# SEARCH
# -------------------------
@app.api_route("/search", methods=["GET", "POST", "HEAD"])
async def search(request: Request):
    if request.method == "POST":
        body = await request.json()
        data = fetch(f"{STAC_URL}/search", method="POST", json=body)
    else:
        data = fetch(f"{STAC_URL}/search")

    return JSONResponse(
        content=fix_links(data, internal=is_internal(request)),
        media_type="application/geo+json"
    )

Agora vamos ao conteúdo do arquivo Dockerfile:

FROM python:3.11-slim

WORKDIR /app

RUN pip install fastapi uvicorn requests

COPY adapter.py .

CMD ["uvicorn", "adapter:app", "--host", "0.0.0.0", "--port", "8081"]

E pra finalizar, você deve adicionar ao seu docker-compose:

adapter:
  container_name: stac-adapter
  build: ./api
  ports:
    - "8087:8081"
  depends_on:
    - stac
  networks:
    - internal
    - external

Agora é só subir o adapter:

docker compose up -d --build

Agora, para finalizar, vamos instalar o nginx e deixar tudo rodando externamente na porta 80. O Nginx atua como proxy reverso, centralizando o acesso:

• /geoserver → GeoServer
• /stac → Adapter
• /stac-api → API direta

E ainda ajuda na organização das rotas, facilidade de exposição externa e melhor controle de segurança.

Vamos criar o arquivo nginx-stac.conf:

cd /docker/
nano nginx-stac.conf

Esse arquivo deve conter o seguinte conteúdo:

server {
    listen 80;

    # -------------------------
    # GEOSERVER
    # -------------------------
    location /geoserver/ {
        proxy_pass http://geoserver:8080/geoserver/;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # -------------------------
    # STAC (via adapter)
    # -------------------------
    location /stac/ {
        proxy_pass http://adapter:8081/;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # -------------------------
    # STAC DIRETO (opcional)
    # -------------------------
    location /stac-api/ {
        proxy_pass http://stac-api:8080/;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Você precisar alterar a seguinte linha do arquivo adapter.py:

PUBLIC_URL = os.getenv("PUBLIC_URL", "http://192.168.186.140:8087")

Para:

PUBLIC_URL = os.getenv("PUBLIC_URL", "http://192.168.186.140/stac")

Agora é só subir o seu container, e pronto:

docker compose up -d --build

Se tudo estiver correto, você verá sua collection retornada via API.

Com essa arquitetura, você passa a ter:

• Um catálogo STAC estruturado e escalável
• Uma API moderna para consulta espacial e temporal
• Integração com GeoServer
• Suporte a dados cloud-native (COG)

Mais do que isso, você construiu uma base sólida para aplicações geoespaciais modernas, preparada para lidar com grandes volumes de dados de forma eficiente.

Historicamente, trabalhar com esses arquivos sempre foi um desafio para profissionais de geotecnologia. Entre os principais problemas estão:

• Leitura lenta de arquivos grandes
• Alto consumo de disco
• Necessidade de armazenamento local
• Dificuldade de uso em ambientes cloud
• Baixa escalabilidade em servidores GIS

Foi nesse cenário que surgiu o Cloud Optimized GeoTIFF (COG).

Hoje o COG é considerado um dos formatos mais importantes para infraestruturas modernas de dados geoespaciais, permitindo trabalhar com rasters gigantes de forma muito mais eficiente.

Neste artigo vamos entender:

• O que é COG
• Como ele funciona
• Por que ele é muito mais rápido
• Vantagens e desvantagens
• Como criar um COG
• Como usar COG com servidores GIS
• Impacto real na performance para usuários

1. O problema dos rasters tradicionais

Um GeoTIFF tradicional não foi projetado para acesso remoto eficiente.

Imagine um ortomosaico de 20 GB. Um usuário acessa apenas uma pequena área no mapa. O que acontece internamente:

Mesmo que o usuário precise de apenas 1% da imagem, o servidor pode acabar lendo uma grande parte do arquivo. Isso gera:

• Alto I/O de disco
• Grande uso de CPU
• Lentidão no acesso
• Pouca escalabilidade

2. O que é Cloud Optimized GeoTIFF (COG)

O Cloud Optimized GeoTIFF (COG) é uma variação do formato GeoTIFF otimizada para acesso eficiente via rede. Ele foi projetado para permitir que aplicações leiam apenas os pedaços necessários do arquivo. Em vez de carregar o raster inteiro, o cliente acessa somente os blocos relevantes.

Isso permite acessar rasters muito grandes diretamente em:

• Servidores HTTP
• Object Storage
• Infraestruturas Cloud

Sem precisar baixar o arquivo completo.

3. Como o COG funciona internamente

A performance do COG depende de três características principais.

3.1 Tiling interno

No COG o raster é dividido em blocos menores chamados de tiles.

Esses blocos normalmente possuem tamanho como:

512 x 512 pixels

Quando um cliente pede uma área específica do mapa, apenas os tiles necessários são lidos.

3.2 Overviews (pirâmide de resolução)

COGs normalmente possuem overviews internas. Isso significa que versões reduzidas da imagem são armazenadas dentro do próprio arquivo. Exemplo:

Quando o usuário está visualizando o mapa em escalas menores, o servidor lê apenas as versões reduzidas. Isso reduz drasticamente:

• Leitura de dados
• Tempo de renderização
• Consumo de CPU

3.3 HTTP Range Requests

Uma das principais características do COG é permitir leitura parcial do arquivo via HTTP. Exemplo de requisição:

GET /imagem.tif
Range: bytes=10000-20000

O servidor retorna apenas aquela parte do arquivo.

Isso permite acessar COGs sem baixar o raster inteiro diretamente em:

• Servidores web
• S3
• MinIO
• Cloud Storage

4. Comparação prática: GeoTIFF vs COG

Comparação visual – GeoTIFF vs COG

4.1 GeoTIFF tradicional

Problemas:

• Alto uso de disco
• Leitura pesada
• Baixa escalabilidade

4.2 COG

Benefícios:

• Leitura mínima de dados
• Muito mais rápido
• Ideal para cloud

5. Vantagens do COG

Principais vantagens:

• Leitura parcial do raster
• Acesso eficiente via HTTP
• Ideal para cloud computing
• Integração com object storage
• Redução de I/O de disco
• Excelente para grandes datasets

6. Desvantagens

Apesar das vantagens, existem alguns pontos a considerar:

• Criação pode ser demorada para rasters muito grandes
• Arquivos podem ficar maiores devido às overviews
• Não é ideal para edição constante
• Exige processamento inicial

Por isso o COG é mais indicado para dados finais de publicação.

7. Como criar um COG

O primeiro passo é converter o raster tradicional para Cloud Optimized GeoTIFF (COG). A maneira mais comum é usar o GDAL:

gdal_translate input.tif output_cog.tif \
-of COG \
-co COMPRESS=LZW \
-co BLOCKSIZE=512 \
-co BIGTIFF=YES

7.1 Parâmetros importantes

7.2 Validação do COG

Depois da conversão, é importante verificar se o arquivo foi gerado corretamente, da seguinte forma:

gdalinfo arquivo_cog.tif

Se aparecer:

LAYOUT=COG

Significa que o arquivo foi criado corretamente.

8. COG e Object Storage

Uma das maiores vantagens do COG é funcionar perfeitamente com Object Storage.

• S3
• MinIO
• Google Cloud Storage
• Azure Blob Storage

Arquitetura típica:

Isso permite criar infraestruturas altamente escaláveis.

9. COG com servidores GIS

Servidores como GeoServer podem acessar COGs diretamente via HTTP.

Fluxo típico:

Uma grande vantagem é que o raster não precisa ficar no servidor GIS.

10. COG substitui o Cache (GWC)?

Não. O COG e cache resolvem problemas diferentes. Enquanto o COG otimiza leitura do raster, o cache otimiza entrega de mapas renderizados.

Arquitetura recomendada:

11. Benchmark de performance

Vamos comparar três cenários. Vamos supor que você tem um ortomosaico de 20GB. Como seria a performance dele nos cenários abaixo:

GeoTIFF tradicional

Primeiro acesso:

3 a 8 segundos

Alta leitura de disco.

COG

Primeiro acesso:

0.5 a 2 segundos

Leitura parcial.

COG + GeoWebCache

Após cache:

20 a 80 milissegundos

Praticamente instantâneo.

12. Conclusão

O Cloud Optimized GeoTIFF se tornou um dos formatos mais importantes para infraestruturas modernas de dados raster.

Ele permite acesso eficiente a grandes rasters, integração com cloud e publicação escalável em servidores GIS.

Quando combinado com object storage e servidores como GeoServer, o COG possibilita arquiteturas altamente performáticas para distribuição de dados geoespaciais.

Uma arquitetura moderna que vem sendo cada vez mais utilizada é baseada em:

• Cloud Optimized GeoTIFF (COG)
• MinIO ou Google Cloud Storage ou Amazon S3 (Object Storage)
• GeoServer

Essa combinação permite que o GeoServer leia diretamente rasters armazenados em object storage, sem precisar copiá-los para o servidor.

Neste post vou mostrar um passo a passo simples e prático para implementar essa arquitetura:

O ponto principal aqui é que o GeoServer não precisa armazenar o raster localmente. Ele apenas acessa o arquivo COG diretamente no storage.

Importante: O plugin COG (HTTP ou S3) já deve ter sido instalado no GeoServer.

1. Converter o raster para COG

O primeiro passo é converter o raster tradicional para Cloud Optimized GeoTIFF (COG). Isso pode ser feito utilizando o GDAL.

gdal_translate ortomosaico.tif ortomosaico_cog.tif \
-of COG \
-co COMPRESS=LZW \
-co BLOCKSIZE=512 \
-co BIGTIFF=YES \
-co OVERVIEWS=IGNORE_EXISTING

Parâmetros importantes

2. Verificar se o COG foi criado corretamente

Depois da conversão, é importante verificar se o arquivo foi gerado corretamente.

gdalinfo ortomosaico_cog.tif

No resultado deve aparecer algo como:

LAYOUT=COG

E também a presença de overviews:

Overviews: 28676x21832, 14338x10916, ...

Isso confirma que o arquivo está otimizado para leitura em nuvem.

3. Subir o arquivo para o storage (S3 ou MinIO)

Agora precisamos enviar o arquivo para um Object Storage.

Você pode utilizar:

• MinIO (self-hosted)
• Amazon S3
• Google Cloud Storage

No caso do MinIO, é comum utilizar o cliente mc.

Instalar o cliente MinIO (caso você não tenha):

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
sudo mv mc /usr/local/bin/

Configurar o acesso ao servidor

mc alias set minio http://SEU_SERVIDOR:9000 ACCESS_KEY SECRET_KEY

Enviar o raster para um bucket

mc cp ortomosaico_cog.tif minio/rasters/

Após o upload, o arquivo ficará acessível em algo como:

http://servidor:9000/rasters/ortomosaico_cog.tif

4. Configurar o raster no GeoServer

Agora vamos configurar o raster no GeoServer.

Acesse a interface administrativa:

http://seu-servidor:8080/geoserver

Criar um novo Store

Vá em:

Stores → Add new Store

Escolha:

GeoTIFF / Cloud Optimized GeoTIFF

Informar a URL do COG

No campo de URL informe o caminho do arquivo:

http://servidor:9000/rasters/ortomosaico_cog.tif

Salve o store.

5. Publicar a Layer

Após salvar o store, o GeoServer detectará automaticamente o raster.

Basta clicar em:

Publish

Configure:

• Bounding Box
• CRS
• Nome da layer

Depois salve.

6. Testar o serviço

Agora o raster já pode ser acessado via:

• WMS
• WCS
• WMTS

Exemplo de endpoint WMS:

http://servidor:8080/geoserver/wms

Ou diretamente pelo Layer Preview do GeoServer.

7. Por que essa arquitetura é interessante?

Escalabilidade

O storage pode crescer independentemente do GeoServer.

Performance

O COG permite leitura parcial do raster utilizando HTTP Range Requests.
Ou seja, o cliente solicita apenas a parte da imagem que precisa.

Integração com cloud

A mesma arquitetura funciona com diversos serviços de object storage.

• Amazon S3
• MinIO
• Google Cloud Storage

8. Conclusão

A combinação de COG + Object Storage + GeoServer é hoje uma das formas mais eficientes de publicar rasters grandes em ambientes WebGIS. Essa abordagem permite:

• separar armazenamento e serviço
• escalar facilmente
• melhorar a performance de acesso aos dados

E o melhor: tudo pode ser implementado utilizando software open source.

Se você instalou o GeoNode 5 via Docker (GeoNode Project) e precisa adicionar um plugin que não vem na instalação padrão do GeoServer, este guia vai te mostrar como fazer isso da maneira correta e reproduzível.

No meu caso, estou utilizando:

• GeoNode 5.0.0
• GeoServer 2.27.3

O objetivo é instalar o plugin Resource Browser Tool, que permite navegar e gerenciar arquivos do GeoServer diretamente pela interface web.

1. Baixar o plugin:

O plugin precisa ser exatamente da mesma versão do GeoServer. Como estou usando a versão 2.27.3, o plugin também deve ser 2.27.3.

> cd /home/fernandoquadro/
> wget https://sourceforge.net/projects/geoserver/files/GeoServer/2.27.3/extensions/geoserver-2.27.3-web-resource-plugin.zip
> unzip geoserver-2.27.3-web-resource-plugin.zip

Após descompactar, você terá um ou mais arquivos .jar.

2. Copiar o plugin para a pasta do Projeto:

> mkdir -p /opt/geonode_custom/my_geonode/docker/geoserver/plugins/resourcebrowser
> cp *.jar /opt/geonode_custom/my_geonode/docker/geoserver/plugins/resourcebrowser

3. Alterar o arquivo Dockerfile do GeoServer

A instalação correta do plugin não deve ser feita manualmente dentro do container.
O procedimento adequado é incluir o plugin no processo de build da imagem.

> cd /opt/geonode_custom/my_geonode/docker/geoserver
> sudo nano Dockerfile

Adicione as seguintes linhas ao final do seu arquivo:

# GeoServer Resource Browser Tool (2.27.3)
COPY plugins/resourcebrowser/*.jar \
  /usr/local/tomcat/webapps/geoserver/WEB-INF/lib/

4. Recriar a imagem do GeoServer

> docker compose build geoserver
> docker compose up -d geoserver

Se quiser garantir um rebuild completo, faça:

> docker compose down
> docker compose build
> docker compose up -d

5. Verificar se o plugin foi instalado

Após executar os passos acima você pode então entrar no GeoServer e verificar se o seu plugin realmente foi instalado. Para isso acesse o painel administrativa em About & Status → Modules, se tudo estiver correto, o Resource Browser Tool aparecerá na lista de módulos instalados.

Esse mesmo procedimento pode ser utilizado para instalar qualquer plugin do GeoServer no GeoNode executado via Docker.

Se você ainda não instalou o GeoNode 5, pode conferir o passo a passo completo clicando aqui.

Neste post irei apresentar como você pode instalar o GeoNode 5 via Docker em uma máquina rodando o Ubuntu Linux 24.04. Ao final dessa instalação você estará com uma instância do GeoNode executando no seu localhost.

Sem enrolação, vamos aos passos:

1. Instalar os pacotes do S.O

> sudo add-apt-repository universe
> sudo apt-get update -y
> sudo apt-get install -y git-core git-buildpackage debhelper devscripts python3.12-dev python3.12-venv virtualenvwrapper
> sudo apt-get install -y apt-transport-https ca-certificates curl lsb-release gnupg gnupg-agent software-properties-common vim

2. Adicionar os repositórios do Docker

> sudo mkdir -p /etc/apt/keyrings
> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
> sudo chmod a+r /etc/apt/keyrings/docker.gpg
> echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

3. Adicionar os pacotes do Docker

> sudo apt-get update -y
> sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose
> sudo apt autoremove --purge

4. Adicionar seu usuário ao grupo docker

> sudo usermod -aG docker ${USER}
> su ${USER}

5. Preparar o ambiente

> sudo mkdir -p /opt/geonode_custom/
> sudo usermod -a -G www-data geonode
> sudo chown -Rf geonode:www-data /opt/geonode_custom/
> sudo chmod -Rf 775 /opt/geonode_custom/

Dica: Se o nome do seu usuário não for geonode, substitua pelo nome do seu usuário na linha 2 e 3 acima.

6. Clonar o código fonte

> cd /opt/geonode_custom/
> git clone https://github.com/GeoNode/geonode-project.git -b 5.0.0

Dica: É importante ressaltar que o número que você passar após o -b é na realidade a versão que você quer baixar/instalar do GeoNode

7. Criar uma instância do Django

> source /usr/share/virtualenvwrapper/virtualenvwrapper.sh
> mkvirtualenv --python=/usr/bin/python3 my_geonode
> pip install Django==5.2
> django-admin startproject --template=./geonode-project -e py,sh,md,rst,json,yml,ini,env,sample,properties -n monitoring-cron -n Dockerfile my_geonode
> cd /opt/geonode_custom/my_geonode

OBS: Chamaremos nossa instância de my_geonode. Você pode alterar o nome conforme desejar.

OBS2: O Django instalado neste virtualenv é usado apenas para gerar a estrutura inicial do projeto. A versão do Django utilizada pelo GeoNode em runtime é definida pela imagem Docker.

No arquivo src/requirements.txt, dentro da pasta my_geonode, altere o arquivo para que ele fique da seguinte forma:

GeoNode==5.0.0
cachetools>=5.3

8. Criar o arquivo .env

> python create-envfile.py

9. Construa os containers

> docker-compose -f docker-compose.yml build --no-cache

10. Finalmente execute o container

> docker-compose -f docker-compose.yml up -d

Agora é só aguardar todos os containers aparecerem como done, e você já pode acessar o GeoNode no seu navegador digitando http://localhost/

Se você quiser mais detalhes sobre a instalação basta acessar a documentação oficial do GeoNode, clicando aqui.

Se você precisa instalar o certificado SSL para poder habilitar o HTTPS no seu GeoNode, então clique aqui e veja o passo a passo.

Estão abertas as inscrições para o Curso Python com GIS do Zero, uma formação técnica e prática para quem quer sair do modo operacional e começar a programar o geoprocessamento de verdade.

Aqui você aprende Python aplicado ao GIS, não Python genérico.

O que você vai dominar:

Python do zero com foco técnico
Pandas e Geopandas aplicados ao GIS
Processamento de vetores e rasters (GDAL/OGR)
Análises espaciais e estatísticas zonais
SQL Espacial moderno com DuckDB Spatial
Automação de processos no QGIS
Introdução ao desenvolvimento de plugins

Tudo aplicado a problemas reais, como acontece no mercado.

Para quem é este curso?

Profissionais de GIS e Geoprocessamento
Usuários de QGIS que querem evoluir
Quem quer ganhar produtividade e escala
Quem quer parar de clicar e começar a programar

Não é curso raso.
Não é só teoria.
É formação técnica aplicada.

Vagas limitadas

Se você quer transformar a forma como trabalha com GIS, essa é a hora.

https://geocursos.com.br/python

Nos últimos dias, circulou no LinkedIn um artigo que afirmava que o GeoServer estaria obsoleto e em declínio, caracterizando-o como uma ferramenta pesada e sugerindo que soluções como pg_tileserv e Martin poderiam substituí-lo integralmente.

A argumentação apresentada, no entanto, baseava-se predominantemente em percepções individuais, sem uma análise técnica mais aprofundada ou consideração dos diferentes contextos de uso. Ao longo deste texto, apresento uma avaliação fundamentada sobre o papel do GeoServer no ecossistema geoespacial atual, demonstrando por que ele permanece uma solução robusta, amplamente utilizada em produção e longe de estar em processo de obsolescência.

1. pg_tileserv / Martin podem substituir o GeoServer em ambientes complexos?

A discussão sobre a substituição do GeoServer por ferramentas como pg_tileserv ou Martin tem ganhado espaço à medida que arquiteturas geoespaciais mais enxutas e orientadas a frontend se popularizam. No entanto, quando analisamos ambientes complexos e institucionais a resposta técnica é clara: essas ferramentas não são substitutos funcionais do GeoServer, mas sim componentes complementares.

2. Escopo funcional e vocação das ferramentas

pg_tileserv e Martin foram concebidos para resolver um problema específico: a entrega eficiente de dados geoespaciais vetoriais a aplicações web modernas, geralmente por meio de vector tiles ou APIs REST simples, com foco em desempenho, baixa latência e simplicidade operacional. Sua arquitetura stateless, o acoplamento direto ao PostGIS e a ausência de camadas intermediárias fazem dessas ferramentas excelentes escolhas para produtos digitais orientados a UX.

O GeoServer, por outro lado, foi projetado como um servidor geoespacial corporativo, voltado à publicação, gestão e interoperabilidade de dados espaciais em ambientes multiusuário e de longo prazo. Seu escopo funcional é deliberadamente mais amplo e atende a requisitos que não são cobertos por servidores de tiles ou APIs minimalistas.

3. Governança e ciclo de vida dos dados

Em infraestruturas complexas, o desafio central não é apenas servir dados, mas governá-los. Isso inclui:

• Publicação controlada de centenas de camadas;
• Organização por temas, domínios e responsabilidades institucionais;
• Gerenciamento de estilos, projeções e escalas;
• Controle de acesso por camada e por serviço;
• Auditoria e rastreabilidade.

Ferramentas como pg_tileserv e Martin não oferecem mecanismos nativos para esse tipo de governança. Para alcançar um nível equivalente, seria necessário desenvolver soluções adicionais para catalogação, versionamento, autorização e gestão operacional, deslocando a complexidade do servidor para a aplicação e aumentando o custo de manutenção.

4. Padrões OGC e interoperabilidade

Ambientes públicos e institucionais dependem fortemente de padrões OGC consolidados, como WMS, WFS e WCS, não apenas por questões técnicas, mas também por exigências legais, normativas e de interoperabilidade. Esses serviços permitem o consumo dos dados por uma ampla variedade de clientes, incluindo QGIS, ArcGIS e sistemas legados.

pg_tileserv e Martin não implementam esses padrões e tampouco se propõem a fazê-lo. Ainda que APIs REST e OGC API representem avanços importantes, a substituição completa de serviços OGC clássicos em ambientes consolidados é, na prática, inviável no curto e médio prazo.

5. Fluxos operacionais e perfil dos usuários

Outro aspecto frequentemente subestimado é o perfil dos usuários responsáveis pela publicação dos dados. Em plataformas complexas, técnicos e analistas utilizam fluxos consolidados, como a publicação direta de camadas a partir do QGIS, sem a necessidade de intervenção de equipes de desenvolvimento ou DevOps.

A adoção exclusiva de ferramentas como pg_tileserv ou Martin exigiria mudanças profundas nesses fluxos, demandando maior especialização técnica, automação customizada e novos processos organizacionais, um custo que raramente é justificável em ambientes públicos.

6. Escalabilidade: técnica versus institucional

É inegável que pg_tileserv e Martin apresentam vantagens claras em termos de escalabilidade técnica e simplicidade operacional. No entanto, em infraestruturas institucionais, a escalabilidade não se limita ao número de requisições por segundo. Ela envolve também:

• Continuidade operacional;
• Estabilidade a longo prazo;
• Facilidade de administração;
• Conformidade com padrões e políticas públicas.

Nesse contexto, o GeoServer demonstra sua robustez ao operar de forma estável em produção por anos, atendendo milhões de acessos e grandes volumes de dados, podendo citar como exemplo o GeoSampa, um dos maiores portais do país.

7. Arquiteturas complementares como caminho evolutivo

A evolução mais consistente para ambientes complexos não passa pela substituição radical do GeoServer, mas pela composição de arquiteturas. Um modelo híbrido, no qual o GeoServer permanece responsável pela governança, interoperabilidade e serviços institucionais, enquanto ferramentas como pg_tileserv ou Martin são utilizadas para a entrega eficiente de dados a aplicações web modernas, tende a oferecer o melhor equilíbrio entre inovação e estabilidade.

8. Conclusão

pg_tileserv e Martin representam avanços importantes no ecossistema geoespacial e são altamente adequados para determinados cenários. Contudo, em ambientes complexos e institucionais, eles não substituem o GeoServer. O desafio não é escolher entre “antigo” e “moderno”, mas compreender o papel de cada componente e projetar arquiteturas que respeitem tanto as necessidades técnicas quanto organizacionais.

A maturidade de uma infraestrutura geoespacial não está em adotar ferramentas minimalistas isoladamente, mas em integrá-las de forma coerente a um ecossistema que exige governança, interoperabilidade e sustentabilidade a longo prazo.

Caso você ainda não tenha acompanhado as últimas novidades do projeto, no primeiro semestre de 2026 a equipe do GeoServer irá disponibilizar a versão 3.0.

Mais do que uma simples mudança de numeração, essa nova versão representa uma atualização tecnológica profunda, essencial para garantir a evolução, a segurança e a sustentabilidade do GeoServer nos próximos anos.

A proposta do GeoServer 3 é transformar a forma como você interage com dados geoespaciais, tornando a plataforma mais rápida, mais intuitiva e mais segura, tanto para administradores quanto para desenvolvedores e usuários finais.

A principal motivação por trás do GeoServer 3 é a atualização do Spring Framework, que evolui da versão 5.3 para a versão 6.

A adoção de uma versão atual e compatível desse framework web é um fator crítico para a segurança e a manutenibilidade do GeoServer.

A atualização do Spring Framework traz uma série de consequências técnicas importantes:

• O ambiente do servidor de aplicações passa de Java Enterprise Edition (Java EE) para
  Jakarta Enterprise Edition, fornecido pelas versões mais recentes do
  Tomcat 10 e Jetty 12.
• O ambiente de execução Java evolui de Java 11 para Java 17. Essa mudança exige a substituição do mecanismo de processamento de imagens Java Advanced Imaging (JAI) pelo ImageN.
• O sistema de segurança é atualizado para o Spring Security 6, o que demanda a
  reescrita dos módulos existentes de OAuth2 e OpenID Connect.

Para viabilizar essas mudanças estruturais, o projeto foi organizado em três grandes marcos (milestones):

Milestone 1: Preparação

Este marco concentrou a maior parte do trabalho, antecipando tudo o que fosse possível antes da migração efetiva para o Spring Framework 6.

Entre as principais atividades realizadas estão:

• Grandes atualizações na biblioteca de interface do usuário Wicket;
• Substituição do mecanismo de processamento de imagens;
• Atualização do ambiente de execução para Java 17.

Essas alterações foram feitas de forma independente do Spring Framework e da migração para o ambiente Jakarta EE, reduzindo riscos na fase seguinte.

Outro ponto de destaque foi a substituição do antigo suporte a OAuth2 por um novo módulo OAuth2 OpenID Connect, já disponível para testes com provedores como Google, GitHub, Microsoft Azure e Keycloak.

Um avanço importante foi a integração testada com o Keycloak por meio de contêineres de teste, abrindo caminho para o suporte oficial dessa extensão no futuro.

Essas entregas já estão disponíveis a partir da versão GeoServer 2.28.x, lançada em setembro.

Milestone 2: Migração

O Spring Framework 5.3, utilizado até então pelo GeoServer, atingiu o fim de seu ciclo de vida em agosto de 2023, o que tornou essa etapa de migração especialmente urgente.

A migração para o Spring Framework 6 exigiu uma coordenação cuidadosa envolvendo nove bases de código. Para garantir consistência e estabilidade, foi necessário um período de “congelamento de código” enquanto as atualizações eram realizadas.

Esse congelamento impactou diretamente projetos fundamentais do ecossistema, como: ImageIO, JAI, ImageN, GeoTools, GeoWebCache, GeoServer, GeoFence, GeoServer ACL, MapFish Print e o Cloud Native GeoServer.

Dado o nível de impacto, a prioridade foi manter essa fase o mais curta possível. Ao final desse marco, o aplicativo principal do GeoServer já pôde ser executado e testado localmente utilizando o Jetty, incluindo módulos que ainda passam por ajustes finais, como o GeoFence.

Essa etapa foi concluída ainda em 2025.

Milestone 3: Entrega

Com os projetos principais atualizados e o encerramento do congelamento de código, iniciou-se a fase de testes de integração com aplicações downstream e módulos da comunidade.

Uma atividade estratégica deste marco é a refatoração da interface do usuário, permitindo que os serviços OGC API sejam integrados como parte nativa da experiência do GeoServer.

Também está previsto um refresh visual do tema da aplicação, acompanhado da atualização das imagens de tela e da documentação durante o ciclo de testes.

O encerramento deste marco culminará no lançamento oficial do GeoServer 3.0, previsto para março de 2026.

Esse plano de trabalho foi cuidadosamente definido para minimizar impactos na comunidade do GeoServer, reduzindo ao máximo o período em que o código-fonte permanece congelado durante o processo de atualização.

Fonte: GS3 Project Plan

E você? Já estava por dentro de todas essas novidades do GeoServer 3.0?

Essa modificação é comum em cenários de ambientes compartilhados, integrações com outros sistemas, migrações de infraestrutura ou simplesmente para padronizar URLs (por exemplo, mudar de /geoserver para /geoserver-admin ou /gis).

No entanto, antes de fazer essa alteração, é importante revisar as configurações do Tomcat, especialmente no arquivo server.xml, e entender a diferença entre deploy automático e manual, garantindo que o GeoServer seja publicado corretamente no novo contexto.

Gostaria de agradecer ao Carlos Eduardo Mota, que foi quem elaborou esse tutorial e enviou gentilmente para publicação neste Blog.

1) Verificando o server.xml

Local do arquivo:

$CATALINA_HOME/conf/server.xml

No arquivo, observe:

• Na tag <Engine>:
  • Propriedade name (geralmente Catalina).
  • Propriedade defaultHost.
• Na tag <Host>:
  • Propriedade appBase (pasta onde os apps são implantados, normalmente webapps).
  • Propriedade autoDeploy (deve estar true para deploy automático).

Exemplo:

<Engine name="Catalina" defaultHost="localhost">

    <!-- Configurações de cluster, log e segurança omitidas -->

    <Realm className="org.apache.catalina.realm.LockOutRealm">
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
    </Realm>

    <Host name="localhost" appBase="webapps"
          unpackWARs="true" autoDeploy="true">

        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b"/>
    </Host>
</Engine>

2) Deploy automático vs. manual

Por padrão, o GeoServer é implantado automaticamente quando o arquivo .war é colocado na pasta definida como appBase no <Host>, geralmente:

$CATALINA_HOME/webapps

Exemplo: colocar meu-app.war em webapps/ fará com que ele seja acessível via /meu-app.

Se você não deseja deploy automático (ou precisa de um contexto customizado), defina o contexto manualmente usando um arquivo de contexto.

3) Deploy manual com arquivo de contexto

1. Posicione o .war (ou o diretório do app já expandido) fora da pasta appBase.
2. Crie um arquivo de contexto .xml com o nome que deseja usar como contextPath do app.

Onde criar:

$CATALINA_HOME/conf/[EngineName]/[HostName]/

Exemplo de caminho real:

$CATALINA_HOME/conf/Catalina/localhost/geoserver-admin.xml

Conteúdo do arquivo de contexto:

<Context docBase="webapps.dist/geoserver" />

Neste exemplo, o contexto será:

http://localhost:8080/geoserver-admin

E o diretório do GeoServer está em:

$CATALINA_HOME/webapps.dist/geoserver

O diretório webapps.dist é fornecido nas imagens de container para colocar webapps para distribuição, e não para deploy automático. É provável que nas instalações clássicas do tomcat não deva existir esse diretório. Nesse caso, é necessário criar esse diretório dentro de $CATALINA_HOME.

Observação importante: o nome do arquivo (geoserver-admin.xml) define o nome do contexto (/geoserver-admin) e tem precedência sobre qualquer META-INF/context.xml incluído no .war ou na aplicação.

O arquivo context.xml pode ser expandido e ser utilizado para outras finalidades, como predefinir recursos de conexão de banco de dados (os famosos JNDI), mas isso é assunto para outro post.

Referências

• Tomcat 8
  • Deployer How-To (Contexts)
  • Configuração: Context
• Tomcat 9
  • Deployer How-To (Contexts)
  • Configuração: Context

Isso é possível com dois módulos da comunidade: JDBCConfig e JDBCStore. Apesar de frequentemente usados juntos, eles têm funções diferentes e complementares.

1. O que é o JDBCConfig

O JDBCConfig é um módulo que permite ao GeoServer salvar toda a configuração do catálogo(metadados) dentro de um banco relacional, como o PostgreSQL.

Por padrão, o GeoServer armazena sua configuração em diversos arquivos XML dentro do diretório data_dir — um para cada workspace, store, camada e estilo. Com o módulo JDBCConfig, essas informações deixam de ser gravadas nesses arquivos e passam a ser persistidas diretamente em tabelas no banco de dados, substituindo por completo o backend de configuração baseado em arquivos.

1.1 O que ele armazena

• Workspaces
• DataStores (referências às fontes de dados)
• Layers
• Styles (metadados, não o conteúdo do arquivo em si)
• Configurações globais e de serviços (WMS, WFS, etc.)

1.2 Vantagens

• Melhor escalabilidade: evita o gargalo de leitura/escrita em centenas de XMLs.
• Mais segurança em cluster: todas as instâncias compartilham o mesmo catálogo.
• Gerenciamento centralizado: fácil backup, versionamento e replicação via banco.

1.3 Quando usar

• Ambientes em cluster (várias instâncias do GeoServer).
• Ambientes com muitas camadas e workspaces (centenas ou milhares).
• Pode ser usado mesmo em um único servidor, apenas para reduzir I/O de disco e facilitar

2. O que é o JDBCStore

O JDBCStore é outro módulo comunitário que complementa o JDBCConfig. Ele permite armazenar os arquivos reais do data_dir (como estilos .sld, imagens, legendas e uploads) dentro do banco de dados, em vez de no sistema de arquivos.

Diferente do JDBCConfig, que salva metadados e estrutura do catálogo, o JDBCStore salva conteúdo binário (arquivos, blobs).

2.1 O que ele armazena

• Arquivos de estilos (SLD, CSS)
• Imagens usadas em símbolos e legendas
• Arquivos de uploads feitos via REST ou UI
• Qualquer outro recurso armazenado dentro de data_dir

2.2 Vantagens

• Evita dependência de compartilhamento via NFS em clusters.
• Centraliza todos os recursos no banco, junto com o catálogo.
• Facilita backup e replicação, basta copiar o banco.

2.3 Quando usar

• Com JDBCConfig, em ambiente clusterizado é ideal.
• Sem JDBCConfig, se você quiser apenas armazenar os arquivos no banco e manter a configuração ainda em XML.
• Útil também em servidores únicos, se você quiser facilitar deploys e migrações (sem precisar sincronizar pastas de estilos entre máquinas).

3. Relação e diferenças entre JDBCConfig e JDBCStore

Embora os dois módulos sejam frequentemente mencionados juntos, eles têm propósitos distintos dentro do GeoServer.

O JDBCConfig é responsável por armazenar as configurações do catálogo, ou seja, toda a estrutura de metadados que descreve o funcionamento do GeoServer, os workspaces, as conexões com bancos de dados, as camadas e os estilos associados. Ele substitui o modelo tradicional baseado em arquivos XML, gravando essas informações diretamente em tabelas no banco de dados.

Já o JDBCStore atua em outro nível: ele armazena o conteúdo físico dos arquivos que normalmente ficam no data_dir. Isso inclui estilos (.sld, .css), imagens, legendas e qualquer outro arquivo binário usado pelo GeoServer. Em vez de deixar esses recursos no sistema de arquivos, o JDBCStore os grava como blobs dentro do banco.

Os dois módulos podem funcionar independentemente. Você pode usar apenas o JDBCConfig, mantendo os arquivos (como SLDs) ainda no disco ou apenas o JDBCStore, guardando os arquivos no banco, mas deixando o catálogo em XML.

No entanto, o uso conjunto dos dois traz o máximo de benefícios: a configuração e os recursos do GeoServer passam a ser totalmente centralizados e sincronizados no banco de dados, eliminando a necessidade de um diretório compartilhado via NFS.

Resumindo:

• O JDBCConfig guarda o “quem é quem” (a estrutura de configuração).
• O JDBCStore guarda o “o que é” (os arquivos e recursos reais).
• Usados juntos, eliminam completamente a necessidade de um data_dir compartilhado, tornando o GeoServer mais robusto e escalável em ambientes distribuídos.

4. Como instalar o JDBCConfig e o JDBCStore no GeoServer 2.28.0

4.1 Baixar os módulos

Acesse a página de Community Modules da sua versão: https://geoserver.org/release/2.28.x/

Baixe os arquivos:

geoserver-2.28.x-jdbcconfig-plugin.zip
geoserver-2.28.x-jdbcstore-plugin.zip

Extraia os .jar e copie para:

GEOSERVER_HOME/WEB-INF/lib/

4.2 Criar o banco no PostgreSQL

Crie um novo banco vazio, por exemplo:

CREATE DATABASE geoserver_catalog;
CREATE USER geoserver_user WITH PASSWORD 'senha_segura';
GRANT ALL PRIVILEGES ON DATABASE geoserver_catalog TO geoserver_user;

4.3 Configurar o JDBCConfig

Após o primeiro restart do GeoServer com o módulo instalado, será criada a pasta:

data_dir/jdbcconfig/

Dentro dela há um arquivo de exemplo jdbcconfig.properties.postgres. Edite-o e configure conforme abaixo:

enabled=true
initdb=true
import=true
...
username=geoserver_user
password=senha_segura
jdbcUrl=jdbc:postgresql://localhost:5432/geoserver_catalog

Salve o arquivo como jdbcconfig.properties, reinicie o GeoServer e observe no log, se tudo estiver certo, ele criará as tabelas automaticamente e importará sua configuração XML atual para o banco.

4.4 Configurar o JDBCStore

Após instalar o módulo jdbcstore, um diretório semelhante será criado:

data_dir/jdbcstore/

Edite o arquivo jdbcstore.properties (também há um .postgres de exemplo):

enabled=true
initdb=true
...
username=geoserver_user
password=senha_segura
jdbcUrl=jdbc:postgresql://localhost:5432/geoserver_catalog

Reinicie o GeoServer novamente.

5. Conclusão

O uso do JDBCConfig e do JDBCStore traz uma série de benefícios, especialmente em ambientes de alta disponibilidade ou clusterizados.

Eles permitem que toda a configuração e os recursos do GeoServer sejam armazenados de forma transacional, centralizada e sincronizada dentro de um banco de dados relacional.

Mas mesmo em ambientes sem cluster, esses módulos podem ser vantajosos para quem busca:

• Simplificar backups e migrações (basta exportar o banco);
• Reduzir I/O de disco em instalações muito grandes;
• Facilitar o versionamento da configuração.

E você leitor, conhecia esses módulos do GeoServer? O que achou? Deixe seu comentário, vou gostar de saber sua opinião.

“Mostre os municípios com população acima de 50 mil.”
“Liste as camadas relacionadas a meio ambiente publicadas em 2024.”
“Quais áreas de risco estão dentro da zona urbana de Florianópolis?”

Essas consultas, que normalmente exigiriam acesso ao banco ou ao painel do GeoNode, podem ser respondidas em segundos por um chatbot integrado com IA.

A ideia deste post é mostrar como criar um assistente geoespacial inteligente, capaz de:

• Compreender perguntas em linguagem natural;
• Traduzir em chamadas à API do GeoNode (ou SQL/PostGIS);
• Retornar respostas estruturadas (tabelas, nomes de camadas, metadados, links);
• E até gerar mapas dinâmicos a partir das consultas.

1. O papel do GeoNode como fonte de conhecimento geoespacial

O GeoNode expõe suas informações por meio de uma API REST poderosa:

• /api/v2/datasets/ → lista de camadas;
• /api/v2/maps/ → mapas compostos;
• /api/v2/documents/ → relatórios e anexos;
• /api/v2/datasets/{id}/ → metadados detalhados de uma camada.

Com essas rotas, é possível consultar qualquer informação sobre os dados publicados, autores, datas, categorias, palavras-chave, links WMS/WFS e muito mais.

O desafio é como traduzir uma pergunta humana em uma sequência de chamadas a essa API? A resposta é, usando IA generativa como intérprete.

A IA funciona como um “tradutor semântico” entre o usuário e o GeoNode. Ela interpreta o que foi pedido e decide:

• Qual endpoint da API deve ser consultado;
• Quais filtros aplicar (categoria, data, palavra-chave, etc.);
• Como formatar a resposta para o usuário.

Além disso, a IA pode resumir os metadados retornados, explicando o contexto da camada em linguagem natural.

2. Chatbot + GeoNode + IA

Vamos montar um exemplo funcional em Python.

import requests
from openai import OpenAI

# Configurações
GEONODE_URL = "http://localhost:8000/api/v2/datasets/"
GEONODE_USER = "admin"
GEONODE_PASS = "geonode"
MODEL = "gpt-4o-mini"

# Inicializa cliente OpenAI
client = OpenAI()

# Entrada do usuário
pergunta = "Liste as camadas de saneamento publicadas em 2024."

# Prompt para IA gerar consulta API
prompt = f"""
Você é um assistente que interpreta perguntas sobre um GeoNode.
Gere a URL completa da API a ser consultada, com base na pergunta abaixo.
URL base: {GEONODE_URL}
Pergunta: {pergunta}
Exemplo de resposta esperada:
GET http://localhost:8000/api/v2/datasets/?keywords__slug=saneamento&date__year=2024
"""

# Chamada à API da OpenAI
resposta = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content": prompt}]
)

# Extrai URL
consulta = resposta.choices[0].message.content.strip().replace("GET ", "")
print("URL gerada pela IA:\n", consulta)

# 2. Executar chamada à API do GeoNode
r = requests.get(consulta, auth=(GEONODE_USER, GEONODE_PASS))
if r.status_code == 200:
    data = r.json().get("results", [])
    print(f"\n{len(data)} camadas encontradas:\n")
    for layer in data:
        title = layer.get("title", "Sem título")
        category = layer.get("category", {}).get("gn_description", "Sem categoria")
        print(f"- {title} ({category})")
else:
    print("Erro na requisição:", r.status_code, r.text)

Após a execução do script você terá a seguinte resposta:

URL gerada pela IA:
http://localhost:8000/api/v2/datasets/?keywords__slug=saneamento&date__year=2024

3 camadas encontradas:
– Sistema de Esgotamento Sanitário (Infraestrutura)
– Pontos de Abastecimento de Água (Saneamento)
– Zonas de Proteção de Mananciais (Meio Ambiente)

A IA traduziu a intenção da pergunta em uma consulta REST real, executou a requisição e retornou os resultados de forma legível.

Além de listar as camadas, a IA pode analisar e descrever o que foi encontrado.

descricoes = "\n".join([f"{l['title']}: {l['abstract']}" for l in data])

prompt_explica = f"""
Gere um resumo amigável das camadas retornadas abaixo, destacando a utilidade
de cada uma para análises de planejamento urbano.
{descricoes}
"""

resumo = openai.ChatCompletion.create(
    model=MODEL,
    messages=[{"role": "user", "content": prompt_explica}]
)

print("\n Resumo gerado pela IA:\n")
print(resumo.choices[0].message.content)

No caso desse script, você teria a seguinte resposta:

“As camadas de saneamento abrangem sistemas de abastecimento, coleta e proteção de mananciais.
Juntas, permitem identificar áreas com déficit de infraestrutura hídrica e orientar o planejamento urbano.”

3. Aplicações práticas

Você pode evoluir os scripts acima para um chatbot completo. Para isso basta encapsular essa lógica em uma API Flask ou interface Web que permita conversas em tempo real:

• O usuário digita perguntas em texto (“Quais camadas são de meio ambiente?”);
• A IA gera a consulta e executa no GeoNode;
• A resposta é retornada em formato legível ou como mapa interativo embutido (via WMS).

Dica: usando o endpoint layer[“ows”], é possível gerar um link direto de visualização do WMS retornado.

Além disso você pode aplicar esse conceito do ChatBot para transformar seu GeoNode através de:

• Atendimento automático em portais WebGIS corporativos;
• Busca semântica de dados espaciais por tema ou localização;
• Consultas técnicas acessíveis a gestores não especialistas;
• Assistentes geoespaciais integrados com Telegram, WhatsApp ou ChatGPT API.

4. Conclusão

O GeoNode deixa de ser apenas um catálogo de dados geoespaciais e se transforma em um sistema de informação conversacional, onde qualquer pessoa pode obter respostas ou gerar mapas a partir de simples perguntas.

Integrar IA + GeoNode é o primeiro passo para construir portais WebGIS realmente inteligentes, acessíveis e colaborativos.

Nesses últimos dias precisei instalar o GDAL e o MrSID em uma máquina que rodava o SuSe Linux Enterprise Server 15 SP6 (SLES). Como a biblioteca libgdaljava não estava disponível eu precisei compilar tudo na mão. Acabei passando por alguns perrengues, mas no final consegui compilar e habilitar tudo no GeoServer. Vou compartilhar o passo a passo, caso alguém esteja passando pelo mesmo problema:

1. Instalar SDK do MrSID

Para compilar o MrSID é necessário baixar o seu SDK no site da Extensis. A versão utilizada nesse tutorial foi: MrSID DSDK 9.5.5.5244 – rhel9.x86-64.gcc1131

> wget https://bin.extensis.com/download/developer/MrSID_DSDK-9.5.5.5244-rhel9.x86-64.gcc1131.zip

Agora vamos extrair e mover o SDK para a pasta /opt:

> sudo unzip MrSID_DSDK-9.5.5.5244-rhel9.x86-64.gcc1131.zip -d /opt/MrSID/
> cd /opt/MrSID
> sudo chown root:root -R MrSID/
> sudo ln -sfn /opt/MrSID/MrSID_DSDK-9.5.5.5244-rhel9.x86-64.gcc1131 /opt/MrSID/current
> sudo ldconfig

2. Instalação do GDAL

O primeiro passa foi atualizar e habilitar os repositórios adicionais no SLES:

> sudo SUSEConnect --product sle-module-development-tools/15.6/x86_64
> sudo zypper refresh

Depois foi necessário instalar as dependências básicas para compilação:

> sudo zypper install gcc gcc-c++ gcc13 gcc13-c++ make cmake ninja \
  libtool automake autoconf git curl wget unzip bison flex swig
> sudo zypper install unzip zip tar which htop net-tools iproute2 ant

E também as dependências de bibliotecas geoespaciais:

> sudo zypper install proj proj-devel geos geos-devel sqlite3 sqlite3-devel \
  libtiff-devel libjpeg8-devel libpng16-devel libcurl-devel

E por último para evitar erros na hora de rodar o make install, instalei o Python + Numpy:

> sudo zypper install python311 python311-devel python311-numpy python311-pip
> python3.11 -m pip install --user --upgrade pip
> python3.11 -m pip install --user "numpy==1.26.4"

Agora vamos baixar e preparar o GDAL para a compilação. No nosso exemplo estamos usando o GDAL 3.10.1:

> wget https://download.osgeo.org/gdal/3.10.1/gdal-3.10.1.tar.gz
> tar -xvzf gdal-3.10.1.tar.gz
> cd gdal-3.10.1
> mkdir build && cd build

E necessário também apontar o compilador para o gcc13/g++13 no ambiente de build

> export CC=/usr/bin/gcc-13
> export CXX=/usr/bin/g++-13
> SWIG_BIN=$(command -v swig || command -v swig4)
> NUMPY_INC=$(python3.11 -c 'import numpy; print(numpy.get_include())')
> JAVA_HOME=$(dirname "$(dirname "$(readlink -f "$(which javac)")")")

Chegou a hora, vamos compilar o GDAL com suporte ao MrSID e JPEG2k usando o CMake e o Ninja, veja:

> cmake -G "Ninja" .. \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_INSTALL_PREFIX=/usr/local \
  -DCMAKE_INSTALL_LIBDIR=lib \
  -DBUILD_SHARED_LIBS=ON \
  -DGDAL_ENABLE_PLUGINS=ON \
  -DBUILD_PYTHON_BINDINGS=ON \
  -DBUILD_JAVA_BINDINGS=ON \           
  -DGDAL_USE_GEOTIFF_INTERNAL=ON \
  -DGDAL_HIDE_INTERNAL_SYMBOLS=OFF \
  -DGDAL_ENABLE_DRIVER_MRSID_PLUGIN=ON \
  -DGDAL_ENABLE_DRIVER_MRSID=ON \
  -DGDAL_ENABLE_DRIVER_JP2MRSID=ON \
  -DCMAKE_INSTALL_RPATH="/usr/local/lib:/usr/local/lib64:/usr/local/lib/jni" \
  -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON \
  -DMRSID_LIBRARY=/opt/MrSID/current/Raster_DSDK/lib/libltidsdk.so \
  -DMRSID_INCLUDE_DIR=/opt/MrSID/current/Raster_DSDK/include \
  -DPython3_EXECUTABLE=/usr/bin/python3.11 \
  -DPython3_NumPy_INCLUDE_DIRS="${NUMPY_INC}" \
  -DSWIG_EXECUTABLE="${SWIG_BIN}" \
  -DJAVA_HOME="${JAVA_HOME}"

> ninja -j"$(nproc)"
> sudo ninja install

Verifique se a biblioteca libgdalalljni.so foi criada:

> ldd /usr/local/lib/jni/libgdalalljni.so | grep gdal

Caso a lib não tenha sido criado, você precisa criá-la, pois ela é essencial para a integração com o GeoServer, então você pode criar da seguinte maneira:

> ninja gdalalljni
> sudo ldconfig

Vamos atualiza o cache das bibliotecas:

> echo "/usr/local/lib" | sudo tee /etc/ld.so.conf.d/gdal.conf
> echo "/usr/local/lib/jni" | sudo tee /etc/ld.so.conf.d/gdal-jni.conf
> echo "/opt/MrSID/current/Raster_DSDK/lib" | sudo tee /etc/ld.so.conf.d/mrsid.conf
> sudo ldconfig

Agora vamos verificar se está tudo correto, pra isso execute os comandos abaixo:

> gdalinfo --version
> gdalinfo --formats | grep -Ei 'mrsid|jp2mrsid'
> ldd /usr/local/lib/jni/libgdalalljni.so | grep gdal

Após executar os passos acima, as saídas abaixo indicam que todo o processo correu bem.

  GDAL 3.10.1, released 2025/01/08
  MrSID -raster- (rov): Multi-resolution Seamless Image Database (MrSID) (*.sid)
  JP2MrSID -raster- (rov): MrSID JPEG2000 (*.jp2)
  libgdal.so.36 => /usr/local/lib/libgdal.so.36 (0x00007fdcbb400000)

Agora para fnalizar é só você habilitar no GeoServer, para isso basta adicionar as seguintes linhas no seu arquivo de inicialização do GeoServer:

-DGDAL_DATA=/usr/local/share/gdal
-Djava.library.path=/usr/local/lib:/usr/local/lib/jni:/opt/MrSID/current/Raster_DSDK/lib

No GeoServer, podemos gerar mapas de calor usando o WMS Heatmap Rendering Transform, mas configurar isso manualmente para dezenas de camadas pode ser trabalhoso.

Neste post, vamos mostrar como automatizar esse processo com Python + IA, criando um pipeline que:

• Analisa automaticamente seus dados espaciais;
• Gera os parâmetros ideais do heatmap (raio, cores, intensidade);
• Publica o estilo e a camada automaticamente no GeoServer;
• Pode ser aplicado a qualquer dataset de pontos no PostGIS.

1. O conceito de heatmap no GeoServer

O GeoServer suporta a geração de heatmaps a partir de camadas de pontos usando o processo de renderização “vec:Heatmap” dentro de um estilo SLD.

Exemplo básico de configuração manual:

<RasterSymbolizer>
  <Geometry>
    <ogc:PropertyName>geom</ogc:PropertyName>
  </Geometry>
  <Opacity>0.6</Opacity>
  <ColorMap type="ramp" extended="true">
    <ColorMapEntry color="#0000FF" quantity="0" opacity="0"/>
    <ColorMapEntry color="#00FF00" quantity="0.5" opacity="0.7"/>
    <ColorMapEntry color="#FF0000" quantity="1" opacity="1"/>
  </ColorMap>
</RasterSymbolizer>

O problema é que definir manualmente raio, opacidade e escala de cores exige tentativas e erros. É aí que você pode utilizar a IA para automatizar essa etapa.

2. Onde entra a IA

A IA pode atuar para:

1. Analisar a densidade e distribuição dos pontos
   (via amostra SQL do PostGIS);
2. Sugerir automaticamente:
   • Raio ideal para suavização do heatmap;
   • Paleta de cores coerente com o contexto (ex.: segurança, saúde, meio ambiente);
   • Limites de intensidade (quantidade mínima/máxima de ocorrências);
3. Gerar o SLD completo com os parâmetros otimizados.

3. PostGIS + Python + IA + GeoServer

A seguir, um exemplo completo de automação, do banco ao GeoServer que:

• Conecta-se ao banco PostGIS e coleta estatísticas da camada (contagem e extensão).
• Envia essas informações à IA, que gera um SLD completo com o transform “vec:Heatmap”.
• Publica automaticamente o estilo no GeoServer via REST API.
• O resultado pode ser aplicado imediatamente na camada eventos_ocorrencias.

import psycopg2
import openai
import requests

# Configurações
DB_NAME = "gisdb"
DB_USER = "gis"
DB_PASS = "123"
DB_HOST = "localhost"

GEOSERVER_URL = "http://localhost:8080/geoserver/rest/styles"
GEOSERVER_USER = "admin"
GEOSERVER_PASS = "geoserver"

LAYER_NAME = "eventos_ocorrencias"
STYLE_NAME = "heatmap_eventos"

# 1. Amostrar dados para análise
conn = psycopg2.connect(f"dbname={DB_NAME} user={DB_USER} password={DB_PASS} host={DB_HOST}")
cur = conn.cursor()
cur.execute(f"SELECT COUNT(*), ST_Extent(geom) FROM {LAYER_NAME};")
total, bbox = cur.fetchone()

# 2. Gerar estilo Heatmap com IA
prompt = f"""
Crie um estilo SLD para gerar um heatmap no GeoServer.
Use o transform 'vec:Heatmap' com parâmetros otimizados.
Contexto:
- Camada: {LAYER_NAME}
- Total de pontos: {total}
- Extensão espacial: {bbox}
- O mapa representa ocorrências de eventos.
A paleta de cores deve ir de azul (baixa densidade) a vermelho (alta densidade).
"""

resposta = openai.ChatCompletion.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}]
)

sld_xml = resposta.choices[0].message.content

# 3. Publicar estilo no GeoServer
headers = {"Content-type": "application/vnd.ogc.sld+xml"}
r = requests.post(
    f"{GEOSERVER_URL}?name={STYLE_NAME}",
    data=sld_xml.encode("utf-8"),
    headers=headers,
    auth=(GEOSERVER_USER, GEOSERVER_PASS)
)

if r.status_code in [200, 201]:
    print(f"Estilo '{STYLE_NAME}' publicado com sucesso!")
else:
    print("Erro ao publicar estilo:", r.status_code, r.text)

A saída gerada pelo script será:

<StyledLayerDescriptor version="1.0.0">
  <NamedLayer>
    <Name>eventos_ocorrencias</Name>
    <UserStyle>
      <Title>Heatmap de Ocorrências</Title>
      <FeatureTypeStyle>
        <Transformation>
          <ogc:Function name="vec:Heatmap">
            <ogc:Function name="parameter">
              <ogc:Literal>weightAttr</ogc:Literal>
              <ogc:Literal></ogc:Literal>
            </ogc:Function>
            <ogc:Function name="parameter">
              <ogc:Literal>radiusPixels</ogc:Literal>
              <ogc:Literal>20</ogc:Literal>
            </ogc:Function>
          </ogc:Function>
        </Transformation>
        <Rule>
          <RasterSymbolizer>
            <Opacity>0.7</Opacity>
            <ColorMap type="ramp">
              <ColorMapEntry color="#0000FF" quantity="0" opacity="0"/>
              <ColorMapEntry color="#00FF00" quantity="0.5" opacity="0.7"/>
              <ColorMapEntry color="#FF0000" quantity="1" opacity="1"/>
            </ColorMap>
          </RasterSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

A IA gera não só as cores, mas também parâmetros adaptados ao tamanho da amostra (por exemplo, ajustando o raio se a camada tiver muitos ou poucos pontos).

Você pode evoluir esse fluxo para:

• Rodar diariamente e gerar heatmaps atualizados com novos dados;
• Integrar ao GeoNode, atualizando automaticamente o estilo da camada;
• Usar IA para escolher paletas temáticas (ex.: “vermelho–amarelo” para calor humano, “verde–azul” para vegetação).

Dica: para heatmaps temporais, combine com filtros SQL por data e gere um estilo dinâmico para cada período (ex.: “ocorrências_2025_01.sld”).

4. Conclusão

A combinação de PostGIS + IA + GeoServer permite criar pipelines geoespaciais realmente inteligentes capazes de analisar, gerar e publicar visualizações complexas de forma automática.

Esse tipo de automação é especialmente útil em projetos de monitoramento ambiental, urbano e operacional, onde o volume de dados cresce rapidamente. Veja alguns benefícios:

• Heatmaps automáticos e personalizados sem ajustes manuais.
• IA adaptando parâmetros de renderização conforme o dataset.
• Integração total com GeoServer via REST API.
• Atualização contínua, ideal para dashboards geoespaciais em tempo real.

Gostou desse post? Achou ele útil? Então que tal deixar um comentário ?

Mas o que acontece quando combinamos o poder do PostGIS com a Inteligência Artificial (IA)? A resposta é simples e poderosa: análises espaciais automatizadas, executadas a partir de comandos em linguagem natural — sem precisar escrever SQL manualmente para cada consulta.

Imagine perguntar: “Quais bairros estão a menos de 500 metros dos rios?” ou “Quantos pontos de coleta existem por zona de drenagem?”

E o sistema traduzir isso automaticamente em SQL espacial, executar no PostGIS e retornar o resultado.

Neste post, você vai ver como isso é possível usando IA generativa + PostGIS, com exemplos práticos que podem ser aplicados em pipelines WebGIS reais.

1. A base: Consultas espaciais no PostGIS

O PostGIS fornece um conjunto extenso de funções espaciais, como:

• ST_Within(geomA, geomB) → verifica se uma geometria está dentro de outra;
• ST_Distance(geomA, geomB) → mede a distância entre objetos;
• ST_Intersects(geomA, geomB) → identifica interseções;
• ST_Buffer(geom, raio) → cria zonas de influência;
• ST_Union(geom) → agrega polígonos em uma única geometria.

Essas funções são poderosas, mas escrever consultas SQL complexas pode ser demorado, especialmente em análises exploratórias.

2. Onde entra a IA

A IA atua como uma camada de tradução inteligente: ela entende o que o usuário quer (em linguagem natural) e gera o SQL equivalente em PostGIS.

Assim, é possível automatizar:

• Consultas ad hoc (“quero saber quantos imóveis estão próximos de escolas”);
• Relatórios recorrentes;
• Geração de scripts de análise complexa (buffer + interseção + agregação);
• Pipeline de integração com GeoServer e GeoNode.

3. IA + PostGIS + Python

O fluxo completo é simples:

• O usuário faz uma pergunta em texto.
• A IA interpreta e gera o SQL espacial.
• O script executa o SQL no PostGIS e retorna o resultado.

Veja como fica o script:

import psycopg2
import openai
import pandas as pd

# Configurações
DB = {"dbname": "gisdb", "user": "gis", "password": "123", "host": "localhost"}
MODEL = "gpt-4o-mini"

# Conectar ao PostGIS
conn = psycopg2.connect(**DB)
cur = conn.cursor()

# Entrada em linguagem natural
pergunta = "Liste os bairros que estão a menos de 500 metros dos rios."

# Prompt para IA gerar SQL
prompt = f"""
Você é um assistente especializado em PostGIS.
Com base na pergunta abaixo, gere uma consulta SQL válida para PostgreSQL/PostGIS.
As tabelas disponíveis são:
- bairros (id, nome, geom)
- rios (id, nome, geom)
Pergunta: {pergunta}
"""

resposta = openai.ChatCompletion.create(
    model=MODEL,
    messages=[{"role": "user", "content": prompt}]
)

sql = resposta.choices[0].message.content.strip()
print(" SQL gerado pela IA:\n", sql)

# Executar consulta no banco
cur.execute(sql)
rows = cur.fetchall()

# Exibir resultados
df = pd.DataFrame(rows, columns=["bairro"])
print("\n Bairros próximos dos rios:\n", df)

O resultado desse script será uma lista com os bairros próximos 500 metros dos rios.

A IA compreendeu a intenção e construiu o SQL espacial correto sem que o usuário precisasse saber SQL.

4. Na prática

Podemos transformar esse conceito em uma ferramenta real de automação:

• Um chatbot geoespacial conectado ao PostGIS, que responde perguntas e executa consultas automaticamente.
• Um relatório inteligente, onde as queries são geradas dinamicamente.
• Um backend WebGIS que recebe comandos em texto e alimenta camadas no GeoServer.

Por Exemplo:

“Crie um buffer de 1000 metros ao redor das escolas e publique o resultado no GeoServer.”

A IA gera a tabela no banco (CREATE TABLE buffer_escolas AS SELECT ST_Buffer(geom, 1000)) e faz a chamada REST API do GeoServer para publicar a nova camada. Tudo em um único fluxo automatizado.

Você pode ir além e usar a IA para:

• Gerar relatórios automatizados em texto (HTML ou PDF) com gráficos e mapas;
• Detectar análises espaciais recorrentes e agendá-las;
• Explicar resultados de forma compreensível para gestores não técnicos.

Exemplo de prompt para explicação:

“Explique o resultado da consulta SQL abaixo em linguagem simples e escreva um resumo técnico.”

A IA retorna algo como: “Foram identificados 12 bairros localizados a menos de 500 metros de rios. Essa análise é útil para estudos de vulnerabilidade a inundações e planejamento urbano.”

5. Conclusão

Combinar IA com PostGIS é um passo natural na evolução das análises geoespaciais. Com poucos ajustes, é possível transformar consultas em linguagem natural em SQLs complexos, prontas para execução abrindo caminho para dashboards e sistemas WebGIS inteligentes.

Mas existe um ponto crítico em qualquer infraestrutura GeoNode: A qualidade e a completude dos metadados.

Sem bons metadados, o portal perde valor: os dados se tornam difíceis de localizar, interpretar e reutilizar. E o problema é bem conhecido, quem nunca publicou uma camada com descrição genérica tipo “dados de teste” ou “importado do PostGIS”?

A boa notícia é que, com o apoio da Inteligência Artificial (IA), é possível automatizar grande parte do processo de enriquecimento de metadados, tornando o GeoNode mais inteligente e autodescritivo.

1. O desafio dos metadados no GeoNode

Ao publicar uma camada, o GeoNode gera automaticamente informações básicas como nome, resumo, bounding box, SRC. Mas não consegue:

• Criar descrições detalhadas do conteúdo;
• Gerar palavras-chave contextuais;
• Escrever resumos técnicos e analíticos;
• Padronizar a linguagem entre diferentes camadas.

Isso deixa o catálogo inconsistente, especialmente quando diferentes analistas publicam dados com estilos e linguagens diferentes.

É exatamente esse tipo de trabalho repetitivo e semântico que uma IA generativa pode resolver com perfeição.

2. Como a IA pode ajudar:

Com um modelo de linguagem (LLM) como o GPT, podemos:

1. Analisar o nome da camada, atributos e amostras de dados;
2. Gerar automaticamente:
   • Descrição detalhada (“O que essa camada representa e por que é importante”);
   • Palavras-chave (keywords) baseadas no conteúdo;
   • Sugestões de categoria temática (ex.: “meio ambiente”, “infraestrutura”, “demografia”);
   • Texto de resumo padronizado.
3. Enviar esses metadados diretamente para o GeoNode via API.

3. GeoNode + IA + Python

Vamos montar um pipeline automatizado que:

• Consulta os metadados existentes via API do GeoNode;
• Gera descrições e palavras-chave com IA;
• Atualiza o registro da camada no catálogo.

Veja como ficaria esse script:

import requests
import openai

# Configurações do GeoNode (GeoNode 4.x usa /api/v2/datasets/)
GEONODE_URL = "http://localhost:8000/api/v2/datasets/"
GEONODE_USER = "admin"
GEONODE_PASS = "geonode"

# Configuração da IA
MODEL = "gpt-4o-mini"
# coloque sua chave de API do OpenAI em OPENAI_API_KEY antes de rodar
openai.api_key = "YOUR_OPENAI_API_KEY"

# 1. Obter lista de camadas (datasets)
r = requests.get(GEONODE_URL, auth=(GEONODE_USER, GEONODE_PASS), headers={"Accept":"application/json"})
r.raise_for_status()
layers = r.json().get("results", [])

for layer in layers:
    title = layer.get("title")
    # GeoNode pode usar 'abstract' ou 'description' dependendo da configuração; pegamos ambos
    abstract = layer.get("abstract", "") or layer.get("description", "")
    keywords = layer.get("keywords", []) or []

    # 2. Gerar enriquecimento com IA
    prompt = f"""
    Analise o título e o resumo abaixo e gere:
    1. Uma descrição aprimorada do dado (3 a 4 linhas);
    2. 5 palavras-chave relevantes;
    3. Categoria temática sugerida.
    ---
    Título: {title}
    Resumo atual: {abstract}
    Palavras-chave atuais: {keywords}
    """

    resposta = openai.ChatCompletion.create(
        model=MODEL,
        messages=[{"role": "user", "content": prompt}]
    )

    enriquecido = resposta.choices[0].message.content
    print(f"\nCamada: {title}\n{enriquecido}\n")

    # 3. Atualizar camada no GeoNode (opcional)
    # Atualiza o campo 'abstract' (GeoNode 4.x aceita PATCH /api/v2/datasets/{id}/)
    payload = {"abstract": enriquecido}
    update = requests.patch(
        f"{GEONODE_URL}{layer['id']}/",
        json=payload,
        auth=(GEONODE_USER, GEONODE_PASS),
        headers={"Content-Type": "application/json", "Accept": "application/json"}
    )

    if update.status_code in [200, 202]:
        print("Metadados atualizados com sucesso.")
    else:
        print("Erro ao atualizar:", update.status_code, update.text)

Em resumo:

• O script percorre todas as camadas publicadas.
• Para cada uma, envia o título e resumo atual à IA.
• A IA retorna um texto padronizado e enriquecido, junto com keywords.
• O script atualiza a camada via API REST do GeoNode.

O resultado é um catálogo muito mais coerente, padronizado e informativo sem depender de preenchimento manual.

4. Exemplo prático

Camada original:

• Título: “Limite municipal SC”
• Resumo: “Limites administrativos.”

Após enriquecimento com IA:

Descrição aprimorada:
Esta camada representa os limites municipais oficiais do estado de Santa Catarina, derivados de bases cartográficas oficiais. Pode ser utilizada para análises de planejamento territorial, gestão pública e integração de dados geoespaciais de infraestrutura.

Palavras-chave sugeridas:
limites, municípios, cartografia oficial, Santa Catarina, administração pública

Categoria: Governança / Administração Pública

Em segundos, o dado fica muito mais informativo.

Podemos ir além: se as camadas do GeoNode vêm do PostGIS, o script pode extrair informações diretas do banco:

• Nomes e tipos de campos (geometry, text, numeric);
• Contagem de registros;
• Amostra de valores (ex.: primeiros 10 nomes de municípios);

Esses dados podem ser enviados à IA para gerar descrições ainda mais precisas, contextualizadas com base no conteúdo real da tabela.

5. Conclusão

Integrar IA ao GeoNode transforma o portal em uma plataforma muito mais inteligente, descritiva e autônoma. Você passa a ter metadados consistentes, atrativos e úteis para quem consome os dados sem depender de preenchimento manual.

Além disso pode ter os seguintes benefícios práticos:

• Automação completa do enriquecimento de metadados.
• Padronização linguística e semântica entre camadas.
• Melhor desempenho de busca dentro do GeoNode.
• Economia de tempo na curadoria de dados.
• Catálogo inteligente, com IA atuando como “editor automático” de conteúdo.

Gostou desse post? Deixe um comentário dando sua opinião.

Quem trabalha com GeoServer sabe que definir estilos SLD (Styled Layer Descriptor) é uma das tarefas mais importantes e, ao mesmo tempo, pode ser bastante trabalhosa.

Um estilo mal configurado pode deixar o mapa confuso, pesado ou até inutilizável.

Já um estilo bem planejado torna os dados claros, comunicativos e eficientes.

O problema:
Criar estilos manualmente exige tempo, conhecimento de XML e testes repetitivos.
Definir cores adequadas para diferentes atributos (população, uso do solo, altimetria) é sempre um desafio.

É nesse ponto que a Inteligência Artificial (IA) pode transformar o jogo. Combinando o GeoServer REST API com modelos generativos (IA), é possível:

• Gerar paletas de cores automáticas e consistentes.
• Criar estilos dinâmicos adaptados ao tipo de dado.
• Automatizar a publicação de SLDs, economizando tempo e reduzindo erros.

2. Onde entra a IA

A IA pode atuar em diferentes etapas:

• Geração de paletas de cores automáticas → sugerindo cores distintas, legíveis e com contraste.
• Sugestão de simbologia → identificar o tipo de dado (ponto, linha, polígono) e propor estilos adequados.
• Automação de SLD → gerar automaticamente o XML completo a partir de metadados da camada.
• Explicação/documentação → IA pode comentar o estilo gerado, explicando a lógica.

3. Na prática: GeoServer + Python + IA

Para ajudar na criação de estilos automatizados, o nosso script vai buscar as classes distintas no banco para que a IA possa gerar automaticamente um SLD completo e válido, e na sequencia esse SLD ser publicado no GeoServer via API Rest, ou seja, tudo automatizado com zero edição manual no XML.

import psycopg2
import openai
import requests

# Configurações
DB_NAME = "gisdb"
DB_USER = "gis"
DB_PASS = "123"
DB_HOST = "localhost"

GEOSERVER_URL = "http://localhost:8080/geoserver/rest/styles"
GEOSERVER_USER = "admin"
GEOSERVER_PASS = "geoserver"

LAYER_NAME = "camada_uso_solo"
FIELD_NAME = "uso_solo"
STYLE_NAME = "uso_solo_auto"

# 1. Coletar classes distintas no PostGIS
conn = psycopg2.connect(f"dbname={DB_NAME} user={DB_USER} password={DB_PASS} host={DB_HOST}")
cur = conn.cursor()
cur.execute(f"SELECT DISTINCT {FIELD_NAME} FROM {LAYER_NAME};")
classes = [row[0] for row in cur.fetchall()]

# 2. Pedir à IA paleta + SLD
prompt = f"""
Gere um SLD válido (XML) para a camada {LAYER_NAME},
usando o atributo {FIELD_NAME} como regra de simbologia.
Classes encontradas: {classes}.
Use uma paleta de cores HEX contrastante, acessível e semântica:
- água = azul
- floresta = verde
- urbano = cinza/vermelho
- solo exposto = laranja
- agrícola = amarelo
"""

resposta = openai.ChatCompletion.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}]
)

sld_xml = resposta.choices[0].message.content

# 3. Publicar estilo no GeoServer
headers = {"Content-type": "application/vnd.ogc.sld+xml"}
r = requests.post(
    f"{GEOSERVER_URL}?name={STYLE_NAME}",
    data=sld_xml.encode("utf-8"),
    headers=headers,
    auth=(GEOSERVER_USER, GEOSERVER_PASS)
)

if r.status_code in [200, 201]:
    print(f"Estilo '{STYLE_NAME}' publicado com sucesso!")
else:
    print("Erro ao publicar estilo:", r.status_code, r.text)

Esse processo pode ser facilmente acoplado a um pipeline de publicação de dados:

• Cada vez que uma nova camada for publicada → o script roda.
• Ele gera e publica o estilo de forma automática.
• Você garante consistência visual em todo o projeto WebGIS.

4. Benefícios práticos

• Simbologia automática e inteligente.
• Redução drástica no tempo gasto criando estilos.
• Padronização visual em múltiplas camadas.
• IA atuando como assistente cartográfico.

5. Conclusão

Com esse pipeline, você transforma o trabalho de estilização no GeoServer em um processo rápido, automatizado e padronizado, deixando para a IA a parte mais repetitiva e demorada.

Quem trabalha com bancos de dados geoespaciais sabe que garantir a qualidade dos dados é um dos maiores desafios. Camadas com geometrias duplicadas, sobreposições ilegais, gaps inesperados ou atributos fora do padrão podem comprometer análises, visualizações e publicações WebGIS.

É aí que entra a combinação de PostGIS + Inteligência Artificial (IA). O PostGIS já oferece funções poderosas para validação e topologia, mas com a ajuda da IA podemos automatizar diagnósticos, detectar padrões e até sugerir correções.

Neste post, você vai aprender como montar um pipeline para:

• Detectar inconsistências geométricas com SQL espacial.
• Usar IA para classificar/explicar os erros.
• Automatizar relatórios e alertas em tempo real.

1. Validação com PostGIS

O PostGIS traz funções fundamentais para validar geometrias:

• ST_IsValid(geom) → checa se a geometria é válida.
• ST_IsSimple(geom) → detecta autointersecções.
• ST_DumpPoints(geom) → útil para analisar vértices.
• ST_Overlaps, ST_Intersects, ST_Within → testam relações espaciais.

Exemplo: detectando geometrias inválidas

SELECT id, ST_IsValidReason(geom) AS motivo
FROM camadas
WHERE NOT ST_IsValid(geom);

Aqui já temos um diagnóstico básico, mas a saída costuma ser técnica (ex.: Self-intersection at or near point).

2. Onde entra a IA

A IA pode atuar em três níveis:

• Interpretação → traduzir mensagens técnicas (ST_IsValidReason) para linguagem clara para o usuário. Ex.: “Self-intersection” → “A geometria tem um polígono que se cruza consigo mesmo, possivelmente um erro de digitalização”.
• Classificação de anomalias → identificar o tipo mais comum de erro em um dataset (gaps, duplicatas, sobreposição, atributos ausentes).
• Sugestão de correções → propor SQL ou operações geoespaciais para corrigir automaticamente (ex.: ST_Buffer(geom,0) para auto-correção simples de polígonos).

3. Na prática: PostGIS + Python + IA

Suponha que você tem uma tabela bairros de Floripa no PostGIS e quer validar as geometrias. Veja abaixo a consulta:

SELECT id, nome, ST_IsValid(geom) AS valido,
       ST_IsValidReason(geom) AS motivo
FROM bairros_floripa
WHERE NOT ST_IsValid(geom);

O Resultado seria:

Agora vamos criar um script Python que vai utilizar a IA para automatizar a melhorar esse processo com uma mensagem mais clara para o usuário:

import psycopg2
import openai  # ou outro modelo LLM

# Conexão PostGIS
conn = psycopg2.connect("dbname=gisdb user=gis password=123 host=localhost")
cur = conn.cursor()
cur.execute("""
    SELECT id, nome, ST_IsValidReason(geom) 
    FROM bairros_floripa WHERE NOT ST_IsValid(geom)
""")

erros = cur.fetchall()

for e in erros:
    id_, nome, motivo = e
    prompt = f"""
    Explique de forma simples o erro em uma geometria espacial:
    Erro detectado: {motivo}
    Contexto: Bairro {nome} (ID {id_}).
    """
    explicacao = openai.ChatCompletion.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )
    print(f"{nome}: {explicacao.choices[0].message.content}")

O resultado esperado do script acima é o seguinte:

“Bairro Centro: A geometria está com uma autointersecção. Isso acontece quando o polígono se cruza, criando áreas inválidas. Sugestão: aplique ST_Buffer(geom,0) para corrigir.”

Importante: essa técnica (do Buffer) resolve muitos casos, mas não todos. Em situações mais complexas, é melhor passar por revisão manual.

4. Automação contínua

Podemos transformar isso em um pipeline automatizado:

• Trigger no PostGIS → cada vez que um dado for inserido/atualizado, roda ST_IsValid.
• Armazenar logs em tabela auxiliar → erros_validacao(id, camada, motivo, data).
• Script Python + IA gera relatórios automáticos semanais (PDF/HTML).
• Integração com GeoServer/GeoNode → impedir publicação de camadas com erros graves.

5. Benefícios práticos

• Menos tempo gasto revisando dados manualmente.
• Garantia de que camadas publicadas no GeoServer/GeoNode estão consistentes.
• Processo contínuo de validação, sem depender só de auditorias pontuais.
• IA como aliada na interpretação e automação de relatórios.

6. Conclusão

A integração entre PostGIS e IA é uma das formas mais inteligentes de elevar a qualidade e confiabilidade de dados geoespaciais.
Com isso, você consegue:

• Detectar anomalias automaticamente.
• Explicar erros de forma compreensível para o usuário final.
• Propor correções rápidas, inclusive automatizadas.

A Geocursos está com inscrições abertas para uma nova turma do Curso WebGIS: Crie Mapas Interativos na Web, sem precisar programar!

Aprenda a disponibilizar dados espaciais na internet com uma plataforma WebGIS através de mapas interativos, dashboards, geostories, tudo isso com controle de acesso por nível de usuários e grupos.

Nesse curso você irá aprender:

• Criar seus próprios bancos da dados geográficos
• Realizar consultas e análises espaciais no banco de dados
• Padrões da OGC (WMS, WFS, WCS, WPS)
• Criar simbologias no padrão SLD
• Criar mapas interativos
• Criar dashboards a partir de seus dados geográficos
• Apresentar seus dados de uma forma mais profissional com o GeoStories
• Realizar a manutenção das informações diretamente pelo QGIS
• Como publicar seus dados em um ambiente de produção (na nuvem)

O curso é ideal para estudantes e profissionais de GIS, Geografia, Engenharia, Meio Ambiente, Planejamento Urbano e TI.

Aulas práticas | Ferramentas livres | SIG na Web

Inscreva-se e leve seus dados espaciais para o mundo online!

Acesse: https://geocursos.com.br/webgis
WhatsApp: https://whats.link/geocursos

Neste post, vamos explorar três processos essenciais para qualquer profissional de GIS:

• Clip (recorte espacial)
• Union (união de geometrias)
• Nearest (análise de vizinhança)

Essas operações, quando dominadas, abrem caminho para fluxos de trabalho robustos em monitoramento ambiental, planejamento urbano, saneamento e diversas outras áreas.

1. Clip: Recortando Dados Espaciais

O Clip é usado para recortar uma camada com base na geometria de outra. É muito útil quando você precisa trabalhar apenas com dados de uma região específica.

Suponha que você tenha uma camada nacional de hidrografia e deseja analisar apenas os rios que passam pelo estado de São Paulo.

Request de execução (WPS Execute):

<wps:Execute service="WPS" version="1.0.0"
    xmlns:wps="http://www.opengis.net/wps/1.0.0"
    xmlns:ows="http://www.opengis.net/ows/1.1"
    identifier="gs:Clip">

  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>features</ows:Identifier>
      <wps:Reference mimeType="text/xml"
          xlink:href="http://localhost:8080/geoserver/wfs"
          method="POST">
        <wps:Body>
          <wfs:GetFeature service="WFS" version="1.0.0"
              xmlns:wfs="http://www.opengis.net/wfs">
            <wfs:Query typeName="workspace:rios_brasil"/>
          </wfs:GetFeature>
        </wps:Body>
      </wps:Reference>
    </wps:Input>

    <wps:Input>
      <ows:Identifier>clip</ows:Identifier>
      <wps:Reference mimeType="text/xml"
          xlink:href="http://localhost:8080/geoserver/wfs"
          method="POST">
        <wps:Body>
          <wfs:GetFeature service="WFS" version="1.0.0"
              xmlns:wfs="http://www.opengis.net/wfs">
            <wfs:Query typeName="workspace:estado_sp"/>
          </wfs:GetFeature>
        </wps:Body>
      </wps:Reference>
    </wps:Input>
  </wps:DataInputs>

  <wps:ResponseForm>
    <wps:RawDataOutput mimeType="application/json">
      <ows:Identifier>result</ows:Identifier>
    </wps:RawDataOutput>
  </wps:ResponseForm>
</wps:Execute>

Esse request retorna apenas os rios contidos dentro do polígono de São Paulo, em formato GeoJSON.

2. Union: Combinando Camadas e Geometrias

O Union permite integrar duas ou mais camadas em uma única saída, preservando atributos e geometrias. É muito usado para cruzar informações espaciais de diferentes fontes.

Imagine que você tem camadas de áreas de preservação e áreas urbanizadas, e precisa identificar interseções ou criar uma camada consolidada.

Exemplo de Request:

<wps:Execute service="WPS" version="1.0.0"
    xmlns:wps="http://www.opengis.net/wps/1.0.0"
    xmlns:ows="http://www.opengis.net/ows/1.1"
    identifier="JTS:union">

  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>geom1</ows:Identifier>
      <wps:Data>
        <wps:ComplexData mimeType="application/wkt"><![CDATA[
          POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))
        ]]></wps:ComplexData>
      </wps:Data>
    </wps:Input>

    <wps:Input>
      <ows:Identifier>geom2</ows:Identifier>
      <wps:Data>
        <wps:ComplexData mimeType="application/wkt"><![CDATA[
          POLYGON((5 5, 15 5, 15 15, 5 15, 5 5))
        ]]></wps:ComplexData>
      </wps:Data>
    </wps:Input>
  </wps:DataInputs>

  <wps:ResponseForm>
    <wps:RawDataOutput mimeType="application/gml+xml">
      <ows:Identifier>result</ows:Identifier>
    </wps:RawDataOutput>
  </wps:ResponseForm>
</wps:Execute>

O resultado é um polígono unificado que representa a soma das áreas fornecidas.

3. Nearest: Identificando o Elemento Mais Próximo

O processo Nearest é essencial para análises de vizinhança. Ele encontra a feição mais próxima de um ponto ou conjunto de pontos.

Agora vamos supor que precisamos encontrar o hospital mais próximo de um acidente registrado em tempo real ou identificar a estação de tratamento de água mais próxima de uma comunidade rural.

Exemplo de Request

<wps:Execute service="WPS" version="1.0.0"
    xmlns:wps="http://www.opengis.net/wps/1.0.0"
    xmlns:ows="http://www.opengis.net/ows/1.1"
    identifier="gs:Nearest">

  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>features</ows:Identifier>
      <wps:Reference mimeType="text/xml"
          xlink:href="http://localhost:8080/geoserver/wfs"
          method="POST">
        <wps:Body>
          <wfs:GetFeature service="WFS" version="1.0.0"
              xmlns:wfs="http://www.opengis.net/wfs">
            <wfs:Query typeName="workspace:hospitais"/>
          </wfs:GetFeature>
        </wps:Body>
      </wps:Reference>
    </wps:Input>

    <wps:Input>
      <ows:Identifier>point</ows:Identifier>
      <wps:Data>
        <wps:ComplexData mimeType="application/wkt"><![CDATA[
          POINT(-46.6333 -23.5505)
        ]]></wps:ComplexData>
      </wps:Data>
    </wps:Input>
  </wps:DataInputs>

  <wps:ResponseForm>
    <wps:RawDataOutput mimeType="application/json">
      <ows:Identifier>result</ows:Identifier>
    </wps:RawDataOutput>
  </wps:ResponseForm>
</wps:Execute>

O retorno é o hospital mais próximo do ponto fornecido.

4. Boas Práticas e Observações

• O desempenho das operações depende do volume de dados. Prefira recortes prévios ou filtros WFS antes de chamar o WPS.
• Para grandes análises (Union de muitos polígonos ou Nearest em bases massivas), utilize execução assíncrona.
• Combine o WPS com clientes como QGIS ou bibliotecas Python (OWSLib, GeoPandas) para integrar análises em fluxos automatizados.
• Sempre valide as geometrias antes do Union, pois polígonos inválidos podem gerar erros.