Planeta SIG - Portugal

<figure class="wp-block-image size-large"></figure>

La Asociación gvSIG pasa a formar parte de la Red Iberoamericana de Observación Territorial (RIDOT), una iniciativa que reúne a instituciones y profesionales comprometidos con el análisis, la gestión y la comprensión del territorio en el ámbito iberoamericano.

Esta incorporación refuerza el compromiso de la Asociación gvSIG con la colaboración internacional y con el impulso de infraestructuras de datos espaciales, estándares abiertos y tecnologías basadas en software libre como pilares para la toma de decisiones y la gestión territorial.

La Red constituye un espacio clave para abordar de forma conjunta retos como el cambio climático, la gestión del riesgo, la planificación territorial o la gobernanza, promoviendo el intercambio de conocimiento y la generación de sinergias entre sus miembros.

Desde la Asociación gvSIG se contribuirá activamente a este ecosistema, aportando experiencia en el desarrollo e implantación de soluciones geomáticas abiertas y en la construcción de modelos basados en interoperabilidad y soberanía tecnológica.

Prezado leitor,

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.

1. Atualização do sistema

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

2. Instalação do Docker

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.

3. Estrutura do projeto

Agora vamos organizar os diretórios do projeto:

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

4. Download dos plugins do GeoServer

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

5. Dockerfile do GeoServer

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.

6. Arquivo Docker Compose

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

7. Criar banco STAC (pgstac)

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.

8. Criar Collection

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

9. Criar itens

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).

10. Adapter STAC (compatibilidade com GeoServer)

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

11. Nginx

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.

12. Conclusão

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.

El concepto de Internet de las Cosas (IoT) se refiere a la red de objetos físicos que están equipados con sensores y que se conectan a internet para recopilar e intercambiar datos. Los sensores recopilan información del entorno como temperatura o movimiento para enviarlos por internet a un centro de almacenamiento donde puede ser procesada. ...

Leer más

Cómo recoger datos en tiempo real de sensores IoT: ejemplo con aviones

<figure class="wp-block-image size-large"></figure>

Hace ya algunos años nació gvSIG Batoví, una iniciativa orientada a acercar los Sistemas de Información Geográfica (SIG) al ámbito educativo en Uruguay, especialmente en educación primaria y secundaria.

Su objetivo sigue siendo plenamente vigente: facilitar a docentes y alumnado la comprensión del territorio a través de herramientas geoespaciales abiertas.

gvSIG Batoví es una distribución de gvSIG Desktop adaptada al entorno educativo, pensada para que el uso de los SIG en el aula sea accesible, práctico y motivador.

Su enfoque va mucho más allá de la enseñanza de la geografía. Puede aplicarse a cualquier materia con componente territorial, como historia, ciencias naturales, economía o sociología… o una combinación de todas ellas que permita a los estudiantes conocer su entorno.

A través de mapas temáticos y análisis espacial, el alumnado puede interactuar con la información, comprender mejor los fenómenos y desarrollar pensamiento crítico sobre el territorio.

Además:

• Facilita el aprendizaje mediante la interactividad
• Permite compartir ejercicios e información entre docentes y alumnado
• Es extensible, favoreciendo su evolución continua
• Es software libre (licencia GNU/GPL), lo que garantiza su uso, estudio, adaptación y distribución sin restricciones

Desde sus inicios gvSIG Batoví ha estado especialmente vinculado a iniciativas educativas en Uruguay, como el conocido curso-concurso que ha permitido a muchos estudiantes iniciarse en el mundo de la geomática.

Descarga gvSIG Batoví

Queremos que este recurso siga siendo útil para la comunidad educativa, por lo que puedes descargarlo y empezar a utilizarlo desde aquí:

Descarga de gvSIG Batoví

El mercado laboral GIS está experimentando una transformación profunda en España. La evolución tecnológica, el auge del análisis de datos y la digitalización de territorios están redefiniendo los perfiles más demandados y las habilidades necesarias para acceder a un empleo en este sector. En este artículo analizamos en detalle cómo está el mercado laboral GIS en 2025–2026, qué ...

Leer más

📊Mercado laboral GIS en España 2025–2026

El mercado laboral GIS está experimentando una transformación profunda en España. La evolución tecnológica, el auge del análisis de datos y la digitalización de territorios están redefiniendo los perfiles más demandados y las habilidades necesarias para acceder a un empleo en este sector. En este artículo analizamos en detalle cómo está el mercado laboral GIS ...

Leer más

Mercado laboral GIS en España 2025–2026

Dados raster estão entre os datasets mais pesados do mundo GIS. Ortomosaicos, imagens de satélite e modelos digitais de elevação frequentemente possuem dezenas ou até centenas de gigabytes.

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

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

Parâmetro	Função
-of COG	gera um Cloud Optimized GeoTIFF
COMPRESS=LZW	compressão sem perdas
BLOCKSIZE=512	otimização para leitura em blocos
BIGTIFF=YES	necessário para arquivos grandes

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.

El pasado 11 de marzo tuve el placer de impartir el webinar “Geomática hoy: del levantamiento al gemelo digital con datos abiertos, IA y estándares”, organizado por la Delegación Territorial de la Comunidad Valenciana y Región de Murcia del Ilustre Colegio Oficial de Ingeniería Geomática y Topográfica (COIGT) en colaboración con la Asociación gvSIG.

En la sesión compartí una reflexión sobre cómo está evolucionando la geomática: desde los levantamientos tradicionales hasta enfoques más avanzados basados en datos abiertos, interoperabilidad, análisis geoespacial e inteligencia artificial, que permiten construir desde inventarios territoriales hasta gemelos digitales del territorio para apoyar la toma de decisiones.

Para quienes no pudieron asistir en directo, el vídeo del webinar ya está disponible y puede verse a continuación. Espero que resulte interesante y que sirva para seguir reflexionando sobre hacia dónde está evolucionando nuestro sector.

<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"></figure>

O uso de geotecnologias na gestão territorial deixou de ser algo restrito a especialistas. Cada vez mais órgãos públicos, municípios e profissionais utilizam ferramentas de geoprocessamento para compreender o território, identificar riscos e apoiar decisões. 

Pensando nisso, a Secretaria de Estado de Defesa Civil do Rio de Janeiro disponibilizou um Manual de Georreferenciamento - QGIS aplicado a Defesa Civil: gestão de riscos e desastres, um material que ensina, de forma prática, como utilizar um dos softwares SIG mais populares do mundo para organizar e analisar informações espaciais. 

Neste post, vamos explorar os principais pontos do documento e entender por que ele pode ser útil tanto para iniciantes quanto para profissionais da área.

O objetivo do manual da Defesa Civil

O manual produzido pela Defesa Civil do Rio de Janeiro tem um objetivo claro: capacitar técnicos e gestores públicos a utilizar geotecnologias para apoiar ações de prevenção e resposta a desastres.

A ideia é que municípios e equipes técnicas consigam:

• organizar dados geográficos
• mapear áreas de risco
• analisar eventos como deslizamentos ou enchentes
• produzir mapas temáticos para tomada de decisão

Esse tipo de abordagem é fundamental em políticas de gestão de riscos e planejamento territorial.

Por que esse manual é relevante

Embora o documento tenha sido criado com foco na Defesa Civil, o conteúdo é útil para diversos perfis:

• estudantes de geografia, engenharia ambiental e geoprocessamento
• analistas ambientais
• profissionais de planejamento urbano
• gestores públicos
• pesquisadores

Além disso, o material demonstra algo importante: o poder das ferramentas abertas para democratizar o acesso à informação geográfica. Hoje, com softwares como o QGIS, qualquer profissional pode construir mapas complexos e análises espaciais sem depender de soluções proprietárias.

O Manual da Defesa Civil do RJ é um excelente material introdutório para quem deseja começar a trabalhar com geoprocessamento aplicado à gestão territorial. Mais do que ensinar comandos do software, o documento mostra como dados espaciais podem apoiar decisões estratégicas, especialmente em áreas críticas como prevenção de desastres e planejamento urbano.

Se você trabalha com território, meio ambiente ou análise espacial, vale a pena explorar esse material.

O documento está disponível neste link: https://defesacivil.rj.gov.br/images/DOC/Manual-Georreferenciamento-QGIS.pdf

En esta entrada de nuestro blog vamos a comentarte las mejoras y novedades más destacadas de la nueva versión de QGIS, la 4.0 que lleva como nombre Norrköping. QGIS 4.0 es la versión más potente hasta la fecha.  Descubre las nuevas funciones, mejoras y todo lo que hace de esta versión un momento histórico. QGIS se encuentra bajo ...

Leer más

QGIS 4.0 Norrköping: la versión más potente hasta la fecha

Quando trabalhamos com ortomosaicos ou rasters muito grandes, um dos principais desafios é como armazenar e publicar esses dados com boa performance, sem sobrecarregar o servidor GIS.

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

Parâmetro	Função
-of COG	gera um Cloud Optimized GeoTIFF
COMPRESS=LZW	compressão sem perdas
BLOCKSIZE=512	otimização para leitura em blocos
BIGTIFF=YES	necessário para arquivos grandes

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.

<figure class="wp-block-image size-large"></figure>

Hoy tengo el placer de impartir el webinar “Geomática hoy: del levantamiento al gemelo digital con datos abiertos, IA y estándares”, organizado por la Delegación Territorial de la Comunidad Valenciana y Región de Murcia del Ilustre Colegio Oficial de Ingeniería Geomática y Topográfica (COIGT).

La idea de la sesión es compartir una reflexión sobre el momento tan interesante que vive la geomática. Nunca antes habíamos tenido a nuestra disposición tantos datos, tanta capacidad de procesamiento y tantas herramientas para transformar la información geoespacial en conocimiento útil para la toma de decisiones.

Durante el webinar haré un recorrido que conecta la topografía y la cartografía tradicional con tecnologías que hoy forman parte del día a día de muchos proyectos: teledetección, SIG, Infraestructuras de Datos Espaciales, estándares abiertos como OGC e INSPIRE y el papel creciente de la inteligencia artificial en el análisis territorial.

También hablaré de cómo, a partir de datos abiertos e interoperabilidad, se pueden construir soluciones que van desde inventarios y gestión catastral hasta gemelos digitales o cuadros de mando para la gestión del territorio.

Este webinar forma parte de un ciclo organizado por el COIGT, con la idea de compartir experiencias, reflexiones y tecnologías relacionadas con la información geográfica.

Además, en futuras sesiones profundizaremos en algunas de las herramientas del ecosistema gvSIG, como gvSIG Desktop, gvSIG Online o gvSIG Mapps, y en cómo pueden aplicarse en distintos ámbitos profesionales.

La sesión se celebra online entre las 17:00 y las 18:00, incluyendo un turno final de preguntas.

Espero que resulte interesante y que sirva para reflexionar sobre hacia dónde está evolucionando la geomática.

Inscripción aquí

<figure class="wp-block-image size-large"></figure>

In recent days, the Roadmap to Accelerate Digital Sovereignty in Spain has been presented, a document that reflects something that has been becoming increasingly clear for some time now: digital sovereignty has ceased to be an abstract concept and has become a strategic issue. We are no longer talking only about innovation, but about decision-making capacity, resilience, technological autonomy, and control over critical infrastructures. Technological dependence is a structural vulnerability.

The document points to a key idea: Europe and Spain cannot limit themselves to consuming technologies developed by others. When a public administration, a company, or a public institution depends on technologies it does not control, on platforms it cannot audit, on licences that can change unilaterally, and on infrastructures that respond to external interests, it is not innovating: it is taking on a strategic risk.

And that risk does not affect technology alone. It affects the ability to decide, to plan, to ensure continuity, to protect data, to guarantee public services, and to sustain long-term policies. The question is why we continue to build critical parts of our administrations and organisations on technologies we do not control.

That is why the answer cannot remain at the level of regulation alone. It is necessary to invest, deploy our own infrastructures, strengthen the use of open standards, and promote technological solutions that can be audited, evolved, and governed within our own institutional framework.

In that context, it is especially relevant that the roadmap explicitly mentions the promotion of free software and open source within public administration, as well as the need to connect Spain’s public digital infrastructure with the European one and to strengthen domestic technological capabilities.

That is where initiatives such as gvSIG fully make sense. gvSIG is not just software. It is, and has always been, a practical commitment to digital sovereignty.

Because talking about digital sovereignty also means talking about the concrete tools with which public administrations manage their territory, their information, and their services. It means asking whether an administration can retain control over its geospatial infrastructure, its data, its processes, and the future evolution of its systems.

Today, gvSIG is a suite, a digital infrastructure, a catalogue of solutions based on free software, open standards, and interoperability. It is an ecosystem that enables administrations and organisations to build and maintain their own Spatial Data Infrastructures, geoportals, and territorial management systems without depending on unilateral decisions by third parties, without becoming trapped by restrictive licences, and with a real capacity to adapt over the long term.

A large share of the critical information managed by public administrations has a territorial dimension: urban planning, emergencies, the environment, mobility, cadastre, infrastructure, public services, security, defence… When that technological layer depends entirely on closed vendors, dependency is not only technical: it is also organisational and strategic.

There is a clear risk in continuing to accept as normal a dependency that compromises the autonomy of our institutions.

When Europe and Spain speak about digital sovereignty, public digital infrastructure, free software, and technological autonomy, this is not a debate that is alien to gvSIG. All of this has been part of gvSIG’s DNA for years. We are looking at a framework that reinforces the relevance of projects that have already been demonstrating, in practice, that another way of building technology is possible.

<figure class="wp-block-image size-large"></figure>

En los últimos días se ha presentado la Hoja de Ruta para acelerar la soberanía digital en España, un documento que refleja algo que desde hace tiempo resulta cada vez más evidente: la soberanía digital ha dejado de ser un concepto abstracto para convertirse en una cuestión estratégica. Ya no hablamos solo de innovación, sino de capacidad de decisión, resiliencia, autonomía tecnológica y control sobre infraestructuras críticas. La dependencia tecnológica es una vulnerabilidad estructural.

El documento apunta a una idea clave: Europa y España no pueden limitarse a consumir tecnologías desarrolladas por terceros. Cuando una administración, una empresa o una institución pública depende de tecnologías que no controla, de plataformas que no puede auditar, de licencias que pueden cambiar unilateralmente y de infraestructuras que responden a intereses ajenos, no está innovando: está asumiendo un riesgo estratégico.

Y ese riesgo no afecta solo a la tecnología. Afecta a la capacidad de decidir, de planificar, de garantizar continuidad, de proteger datos, de asegurar servicios públicos y de sostener políticas a largo plazo. La pregunta es por qué seguimos construyendo piezas críticas de nuestras administraciones y organizaciones sobre tecnologías que no controlamos.

Por eso, la respuesta no puede quedarse en la regulación. Hace falta invertir, desplegar infraestructuras propias, reforzar el uso de estándares abiertos y promover soluciones tecnológicas que puedan ser auditadas, evolucionadas y gobernadas desde nuestro propio marco institucional.

En ese contexto, resulta especialmente relevante que la hoja de ruta mencione de forma expresa el impulso al software libre y al código abierto en la Administración, así como la necesidad de conectar la infraestructura pública digital española con la europea y de fortalecer capacidades tecnológicas propias.

Ahí es donde iniciativas como gvSIG adquieren todo su sentido. gvSIG no es solo software. Es, siempre ha sido, una apuesta práctica por la soberanía digital.

Porque hablar de soberanía digital también es hablar de las herramientas concretas con las que las administraciones públicas gestionan su territorio, su información y sus servicios. Es hablar de si una administración puede mantener el control sobre su infraestructura geoespacial, sobre sus datos, sobre sus procesos y sobre la evolución futura de sus sistemas.

Hoy día gvSIG es una suite, una infraestructura digital, un catálogo de soluciones basadas en software libre, estándares abiertos e interoperabilidad. Un ecosistema que permite a administraciones y organizaciones construir y mantener sus propias Infraestructuras de Datos Espaciales, geoportales y sistemas de gestión territorial sin depender de decisiones unilaterales de terceros, sin quedar atrapadas por licencias restrictivas y con capacidad real de adaptación a largo plazo.

Buena parte de la información crítica de una administración tiene una componente territorial: urbanismo, emergencias, medio ambiente, movilidad, catastro, infraestructuras, servicios públicos, seguridad, defensa… Cuando esa capa tecnológica depende por completo de proveedores cerrados, la dependencia no es solo técnica: es también organizativa y estratégica.

Hay un riesgo claro en seguir aceptando como normal una dependencia que compromete la autonomía de nuestras instituciones.

Cuando desde Europa y desde España se habla de soberanía digital, de infraestructura pública digital, de software libre y de autonomía tecnológica, no estamos ante un debate ajeno, todo eso forma parte, desde hace años, del ADN de gvSIG. Estamos ante un marco que refuerza la relevancia de proyectos que ya vienen demostrando, en la práctica, que otra forma de construir tecnología es posible.

La nueva versión gvSIG Desktop 2.7 incluye la herramienta de Swipe o Cortinilla. Con esta herramienta es posible comparar cartografía diferente de forma sencilla, como por ejemplo dos ortofotos de años diferentes.

El funcionamiento de esta herramienta es a partir de dos vistas diferentes, donde en cada una de ellas se deberá tener una de las capas a comparar. El usuario podrá elegir la opción de realizar cortinilla de forma vertical u horizontal, y se aplicará sobre las capas que se tenga visibles en ese momento en las dos vistas. Una vez seleccionadas ya solo deberá desplazar la barra central horizontalmente o verticalmente para poder ver las diferencias.

En este vídeo te mostramos el funcionamiento:

Las consultas espaciales en bases de datos pueden volverse extremadamente lentas cuando el volumen de datos crece o cuando no están correctamente optimizadas. Si trabajas con miles (o millones) de geometrías en PostGIS, seguramente te ha pasado: Una consulta que antes tardaba segundos ahora tarda minutos. Un ST_Intersects bloquea el servidor. El visor SIG parece ...

Leer más

Cómo optimizar consultas espaciales en PostGIS

O GeoAmapá é um complemento desenvolvido para o QGIS com o objetivo de facilitar consultas territoriais no estado do Amapá. A ferramenta permite selecionar uma área diretamente pela extensão visível no mapa e consultar automaticamente diferentes bases oficiais, como CAR, SIGEF/INCRA, Terras Indígenas, Unidades de Conservação, Assentamentos e Direitos Minerários. O resultado é uma camada temporária contendo apenas as feições que interceptam o retângulo selecionado, tornando a análise mais rápida, organizada e eficiente.

A proposta é simples: você define a área de interesse e o plugin retorna apenas os dados relevantes para aquela região.

Instale o plugin

No QGIS, vá em: Complementos → Gerenciar e Instalar complementos. Pesquise por GeoAmapá e clique em Instalar. Após instalado, o botão da ferramenta aparecerá na barra do QGIS e também no menu.

Instalar complemento GeoAmapá.

Navegue até a área de interesse

Antes de abrir o complemento, aproxime o mapa até a região que deseja consultar. A ferramenta utiliza exatamente a área visível na tela como referência para a busca.

💡Dica: quanto menor a área visível, mais rápida e precisa será a consulta.

Abra o GeoAmapá

Clique no botão do complemento e capture a extensão. O complemento irá preencher automaticamente o campo com as coordenadas do retângulo atual da tela. Esse retângulo representa a área que será usada como filtro espacial. 

Atenção: se você alterar o zoom ou mover o mapa, é necessário clicar novamente em capturar para atualizar a área.

No menu suspenso, selecione a base desejada. Cada consulta é feita individualmente.

Clique em Consultar. O GeoAmapá irá:

• Verificar se a área não ultrapassa o limite máximo permitido.
• Consultar a base selecionada.
• Criar uma camada temporária contendo apenas as feições que interceptam a área.

Se existirem feições na área, uma nova camada será adicionada ao painel do QGIS. Se não houver registros para aquela região, o plugin exibirá uma mensagem informando que não existem feições na área selecionada.

O GeoAmapá foi desenvolvido para tornar a análise territorial mais objetiva e operacional dentro do QGIS, reduzindo tempo de busca e facilitando a visualização de sobreposições.

Uma das maiores limitações das análises espaciais tradicionais é que todas as áreas são calculadas em 2D. Ou seja: o QGIS, ArcGIS, PostGIS e praticamente qualquer SIG mede área projetada no plano horizontal, mas o terreno não é plano.

Uma área em encosta, morro ou montanha pode ser significativamente maior do que a área cartográfica. Para resolver isso desenvolvi o plugin: Terrain Surface Area (DEM). O plugin calcula a área real da superfície do terreno de um polígono usando um Modelo Digital de Elevação (DEM). Ele não aproxima por triangulação, ele usa o gradiente da superfície derivado do raster.

O problema da área 2D

Quando você mede um polígono no SIG:

$$A_{2D}=\acute{a}reaprojetadanoplano$$

A2D​ = área projetada no plano. Mas a área verdadeira é:

$$A_{real}>A_{2D\mathrm{<br>}}$$

Exemplo simples. Imagine um terreno inclinado 0°:

$$A_{real}=\frac{A_{2D}}{\cos (\theta )}$$

$$A_{real}=\frac{A_{2D}}{\cos (30\mathrm{°})}=1.1547\times A_{2D}$$

Ou seja: 15,47% maior

Agora imagine isso distribuído pixel a pixel no relevo.

O que o plugin retorna

Para cada polígono ele cria 4 campos:

Campo	Significado
AREA_2D_M2	área cartográfica
AREA_SURF_M2	área real da superfície
SURF_RATIO	fator de relevo
DEM_COV_PCT	cobertura válida do DEM

O significado do SURF_RATIO

Esse é o campo mais importante. Ele indica o fator de rugosidade do terreno: 

$$$$

$$SURF\mathrm{\_}RATIO=\frac{\acute{A}reareal}{\acute{A}reaplana}$$

SURF_RATIO	Terreno	O que significa na prática
1.00	plano	área praticamente horizontal
1.01 – 1.03	suave ondulado	pequenas variações
1.03 – 1.08	ondulado	relevo perceptível
1.08 – 1.15	forte ondulado	encostas frequentes
1.15 – 1.30	montanhoso	morros dominantes

Interpretação intuitiva. Você pode pensar assim:

SURF_RATIO − 1 = porcentagem de aumento de área

Exemplo:

Ratio	Aumento real
1.02	+2% de terreno
1.10	+10% de terreno
1.25	+25% de terreno

O DEM_COV_PCT (confiabilidade)

Esse campo indica quanto do polígono tinha dados válidos no DEM.

Valor	Significado
100	cálculo totalmente confiável
90–99	confiável
70–90	usar com cautela
<70	resultado pode não representar o terreno

Se for baixo, normalmente existe: 

• sombra de radar (parte oculta)
• borda do raster
• NoData

Tutorial de uso

Abra o QGIS e instale o complemento Terrain Surface Area.

Carregue:

• um polígono
• um DEM

Abra na caixa de ferramenta do QGIS, algoritmo: Processing Toolbox → Terrain analysis → Terrain Surface Area (DEM)

Configure:

Input polygons → camada vetorial
Elevation raster → DEM
Slope method:

1. Horn — recomendado para a maioria dos MDEs
2. Zevenbergen & Thorne — mais suave, pode ser sensível a ruído.

Prezado leitor,

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.

O Terrain Surface Area é um plugin para QGIS que calcula a área real da superfície do terreno utilizando um Modelo Digital de Elevação (DEM). Diferente da medição tradicional do SIG, que considera apenas a área projetada no plano horizontal (2D), este plugin incorpora a variação do relevo no cálculo, estimando a superfície inclinada pixel a pixel. 

Na prática, isso significa que ele mede o terreno como ele realmente é, e não apenas sua “projeção” no mapa. A principal diferença está justamente aí: enquanto a área convencional representa a projeção cartográfica, o Terrain Surface Area considera a inclinação do terreno, podendo revelar aumentos significativos em áreas localizadas em encostas ou regiões montanhosas.

Abra o QGIS, adicione o raster (neste caso um SRTM) e o polígono de interesse. Vale ressaltar que os arquivos devem estar em sistema de coordenadas projetada.

Instale o complemento TERRAIN SURFACE AREA através do repositório oficial do QGIS.

Instalar complemento Terrain Surface Area

En este artículo te enseñamos cómo crear un mapa de flujo radial en QGIS paso a paso, utilizando como ejemplo vuelos con destino Madrid. Aprenderás a generar líneas radiales mediante círculos máximos (Great circle) usando el complemento Shape Tools. Un mapa de flujo es una técnica cartográfica utilizada para representar el movimiento de personas, bienes ...

Leer más

Cómo crear un mapa de flujo radial en QGIS paso a paso (ejemplo práctico de vuelos)

Hemos actualizado nuestro Curso online de Visores Webmapping con Leaflet para dar un paso más allá e incorporar MapLibre, una de las tecnologías más potentes y demandadas actualmente en el desarrollo de cartografía web avanzada. Hasta ahora trabajábamos en profundidad con Leaflet, una librería ligera y muy extendida. Con esta ampliación, el curso evoluciona hacia ...

Leer más

Nuevo curso online de webmapping, ahora con MapLibre

En el mundo de los Sistemas de Información Geográfica, el código abierto no es solo una alternativa tecnológica: es un modelo de innovación, colaboración y sostenibilidad. En MappingGIS llevamos años trabajando con QGIS como herramienta central de nuestra formación especializada en SIG. Nuestro compromiso con el software libre no se ha limitado al uso. Fuimos ...

Leer más

Apoyo al código abierto: el compromiso de MappingGIS con QGIS

Prezados leitores,

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.

<figure class="wp-block-image size-full"></figure>

What does it mean to speak about European digital infrastructure? It means:

• Use of open standards (such as those promoted by the Open Geospatial Consortium).
• Compliance with regulatory frameworks such as INSPIRE.
• A real possibility of self-hosting.
• Independence from unilateral changes in licenses or terms of use.
• The ability to audit, evolve, and adapt the system over the long term.

Europe has clearly defined its commitment to the digital commons and technological sovereignty.
But that strategy is not materialized through declarations. It is materialized through real infrastructures.

Within this framework, gvSIG is more than a technology: it constitutes a digital infrastructure.

Today, the gvSIG brand represents an ecosystem of solutions — the gvSIG Suite — characterized by being:

• Free and open-source software
• Standards-based
• Modular
• Interoperable
• Evolvable

Both on the web and complemented by desktop and mobile products, the gvSIG Suite enables the deployment of complete Spatial Data Infrastructures, aligned with European standards and fully controlled by the organization implementing them.

This means:

• Own servers or trusted hosting environments
• Integration with administrative systems
• Adaptation to local regulations
• Development of specific extensions
• Progressive scalability

No dependencies.

With the gvSIG Suite, we can build a territorial digital infrastructure that:

• Enables governance of sensitive data
• Ensures long-term continuity
• Reduces future risks
• Strengthens internal technical capacities
• Generates reusable knowledge

In the geospatial domain, the gvSIG Suite has become a structural component of digital public administration.

<figure class="wp-block-image size-large"></figure>

¿Qué significa hablar de infraestructura digital europea? Significa:

• Uso de estándares abiertos (como los promovidos por el Open Geospatial Consortium).
• Cumplimiento de marcos normativos como la directiva INSPIRE.
• Posibilidad real de autohospedaje.
• Independencia frente a cambios unilaterales de licencias o condiciones de uso.
• Capacidad de auditar, evolucionar y adaptar el sistema a largo plazo.

Europa ha definido claramente su apuesta por el bien común digital y la soberanía tecnológica. Pero esa estrategia no se concreta en declaraciones. Se concreta en infraestructuras reales.

En este marco gvSIG es más que una tecnología: se constituye como una infraestructura digital. Hoy la marca gvSIG representa un ecosistema de soluciones, la Suite gvSIG, caracterizado por ser:

• Software libre y abierto
• Basado en estándares
• Modular
• Interoperable
• Evolucionable

Tanto en web como complementada por los productos de escritorio y movilidad, la Suite gvSIG permite desplegar Infraestructuras de Datos Espaciales completas, alineadas con estándares europeos y plenamente controladas por la organización que las implementa.

Eso significa:

• Servidores propios o en entornos de confianza
• Integración con sistemas administrativos
• Adaptación a normativa local
• Desarrollo de extensiones específicas
• Escalabilidad progresiva

Sin dependencias. Con la Suite gvSIG podemos construir una infraestructura digital territorial que:

• Permite gobernar datos sensibles.
• Garantiza continuidad en el tiempo.
• Reduce riesgos futuros.
• Refuerza capacidades técnicas internas.
• Genera conocimiento reutilizable.

En el ámbito geoespacial, la Suite gvSIG se ha convertido en un componente estructural de la administración digital.

E-book disponível para download no repositório da UFPA. Seus organizadores são Eder Mileno Silva De Paula e Emanuel Lindemberg Silva Albuquerque e está dividido em 9 capítulos. 

• Leia também: Livro de "Fotogrametria Digital" disponível para download

O e-book está disponível nesse link, clique aqui

Se você trabalha com GIS/QGIS e ainda depende de cliques, processos manuais e retrabalho, chegou a hora de mudar isso.

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

AI Segmentation by Terralab es un complemento para QGIS que permite segmentar objetos desde imágenes ráster utilizando Inteligencia Artificial. En lugar de dibujar polígonos manualmente, el complemento detecta objetos automáticamente a partir de simples clics del usuario y genera geometrías vectoriales precisas a partir de esos elementos. Publicado en el repositorio oficial de complementos de ...

Leer más

Segmentación automática con IA en QGIS: AI Segmentation by Terralab

La nueva versión 2.7 de gvSIG Desktop incluye una nueva calculadora de campos, cuyas principales ventajas son, por un lado, que se pueden rellenar varios campos a la vez, y por otro, que ha mejorado significativamente el rendimiento cuando se pretenden rellenar muchos registros a la vez, al no cargarse en memoria todos ellos sino por bloques.

La nueva calculadora se basa en la herramienta de actualizar tabla que se había incluido en la versión anterior, donde se había mejorado la parte de rellenado de registros. Ahora dispone de una pestaña “Opciones” donde se puede seleccionar el número de registros en los que se quiere que termine edición y reinicie. De esa forma no carga todos los datos en memoria y no bloquea el equipo, evitando así también posibles pérdidas de datos.

Por otro lado, permite rellenar varios campos a la vez, cada uno con su fórmula, indicando el usuario qué campos quiere rellenar. Si se tiene seleccionado un campo de la tabla cuando se abre la calculadora de campos, ese es el campo que se queda marcado para insertar la fórmula a ejecutar. Si no se tiene ninguno seleccionado se activan todos, por lo que habría que desactivar los que no se desee rellenar.

Otra novedad es que no hace falta comenzar edición para poder utilizar la calculadora de campos.

QGIS es una herramienta GIS profesional diseñada para el análisis, la edición y la gestión avanzada de datos geoespaciales. Google Maps, por su parte, es una de las plataformas de cartografía más conocidas y utilizadas a nivel mundial, orientada principalmente a la visualización y navegación. Aunque cumplen funciones muy distintas, ambas pueden convivir dentro de ...

Leer más

5 plugins imprescindibles de QGIS para trabajar con Google Maps

O presente artigo foi fruto da inquietação sobre a classe de monitoramento do Deter e também do Prodes, chamada de Corte Raso com Vegetação. Muitas vezes essa classe é entendida como uma classe de regeneração, quando na verdade ela é uma classe de degradação. A explicação para que essa classe exista reside em um problema […]

Prezado leitor,

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.

Prezado leitor,

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?

Em ambientes onde o GeoServer é executado dentro de um contêiner Apache Tomcat, pode surgir a necessidade de alterar o caminho de contexto (contextPath) da aplicação, ou seja, o endereço pelo qual o serviço será acessado.

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

Você sabia que o GeoServer pode armazenar toda a sua configuração (workspaces, stores, layers, styles) em um banco de dados PostgreSQL, em vez de gravar arquivos XML no diretório data_dir?

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.

Hoy, Bentley Systems y Enactus anunciaron los equipos ganadores del iTwin4Good Challenge 2025, la competencia internacional que reúne a estudiantes universitarios para aplicar la tecnología de gemelos digitales y resolver desafíos del mundo real. Los competidores de este año buscaron aprovechar el poder de la innovación digital para abordar desafíos críticos de sostenibilidad, demostrando cómo …

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Hoje, muitos mapas são criados e usados em computadores, usando Sistemas de Informação Geográfica (SIG).

o SIG é um conjunto de procedimentos (manual ou computacional) usado para armazenar e manipular dados georreferenciados.

o Em SIG, os dados geográficos são organizados em "camadas" ou "planos de informação", como se fossem transparências que podem ser sobrepostas. Cada camada geralmente tem o mesmo tipo de geometria (ponto, linha, polígono) e atributos.

o Entender conceitos como projeções e sistemas de referência de coordenadas (SRC) é fundamental em SIG para garantir que as camadas "encaixem" corretamente. O datum é parte desse sistema de referência.

o Os dados geográficos (geometria e atributos) podem ser armazenados em bancos de dados geográficos. A geometria e os atributos podem ser armazenados juntos ou separados e relacionados por identificadores.

o SIGs nos permitem analisar dados geográficos (Análise Espacial) e criar mapas para responder perguntas complexas, realizando operações como consultas por atributo ou junções espaciais. A simbologia e os rótulos baseados em atributos são importantes para visualizar os resultados da análise. Também permitem medir distâncias, áreas, calcular centróides, etc..

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Mapas Gerais (ou Topográficos): Fornecem informações genéricas, de uso não particularizado. Mostram uma variedade de características naturais e artificiais (relevo, rios, estradas, cidades). São a "base".

o Mapas Especiais: Registram informações específicas para uma única classe de usuários (ex: náutico, aeronáutico, meteorológico).

o Mapas Temáticos: Apresentam um ou mais fenômenos específicos (ex: mapa de população, mapa de solos, mapa de uso da terra). Eles geralmente usam uma base cartográfica para situar o tema. Um mapa temático associa a cada medida um número ou nome ligando a observação a um tema ou classe.

o A escolha do tipo de mapa depende do que você quer analisar ou comunicar.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Um bom mapa tem vários elementos para ser útil e compreensível.

o Elementos essenciais: Título (O que o mapa mostra?), Corpo do Mapa (O desenho principal), Legenda (Explica os símbolos/convenções), Escala (Numérica e/ou Gráfica), Seta Norte (Onde fica o Norte? Orientação do mapa), Fonte dos Dados (Quem fez o mapa e de onde vieram os dados?), Data da Edição, nome da projeção e seus dados definidores.

o Outras informações marginais incluem diagramas de articulação das folhas, nome da entidade editora, número da edição, e a borda/moldura do mapa. Mapas podem conter encartes para mostrar áreas em escalas diferentes ou locais fora da área principal.

o A forma como esses elementos são organizados (o layout) é importante para a clareza.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Mapas podem representar a altimetria, mostrando o relevo detalhadamente.

o A forma mais comum de mostrar o relevo em mapas topográficos são as curvas de nível. Curvas de nível são linhas que conectam pontos da superfície com o mesmo valor de elevação (altitude). A altitude é a distância medida acima ou abaixo de uma superfície de referência, geralmente o nível médio do mar (que se aproxima do geoide).

o As curvas de nível são determinadas a partir da interseção da superfície do terreno com planos horizontais e a projeção dessas interseções no plano do mapa. Elas não se cruzam.

o Quanto mais próximas as curvas, mais inclinado é o terreno. Quanto mais afastadas, mais plano. Existem curvas mestras (traço mais grosso) e intermediárias, além de auxiliares.

o Outras formas incluem sombreamento ou cores de altitude. Mapas que mostram altimetria e planimetria são chamados de cartas.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

No dia 4 de junho de 2025, a Comunidade QGIS Brasil realizou mais uma edição do Encontro de Usuários QGIS durante o MundoGEO Connect, no Expo Center Norte, em São Paulo. O evento reuniu profissionais, estudantes, desenvolvedores e entusiastas do QGIS de todas as regiões do país, consolidando-se como um dos principais espaços de troca de experiências e fortalecimento da comunidade no Brasil.

A programação contou com palestras sobre aplicações do QGIS em áreas como Inteligência Artificial, Pesquisa Socioambiental, Consultoria Ambiental, Planejamento de Voos com Drones, e Gestão de Saneamento, além de momentos de debate e interação entre os participantes.

Se você não pôde participar presencialmente ou deseja rever os conteúdos apresentados, todos os vídeos das palestras estão disponíveis gratuitamente no nosso canal do YouTube!

Acesse agora a playlist completa:
youtube.com/playlist?list=PLzKam0lvXworikfwwcQ31oIj1RUp__aNv

<figure class="wp-block-embed aligncenter is-type-video is-provider-youtube wp-block-embed-youtube"></figure>

Este evento foi organizado pela Comunidade QGIS Brasil com apoio da OSGeo Brasil, reforçando nosso compromisso com a promoção do software livre e o avanço das geotecnologias no país.

Continue acompanhando nossas redes sociais e site para ficar por dentro dos próximos encontros, oficinas e oportunidades de capacitação!

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Além da localização e do tipo (ponto, linha, polígono), os objetos no mapa (feições) têm informações extras ligadas a eles, chamadas atributos.

o Esses atributos descrevem as propriedades das feições. Além das coordenadas, outros dados não espaciais (atributos) podem ser arquivados para indicar de que tipo de ponto ou linha se está tratando.

o Os atributos podem ser armazenados em uma tabela, que é como uma planilha. Cada coluna é um campo (representa uma propriedade, como altura, cor da cobertura), e cada linha é um registro (corresponde a uma feição).

o Exemplo: Para um ponto "Cidade", os atributos podem ser "Nome" (Rio de Janeiro), "População", "Estado". Para uma linha "Estrada", pode ser "Tipo" (Asfaltada, Terra), "Nome". Para uma sala de aula (polígono), pode ser o número de alunos.

o Em sistemas de informação geográfica (SIG), esses atributos ficam em tabelas, permitindo buscar e analisar informações. O SIG vincula o registro da tabela à feição geométrica. Consultas por atributo são operações comuns em SIG.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Como saber o que cada ponto, linha ou polígono representa? Usamos símbolos.

o Símbolos são desenhos, cores ou padrões que comunicam o tipo de objeto. Uma linha azul pode ser um rio, uma linha vermelha pode ser uma estrada principal. Um polígono verde pode ser uma área florestada. Catálogos de letras indicam tipos de caracteres para o letreiro. O mapa deve ter um quadro de convenções empregadas (legenda).

o Escolher bons símbolos torna o mapa fácil de entender. A simbologia pode ser baseada em atributos.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o No mapa, representamos as coisas do mundo real (rios, estradas, casas) usando elementos gráficos chamados feições geográficas.

o No caso da representação vetorial, os elementos gráficos básicos são pontos, linhas poligonais (arcos) e áreas (polígonos).

o Um Ponto é um par ordenado de coordenadas (x, y). Pode representar localizações ou ocorrências específicas (ex: localização de crimes, estações de medição de temperatura, mastro da escola, locais de torneiras).

o Uma Linha (linha poligonal, arco, ou elemento linear) é um conjunto de pontos conectados. É usada para guardar feições unidimensionais (ex: rios, estradas, trilhas dentro e ao redor da escola).

o Uma Área (ou Polígono) é a região do plano limitada por uma ou mais linhas poligonais conectadas que formam um contorno fechado. Polígonos são usados para representar unidades (ex: um lago, um edifício, um país, um campo de futebol, salas de aula).

o A escolha do tipo de geometria depende do tamanho real do objeto e da escala do mapa. Além das coordenadas, dados não espaciais (atributos) podem ser arquivados para descrever o tipo de ponto ou linha.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Una de las amenazas más actuales y desconocidas debido al desconocimiento sobre cómo afectará a largo plazo a los sistemas biológicos es la contaminación por plástico, y en especial los microplásticos, aquellos a los que apenas vemos y por tanto, su eliminación de los ecosistemas naturales, especialmente en los océanos, es bastante complicada y todo un reto para la comunidad científica y los gestores.

Fuente: https://www.grida.no/resources/13339

Cada vez hay un mayor conocimiento al respecto y prueba de ello es la proliferación de bases de datos relacionadas y, por suerte, puestas a disposición del público para su consulta y descarga. Esto ayuda a la concienciación y visualización del problema. Voy a hacer una selección de las que considero que poseen una información más completa, pero por supuesto existen muchas más , tenlo en cuenta si estás interesad@ en este tema.

Atlas of Ocean Microplastics (AOMI): El Atlas de Microplásticos Oceánicos (AOMI) es una base de datos global de microplásticos superficiales de los océanos. Han contribuido unos 18 países, entre ellos se encuentra España.

Puedes descargar los datos directamente de los visores que aporta AOMI, por ejemplo, desde el dedicado a la densidad de partículas y descargarlo en diferentes formatos:

También podemos encontrar este tipo de información en Litterbase: este portal engloba datos más generales relacionados con la basura marina pero también puedes encontrar información muy interesante sobre microplásticos y, sobre todo, estudios relacionados. Además también puedes consultar un visor sobre el impacto de estas basuras marinas sobre los seres vivos.

El programa de la NOAA sobre basuras marinas por supuesto también es destacable y aporta mucha información sobre esta problemática.

Si conoces algún proyecto relacionado te animo a que lo incluyas en comentarios así englobaremos más información al respecto.

Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.

Formación de calidad impartida por profesionales

La entrada Bases de datos sobre microplásticos en los océanos se publicó primero en Cursos GIS | TYC GIS Formación.

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Existem diferentes "famílias" de projeções (cilíndrica, cônica, planar/azimutal), baseadas em superfícies auxiliares.

o Cada projeção tenta preservar alguma coisa (formas/ângulos - conforme, áreas - equivalente, ou distâncias - equidistante), mas sempre distorce outras coisas.

o Algumas preservam formas (úteis para navegação, como a Projeção de Mercator), outras preservam áreas (úteis para comparar distribuições de fenômenos). A escolha da projeção depende do objetivo do mapa e da área representada (por exemplo, áreas equatoriais se encaixam bem em projeções equatoriais, áreas polares em projeções polares).

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

A floresta amazônica vem sendo monitorada há décadas, mas há um detalhe importante frequentemente ignorado: a vegetação secundária, aquela que ressurge após o desmatamento e pode capturar carbono e recuperar biodiversidade, também está sendo destruída – e em ritmo alarmante. Nesse novo estudo que tive participação pontual, publicado na revista Environmental Research Letters revela que […]

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Vimos que não dá para achatar a Terra sem deformar.

o As Projeções Cartográficas são os métodos usados para transferir a superfície curva da Terra para um plano.

o Elas criam uma "regra" ou fórmula para saber onde cada ponto da Terra vai parar no mapa.

o Imagine usar uma lanterna para "projetar" a Terra em uma folha de papel - isso dá a ideia de projeção.

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Uno de los grandes avances en los Sistemas de Información Geográfica (SIG) es la integración de lenguajes de programación para agilizar y automatizar las tareas. En el caso de ArcGIS Pro de Esri nos podemos encontrar con lenguajes como Arcade, SQL, o Python que es el que nos ocupa en esta ocasión.

Fuente: Imagen creada a través de la IA

La idea de este tutorial es sencilla, crear una Feature Class de tipo punto y añadirle una serie de puntos aleatorios en una zona de mi interés, esto lo haré con la herramienta “Create Random Points” de ArcGIS Pro. Le digo que quiero un total de 50 puntos.

Por supuesto esa FC se guardará en la geodatabase de mi proyecto, en la siguiente imagen se visualiza el resultado:

El siguiente paso es abrir un notebook para escribir nuestro script con Python, para ello nos dirigimos a la pestaña “Análisis” de ArcGIS Pro:

E introducimos nuestro código, antes que nada, importamos la librería arcpy y apuntar a la geodatabase de nuestro proyecto y a nuestra FC:

A continuación, le decimos el Sistema de Referencia de Coordenadas (SRC) con el que estamos trabajando y el punto que nos interesa incluir en nuestra FC así como su geometría.

Con “Insert Cursor” podemos darle la premisa de que nos incluya ese punto en nuestra FC gracias a arcpy.da que te permite acceder a dichos datos y realizar dicha acción.

Y ya lo tendremos, no te olvides de guardar la edición.

Si quieres aprender más sobre cómo trabajar con Python en ArcGIS Pro desde TYC GIS te ofrecemos varios cursos y también puedes consultar los tutoriales que se han redactado en nuestro blog.

Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.

Formación de calidad impartida por profesionales

 

La entrada Cómo trabajar con Python en ArcGIS Pro para añadir datos a tu “Feature Class” se publicó primero en Cursos GIS | TYC GIS Formación.

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

o Uma escala grande (ex: 1:1.000) mostra pequenas áreas com muito detalhe. Pense em um mapa de um bairro.

o Uma escala pequena (ex: 1:1.000.000) mostra grandes áreas com pouco detalhe. Pense em um mapa do Brasil.

o A escolha da escala depende do que você quer representar.

e>

Este conteúdo foi gerado com auxílio de inteligência artificial e você poderá acessar os materiais base utilizados no link.

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

Adquira nosso curso sobre customização de formulários no QGIS pelo link https://www.udemy.com/course/customizacao-de-formulario-qgis/?referralCode=658DB6242221F6D7BFD7

Veja nossos cursos na plataforma Udemy: https://www.udemy.com/user/hebert-azevedo-2/

Inscreva-se e acompanhe nosso blog: http://bit.ly/2CL63UZ

Inscreva-se e acompanhe nosso canal Youtube: http://bit.ly/2J0H2Wa

Curta e acompanhe nossa página no Facebook: http://bit.ly/2yGErMp

Los Sistemas de Información Geográfica están presente en muchos ámbitos de nuestra vida, en esta entrada os vamos a mostrar una serie de ejemplos para trabajar con programas como ArcGIS Pro o QGIS en el ámbito marino. Si tienes alguna duda al respecto sobre cómo puedes aplicar tu idea o tienes un ejemplo más puedes escribirnos en comentarios.

A continuación, os dejo una relación de aplicaciones:

Realización de mapas de vulnerabilidad costera: el cambio global nos exige el estudio y determinación de vulnerabilidades de nuestras zonas costeras a fenómenos imprevisibles. Es por ello que el estudio y conocimiento del Índice de Vulnerabilidad Costera a la subida del nivel del mar (Coastal Vulnerability Index, CVI) es necesario partir de diferentes tipos de variables sociales, económicas y físicas. Esto es posible gracias a los SIG y los visores cartográficos nos permiten mostrar al público en general de dicha información. Existe mucha bibliografía al respecto por si tienes más interés.

Visualización de dinámicas oceánicas: hoy en día gracias a las nuevas tecnologías y el avance en la teledetección ha permitido la suficiente capturas de datos para crear los modelos de corrientes y otras dinámicas oceánicas de gran interés para conocer cómo evoluciona por ejemplo el clima y predecir fenómenos como las Danas o los huracanes. Incluso para entender los upwellings o afloramientos, zonas de gran productividad de los océanos, La NASA está desarrollando un nuevo proyecto denominado ECCO que nos permite con mayor rigor entender el funcionamiento de estos fenómenos.

Mapa de aptitud para el baño en playas según la calidad del agua: existe mucha información que puedes chequear y descargar , como en la página web del MITERD, pero si quieres una información más detallada y actualizada de una zona de estudio, puedes dirigirte a fuentes de datos como por ejemplo del Proyecto Náyade y gracias a los SIG realizar tus propios análisis.

Creación de modelos de distribución de especies marinas, así como como su visualización: gracias a la gran cantidad de registros de especies que nos podemos encontrar en plataformas como GBIF (siempre realizando una depuración previa de los datos) podríamos realizar mapas de calor o estimaciones de densidad (Kernel) de especies de cetáceos, tortugas marinas, aves marinas, etc. para conocer su distribución espacial y tener una idea del uso del territorio de estos animales. Esto puede ser interesante a la hora de elaborar corredores ecológicos como el recién creado “Corredor de migración de cetáceos del Mediterráneo».

Impacto del tráfico marítimo: ligado al punto anterior, es interesante conocer las rutas de tráfico marítimo que actúan como enormes autopistas y a veces en zonas de gran congragación de especies marinas como es el caso del Estrecho de Gibraltar o Stellwagen Bank en Estados Unidos . Gracias a la información obtenida a través de los AIS (Sistema de Identificación Automática que transmite la ubicación, identidad, rumbo y velocidad de las embarcaciones) esto es posible.

Todos estos proyectos amparados gracias a la enorme disponibilidad de bases de datos gratuitas que existen en la actualidad las cuales favorecen y mejoran la investigación y divulgación de información, especialmente en el ámbito marino. El principal objetivo , la conservación de estas especies y hábitats para que exista una sintonía con el desarrollo económico y el establecimiento de nuevas actividades como la eólica marina o la minería de tierras raras en los océanos.

Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.

Formación de calidad impartida por profesionales

 

La entrada Ejemplos de uso para trabajar en Sistemas de Información Geográfica (ArcGIS Pro y QGIS) se publicó primero en Cursos GIS | TYC GIS Formación.

Últimamente se me ha cruzado este programa y me ha entrado la curiosidad. Así que he aprovechado y os escribo esta entrada con los principales aspectos a destacar.

DuckDB es una base de datos SQL utilizada para el análisis de datos e implementada para entornos R o Python,entre otros. A diferencia de PostgreSQL/PostGIS que está más enfocada a trabajar con datos geoespaciales. Así estas dos plataformas poseen grandes diferencias, la primera su instalación.

Como se muestra en su web, y hay abundante documentación, puedes instalar o trabajar con ella en Python en R instalándolo como una simple librería.

O descargarlo , y trabajar con ella desde la línea de comandos de manera sencilla.

A continuación te dejo un ejemplo sobre su uso en R:

Así si trabajas en este ámbito, puede ser una gran opción, y además es open source.

Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.

Formación de calidad impartida por profesionales

La entrada ¿Qué es DuckDB? se publicó primero en Cursos GIS | TYC GIS Formación.

Em nosso artigo publicado na Nature Communications, “Uncontrolled Illegal Mining and Garimpo in the Brazilian Amazon” (https://www.nature.com/articles/s41467-024-54220-2), revelamos, com base em análise geoespacial detalhada, que a expansão do garimpo na região é massiva, acelerada e muitas vezes invisibilizada pelas estatísticas oficiais. O estudo foi fruto de anos de trabalho conjunto e faz parte da tese […]

Nosso artigo “Google Earth Engine: A Global Analysis and Future Trends“, publicado na revista Remote Sensing em 2023, oferece uma análise abrangente do uso da plataforma Google Earth Engine (GEE) em pesquisas científicas globais. Examinamos a distribuição geográfica dos usuários, os principais temas abordados e as tendências emergentes no uso do GEE, destacando sua importância […]

Versão do conjunto de dados em análise: 01de Maio 2025

• Número total de features / polígonos [3]: 2615362
• Área total dos polígonos, em hectares [4]: 1255936.8
• Número de features / polígonos com geometrias inválidas [5]: 112282
• Número de features / polígonos repetidos [6]: 0
• Número de sobreposições [10] : 964584 (36,88 %)
• Área ocupada pelas sobreposições, em hectares: 30426.8 (2,42 %)

#### Operações Realizadas ####

[1]

ogrinfo -so opendata-rgg-01072024.gpkg opendata-rgg-01072024
INFO: Open of `opendata-rgg-01072024.gpkg'
      using driver `GPKG' successful.

Layer name: opendata-rgg-01072024
Geometry: Multi Polygon
Feature Count: 2255870
Extent: (-94062.316000, -41320.713000) - (162060.682800, 276013.258500)
Layer SRS WKT:
PROJCRS["ETRS89 / Portugal TM06",
    BASEGEOGCRS["ETRS89",
        ENSEMBLE["European Terrestrial Reference System 1989 ensemble",
            MEMBER["European Terrestrial Reference Frame 1989"],
            MEMBER["European Terrestrial Reference Frame 1990"],
            MEMBER["European Terrestrial Reference Frame 1991"],
            MEMBER["European Terrestrial Reference Frame 1992"],
            MEMBER["European Terrestrial Reference Frame 1993"],
            MEMBER["European Terrestrial Reference Frame 1994"],
            MEMBER["European Terrestrial Reference Frame 1996"],
            MEMBER["European Terrestrial Reference Frame 1997"],
            MEMBER["European Terrestrial Reference Frame 2000"],
            MEMBER["European Terrestrial Reference Frame 2005"],
            MEMBER["European Terrestrial Reference Frame 2014"],
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]],
            ENSEMBLEACCURACY[0.1]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4258]],
    CONVERSION["Portugual TM06",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",39.6682583333333,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-8.13310833333333,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",1,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Topographic mapping (medium scale)."],
        AREA["Portugal - mainland - onshore."],
        BBOX[36.95,-9.56,42.16,-6.19]],
    ID["EPSG",3763]]
Data axis to CRS axis mapping: 1,2
FID Column = fid
Geometry Column = geom
area: Real (0.0)

[2]

ogr2ogr -f PostgreSQL PG:"host=localhost dbname=geocatalogo user=*** password=*** active_schema=catalogo" opendata-rgg-01072024.gpkg opendata-rgg-01072024 -nln catalogo.ebupi -lco FID=gid -overwrite

[3]

geocatalogo=# SELECT count(*) FROM catalogo.ebupi;
  count
---------
 2255870
(1 row)

[4]

geocatalogo=# SELECT sum(ST_Area(geom))/10000 AS area FROM catalogo.ebupi;        
area
--------------------
1419771.2919224324
(1 row)

[5]

geocatalogo=# SELECT count(*) FROM catalogo.ebupi WHERE ST_IsValid(geom) IS FALSE;
 count
-------
     0
(1 row)

[6]

WITH repeated_polygons AS (
    SELECT 
        ARRAY_AGG(gid) AS id_list,    
        COUNT(*) AS count,            
        geom                          
    FROM 
        catalogo.ebupi
    GROUP BY 
        geom
    HAVING 
        COUNT(*) > 1                  
)

SELECT 
    ROW_NUMBER() OVER () AS id,         
    count,                              
    ARRAY_TO_STRING(id_list, '|') AS id_list,
    geom AS geom
FROM 
    repeated_polygons
	ORDER BY count DESC;

[7]

WITH polygon_repetitions AS (
    SELECT 
        COUNT(*) AS repetition_count
    FROM 
        catalogo.ebupi
    GROUP BY 
        geom
    HAVING 
        COUNT(*) > 1                
)

SELECT 
    repetition_count,               
    COUNT(*) AS num_polygons       
FROM 
    polygon_repetitions
GROUP BY 
    repetition_count
ORDER BY 
    repetition_count;

[8]

WITH repeated_polygons AS (
    SELECT 
        ARRAY_AGG(gid) AS id_list,          
        COUNT(*) AS count,                  
        ST_Area(geom) AS area,              
        geom                                
    FROM 
        catalogo.ebupi
    GROUP BY 
        geom
    HAVING 
        COUNT(*) > 1                        
)

SELECT 
    SUM(count - 1) AS total_extra_polygons,   
    SUM((count - 1) * area)/10000 AS total_extra_area
FROM 
    repeated_polygons;

[9]

CREATE TABLE catalogo.ebupi_no_duplicates AS
WITH ranked_polygons AS (
    SELECT 
        gid,                         
        geom,                        
        ROW_NUMBER() OVER (
            PARTITION BY geom        
            ORDER BY gid ASC         
        ) AS rank                    
    FROM 
        catalogo.ebupi
)

SELECT 
    gid,                             
    geom                              
FROM 
    ranked_polygons
WHERE 
    rank = 1;                         


ALTER TABLE catalogo.ebupi_no_duplicates
ADD CONSTRAINT ebupi_no_duplicates_pkey PRIMARY KEY (gid);

CREATE INDEX ebupi_no_duplicates_geom_idx
ON catalogo.ebupi_no_duplicates
USING GIST (geom);

[10]

CREATE TABLE catalogo.ebupi_partial_overlaps AS
WITH bbox_filtered AS (
    SELECT 
        a.gid AS gid_polygon1,
        b.gid AS gid_polygon2,
        a.geom AS geom1,
        b.geom AS geom2
    FROM 
        catalogo.ebupi_no_duplicates a,
        catalogo.ebupi_no_duplicates b
    WHERE 
        a.gid < b.gid  
        AND a.geom && b.geom  
)
SELECT 
    row_number() over() AS gid,
    gid_polygon1, 
    gid_polygon2, 
    ST_Area(ST_Intersection(geom1, geom2))/10000 AS area_hectares,
    ST_Multi(ST_Intersection(geom1, geom2)) AS geom
FROM 
    bbox_filtered
WHERE 
    ST_Intersects(geom1, geom2)  
    AND (ST_GeometryType(ST_Intersection(geom1, geom2)) = 'ST_Polygon'
    OR ST_GeometryType(ST_Intersection(geom1, geom2)) = 'ST_MultiPolygon');


ALTER TABLE catalogo.ebupi_partial_overlaps
ADD CONSTRAINT ebupi_partial_overlaps_pkey PRIMARY KEY (gid);

CREATE INDEX ebupi_partial_overlaps_geom_idx
ON catalogo.ebupi_partial_overlaps
USING GIST (geom);

QGIS es un Sistema de Información Geográfica (SIG) gratuito e instalable en varios tipos de sistemas operativos (Linux, Windows).

Es un ecosistema en constante evolución, prueba de ello es el inminente lanzamiento de la versión QGIS 4x con todo lo que ello representa a nivel de desarrollo (como ya lo fue en su momento la saga QGIS 3x) de sus complementos.

Esos complementos facilitan mucho la labor del usuario, en esta ocasión vamos a mostrar cómo modificar el nombre de un campo de una tabla de atributos, algo que, si no te ha pasado ya, te pasará. Y lo vamos a realizar de una manera sencilla, ojo, esto también va a variar según el formato datos que utilices.

Veamos cómo hacerlo, para ello vamos a trabajar con datos del Banco de la Naturaleza del MITERD de los Espacios Naturales Protegidos (ENP). Si lo cargamos en QGIS y chequeamos la tabla de atributos:

Observamos que los nombres de los campos no son muy comprensibles si quieres desarrollar un visor o crear un “dashboard” y mostrar dicha información en un “pop-up”.

Para editar la tabla, podemos utilizar la herramienta “Rehacer campos” y escribir los nombres de los campos que nos interese, además, podríamos modificar el tipo de datos, entre otras características.

Vamos a crear una capa temporal, ten en cuenta que en este caso, para guardar los cambios debemos exportarla. Si se abre la tabla de atributos comprobaremos los cambios llevados a cabo:

Y ya lo tendríamos, una manera rápida y sencilla de modificar dichos campos de manera que nos interese.

Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.

Formación de calidad impartida por profesionales

La entrada Cómo cambiar en QGIS el nombre de los campos en las tablas de atributos se publicó primero en Cursos GIS | TYC GIS Formación.

 

Te invitamos a formar parte de las Jornadas de SIG Libre, Geotech & Spatial Data Science que se celebrarán el 17 y 18 de septiembre de 2025 en Girona.

Las Jornadas de SIG Libre son un evento donde compartir e intercambiar conocimientos alrededor de las geotecnologías libres y la ciencia de datos espaciales y en estos momentos está abierta la convocatoria para presentar una comunicación, lightning talk o taller.

Si trabajas en el ámbito de las geotecnologías y la ciencia de datos espaciales, y deseas compartir un proyecto, una solución o impartir un taller, ¡envíanos tu propuesta!

Los temas aceptados incluyen:

• Visualización de datos

• Análisis espacial

• Desarrollo de software y aplicaciones

• Webmapping

• Observación de la Tierra

• Ciencia de datos

• Geoestadística

• Machine learning

• Datos abiertos

Las Jornadas de SIG Libre buscan la participación tanto de empresas como de organizaciones, universidades, investigadores y cualquier persona involucrada en el ámbito de las geotecnologías libres.

¡No pierdas la oportunidad de ser parte de este evento! La fecha límite para enviar la propuesta es el 24 de abril de 2025.

Más información: https://www.jornadassiglibre.org

Publicado por Laura Olivas Corominas.

Las bounding box corresponden a un vectorial tipo polígono de forma rectangular que engloban uno o un grupo de rasgos geográficos de un área de interés (puntos, líneas o polígonos). Se definen con base en las coordenadas mínimas y máximas … Continue reading →

En el post anterior se consideró el redimensionamiento de una imagen en un documento con Google Apps Script. En éste, adicionalmente, también se va a considerar la inclusión del link que apunta a la imagen correspondiente en Google Drive. Para ello, … Continue reading →