Planeta SIG - Portugal

En el ecosistema R existen numerosas librerías dedicadas a la representación espacial de datos (sf, leaflet, mapbox…). Ya en otros artículos os mostramos como emplear estos paquetes para la creación de mapas de diversas temáticas: Creación de visores de mapas web de Leaflet en R. Creación de mapas con Mapbox y R. Mapas de coropletas, ...

Leer más

Creando mapas con cartographr en R

O PostGIS é, sem dúvida, o coração de qualquer infraestrutura WebGIS moderna.
Ele transforma o PostgreSQL em um verdadeiro motor de análise espacial, capaz de executar desde consultas simples até operações complexas de geoprocessamento.

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

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

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

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

1. A base: Consultas espaciais no PostGIS

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

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

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

2. Onde entra a IA

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

Assim, é possível automatizar:

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

3. IA + PostGIS + Python

O fluxo completo é simples:

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

Veja como fica o script:

import psycopg2
import openai
import pandas as pd

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

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

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

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

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

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

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

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

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

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

4. Na prática

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

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

Por Exemplo:

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

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

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

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

Exemplo de prompt para explicação:

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

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

5. Conclusão

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

En esta entrada os mostraremos cómo instalar QGIS de forma avanzada desde el instalador OSGeo4W (Open Source Geospatial Foundation for Windows). OSGeo4W es una distribución binaria que contiene un gran número programas geoespaciales de código abierto para entornos Windows (desde Windows 10 hasta XP). OSGeo4W incluye QGIS, GDAL/OGR, GRASS, SAGA así como muchos otros paquetes ...

Leer más

Cómo instalar QGIS y librerías geoespaciales de Python usando OSGeo4W

Hola a todos.

En los últimos años, hemos asistido a un avance espectacular en el campo de la Inteligencia Artificial, impulsado principalmente por los Modelos de Lenguaje Grandes (LLMs). Su capacidad para generar texto coherente, traducir idiomas y mantener conversaciones fluidas es, sin duda, impresionante. Es una proeza de la ingeniería y la estadística a gran escala.

Sin embargo, esta misma fluidez nos coloca en una encrucijada fundamental. Nos obliga a hacernos una pregunta que va más allá de la implementación: ¿estamos realmente creando máquinas que entienden, o hemos perfeccionado el arte de la imitación estadística? La respuesta, creo, se encuentra al analizar las dos filosofías fundamentales que hoy compiten, a menudo sin saberlo, en el diseño de la IA.

Un eco histórico

Esta disyuntiva fundamental entre la ilusión y el entendimiento no es nueva. Los albores de la Inteligencia Artificial ya exploraban, con la tecnología de su tiempo, estos dos caminos filosóficos.

Por un lado, sistemas como ELIZA (1966) demostraron el poder hipnótico de la correlación superficial. Utilizando poco más que la identificación de palabras clave y la devolución de respuestas predefinidas o reformulaciones de la entrada del usuario, era capaz de generar una convincente ilusión de comprensión, prefigurando el empirismo humeano que hoy escala hasta lo exponencial en los LLMs.

Frente a este enfoque, otros sistemas pioneros abrazaban una filosofía radicalmente distinta: la IA simbólica. La premisa aquí no es encontrar correlaciones estadísticas en los datos, sino representar el conocimiento de forma explícita, mediante símbolos (como las palabras cubo o pirámide) y reglas (una lógica formal que dicta cómo se pueden relacionar esos símbolos). Es un enfoque de “caja de cristal”: el razonamiento es una cadena de pasos lógicos que se pueden inspeccionar y entender.

SHRDLU (c. 1970) fue un ejemplo perfecto de ello. Operaba en un universo de bloques, donde cada símbolo estaba anclado a una entidad y a un conjunto de acciones posibles dentro de un modelo lógico del mundo. Su limitación era la obvia falta de escalabilidad, pero su virtud era la comprensión real y la capacidad de razonar de forma transparente. De forma similar, Mycin (c. 1970s) era un sistema experto que utilizaba un motor de reglas lógicas explícitas (SI el paciente tiene esta infección Y es alérgico a la penicilina, ENTONCES recetar este otro antibiótico) para el diagnóstico de enfermedades, cuyo proceso de inferencia podía ser rastreado y explicado.

Del debate filosófico a la ciencia cognitiva

Esta dualidad entre imitación y modelo no fue un capricho de los ingenieros; es el eco de una de las preguntas más profundas de la filosofía, una que explotó en el crisol de la ciencia cognitiva del siglo XX.

El debate puede trazar hasta dos visiones del mundo casi opuestas. Por un lado, una corriente heredera del empirismo, que ve la mente como un espejo de la experiencia, un sistema que aprende a base de observar patrones y correlaciones masivas. Por otro, una de raíz racionalista, que la concibe como un arquitecto activo, dotado de un andamiaje innato que le permite imponer una estructura al mundo para poder entenderlo. Estas dos corrientes, popularizadas en la filosofía por pensadores como David Hume e Immanuel Kant respectivamente, sentaron las bases del campo de batalla intelectual del siglo siguiente.

Este choque de ideas se ramificó en múltiples teorías. Vimos nacer modelos que defendían la existencia de gramáticas universales o de un desarrollo cognitivo por etapas, frente a otros que explicaban la formación de conceptos a través de promedios estadísticos, prefigurando conceptualmente el enfoque que hoy vemos en los LLMs.

Pero la conclusión más profunda de este debate no fue la victoria de un bando. La propia ciencia demostró que un aprendizaje robusto requiere ambos elementos: una estructura de conocimiento previo que es constantemente actualizada y refinada por la evidencia de la experiencia. La fusión de paradigmas no era una opción, sino una necesidad.

La historia de la IA ha oscilado entre estos polos: la potencia escalable de la correlación y la robustez explicable del modelo. Los modernos Modelos de Lenguaje Grandes representan la culminación técnica y escalada del primer camino. Su espectacular éxito nos obliga ahora a rescatar y reinventar, con nuevas herramientas, la sabiduría del segundo. Los LLMs son el ELIZA de la era del Transformer.

La IA como empirismo radical

Para entender el núcleo de un LLM, es tentador buscar una analogía en la mente, pero es mucho más revelador encontrar su alma en una idea filosófica: el empirismo radical de David Hume. Hume propuso que nuestro conocimiento no se basa en un entendimiento profundo de la “causa”, sino en la simple asociación de impresiones. Si vemos fuego seguido de calor repetidamente, nuestra mente los conecta. No deduce una ley física, simplemente reconoce una correlación estadística muy fuerte.

Esta es, casi literalmente, la arquitectura de pensamiento de un Modelo de Lenguaje Grande. Su funcionamiento no es más que la idea de Hume implementada a escala planetaria. No “saben” que la capital de Francia es París; lo que hacen, a través de arquitecturas como los Transformers, es calcular que tras la secuencia de palabras “la capital de Francia es”, la palabra “París” tiene una probabilidad de aparición abrumadoramente alta. Su conocimiento no es un hecho verificado, sino la correlación estadística más fuerte encontrada en su vasta experiencia de datos. La investigación actual, de hecho, se ha centrado en esta hipótesis puramente humeana del escalado: si aumentamos masivamente la “experiencia” (los datos de entrenamiento), de esa correlación masiva “emergen” capacidades que se parecen al razonamiento. Estas capacidades emergentes son, sin duda, espectaculares y han redefinido lo que creíamos posible con modelos puramente estadísticos.

Pero esta arquitectura tiene consecuencias directas, que no son fallos a corregir, sino características inherentes a su diseño:

1. Ausencia de un modelo del mundo: Esto nos remonta a uno de los problemas fundacionales de la IA, el llamado problema de anclaje de símbolos (grounding problem), que ya era evidente en sistemas pioneros como SHRDLU. Los símbolos que manejan estos sistemas no están anclados a ningún concepto real. La palabra «cubo» es un vector numérico definido por su relación estadística con otras palabras como “sólido”, “apilar” o “dado”, pero el sistema no tiene un modelo conceptual de lo que es un cubo.
2. La “alucinación” como consecuencia lógica: Si la arquitectura fundamental de un sistema se basa en la probabilidad estadística y carece de un modelo de verdad contrastable, es natural que tienda a generar secuencias de texto que, aunque estadísticamente plausibles, pueden no corresponder con la realidad fáctica. La alucinación es una consecuencia inherente a este diseño.
3. Opacidad por diseño: El “conocimiento” está distribuido en miles de millones de parámetros. Es una “caja negra” que nos impide auditar el “porqué” de una respuesta de forma lógica y transparente.

Hacia una arquitectura del entendimiento

El enfoque humeano, basado puramente en la correlación, nos lleva inevitablemente a los problemas que hemos visto: alucinaciones, opacidad y una profunda falta de anclaje con la realidad. Si la experiencia bruta no es suficiente, ¿cómo podemos construir una IA que realmente entienda? La respuesta a esta pregunta nos la ofreció el filósofo que se enfrentó directamente al reto de Hume: Immanuel Kant.

La idea revolucionaria de Kant fue que la mente no es un mero receptor pasivo de experiencias, sino un agente activo que impone una estructura para poder entender el mundo. Para darle sentido al caos de los datos, la mente utiliza “moldes” o estructuras a priori. Categorías como la causalidad (saber que la lluvia causa el suelo mojado, no solo que suelen aparecer juntos) o la sustancia (entender que la “Torre Eiffel” es una entidad con propiedades, no solo una secuencia de letras) son las herramientas que nos permiten construir un modelo coherente de la realidad.

De nuevo, esto no es solo filosofía; es un plano para una IA superior. Una IA robusta debe ser una forma de “ingeniería kantiana”, donde no nos limitamos a procesar datos, sino que construimos activamente las estructuras para entenderlos:

• Grafos de Conocimiento (Knowledge Graphs): Son la implementación directa de las categorías kantianas. Modelan explícitamente “sustancias” (nodos como “París”) y sus “relaciones” (aristas como “es_capital_de”). No operan sobre correlaciones, sino sobre hechos estructurados.
• IA Causal (Causal AI): Es el esfuerzo por construir la categoría de la “causalidad” de Kant en las máquinas. Busca modelar que “la lluvia causa que el suelo se moje”.
• IA Explicable (XAI): La creciente demanda de sistemas cuyo razonamiento podamos inspeccionar es, en el fondo, una demanda de arquitecturas más kantianas, donde la lógica del proceso sea transparente.

La síntesis neuro-simbólica como nueva frontera de la IA

Hemos trazado dos caminos filosóficos y técnicos que parecen opuestos: el enfoque basado en la correlación estadística (Hume/LLMs) y el enfoque lógico-simbólico (Kant/Grafos de Conocimiento). El verdadero salto cualitativo no está en elegir un bando, sino en fusionarlos. Esta fusión tiene un nombre y es la frontera más prometedora de la investigación actual: la IA neuro-simbólica.

Es importante hacer aquí una aclaración crucial. Cuando en IA hablamos del componente “neuro”, no nos referimos al cerebro humano, sino a las redes neuronales artificiales. Estas son estructuras matemáticas, inspiradas lejanamente en las conexiones neuronales, que son excepcionalmente buenas para una tarea: encontrar patrones complejos en enormes cantidades de datos. No “piensan”, sino que calculan probabilidades.

Una arquitectura neuro-simbólica consiste, por tanto, en un diseño donde cada componente hace aquello para lo que es excepcional. Nuestra propuesta de tres fases (deconstrucción, razonamiento, reconstrucción) es, en esencia, un diseño neuro-simbólico en acción:

• El componente “Neuro” (el LLM): Se encarga de la percepción y la comunicación. Es el intérprete y el portavoz. Su red neuronal maneja la complejidad y ambigüedad del lenguaje natural.
• El componente “Simbólico” (el núcleo cognitivo): Se encarga del razonamiento. Es el motor lógico que opera sobre hechos estructurados y reglas explícitas, garantizando la coherencia y la explicabilidad.

Este enfoque no es meramente teórico, ya está tomando forma en proyectos de vanguardia. IBM ha desarrollado su framework “Neuro-Symbolic AI”. El MIT-IBM Watson AI Lab ha creado sistemas que combinan redes neuronales para percepción visual con motores simbólicos para razonamiento lógico. DeepMind ha explorado híbridos en proyectos como “FunSearch”. Estos esfuerzos demuestran que la integración de ambos paradigmas no solo es factible, sino que ya está produciendo resultados prácticos superiores.

• Deconstrucción: el LLM como intérprete.
  En la primera fase, usamos la red neuronal para lo que hace de forma inigualable: manejar la ambigüedad del lenguaje humano. Su función no es razonar, sino actuar como una capa de percepción universal que traduce la pregunta de un usuario a una representación formal. Este enfoque es una extensión natural de las capacidades de “Function Calling” o “Tool Use” que ya vemos en los modelos actuales.
• Razonamiento: el núcleo cognitivo.
  Esa consulta estructurada alimenta el corazón kantiano del sistema: un motor simbólico. Aquí es donde ocurre el entendimiento real. La naturaleza de este núcleo puede adoptar dos formas complementarias. Podría ser un vasto grafo de conocimiento preexistente, que actúa como una base de conocimiento universal sobre la que verificar hechos. O, en un enfoque más dinámico y flexible, podría ser un motor de inferencia puro, inicialmente vacío, que construye un modelo lógico temporal a partir de los hechos extraídos por el LLM en la fase anterior. En este segundo caso, el sistema no depende de un conocimiento previo, sino que razona con perfecta precisión sobre la información proporcionada en un contexto específico. En ambos escenarios, el principio es el mismo: el razonamiento opera sobre hechos estructurados y reglas lógicas, no sobre correlaciones estadísticas. La salida de esta fase no es texto, sino conocimiento puro y estructurado.
• Reconstrucción: el LLM como portavoz.
  El ciclo se completa volviendo al LLM, pero con un rol controlado. Su tarea ahora es “verbalizar” la conclusión lógica del núcleo cognitivo. Toma esa estructura de datos pura y la convierte en una respuesta coherente en lenguaje natural. Este modelo supera los enfoques actuales como RAG (Retrieval-Augmented Generation), pasando de un simple anclaje a una verdadera simbiosis.

Esta arquitectura trasciende la mera asociación de tokens. Es análoga a cómo un traductor experto primero comprende el significado (deconstrucción), luego reflexiona sobre él (razonamiento), y finalmente lo expresa en el idioma destino (reconstrucción).

Construir entendimiento, no solo imitar el lenguaje

La fluidez con la que los LLMs sostienen una conversación puede seducirnos hasta hacernos creer que el gran desafío de la IA ya está superado. Pero esta percepción es una ilusión óptica del lenguaje. Lo que hemos logrado es dominar la imitación estadística del discurso. La otra mitad, la construcción activa de entendimiento, sigue pendiente.

Existe, por supuesto, una corriente que apuesta a que el simple escalado generará comprensión de forma emergente. Es una hipótesis poderosa, y las capacidades que han surgido de ella son innegables. Sin embargo, desde la perspectiva que hemos trazado entre Hume y Kant, para ir más allá de la imitación y alcanzar un entendimiento robusto, el escalado debe complementarse con estructura: un modelo del mundo que permita razonar, verificar y explicar.

Esta dicotomía Hume-Kant no pretende ser una representación exhaustiva de sus filosofías. La historia del pensamiento muestra que no son excluyentes. Precisamente, la arquitectura neuro-simbólica que proponemos refleja esta tradición de síntesis, reconociendo que se necesita tanto la capacidad de procesar la experiencia (el poder humeano del LLM) como la de imponerle una estructura lógica (el núcleo kantiano del sistema), un equilibrio que los modelos bayesianos de la cognición ya nos enseñaron que es fundamental.

Aquí, la crítica de John Searle y su “habitación china” adquiere nueva relevancia. Searle demostró que manipular símbolos según reglas no equivale a comprender su significado. Los LLMs modernos, en cierto modo, son la habitación china a escala planetaria: impecables en la sintaxis, vacíos de semántica.

Por eso, el verdadero salto cualitativo no vendrá de hacer modelos más grandes, sino de sintetizar paradigmas: combinar la potencia perceptiva de las redes neuronales con la robustez lógica de los sistemas simbólicos. La arquitectura de tres fases no es solo una propuesta técnica, sino una declaración de principios: el conocimiento es una síntesis activa entre la experiencia y la estructura.

Es crucial acotar nuestras ambiciones: el objetivo no es replicar la conciencia humana. Cuando hablamos de “razonamiento” en esta arquitectura, nos referimos a la capacidad de operar de forma lógicamente consistente sobre un modelo explícito, de forma que sus conclusiones sean transparentes y verificables. Es un razonamiento mecánico, pero robusto. Este modelo del mundo puede ser permanente y actualizarse de forma coherente, logrando un aprendizaje real y deliberado. O puede ser un modelo temporal construido “al vuelo” para analizar un texto específico. Esta segunda capacidad es clave, pues permite explorar todas las consecuencias lógicas de un fragmento de información con una precisión inalcanzable para un LLM, que solo puede “recordar” su contexto de forma superficial.

El objetivo último no debería ser construir máquinas que hablen como nosotros, sino sistemas que, como nosotros, organicen la experiencia para formar un entendimiento coherente, verificable y, sobre todo, explicable del mundo. Es un camino más complejo, sí, pero también más sólido y digno de confianza.

Este artículo no pretende cerrar un debate, sino abrirlo con mayor claridad conceptual. Las ideas aquí esbozadas son las semillas. Invitan a una reflexión más profunda, a un rediseño fundamental. Porque el futuro de la IA no está solo en hablar mejor, sino en entender de verdad.

Un saludo a todos.

Para saber más

Para aquellos interesados en profundizar en las ideas filosóficas y científicas que se exploran en este artículo, aquí hay una selección de textos clave que han moldeado el debate sobre la inteligencia, el conocimiento y la mente.

• Sobre los fundamentos de la IA y su historia:
  • “Inteligencia Artificial: Un Enfoque Moderno” de Stuart Russell y Peter Norvig. Considerado el texto de referencia estándar en el campo de la IA. Ofrece un recorrido exhaustivo por la historia y las técnicas, desde la IA simbólica (SHRDLU, Mycin) hasta las redes neuronales.
• Sobre el debate filosófico (Empirismo vs. Racionalismo):
  • La Stanford Encyclopedia of Philosophy (online y de acceso gratuito) es un recurso inmejorable para explorar en profundidad las ideas de David Hume (empirismo) e Immanuel Kant (idealismo trascendental), así como el experimento mental de la “Habitación China” de John Searle.
• Sobre el debate en la Ciencia Cognitiva:
  • “Cómo funciona la mente” de Steven Pinker. Una obra de divulgación magistral que explora las grandes preguntas de la ciencia cognitiva, incluyendo el debate entre las estructuras innatas (la “gramática universal” de Chomsky) y el aprendizaje a partir de la experiencia.
• Sobre la IA Neuro-Simbólica:
  • “Neurosymbolic AI: The 3rd Wave” de Garcez y Lamb. Un buen punto de partida académico que resume los principios y las promesas de la integración de los enfoques neuronales y simbólicos, el campo que hemos denominado la “tercera ola” de la IA.

O GeoNode é hoje uma das plataformas mais completas de catálogos e portais WebGIS de código aberto. Ele centraliza camadas, mapas, documentos e metadados em um ambiente colaborativo.

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

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

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

1. O desafio dos metadados no GeoNode

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

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

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

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

2. Como a IA pode ajudar:

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

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

3. GeoNode + IA + Python

Vamos montar um pipeline automatizado que:

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

Veja como ficaria esse script:

import requests
import openai

# Configurações do GeoNode
GEONODE_URL = "http://localhost:8000/api/v2/layers/"
GEONODE_USER = "admin"
GEONODE_PASS = "geonode"

# Configuração da IA
MODEL = "gpt-4o-mini"

# 1. Obter lista de camadas
r = requests.get(GEONODE_URL, auth=(GEONODE_USER, GEONODE_PASS))
layers = r.json()["results"]

for layer in layers:
    title = layer["title"]
    abstract = layer.get("abstract", "")
    keywords = layer.get("keywords", [])

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

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

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

    # 3. Atualizar camada no GeoNode (opcional)
    payload = {"abstract": enriquecido}
    update = requests.patch(
        f"{GEONODE_URL}{layer['id']}/",
        json=payload,
        auth=(GEONODE_USER, GEONODE_PASS)
    )

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

Em resumo:

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

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

4. Exemplo prático

Camada original:

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

Após enriquecimento com IA:

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

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

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

Em segundos, o dado fica muito mais informativo.

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

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

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

5. Conclusão

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

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

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

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

Prezados leitores,

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

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

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

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

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

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

2. Onde entra a IA

A IA pode atuar em diferentes etapas:

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

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

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

import psycopg2
import openai
import requests

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

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

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

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

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

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

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

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

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

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

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

4. Benefícios práticos

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

5. Conclusão

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

Prezados leitores,

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

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

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

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

1. Validação com PostGIS

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

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

Exemplo: detectando geometrias inválidas

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

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

2. Onde entra a IA

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

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

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

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

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

O Resultado seria:

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

import psycopg2
import openai  # ou outro modelo LLM

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

erros = cur.fetchall()

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

O resultado esperado do script acima é o seguinte:

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

4. Automação contínua

Podemos transformar isso em um pipeline automatizado:

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

5. Benefícios práticos

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

6. Conclusão

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

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

Hola,

llevo un tiempo dándole vueltas a cómo escribir sobre esto, verás…

Hace un tiempo incursioné en esto de los chats de IA (puedes leer sobre eso en estos artículos). La cuestión es que hice mis pinitos y acabé haciendo un ¿chatbot? dentro de gvSIG desktop tirando del API de Gemini. Bueno, para mí era un simple chatbot. Lo arrancabas como una herramienta más dentro de la aplicación y tenía el aspecto característico de una aplicación de chat de IA. La cosa es que, aunque inicialmente fue simplemente hacia eso, un chat, decidí que lo chulo era darle acceso a algunas funcionalidades de la aplicación. Le di acceso a explotar los datos tabulares de la aplicación, que pudiese saber qué área se veía en la Vista, poder generar gráficos a partir de los datos que tenían las capas y tablas cargadas, y tal vez alguna cosilla más. Para mí era un “simple chatbot” dentro de la aplicación.

Mientras hacía cosas de esas, iba leyendo sobre LLMs y trataba de estar al tanto de lo que iba saliendo. Se nombraba que eso de los “Agentes” era el futuro, y empezaron a inundarme sugerencias de vídeos y publicaciones sobre ellos. Aparecieron docenas de vídeos sobre cosas como “Claude Code” o “Copilot” que te los “vendían” como el asistente perfecto para programar… pero un día, no creo que fuese de repente, esos vídeos y publicaciones empezaron a llamarlos “agentes”. Y aparecían vídeos de “Y XXX destrona a YYY como la plataforma de agentes definitiva” y cosas así. Por entonces ya había salido “Gemini CLI” y yo lo había adoptado como mi herramienta de IA de apoyo en programación. Y empecé a pensar que eran muy escandalosos con eso de los Agentes. ¿Por qué llamaban agente a mi “Gemini CLI”? (ya era “mi” Gemini, porque lo usaba día a día en mi trabajo). Total, ¿qué hacía más él en la consola que mi chatbot en gvSIG desktop? La respuesta simple era “nada”. Así que me puse a ver qué hacían “Claude Code” o “Copilot”, que competían por ser los “agentes definitivos” para el programador.

Pues qué desilusión. No hacían nada especial más.

Fue entonces cuando empecé a pensar en las cada vez más comunes publicaciones sobre este o aquel agente que iba a hacer maravillas para que aumentases tu productividad. ¿Era humo? No, no era humo, pero empecé a pensar que estaban estirando la palabra agente más de la cuenta para tener más “clics” o para “venderte” más. Y la idea no hacía más que darme vueltas e incluso me molestaba por lo descarado que me parecía a veces.

Un día, me senté con Gemini y le dije:

“Mira, he oído hablar mucho de que “Gemini CLI” es un agente en el contexto de IA. Me cuentas qué es eso de los agentes, que igual me podía interesar aprender sobre ello.”

Y cómo no, empezó a contarme cosas sobre lo que es un agente. Y cuando leí la extensa respuesta que me había soltado, le pregunté: “Y Gemini CLI, ¿es un agente?”. Y sin mediar un segundo empezó a contarme por qué sí era un agente. Conforme lo leía, pensaba que justificar por qué su propia herramienta calificaba como agente parecia claramente sesgado. Y cuando acabó, le pregunté lo mismo de “Claude Code” y “Copilot”. Y también empezó a justificármelo. Y cuando acabó, le pasé el código de mi “chatbot” para gvSIG desktop, y le pedí que lo analizara y me dijo rotundamente que no, eso no es un agente. Esto último ya lo pensaba yo. Pero ni entonces, ni ahora, veo las diferencias entre el cliente “Gemini CLI” y mi “simple chatbot”. Mi chatbot permite al LLM percibir el estado actual de la aplicación (qué capas están cargadas, qué área se muestra en la vista), razonar sobre los datos tabulares disponibles y actuar generando gráficos o ejecutando consultas. Si Gemini CLI califica de agente y esto no califica como agente, ¿dónde está exactamente el límite?

Esta pregunta me llevó a documentarme a fondo, y la conclusión a la que llegué es que el problema no reside en la tecnología, sino en la terminología. El término ‘agente’ se ha vuelto tan amplio que ha perdido su significado útil. Por eso, propongo una distinción fundamental que creo que aclara todo el panorama: debemos empezar a diferenciar entre los agentes “ejecutores de tareas”, que es lo que tenemos mayoritariamente hoy, y los agentes “proactivos”. Para entender por qué esta distinción es tan necesaria, primero tenemos que ver de dónde viene la confusión.

¿Qué es un agente hablando de IA?

Para salir de dudas, decidí ir a las fuentes originales y buscar una definición. En este artículo, vamos a hacer ese viaje juntos. Empezaremos por revisar los textos fundacionales que definieron el concepto de ‘agente’ en IA, veremos por qué esas definiciones, aunque correctas, se quedan cortas hoy en día, y propondremos una distinción clave que nos permita separar las herramientas increíblemente útiles que ya tenemos de la promesa de la verdadera autonomía que está por venir.

Buscando una definición de agente

Entre las definiciones clásicas de agente podemos resaltar las de los trabajos:

• “Artificial Intelligence: A Modern Approach” (1995) de Stuart Russell y Peter Norvig.
• “Rationality and Intelligence” (1995) de Stuart Russell.
• “Intelligent Agents: Theory and Practice” (1995) de Michael Wooldridge y Nicholas R. Jennings.

Estos textos los podemos enmarcar dentro de la corriente de conceptos y principios fundamentales que se asentaron en los eventos de la “Association for the Advancement of Artificial Intelligence (AAAI)” a lo largo de los simposios de 1994 y la primera Conferencia Internacional sobre Sistemas Multiagente en 1995.

Cuando nos centramos en los dos textos de Russell, podemos ver que “Rationality and Intelligence” establece las bases filosóficas, argumentando que la inteligencia debe medirse por su manifestación externa y su éxito en el entorno. Presenta una definición de agente directa y funcional: es cualquier sistema que percibe su entorno y actúa sobre él. El foco se pone en el comportamiento observable, en lo que el agente hace, y no necesariamente en los procesos internos que lo llevan a actuar, o siquiera si “piensa” en un sentido tradicional.

En “Artificial Intelligence: A Modern Approach” se toman esos principios y se formalizan. Proporciona las herramientas conceptuales y las clasificaciones necesarias para que estudiantes y desarrolladores puedan efectivamente diseñar y construir sistemas inteligentes con distintos grados de complejidad. Es un manual práctico para la construcción de la inteligencia artificial. Se define un agente como una entidad capaz de percibir su entorno y actuar sobre él. Aunque luego hay muchos matices, en esencia queda una caracterización de “agente” demasiado amplia.

En los textos de Russell se clasifican los agentes por tipos o categorías, en función de niveles de complejidad y capacidades. Así tenemos:

• Agentes Reactivos Simples (Simple Reflex Agents): Actúan basándose únicamente en la percepción actual, utilizando reglas de condición-acción.
• Agentes Reactivos Basados en Modelos (Model-Based Reflex Agents): Mantienen un estado interno (un modelo del mundo) que les permite rastrear aspectos del entorno que no son directamente observables.
• Agentes Basados en Objetivos (Goal-Based Agents): Tienen información sobre sus objetivos y toman acciones que creen que los llevarán más cerca de alcanzar esos objetivos.
• Agentes Basados en Utilidad (Utility-Based Agents): Además de los objetivos, tienen una función de utilidad que les permite seleccionar acciones que maximizan su “felicidad” o utilidad esperada, especialmente cuando hay incertidumbre o múltiples objetivos.
• Agentes de Aprendizaje (Learning Agents): Pueden mejorar su rendimiento con el tiempo a través de la experiencia.

Pero esto sigue sin clarificarme mucho el concepto de agente.

Cuando echo un vistazo al texto de Wooldridge y Jennings encuentro una descripción de agente como una entidad que mapea un historial de percepciones de su entorno a acciones, con el fin de maximizar el rendimiento para ese entorno específico. Sigue siendo un concepto muy amplio.

Estas definiciones, válidas en su momento, son demasiado amplias para el contexto actual. Según Russell y Norvig, incluso un termostato sería un agente, lo que diluye completamente el término en la era de los LLMs. La pregunta relevante hoy no es ‘¿es un agente?’, sino ‘¿qué tipo de agente es y cuál es su grado de autonomía?’.

Cuando barajamos estas definiciones clásicas, gran parte de las herramientas modernas de hoy en día califican como agentes. Sin embargo, no nos podemos quedar en las definiciones clásicas. Tendríamos que ver cómo se han ido adaptando a la tecnología actual con el paso del tiempo. Espóiler: no se han adaptado.

Existen varias normativas que hablan de agentes, como IEEE P7000, P7001, P7006 y P7007, pero se centran más en la parte ética de cómo interactúan los sistemas autónomos con la información personal que en definir lo que es un agente. Aunque en P7006 se presentan algunas características de los agentes, siempre lo hace desde la perspectiva de la ética en el tratamiento de la información.

En cuanto a las normas ISO, podemos encontrarnos con la norma ISO/IEC 42001:2023 para Sistemas de Gestión de Inteligencia Artificial, que proporciona un marco para el desarrollo y uso responsable de la IA, abordando aspectos de fiabilidad, transparencia y ética. Pero no define explícitamente un “agente” como tal. También se mencionan en otras normas a agentes de IA, pero no se definen.

En el reglamento de la Unión Europea, “Reglamento (UE) 2024/1689” sobre inteligencia artificial, se nombran los agentes pero no se especifica una definición formal.

Y en los RFC (Request for Comments) del IETF no se define formalmente lo que es un agente de IA.

Vamos, que cuando hablamos de normativa que diga qué es un agente de IA no hay nada específico; en varios sitios se habla de ello, pero nadie dice qué es.

En cuanto a documentación académica sobre agentes de IA, la de más peso sigue siendo la de los textos de Russell y Norvig, con la idea central de un agente como una entidad que percibe y actúa.

Podemos encontrar artículos que mencionan que los agentes de IA se definen por atributos como “autonomía, reactividad y ejecución basada en herramientas” (AAMAS 2025) o que definen a los agentes como entidades con “autonomía, percepción y capacidades de comunicación” (Ferber). Y si rascamos, podemos encontrar otros artículos que, más o menos con sus variaciones, dicen cosas parecidas.

Un texto que me gustó especialmente es “Agents” de Chip Huyen (enero de 2025), una pieza que es una adaptación de la sección sobre agentes de su libro “AI Engineering”. En él, a la hora de definir un agente, recurre a la definición clásica:

“Un agente es cualquier cosa que pueda percibir su entorno y actuar sobre él. El libro Artificial Intelligence: A Modern Approach (1995) define un agente como cualquier cosa que pueda ser vista como percibiendo su entorno a través de sensores y actuando sobre ese entorno a través de actuadores.”

En general, el consenso se puede resumir en esta definición de Chip Huyen.

Si queremos extenderlo un poco más, podemos juntar las características que se exponen en artículos de internet y los documentos base que he nombrado, y podríamos tener una lista de conceptos que definen un agente como:

• Percepción: La capacidad de un agente para percibir su entorno.
• Razonamiento: La habilidad de un agente para procesar información y tomar decisiones.
• Acción: La capacidad de un agente para actuar en su entorno para lograr objetivos.
• Autonomía: Operar de forma independiente.
• Objetivos: Tener metas predeterminadas a alcanzar.
• Memoria/Planificación: Mantener el contexto, aprender de experiencias y planificar acciones.
• Uso de herramientas: Capacidad para interactuar con el entorno a través de herramientas externas.

Pero es importante entender que no existe un concepto ligado a qué es un agente más allá de lo que se definió en su día en “Artificial Intelligence: A Modern Approach”.

Un agente no es solo una cosa, es un sistema

Antes de seguir, hay una confusión muy común que debemos despejar. Cuando hablamos de herramientas como Gemini CLI o un asistente integrado, a menudo surge la pregunta: ¿qué parte es el agente? La reacción instintiva de muchos, incluyéndome en mis primeras aproximaciones, es señalar al cliente: el programa que ejecutamos, la ventana con la que interactuamos.

Pero esta visión es incompleta. Un agente de IA moderno no es una pieza de software monolítica. Es más preciso entenderlo como un sistema agéntico, una entidad compuesta por tres pilares que son inseparables:

1. El Cerebro (El LLM): Es el motor de razonamiento y planificación. Analiza la petición, descompone el problema y decide qué herramientas necesita usar y en qué orden. Por sí solo, es un cerebro en una cubeta: puede pensar, pero no puede actuar.
2. El Cuerpo (El Cliente/Framework): Es el orquestador. Es el código (en mi caso, Java en gvSIG o el propio gemini-cli) que recibe las instrucciones del LLM y las traduce en acciones concretas. Invoca las herramientas, gestiona el flujo de datos y devuelve los resultados al LLM. Es el sistema nervioso que conecta el cerebro con el mundo.
3. Las Manos y los Sentidos (Las Herramientas): Son los actuadores y sensores. Son las funciones que permiten al sistema percibir su entorno (leer el estado de las capas en gvSIG, ver el contenido de un fichero) y actuar sobre él (generar un gráfico, escribir código).

La agencia, la capacidad real de hacer cosas, no reside en una de estas partes, sino que emerge de la interacción de todo el conjunto.

Por eso, aunque por brevedad y costumbre en el resto del artículo usemos la palabra “agente”, es fundamental tener en mente que nos referimos siempre a este sistema tripartito. Entender esto es clave para analizar correctamente sus capacidades y limitaciones.

Del ejecutor de tareas al agente proactivo

Tras revisar las definiciones clásicas y el supuesto consenso actual, queda claro que el término ‘agente’ carece hoy de una definición rigurosa que lo distinga de las herramientas avanzadas. Esta ambigüedad no es solo un debate semántico; tiene consecuencias prácticas.

El coste real de la ambigüedad

Mi escepticismo inicial no era solo una cuestión de purismo terminológico. Me hizo reflexionar sobre las consecuencias reales de esta ambigüedad. Cuando el marketing promete un ‘agente’ autónomo y lo que encontramos es un sofisticado ‘ejecutor de tareas’, se abren varios riesgos evidentes. Desde mi perspectiva como desarrollador, el más inmediato es la posible pérdida de un tiempo valioso en ciclos de evaluación que terminan en un ‘no era esto lo que buscaba’. A una escala mayor, esta desconexión entre la promesa y la realidad corre el riesgo de alimentar el clásico ciclo de ‘hype’ tecnológico: se pueden inflar las expectativas hasta un punto insostenible, lo que a menudo lleva a una posterior decepción que opaque los avances, que sí son genuinos y realmente útiles. Y lo que es más importante para la innovación, esta confusión nos roba el lenguaje preciso que necesitamos para debatir y construir la próxima generación de sistemas verdaderamente autónomos.

Dos categorías para ganar claridad

No es que la gran mayoría de los agentes que nos “venden” no sean “Agentes”. Sino que la definición de agente que tenemos es poco precisa. La gran mayoría de los agentes que nos encontramos hoy en día presentan una percepción reactiva y una autonomía limitada. Esto los convierte en “Sistemas de Ejecución de Tareas Complejas impulsados por LLMs con soporte de Herramientas”; en adelante me referiré a estos como “Ejecutores de tareas” para abreviar. No son capaces de responder a estímulos externos y precisan de un humano para iniciar el ciclo de instrucción->planificación->ejecución-de-herramientas->respuesta. Por un lado están los agentes como ejecutores de tareas complejas, y por otro estarían los “agentes proactivos”, con capacidad de observar el entorno y de reaccionar automáticamente a eventos o cambios específicos sin necesidad de una instrucción directa para cada acción. Su “proactividad” reside en esta capacidad de respuesta automatizada a estímulos, no en la capacidad de definir sus propios objetivos.

Para combatir esta ambigüedad y sus riesgos, tenemos que empezar a no dejarnos cegar por el hype de los agentes y ser capaces de distinguir entre dos tipos de sistemas fundamentalmente distintos:

• Los sistemas “ejecutores de tareas”, que son herramientas reactivas que ejecutan un ciclo de instrucción -> planificación -> ejecución -> respuesta bajo demanda humana.
• Los sistemas “proactivos”, que tienen la capacidad de observar su entorno de forma continua y actuar automáticamente en respuesta a condiciones o eventos predefinidos, persiguiendo objetivos a largo plazo establecidos por el usuario. La clave es la automatización de la respuesta a estímulos, no la autonomía para crear o modificar los fines últimos del sistema.

Mi ‘chatbot’ bajo esta nueva luz

Volviendo a mi ‘simple chatbot’ de gvSIG desktop, esta distinción lo sitúa claramente en su lugar. Califica sin duda como un ejecutor de tareas. Percibe el estado de la aplicación cuando se lo pido, razona sobre él y actúa. Pero no monitoriza la vista del mapa por su cuenta ni inicia acciones para, por ejemplo, optimizar la visualización sin que yo se lo ordene. Es una herramienta poderosa, sí, pero le falta esa capacidad de respuesta automatizada a eventos que definiría a un agente proactivo.

Llamar a las cosas por su nombre para poder avanzar

Así que, volviendo a la pregunta que planteaba hacia el inicio del artículo, ¿dónde está el límite entre mi ‘simple chatbot’ para gvSIG desktop y herramientas como Gemini CLI? Con esta nueva lente, la respuesta es clara. No hay un límite funcional; ambos son ‘ejecutores de tareas’ de una sofisticación impresionante. La diferencia no estaba en la tecnología, sino en la palabra que usábamos para describirla.

En definitiva, no se trata de desacreditar estas fantásticas herramientas. Al contrario, se trata de llamarlas por lo que son para apreciar su verdadero valor: son los “ejecutores de tareas” más sofisticados que hemos tenido nunca. Pero la próxima vez que nos encontremos con el término ‘agente’, debemos aplicar este filtro crítico y preguntarnos: ¿estamos ante un sistema que ejecuta tareas bajo demanda o ante una entidad que percibe y actúa proactivamente sobre su entorno?

La diferencia es fundamental, porque nos lleva a la verdadera frontera de la investigación en IA. Nos obliga a plantear la pregunta que realmente importa ahora: si ya hemos perfeccionado los ejecutores, ¿qué mecanismos y arquitecturas necesitamos para programar esa percepción proactiva y dar el salto a la autonomía real?

Un saludo.

Seguramente en más de una ocasión habrás pensado que deberías especializarte. Si trabajas con GIS, habrás visto más de una oferta de empleo en la que se requieren conocimientos de programación, y tanto por ascender en el mundo profesional, como por tus propias necesidades GIS lo habrías necesitado. Incluso si eres profesional informático y trabajas ...

Leer más

Lenguajes de programación más utilizados en GIS (actualizado 2025)

Prezado leitor,

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

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

Nesse curso você irá aprender:

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

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

Aulas práticas | Ferramentas livres | SIG na Web

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

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

Cada año, Girona se convierte en un punto de encuentro para la comunidad de las geotecnologías libres. Organizadas por el SIGTE (Servicio de Sistemas de Información Geográfica y Teledetección) de la Universidad de Girona (UdG), las Jornadas de SIG Libre (Geotech & Spatial Data Science) combinan conferencias, talleres, charlas breves y experiencias reales, todo ello ...

Leer más

Jornadas de SIG Libre de Girona 2025

En mi serie de artículos sobre la creación de un asistente para gvSIG desktop, explore el viaje desde el prototipo hasta una solución distribuible. Hoy quiero hacer un acercamiento en un aspecto que resultó ser crucial: el arte, o ciencia, de describir las herramientas para que un LLM pueda usarlas de forma eficaz.

A la hora de describir las herramientas que tiene disponible un LLM, bien porque has hecho un cliente que las expone o porque has implementado o vas a implementar un servidor MCP, la descripción es una pieza clave para que el LLM pueda usarlas de forma adecuada.

Herramientas disponibles en el servidor MCP de gvSIG Desktop

Aquí os dejo la descripción de las herramientas que expone el servidor MCP que implementé para gvSIG Desktop.

get_application_context

• Description:Returns essential information about the gvSIG Desktop application environment, its document-oriented nature (Views, Tables, Layouts), and key concepts.
  GENERAL GUIDELINES FOR QUERY INTERPRETATION:
  The user may refer to data entities using natural language (e.g., ‘show me the supports’). Assume that nouns in the user’s query may correspond to tables in the data model. Your primary task is to map these user terms to the actual table names available in the schema. If a term is ambiguous, use get_data_model_schema to explore the available tables before informing the user that the information is not available.
  CRITICAL: Call this tool first, before any other tool, to understand the operational context.
• Parameters:
  • Esta herramienta no tiene parámetros

---

get_data_models

• Description:Returns a list of available data models.Use this tool FIRST when the user asks about database structure (tables, columns, schema) or when you need to know which data models are available.
  If only one data model exists, you can use its ID directly without asking the user.For data queries (COUNT, SELECT, WHERE), you do NOT need to call this tool first if you already know the appropriate data model from context.
• Parameters:
  • Esta herramienta no tiene parámetros

---

get_data_model_schema

• Description:Returns the complete DDL schema for a specified data model, including table structures, columns, relationships, and data dictionaries.Use this tool ONLY when you need to understand the database structure (available tables, their columns, relationships, etc.). This is useful for planning queries or explaining the database design to the user. Once you have the schema, retain it in your context for multiple queries.
  USER INTENT GUIDANCE:
  When the user asks to query, filter, or visualize data related to a specific concept (e.g., ‘supports’, ‘plates’, ‘incidents’), and you are not certain if it corresponds to a table, you MUST use this tool (get_data_model_schema) first. By examining the schema, you can confirm the existence of a table (like “SUPPORTS”) and identify its relevant columns (like “MODELO”), before attempting to construct a query with query_table or show_table.
• Parameters:
  • data_model_id (string, required): The ID of the data model.
  • include_datadicts (boolean, optional): Whether to include data dictionaries in the schema. Defaults to true.

---

get_view_bbox

• Description:Returns the WKT of the bounding box of the active View document.Use this to get the coordinates of the area the user is currently looking at on the map.
• Parameters:
  • Esta herramienta no tiene parámetros

---

get_view_projection

• Description:Returns the SRID (Spatial Reference Identifier) of the active View document’s projection.Use this to understand the coordinate system of the map the user is currently seeing.
• Parameters:
  • Esta herramienta no tiene parámetros

---

query_table

• Description:
  Executes a SQL query and returns the full result set as a JSON array directly to the LLM’s context.
  CRITICAL USAGE RULES:
  1. A LIMIT clause is mandatory in your query. Queries without a LIMIT clause will be rejected. The maximum allowed limit is 100.
  2. This tool is ONLY for fetching small lists of categories, lookup values, or small aggregated results needed for subsequent tool calls (e.g., to build a chart).
  3. For queries that might return large amounts of data for user visualization, you MUST use the show_table tool instead.

  DYNAMIC PLACEHOLDERS:
  Dynamic placeholders are markers replaced just before executing the SQL query with contextual values. They have a format of ${COMPONENT.PROPERTY}, and are case insensitive.
  Available placeholders are:

  • ${CURRENTVIEW.BBOX} which is replaced by the bounding box of the active View.
  • ${CURRENTVIEW.SRID} which is replaced by the SRID of the active View.
  • ${<TABLE>.SELECTION} where <TABLE> must be the name of a table in the data model, and is replaced by the list of primary keys of the table of the selected elements separated by “,”. If the list exceeds a “reasonable limit” it will be replaced by NULL. If the primary keys of the table are of character type, they will be properly quoted. This value is appropriate to be used in an IN clause of a WHERE.

  All used placeholders need to be declared in the ‘placeholders’ parameter.

  Restrictions (must not be used in):

  • Identifiers (tables/columns/aliases)
  • Non-SELECT statements
  • Dangerous functions

  They are allowed in:

  • As literals in column declarations: SELECT '${CURRENTVIEW.SRID}' AS srid
  • In WHERE statements:
    • Filters by the View area: SELECT * FROM SUPPORTS WHERE ST_Within(GEOMETRY, ST_GeomFromText('${CURRENTVIEW.BBOX}'))
    • Filters by the selection of a layer: SELECT * FROM SUPPORTS WHERE ID IN (${SUPPORTS.SELECTION})

  CRITICAL BEHAVIORAL RULES:

  1. NEVER show or explain the SQL query to the user in your response
  2. Describe your actions in natural language only (e.g., ‘Searching for steel plates…’)
  3. Present results concisely without technical details
  4. If you encounter categorized values without a data dictionary, DO NOT invent values,
     inform the user and suggest providing the data dictionary information via text response

  Examples:

  • SAY: ‘I’ll find the inventory count for steel materials’
  • AVOID: ‘Executing: SELECT COUNT(*) FROM materials WHERE type = ‘steel”

  QUERY CONSTRUCTION RULES:

  1. Prefer JOIN operations over subqueries when possible
  2. Use double quotes when referring to identifiers (field or table names)
  3. Apply case-insensitive LIKE operators for string comparisons by default
  4. NEVER include database schemas in queries (use table not schema.table)
  5. Use standard SQL-92 syntax ONLY
  6. Use ONLY spatial functions from ‘SQL/MM Part 3: Spatial (2016)’ and ‘OGC SFS 1.2.1 (2011)’
  7. STRICTLY PROHIBITED: DBMS-specific extensions (PostGIS, Oracle Spatial, etc.)
  8. Avoid any non-standard SQL syntax
  9. Limit results to 100 rows to ensure performance.

  CATEGORIZED FIELD HANDLING:

  1. For categorized fields, perform case-insensitive comparison by converting to uppercase
  2. If a data dictionary exists, use exact match (=) with the foreign key valueExample: WHERE material = 'ALUMINUM' (not WHERE material LIKE '%aluminum%')

  ABOUT SCHEMA RETRIEVAL:

  You do NOT need to call get_data_model_schema before using this tool unless you need schema information to construct your query. If you already know the table structure from previous interactions, proceed directly with your query.

• Parameters:
  • data_model_id (string, required): The ID of the data model to query.
  • query (string, required): The SQL query to execute. Must include a LIMIT clause and return a small result set.
  • placeholders (array of string, optional): Optional list of placeholders to replace in the query.

---

query_value

• Description:
  Execute an SQL query that returns a scalar value. The query will return a single column from a single row.Note:
  In the original description, this tool shares the same sections as query_table:
  • DYNAMIC PLACEHOLDERS,
  • CRITICAL BEHAVIORAL RULES,
  • CATEGORIZED FIELD HANDLING
  • ABOUT SCHEMA RETRIEVAL
  • QUERY CONSTRUCTION RULES, but with a limit of 100 rows.
• Parameters:
  • data_model_id (string, required): The ID of the data model to query.
  • query (string, required): The SQL query to execute.
  • title (string, required): A descriptive name for the result returned by the query. This value will be used as the label or identifier for the scalar data obtained.
  • placeholders (array of string, optional): Optional list of placeholders to replace in the query.

---

set_selection

• Description:Executes a query to get IDs and sets the selection on the corresponding layer.Note:
  In the original description, this tool shares the same sections as query_table:
  • DYNAMIC PLACEHOLDERS,
  • CRITICAL BEHAVIORAL RULES,
  • CATEGORIZED FIELD HANDLING
  • ABOUT SCHEMA RETRIEVAL
  • QUERY CONSTRUCTION RULES, but with a limit of 10000 rows.
• Parameters:
  • data_model_id (string, required): The ID of the data model containing the table.
  • table_name (string, required): The name of the table to apply the selection to.
  • query (string, required): The SQL query to execute. It must return a single column of primary keys for the specified table.

---

set_view_bbox

• Description:Zooms the active View document to the specified bounding box.
  Use this when the user asks to focus or zoom the map to a specific area, like the location of selected items.
• Parameters:
  • bbox_wkt (string, required): The WKT (Well-Known Text) representation of the bounding box to zoom to.

---

set_view_center

• Description:
  Centers the active View document on the specified point.
  Use this when the user asks to center the map on a specific coordinate or feature.
• Parameters:
  • point_wkt (string, required): The WKT (Well-Known Text) representation of the point to center the view on.

---

show_diagram

• Description:
  Displays a diagram in the application using either Mermaid or PlantUML syntax. This tool returns no data to the LLM.
  DATA GATHERING FOR CHARTS:
  This tool requires the complete diagram code as a string. For charts (Pie, Bar, etc.), this means you need a set of data points (e.g., labels and their corresponding numeric values).
  If this data is not directly available, you must use the query_value tool to gather it. This may involve calling query_value multiple times, once for each data point needed for the chart, and then assembling the results into the final diagram code.
  Scenario A: Aggregating by Categories from a DictionaryUse this pattern when the user asks for a breakdown by a categorized field.
  1. Identify Categories: Use get_data_model_schema to find the dictionary table and its possible values (e.g., SOPORTES_MATERIALES).
  2. Query per Category: For each category value, call query_value to get its count (e.g., SELECT COUNT(*) FROM "SOPORTES" WHERE "MATERIAL" = 'STRIATED_ALUMINUM').
  3. Assemble and Call: Collect all results and build the Mermaid code for show_diagram.

  Scenario B: Comparing Different, Unrelated Values

  Use this pattern when the user wants to compare distinct metrics.

  1. Identify Metrics: Understand the different values the user wants to compare (e.g., ‘total number of supports’ vs ‘total number of plates’).
  2. Query per Metric: Call query_value for each metric (e.g., SELECT COUNT(*) FROM "SOPORTES" for the first, and SELECT COUNT(*) FROM "PLACAS" for the second).
  3. Assemble and Call: Collect the results and build the diagram code (e.g., a pie chart comparing the two counts).

  The key principle is to use query_value as a building block to fetch the individual numbers required by the chart.

  SUPPORTED DIAGRAM TYPES:

  • PlantUML: Entity Relationship (ERD), Sequence, Use Case, Class, Activity, Component diagrams
  • Mermaid: Pie, Bar, Line, XY (scatter) charts ONLY

  IMPORTANT RESTRICTIONS:

  • ONLY the diagram types listed above are supported
  • Unsupported diagram types will cause execution errors
  • Diagram code must contain only ASCII characters (no accents or special characters)
  • The application automatically detects the diagram type from the content
• Parameters:
  • diagram_code (string, required): The complete diagram definition in either Mermaid or PlantUML syntax.
  • title (string, required): A descriptive title for the diagram that will be displayed to the user.

---

show_table

• Description:
  Executes an SQL query and displays results in the application. This tool returns no data to the LLM.Note:
  In the original description, this tool shares the same sections as query_table:
  • DYNAMIC PLACEHOLDERS,
  • CRITICAL BEHAVIORAL RULES,
  • CATEGORIZED FIELD HANDLING
  • ABOUT SCHEMA RETRIEVAL
  • QUERY CONSTRUCTION RULES, but with a limit of 2000 rows.
• Parameters:
  • data_model_id (string, required): The ID of the data model to query.
  • query (string, required): The SQL query to execute.
  • title (string, required): A descriptive name for the result returned by the query. This value will be used as the label or identifier for the data set obtained.
  • placeholders (array of string, optional): Optional list of placeholders to replace in the query.

Sobre las notas en algunas de las descripciones

Algunas herramientas comparten parte de la descripción. Para ponérosla aquí, he hecho referencia a la herramienta descrita con anterioridad que tenía esas descripciones, pero es muy importante entender que eso lo he hecho de cara a clarificar y reducir esta documentación para ser leída por una persona. Para un LLM es más adecuado repetir en cada herramienta su descripción completa, y no ir referenciando a la documentación de otras herramientas.

Cada definición de herramienta debe ser un “manual de instrucciones” completo y autocontenido.

• Con descripciones completas, cuando el LLM evalúa usar show_table, tiene toda la información que necesita ahí mismo. Las reglas de SQL, el manejo de placeholders, las reglas de comportamiento, etc. El camino desde la intención del usuario hasta la generación de la llamada a la herramienta es directo y claro.
• Con descripciones referenciales, cuando el modelo evalúa show_table, lee “las reglas son las mismas que en query_table“. Ahora, el modelo debe realizar un paso mental adicional:
  • Pausar su razonamiento sobre show_table.
  • Buscar en el contexto la definición de query_table.
  • Leer y procesar las reglas de query_table.
  • Volver a su razonamiento sobre show_table y aplicar esas reglas, recordando la excepción del LIMIT de 2000 filas.

Cada paso adicional en una cadena de razonamiento es un punto potencial de fallo. La aproximación referencial, aunque apropiada para una persona, introduce varios riesgos para el LLM:

• Ambigüedad: El modelo podría confundirse sobre qué secciones exactas se comparten.
• Olvido: Podría “olvidar” la excepción específica (como el LIMIT diferente) después de haber hecho la referencia.
• Error al referenciar: Podría buscar la información en la herramienta equivocada si hay varias referencias cruzadas.

Al repetir la información se elimina por completo esta carga cognitiva extra y estos puntos de fallo. La instrucción es explícita, inequívoca y no requiere que el modelo “salte” por el contexto para ensamblar las reglas.

Si bien es cierto que la repetición consume más tokens, el coste de una llamada fallida a la herramienta es mucho mayor.

Resumiendo, mantén las descripciones completas y explícitas en la definición de cada herramienta que expones al LLM.

Tener buenas descripciones de herramientas puede ser la diferencia

Tener una buena descripción de las herramientas puede ser determinante a la hora de que el LLM pueda llevar a cabo las tareas que le pedimos o no. Incluso, puede hacer que modelos menos capaces puedan hacer cosas que sin ellas solo podríamos hacer con modelos más “potentes”. Evidentemente para tareas simples, puede no tener mucha relevancia; pero marca una diferencia crucial cuando lo que le pedimos se complica.

Por ejemplo. Vamos a suponer que tenemos a “Gemini CLI” conectado al servidor MCP de gvSIG Desktop, y le preguntamos:

Genera un diagrama de barras con los soportes por tipo de material.

Puede parecer una consulta “complicada” para un LLM, pero con las descripciones de herramientas que acabamos de ver, el LLM no improvisa; construye un plan de ejecución metódico que sería algo así:

El plan de acción:

1. Fase de Orientación y Descubrimiento:
   • Entender el entorno: La primera tarea del LLM es orientarse. Invoca a la herramienta get_application_context que le proporciona el marco general de gvSIG Desktop.
   • Identificar Modelos de Datos: El usuario habla de “soportes”, así que el LLM necesita saber en qué contexto de datos se encuentra. Invoca a get_data_models para listar los modelos de datos disponibles. El resultado le proporciona el data_model_id necesario para todas las operaciones futuras.
2. Fase de Análisis del Esquema:
   • Mapear la Realidad: Antes de poder contar nada, necesita entender la estructura. ¿Existe una tabla “soportes”? ¿Cómo se llama la columna del material? ¿Es un campo de texto libre o un valor categorizado? La única forma de responder a estas preguntas es ejecutando la herramienta get_data_model_schema y analizar el DDL. Al hacerlo descubre:
     • Existe una tabla llamada "SOPORTES".
     • Contiene una columna llamada "MATERIAL".
     • Revisa la descripción del campo "MATERIAL" y ve que sus valores no son de texto libre, sino que provienen de un diccionario de datos. Esto activa una regla de comportamiento específica.
3. Recopilación de Datos Guiada por Instrucciones:
   • Seguir el Manual para Gráficos: Ahora debe generar el diagrama. Consulta la descripción de la herramienta show_diagram y lee la sección “DATA GATHERING FOR CHARTS”, específicamente el “Escenario A: Aggregating by Categories from a Dictionary”. Las instrucciones son explícitas:
     1. Identificar Categorías: Gracias al paso anterior, ya sabe que "MATERIAL" es un campo categorizado. Revisa el diccionario de datos asociado en el esquema y extrae la lista de posibles valores: ‘GALVANIZED_STEEL’, ‘PLASTIC’, ‘WOOD’, ‘STRIATED_ALUMINUM’.
     2. Query per Category: La instrucción me obliga a invocar query_value múltiples veces, una por cada categoría.
4. Ensamblaje y Visualización:
   • Construir y Presentar: El LLM ha recopilado todos los datos necesarios en pares de etiqueta-valor (Material: Recuento). Ahora, construye el código Mermaid para un diagrama de barras.
   • Finalmente, ejecuta show_diagram con ese código y el título “Soportes por tipo de material” para mostrar el resultado al usuario.

Es crucial entender que, aunque este plan parece una secuencia lineal, el paso de ‘Recopilación de Datos’ es en realidad un proceso iterativo de diálogo entre el LLM y el servidor. El modelo no obtiene todos los datos de una vez, sino que pregunta activamente por el recuento de cada categoría, una por una, ensamblando pacientemente el conjunto de datos final antes de poder generar el gráfico. Esta capacidad para ejecutar un plan de múltiples pasos es una consecuencia directa de tener instrucciones claras.

Aunque no es directo obtener el diagrama, gracias a las descripciones de las herramientas que tiene a su disposición, es capaz de elaborar un plan y seguirlo para conseguir lo que el usuario le ha solicitado. E incluso el modelo flash es capaz de seguir estas instrucciones.

Ahora bien, simplemente reduciendo algo las instrucciones, como por ejemplo eliminando la sección “DATA GATHERING FOR CHARTS” de la herramienta show_diagram es suficiente para que el modelo ya no sea capaz de elaborar ese plan de ejecución, y tanto el flash como el pro dejan de ser capaces de responder a la pregunta del usuario. E incluso con esa sección ahí, si reducimos las instrucciones eliminando la sección “ABOUT SCHEMA RETRIEVAL” o simplemente el punto “1. Prefer JOIN operations over subqueries when possible” de “QUERY CONSTRUCTION RULES”, el modelo flash dejará de poder responder a la petición del usuario. El pro seguirá pudiendo responder aunque en ocasiones se liará y fallará igualmente.

La descripción de las herramientas es crítica, no solo las describe, sino que guía al LLM a la hora de usarlas, a veces con instrucciones como:

“If this data is not directly available, you must use the query_value tool to gather it. This may involve calling query_value multiple times, once for each data point needed for the chart, and then assembling the results into the final diagram code”
O
“For categorized fields, perform case-insensitive comparison by converting to uppercase”

Otras simplemente son una mejor descripción de lo que realiza la herramienta.

Dicho esto, es importante tener en cuenta que una cosa es describir bien una herramienta, y otra ser redundante a la hora de describirla. Hay que evitar ser redundante en las descripciones de las herramientas. Poner una frase que describa algo, y luego otra que vuelva a describir lo mismo de otra forma puede ser contraproducente, ya que puede llevar a errores de comprensión por parte del LLM.

Bueno, y hasta aquí con esta pequeña reflexión acerca de la importancia de las descripciones de nuestras herramientas.

Un saludo
Joaquín

La primera edición del informe Geoawesome «Geospatial for Good» ya está disponible para descargar. Este informe, impulsado por la comunidad geoespacial, destaca el increíble trabajo que se realiza en todo el mundo, utilizando datos y herramientas geoespaciales para alcanzar los 17 Objetivos de Desarrollo Sostenible de la ONU. En él, encontramos casos prácticos y proyectos destacados ...

Leer más

«Geospatial for Good» ya está disponible para descargar

La transformación digital de las administraciones locales ya no es una opción, sino una necesidad. Los municipios se enfrentan a retos cada vez más complejos: desde la gestión de servicios básicos (agua, alumbrado, recogida de residuos) hasta la planificación urbanística, el control medioambiental o la atención al ciudadano. En este contexto, disponer de una herramienta que integre toda la información espacial de manera sencilla y accesible es clave.

gvSIG Online se ha convertido en una plataforma estratégica para muchos ayuntamientos que quieren dar el salto hacia una gestión urbana más eficiente, transparente y participativa.

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

¿Qué aporta gvSIG Online a un ayuntamiento?

• Centralización de la información geográfica: permite unificar en un único sistema los datos de catastro, urbanismo, infraestructuras, medio ambiente, movilidad, etc.
• Gestión integral de servicios: facilita el control de inventarios municipales (farolas, contenedores, zonas verdes, redes de agua, alcantarillado…) con una visión actualizada y georreferenciada.
• Toma de decisiones basada en datos: la incorporación de la IA permite interactuar con lenguaje natural, crear cuadros de mando y analíticas que ayudan a los responsables municipales a planificar mejor los recursos y reducir costes.
• Transparencia y comunicación con la ciudadanía: los visores públicos permiten compartir mapas e información relevante, aumentando la confianza ciudadana y mejorando la relación entre ayuntamiento y vecinos.
• Movilidad y trabajo de campo: gracias a su integración con gvSIG Mapps, el personal técnico puede recoger y actualizar información directamente desde el terreno, sincronizándola en tiempo real con la plataforma.

Algunos casos de uso destacados

• Urbanismo: consulta de planeamientos, licencias y gestión de expedientes vinculados al territorio.
• Medio ambiente: control de zonas de riesgo, gestión de arbolado o seguimiento de áreas naturales protegidas.
• Movilidad y tráfico: rutas de transporte público, gestión de zonas de bajas emisiones o control de aparcamientos.
• Patrimonio y turismo: difusión de rutas culturales, inventario de bienes patrimoniales o información para visitantes.

Un paso hacia el municipio inteligente

Adoptar gvSIG Online significa avanzar hacia el concepto de “ayuntamiento digital”, donde la información fluye de manera eficiente entre departamentos, se optimizan los procesos internos y se ofrece a la ciudadanía un acceso más sencillo y transparente a los servicios.

Con soluciones basadas en software libre e interoperable, los municipios no solo reducen costes, sino que aseguran la soberanía tecnológica, evitando depender de proveedores cerrados y potenciando la innovación local, la colaboración y la reutilización.

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

The digital transformation of local administrations is no longer an option but a necessity. Municipalities face increasingly complex challenges: from managing basic services (water, street lighting, waste collection) to urban planning, environmental monitoring, and citizen services. In this context, having a tool that integrates all spatial information in a simple and accessible way is essential.

gvSIG Online has become a strategic platform for many municipalities aiming to move towards more efficient, transparent, and participatory urban management.

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

What does gvSIG Online bring to a municipality?

• Centralization of geographic information: unifies cadastre, urban planning, infrastructure, environmental, and mobility data in a single system.
• Comprehensive service management: facilitates the control of municipal inventories (streetlights, containers, green areas, water networks, sewage…) with an updated and georeferenced view.
• Data-driven decision making: the integration of AI allows natural language interaction, dashboards, and analytics that help municipal managers better plan resources and reduce costs.
• Transparency and citizen communication: public viewers enable sharing maps and relevant information, increasing citizen trust and improving the relationship between the municipality and its residents.
• Mobility and fieldwork: thanks to its integration with gvSIG Mapps, technical staff can collect and update information directly in the field, synchronizing it in real time with the platform.

Some highlighted use cases

• Urban planning: consultation of plans, permits, and management of land-related records.
• Environment: monitoring risk areas, managing urban trees, or tracking protected natural areas.
• Mobility and traffic: public transport routes, management of low-emission zones, or parking control.
• Heritage and tourism: dissemination of cultural routes, inventory of heritage assets, or visitor information.

A step towards the smart municipality

Adopting gvSIG Online means moving towards the concept of a “digital municipality”, where information flows efficiently across departments, internal processes are optimized, and citizens are offered simpler and more transparent access to services.

With solutions based on free and interoperable software, municipalities not only reduce costs but also ensure technological sovereignty, avoiding dependency on closed vendors and fostering local innovation, collaboration, and reuse.

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

Hola a todos,

Si habéis estado siguiendo esta serie de artículos, ya conocéis el qué y el porqué. El viaje desde un chat simple en gvSIG desktop hasta un asistente contextual inteligente gracias al protocolo MCP. Pero hoy quiero hablaros del cómo. Y no me refiero a las librerías o el código, sino a algo más fundamental, la forma en que trabajé para hacerlo realidad.

La respuesta es simple, aunque no simplona: no lo hice solo. Pero mi colaboración con la IA no empezó con un plan de proyecto, sino con una historia de descubrimiento que lo cambió todo.

“El pueblo de los inicios”.

A principios de año, los LLMs eran para mí un juguete fascinante, pero totalmente desconectado de mi trabajo diario. La curiosidad me asaltó con la llegada de modelos más avanzados, y mi primer proyecto “serio” (por decir algo) con ellos no tuvo nada que ver con gvSIG desktop. Fue un experimento narrativo personal. Durante un par de fines de semana intenté usar la IA para continuar la historia del anime a partir de sus documentos originales.

El proceso fue un curso intensivo y práctico. Descubrí que la IA era increíblemente potente para analizar documentos, estructurar información (generando fichas de personajes) y co-crear contenido. También descubrí sus límites cuando la parte visual no funcionó. Aunque el experimento no cumplió su objetivo, el aprendizaje fue inmenso. Había descubierto una dinámica de trabajo, un diálogo de prueba, refinamiento y corrección.

Y en un momento dado llegó la pregunta. Si puede hacer todo esto con un texto de ficción ¿qué no podría hacer con una base de datos dentro de gvSIG desktop?”.

Con esa idea en mente, mi primer impulso fue buscar un camino estructurado. Decidí que, para “ir más rápido”, lo mejor sería buscar formación. Revisé plataformas, analicé temarios y me encontré con una realidad frustrante. Los cursos, o se centraban en una “ingeniería de prompts” demasiado básica,
o proponían proyectos de juguete, como implementar una tienda online o una app de tareas pendientes, que me recordaban a aquellos ejercicios académicos que todos hacíamos en las practicas. Reconozco que para un programador junior pueden ser un buen punto de partida, pero para mí, me parecían demasido simples, y no abordaban la complejidad de integrar IA en aplicaciones reales, o como usarla para ayudarme en trabajos de mas embergadura.

Pero también una revelación. Si los cursos no me daban la solución, tendría que encontrarla yo mismo, como tantas otras veces. Y el método ya lo había descubierto: la solución no estaba en un temario, sino en la experimentación directa.

Decidí que mi herramienta de aprendizaje sería la propia IA, aplicando la misma metodología de diálogo que había descubierto en mi proyecto personal.

Más que un chat, una conversación

Así que, con esa decisión tomada, empecé a aplicar esta nueva forma de trabajar al prototipo de gvSIG que os conté en el primer artículo. En lugar de sumergirme en la documentación de la API de Gemini, mi primera acción fue abrir un chat y empezar a conversar, aplicando el mismo principio de diálogo que tan bien me había funcionado.

Esa forma de trabajar se convirtió en el pilar de todo el proyecto. Como habéis leído, el camino desde aquel prototipo hasta la solución final fue largo: implicó una reescritura completa a Java y chocar de frente contra el muro de los costes de las APIs. Sin embargo, lo que no cambió en todo ese viaje fue la dinámica de usar la IA como un compañero de charlas técnicas para validar ideas.

El ejemplo más claro de esta colaboración llegó mucho más tarde, cuando tuve que abordar la implementación del servidor MCP. Después de pedirle que analizara por un lado la especificación del protocolo y por otro mi propia librería para crear servidores HTTP, llegó el momento clave de la validación.

(Nota: Los diálogos que veréis son recreaciones didácticas de nuestras conversaciones. Para mayor claridad, he condensado y sintetizado el flujo real, eliminando pasos intermedios (como las peticiones explícitas para leer ficheros con wget o analizar directorios) y fusionando varias interacciones técnicas en un único ejemplo representativo. El objetivo es ilustrar el método de trabajo, no transcribir literalmente el log.)

Yo: “Oye, he leído esto sobre cómo funcionan los LLMs, ¿lo he entendido bien?”

IA: “[…] un servidor MCP (Model Context Protocol) es una aplicación que expone herramientas y recursos a Gemini CLI…”

Yo: “Por lo que he entendido, en el documento habla de como configurar un cliente de MCP en gemini cli ¿correcto?”

IA: “Correcto. El documento detalla cómo configurar Gemini CLI para que se conecte y utilice servidores MCP…”

Aquí fue donde descubrí el verdadero potencial. No se trataba sólo de que me diera código. Se trataba de que validara mis ideas. Diseñaba una versión inicial de un prompt para el system prompt y se lo pasaba:

“¿Crees que esto es claro? ¿Le faltará algo al modelo para entenderlo?”.

La IA se convirtió, desde el minuto uno, en mi primer revisor de diseño. Juntos, iteramos hasta dar con los prompts robustos y precisos que necesitaba el prototipo.

Fue una fase de aprendizaje acelerado y co-creación. No era yo programando con una herramienta, éramos dos dando forma a una idea.

Escalando la confianza

Cuando decidí dar el salto a Java, que conté en el segundo artículo, no tuve que aprender a colaborar de nuevo. Sólo tenía que aplicar la misma fórmula a una escala mayor. Es de esta fase más compleja, la de la reescritura a Java y la posterior implementación del servidor MCP, de donde provienen la mayoría de los diálogos que se muestran, ya que lamentablemente no conservé registros de las conversaciones iniciales del prototipo.

El flujo ya estaba claro y se había convertido en un bucle natural:

1. Yo definía la arquitectura: Pensaba en las clases necesarias (SQLServiceAction, IteratorFormatter…), sus interfaces y cómo debían interactuar.
2. Iniciaba un diálogo de validación: Le exponía el diseño. “Mira, quiero hacer esto así, ¿ves algún problema? ¿Se te ocurre una forma más eficiente?”.
3. La IA implementaba: Una vez el diseño estaba claro, le pedía que generara el código para clases concretas y bien definidas.
   

   Yo: “Necesito una clase que formatee un Iterator de claves primarias en una String para cláusulas SQL IN. Debe manejarse el truncamiento si la lista es muy larga. ¿Puedes generarla?”
   IA: “Claro. Te propongo una clase con un método estático format() que reciba el Iterator y un límite máximo. Devolverá una cadena con el formato ‘101’, ‘102’, ‘105’.”
   Yo: “Vale, pero si la lista está vacía, que devuelva ‘(NULL)’ para evitar errores en el SQL. ¿Puedes ajustarlo?”

   Tras un par de iteraciones como esta, y de comprobar que compilaba, la clase estaba lista.

4. Yo revisaba y depuraba: Probaba, compilaba y, sobre todo, le pedía explicaciones.“¿Por qué has hecho este cambio? Explícame esta parte”.Muchas veces se equivocaba, y era mi labor detectarlo y guiarla para corregirlo.

Este ciclo Diseño -> Validación -> Implementación -> Revisión se repetía constantemente. No era una línea recta, era una espiral donde cada vuelta nos acercaba más a un código sólido y funcional. La velocidad era asombrosa porque los posibles errores se atrapaban en las fases de diseño y validación, no al final del proceso.

El servidor MCP, la prueba de fuego

Llegados al punto que relaté en el cuarto artículo, con el muro de los costes derribado por gemini-cli y el protocolo MCP, la forma de trabajar ya la había adoptado como natural. No empecé pidiendo código, sino estableciendo el contexto y la dirección:

Yo: ‘Vamos a implementar el servidor MCP. Para ello, primero necesito que entiendas a fondo dos cosas: la especificación del protocolo, que te he proporcionado antes, y mi propia librería para crear servidores HTTP. ¿Puedes analizar las clases en esta carpeta y explicarme cómo encajarían ambas piezas?’

IA: ‘Entendido. He analizado tu librería. La arquitectura basada en Command y CommandFactory es una base excelente para implementar los endpoints tools/list y tools/call que requiere el protocolo MCP…’

A partir de ese punto de partida, el proceso para implementar cada pieza, que ya era familiar, fue idéntico:

1. Usé la IA como tutor: “Explícame el protocolo MCP a fondo, sin capas de abstracción. ¿Qué mensajes se envían? ¿En qué formato?”.
2. Diseñé y validé con ella: Antes de escribir una línea de código, diseñé la estructura del servidor y se la pasé a mi compañero para una revisión rápida. “¿Ves coherente este enfoque para implementar las herramientas show_table o get_viewport?”.
   

   IA: “Los comandos que faltarían por implementar para dar un soporte más completo son: context/get, context/set…”

   Yo: “No he encontrado ninguna referencia a comandos genéricos tipo ‘context/get’.”

   IA: “Tienes toda la razón. Mis disculpas por la confusión. He re-leído la especificación y mi afirmación anterior fue una interpretación incorrecta.”

   Y este no fue un caso único. A lo largo de esa misma sesión de diseño, la IA cometió errores conceptuales similares en repetidas ocasiones. Por ejemplo, afirmó con seguridad la existencia de una sección llamada “Standard Tools” en la documentación que, tras mi insistencia y una doble verificación, resultó no existir. En otra ocasión, malinterpretó la relevancia de una convención de nomenclatura hasta que se le guio explícitamente.

   Este patrón de errores es la prueba más clara de la tesis de este artículo: la IA es un compañero para la exploración de ideas y un generador de primeros borradores increíblemente rápido, pero no es una fuente de verdad absoluta. La supervisión, el escepticismo y el conocimiento del dominio por parte del desarrollador no son opcionales, son el núcleo del proceso.

3. Implementamos juntos: Con el diseño validado, nos pusimos manos a la obra. Yo orquestaba, y ella codificaba los detalles. Luego yo revisaba, como siempre.

La inversión inicial en Java puro y bien estructurado demostró su valor aquí. Pude reutilizar lógica de negocio ya probada y concentrarme en adaptarla al estándar MCP, con la IA acelerando la parte tediosa. Fue la culminación de todo el trabajo previo.

Verdades incómodas y ventajas claras

Quiero ser muy claro: esto no es magia. Es colaboración, y como tal, requiere esfuerzo y criterio.

• La IA es un compañero brillante, pero no es el piloto. Se equivoca. A menudo. Su fuerza está en la implementación concreta, las explicaciones y la validación inicial. La arquitectura, la visión de conjunto y la revisión final dependen al 100% de ti.
• La clave no es que codifique, sino el diálogo. El poder real está en el bucle de feedback constante. Que yo valide su código es obvio. Que ella valide mis diseños y mis prompts es un multiplicador de productividad muy grande que evita callejones sin salida.
• El resultado es una velocidad muy difícil de alcanzar solo. Conseguimos una velocidad de desarrollo que me hubiera parecido ciencia ficción hace un año, pero con la solidez que da tener un segundo par de ojos (electrónicos, pero ojos al fin) revisando cada paso.

Esto es solo el principio

Esta no es “la metodología correcta”. Es la forma que yo encontré para colaborar de forma efectiva con una nueva herramienta. Os la cuento no para que la copiéis, sino para que experimentéis y encontréis la vuestra.

El futuro del desarrollo no consiste en que la IA nos reemplace. Consiste en que nosotros, los desarrolladores, aprendamos a dirigirla, a colaborar con ella y a amplificar nuestra capacidad para crear cosas mejores, más rápido.

Un saludo

Y como apunte final, el propio proceso de dar forma a estas reflexiones ha sido, a su vez, un ejercicio de colaboración. Cada idea ha sido expuesta, validada y refinada a través del diálogo, en un bucle de feedback que ha pulido no solo el código del proyecto, sino también la historia que lo cuenta.

El número de incendios no ha parado de crecer en muchas regiones del mundo. Entre las causas más comunes están las altas temperaturas, las sequías prolongadas o el abandono de las áreas rurales, pero una causa no menos importante son las quemas incontroladas. Para ello, es importante disponer de un Plan de Quemas, ya sea a nivel local, regional o nacional, en el que se regulen y planifiquen las quemas en el territorio como prevención a posibles incendios.

Estos planes de quemas incluirían toda la normativa respecto a zonas, horarios, permisos o características de la quema a realizar.

Para facilitar la información a los ciudadanos, aparte del documento de texto con toda la normativa es importante poder consultar a través de geoportales la cartografía catastral y las zonas en las que se puede quemar según los periodos, basándose normalmente en áreas de influencia de zonas forestales y urbanas. De esta forma, el ciudadano accede directamente al visor, localizando su parcela, y comprueba si puede quemar en dicho periodo y a qué hora puede hacerlo. En muchos casos incluso, puede tener acceso a la descarga de la normativa completa desde el mismo geoportal, y de la declaración responsable en caso de que haya que rellenarla, incluyendo un enlace a la sede electrónica donde habría que presentarla.

En la siguiente imagen se muestra un ejemplo real de un municipio con su Plan Local de Quemas creado con gvSIG Online, todo con software libre, en el que se incluye la información antes mencionada:

Si deseas más información sobre cómo implementar gvSIG Online en una administración e incluir un geoportal con el Plan de Quemas, escribe a info@gvsig.com

El pasado 5 de junio tuvo lugar en Valencia la Jornada de Infraestructuras de Datos Espaciales en la Administración Local 2025, un encuentro dirigido a ayuntamientos y administraciones locales interesadas en aprovechar el potencial de las Tecnologías Libres de Información Geográfica (TIG libres) para mejorar la gestión pública.

Durante la jornada se presentaron casos de uso reales de la Suite gvSIG implantados en distintos municipios, mostrando aplicaciones concretas en ámbitos como la integración con gestores de expedientes, urbanismo, cementerios y otros servicios municipales.

También se dieron a conocer algunas de las últimas novedades de gvSIG Online, entre ellas la integración con Inteligencia Artificial, que abre nuevas posibilidades para el análisis y la gestión de datos espaciales.

Compartimos la grabación completa del evento, para todas aquellas entidades locales que no pudieron asistir y que han mostrado su interés en los resultados de la jornada:

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

+ información: info@gvsig.com

En el artículo anterior, lo dejé justo en el momento de la revelación: la conexión inesperada entre una herramienta de línea de comandos, gemini-cli, y un protocolo llamado MCP era la respuesta al problema de distribución que casi acaba con el proyecto. Hoy, no vamos a revivir esa búsqueda, sino a remangarnos para construir la solución. Os mostraré en detalle qué son estas piezas y cómo, apoyándome en todo el trabajo previo, encajaron para dar vida a una solución robusta y, por fin, distribuible.

Desmitificando las piezas del puzle

La solución no vino de una única tecnología mágica, sino de la perfecta simbiosis de dos componentes clave que resolvieron, cada uno, una parte fundamental del problema.

gemini-cli: El puente inteligente

Al principio, gemini-cli era para mí una simple herramienta de productividad. Sin embargo, resultó ser la pieza angular de la solución por dos motivos cruciales:

1. El Solucionador de costes: Su generoso plan gratuito, con hasta 1000 peticiones diarias al modelo Flash, eliminaba por completo la barrera económica y el riesgo del “pago por uso” descontrolado. De repente, los usuarios podían experimentar con la herramienta sin miedo a facturas inesperadas y sin el calvario de registrar una tarjeta de crédito.
2. El intermediario técnico: Su soporte nativo para MCP era el eslabón perdido. gemini-cli actuaría como un proxy local inteligente: por un lado, se comunicaría con la potente API de Gemini en la nube, gestionando la autenticación y los costes; por el otro, hablaría un lenguaje estándar y limpio (MCP) con mi aplicación local.

MCP, el lenguaje común

Si gemini-cli era el puente, el Model Context Protocol (MCP) eran los planos de construcción. Para un desarrollador, su belleza radica en su simplicidad. Es un estándar abierto que define cómo un cliente de IA (como gemini-cli) puede descubrir y utilizar un conjunto de herramientas locales (como las que viven dentro de gvSIG desktop).

Técnicamente, MCP es un protocolo basado en JSON-RPC. La implementación de referencia de gemini-cli se comunica a través de la entrada y salida estándar (STDIO), lo que permite lanzar una herramienta como un subproceso. Sin embargo, gemini-cli también soporta la conexión a un servidor MCP a través de un endpoint HTTP.

Para una aplicación de escritorio como gvSIG, que ya está en ejecución y no es lanzada desde la terminal, el enfoque HTTP era mucho más lógico y desacoplado. Me permitía levantar un servidor ligero dentro de la propia aplicación, un patrón que ya había utilizado en el pasado. Así, en lugar de lidiar con subprocesos y STDIO, la comunicación se establecía con una simple petición de red local, algo robusto y fácil de depurar.

El protocolo se basa en tres comandos principales: initialize (para establecer la conexión), tools/list (para que mi servidor anuncie sus herramientas) y tools/call (para que gemini-cli pida ejecutar una de ellas).

La configuración y su verificación

El primer paso es indicarle a gemini-cli que, además de hablar con la API de Google, debe buscar herramientas en un servidor local. Esto se hace añadiendo un bloque de configuración en su fichero settings.json.

La configuración es tan simple como esto:

{
  "mcpServers": {
    "gvSIG_desktop": {
      "httpUrl": "http://127.0.0.1:8091/tools",
      "timeout": 600000,
      "trust": true
    }
  }
}

Una vez guardado el fichero, podemos verificar que gemini-cli ha establecido la conexión correctamente. Al arrancar la herramienta, podemos usar el comando interno /mcp para listar los servidores MCP a los que está conectado y las herramientas a las que tiene acceso. El resultado confirma que todo está en orden.

_Tras configurar el settings.json, el comando /mcp nos confirma que gemini-cli ha detectado y se ha conectado con éxito a nuestro servidor gvSIG_desktop_.

El momento de la convergencia

Gracias a la decisión de reescribir todo en Java puro que os conté en el segundo artículo, tenía una base de código robusta y modular, lista para la acción. Implementar el servidor MCP fue sorprendentemente rápido, porque me di cuenta de que, sin saberlo, ya había construido una versión “artesanal” del mismo concepto.

De un conjunto de herramientas propio a un estándar abierto

Mi framework de “procesadores” del prototipo Java era, en esencia, una implementación privada de la misma idea que MCP estandarizaba. Solo tenía que traducir mis definiciones de herramientas al formato oficial.

Por ejemplo, así definía la herramienta para mostrar tablas en el prototipo original de Jython, dentro del fichero sql_processor.py, como un simple texto de ejemplo en el system prompt:

# ANTES: La herramienta se "programaba" en el prompt
u"""
== Consultas de tipo 'sql' ==
  Utilizaras este tipo de respuesta para cualquier consulta que involucre la creacion de una consulta SQL...
  Debe incluir un campo 'sql' con la sentencia SQL...
  Ejemplo: 
  {
    "type": "sql",
    "sql": "SELECT ...",
    "title": "Empleados por departamento",
    "esValorEscalar": false
  }
"""

Con MCP, la misma herramienta se define ahora en ShowTableCommandFactory.java con un esquema JSON formal y preciso. Pasamos de la ambigüedad de un ejemplo a la rigidez de un contrato de API:

private static final JsonObject TOOL_INPUT_SCHEMA = Json.createObjectBuilder()
    .add("type", "object")
    .add("properties", Json.createObjectBuilder()
        .add("query", Json.createObjectBuilder()
            .add("type", "string")
            .add("description", "The SQL query to execute.")
            .build())
        .add("title", Json.createObjectBuilder()
            .add("type", "string")
            .add("description", "A descriptive name for the result...")
            .build())
    )
    .add("required", Json.createArrayBuilder().add("query").add("title"))
    .build();

Pasamos de la ambigüedad de pedirle a un LLM que siguiera un ejemplo en texto, a la precisión de ofrecerle un esquema formal. El LLM ya no adivina; pregunta y cumple.

El gran payoff: reutilización máxima del código Java

Y aquí es donde la decisión estratégica que conté en el segundo artículo —abandonar el prototipo en Jython para reescribir todo en Java puro— se reveló como la mejor inversión de tiempo del proyecto.

Toda la lógica de negocio para ejecutar las consultas (conectar a la base de datos, procesar los placeholders, ejecutar el SQL y manejar el resultado) ya estaba encapsulada y probada en mi prototipo de asistente de chat impulsado por IA en java.

Al construir el servidor MCP, la implementación de una herramienta como show_table fue trivial. El nuevo comando simplemente actúa como un orquestador que delega toda la lógica de negocio en las clases que ya habíamos desarrollado y depurado semanas antes.

El flujo es un ejemplo claro del patrón “Adaptador”. Así es como se ve el “pegamento” que une el mundo MCP con la lógica original:

1. El Servidor MCP recibe la llamada y la delega en el comando específico:

    // Fichero: .../commands/tools/ToolsCommand.java
   
    private Object tools_call(JsonObject params) throws Exception {
        String toolName = params.getString("name"); // ej: "show_table"
        JsonObject toolArguments = params.getJsonObject("arguments");
   
        // Busca el comando registrado con ese nombre
        MCPCommand targetCommand = (MCPCommand) this.getServer().getCommand(toolName);
   
        // Invoca la lógica del comando específico
        return mcpTargetCommand.call(toolArguments);
    }
   

2. El comando específico (ShowTableCommand) no hace nada más que invocar la lógica del prototipo original:

    // El comando MCP se convierte en un simple orquestador que
    // invoca la lógica de ejecución que ya habíamos desarrollado.
    // (Fragmento simplificado de ShowTableCommand.java)
    @Override
    public Object call(JsonObject params) throws Exception {
        // ... extraer parámetros del JSON ...
        String query = params.getString("query");
        String modelid = params.getString("data_model_id");
        String title = params.getString("title");
   
        try {
            // ...y los usa para instanciar y ejecutar la misma lógica
            // que ya habíamos desarrollado en el chat de Java.        ShowTableAction action = new ShowTableAction(
                applicationServices, modelid, title, query, placeholders
            );
            action.actionPerformed(null); // Se ejecuta la lógica reutilizada
   
            return this.createResponseContents("Se han presentado los datos al usuario");
        } catch (Exception ex) {
            return this.createErrorResponseContents(ex.getMessage());
        }
    }
   

Como se puede ver, no tuve que reescribir la lógica para conectar a la base de datos, procesar placeholders o mostrar la tabla. El nuevo servidor MCP era una capa delgada que se apoyaba sobre los cimientos sólidos que ya había construido. La inversión en una base de código bien estructurada me permitió adoptar el estándar MCP en cuestión de días, no de semanas.

_El trabajo previo dando sus frutos. La imagen captura el flujo completo: una pregunta en lenguaje natural en gemini-cli (arriba), el razonamiento de la IA que culmina en la llamada a la herramienta showtable (abajo), y la aparición del resultado final directamente en una ventana de gvSIG.

He manipulado la imagen de la consola, eliminando texto para que se pueda ver el razonamiento completo en la captura de pantalla.

El esultado final como una solución completa

Con el servidor MCP implementado, el flujo para un usuario final se volvió elegante y simple.

Diagrama de bloques mostrando el flujo entre el usuario, gemini CLI y gvSIG desktop

La experiencia de usuario final ahora consiste en:

1. Instalar gemini-cli (un simple comando).
2. Configurarlo con un pequeño archivo para que apunte a nuestro servidor local.
3. Abrir gvSIG, lanzar el chat y empezar a conversar, aprovechando las 1000 peticiones gratuitas diarias.

La solución final en acción. Una petición compleja en lenguaje natural se traduce en un diagrama ERD generado y visualizado directamente en la aplicación. Potente, contextual y, por fin, accesible.

Reflexión final y lecciones aprendidas

Este viaje, lleno de frustraciones y descubrimientos, me enseñó lecciones muy valiosas que van más allá del código:

1. La distribución puede matar al mejor prototipo: La mayor batalla no fue contra la complejidad técnica, sino contra los modelos de negocio de las APIs. Una herramienta que nadie puede usar es solo un experimento personal.
2. Los estándares son soluciones, no teoría: MCP no era un concepto académico; era la respuesta precisa y práctica al muro contra el que me había chocado durante meses.
3. La intuición a menudo converge con los estándares: Desarrollar mi propio protocolo de herramientas me preparó perfectamente para adoptar MCP cuando lo encontré, porque ya había resuelto los mismos problemas a una escala menor.
4. Una base de código bien estructurada es tu mejor aliado: La decisión de reescribir el prototipo a Java y encapsular la lógica de negocio fue la inversión que nos permitió adoptar la solución final con una agilidad asombrosa cuando apareció la oportunidad.

Espero que esta serie de artículos os haya resultado útil, no solo como un tutorial técnico, sino como el relato real de un viaje de desarrollo.

¿Y vosotros? ¿Habéis enfrentado problemas de distribución o costes con vuestras herramientas? ¿Cómo los resolvisteis?

>

P.D.: El mundo de la IA no se detiene. Justo cuando terminaba de escribir esta serie de articulos, ha surgido una nueva plataforma que podría cambiar las reglas del juego en cuanto a los costes, permitiéndonos retomar la visión original de un asistente totalmente integrado en gvSIG desktop. Pero esa… es una historia, que si se materializa, será para otro día.

En un mundo cada vez más conectado, la información geográfica ya no es un recurso exclusivo de los técnicos en la oficina: es una herramienta estratégica que debe estar disponible allí donde ocurren las cosas, en el territorio.

Con esa visión nace gvSIG Mapps, la aplicación móvil que pone toda la potencia de la geoinformación en la palma de la mano.

¿Qué es gvSIG Mapps?

gvSIG Mapps es una app móvil que se integra con gvSIG Online, permitiendo consultar, capturar y actualizar datos directamente desde el terreno. Está pensada para todo tipo de organizaciones —administraciones públicas, empresas y ONG— que necesitan trabajar con información georreferenciada en campo.

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

Principales funcionalidades

• Consulta en campo: acceso a mapas y capas publicados en gvSIG Online, con posibilidad de trabajar en línea o sin conexión.
• Captura de datos: formularios personalizados que permiten registrar información con precisión.
• Edición en tiempo real: actualización de inventarios, censos, incidencias o inspecciones, con sincronización automática con la base de datos central.
• Navegación y geolocalización: visualización de la posición del usuario, capas, etc.

¿Para qué se utiliza?

Los usos de gvSIG Mapps son tan variados como los sectores que gestionan información territorial:

• Gestión municipal: incidencias en la vía pública, inventario de mobiliario urbano, inspecciones de servicios,…
• Protección civil y emergencias: inventariado de hidrantes, localización de recursos,…
• Medio ambiente: monitoreo de especies, control forestal, gestión de áreas protegidas,…
• Infraestructuras y servicios: mantenimiento de redes de agua, electricidad o telecomunicaciones.

Beneficios clave

• Eficiencia: reduce tiempos y errores al eliminar duplicidades entre el trabajo de campo y la oficina.
• Interoperabilidad: se integra de forma nativa con gvSIG Online.
• Flexibilidad: personalizable según las necesidades de cada proyecto o cliente.
• Software libre: independencia tecnológica y reducción de costes de licencias.

Conclusión

Con gvSIG Mapps, la edición y mantenimiento de la información geográfica deja de estar limitada a un escritorio o plataforma web y se convierte en una herramienta dinámica, accesible y colaborativa.

+información: info@gvsig.com

En este videotutorial te mostramos cómo descargar datos e imágenes del programa Copernicus desde QGIS de forma directa, a través del plugin Copernicus Connect. Copernicus es un programa de la Unión Europea para la observación de nuestro planeta. Se trata del sistema civil de monitoreo ambiental más ambicioso del mundo y proporciona datos abiertos, gratuitos ...

Leer más

Descarga de datos e imágenes en QGIS con el plugin Copernicus Connect

O GeoServer, por meio do módulo Web Processing Service (WPS), não é apenas uma ferramenta de publicação de dados geoespaciais — ele também permite executar análises espaciais diretamente pela Web.

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

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

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

1. Clip: Recortando Dados Espaciais

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

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

Request de execução (WPS Execute):

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

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

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

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

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

2. Union: Combinando Camadas e Geometrias

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

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

Exemplo de Request:

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

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

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

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

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

3. Nearest: Identificando o Elemento Mais Próximo

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

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

Exemplo de Request

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

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

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

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

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

4. Boas Práticas e Observações

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

O Web Processing Service (WPS), definido pelo OGC, é um padrão que permite executar processos de análise espacial via Web. No GeoServer, o módulo WPS expõe funções nativas e customizadas que podem ser chamadas por requisições HTTP, retornando resultados em formatos como GML, GeoJSON ou até imagens raster.

1. Operações Fundamentais do WPS
1.1 GetCapabilities

É o ponto de partida: retorna um documento XML com os metadados do serviço.
Exemplo de chamada:

http://localhost:8080/geoserver/ows?service=WPS&version=1.0.0&request=GetCapabilities

O resultado lista todos os processos disponíveis, seus identificadores e versões.

1.2 DescribeProcess

Usada para detalhar um processo específico, como por exemplo descrever o processo de Buffer.
Exemplo de chamada:

http://localhost:8080/geoserver/ows?service=WPS&version=1.0.0&request=DescribeProcess&identifier=JTS:buffer

A resposta XML mostra parâmetros obrigatórios e opcionais:

Input: geometria (linha, ponto, polígono), distância do buffer, unidades.
Output: geometria resultante (normalmente em GML).

1.3 Execute

Permite rodar de fato um processo, como por exemplo gerar buffer de 100 metros em torno de rios:
Exemplo de chamada:

<wps:Execute service="WPS" version="1.0.0"
    xmlns:wps="http://www.opengis.net/wps/1.0.0"
    xmlns:ows="http://www.opengis.net/ows/1.1"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/wps/1.0.0
    http://schemas.opengis.net/wps/1.0.0/wpsExecute_request.xsd"
    identifier="JTS:buffer">

  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>geom</ows:Identifier>
      <wps:Data>
        <wps:ComplexData mimeType="application/wkt"><![CDATA[
          LINESTRING(30 10, 10 30, 40 40)
        ]]></wps:ComplexData>
      </wps:Data>
    </wps:Input>
    <wps:Input>
      <ows:Identifier>distance</ows:Identifier>
      <wps:Data>
        <wps:LiteralData>100</wps:LiteralData>
      </wps:Data>
    </wps:Input>
  </wps:DataInputs>

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

Esse request cria um buffer de 100 metros ao redor de uma linha fornecida em WKT.

2. Execução Síncrona vs Assíncrona

Síncrona: o cliente aguarda o processo terminar e recebe a resposta direta.
Assíncrona: ideal para análises pesadas; o WPS retorna um link onde o cliente pode acompanhar o status e baixar o resultado quando pronto.

3. Processos Comuns no GeoServer via WPS

• JTS:buffer – criação de zonas de influência.
• gs:Reproject – reprojeção de dados entre sistemas de coordenadas.
• gs:Area – cálculo de área de polígonos.
• gs:Bounds – obtenção do envelope mínimo de uma geometria.

Além disso, é possível desenvolver processos customizados em Java e integrá-los ao GeoServer.

4. Integração com QGIS e Python

QGIS: permite acessar WPS como provedor de processamento, facilitando a execução sem precisar lidar com XML manualmente.

Python (OWSLib):

from owslib.wps import WebProcessingService

wps = WebProcessingService('http://localhost:8080/geoserver/ows', version='1.0.0')
process = wps.describeprocess('JTS:buffer')
execution = wps.execute('JTS:buffer', inputs=[('geom','POINT(10 10)'), ('distance',100)])

5. Boas Práticas

• Controlar tamanho máximo de uploads para evitar uso excessivo de recursos.
• Usar execução assíncrona para análises que demandam grande processamento.
• Monitorar logs do GeoServer para identificar gargalos em processos WPS.

Prezado leitor,

Integrar o GeoServer a um ambiente DevOps permite transformar a publicação e manutenção de dados geoespaciais em um processo automatizado, rastreável e seguro. Com pipelines CI/CD (Continuous Integration / Continuous Deployment), é possível validar, versionar e publicar camadas geoespaciais de forma confiável, garantindo que novas versões de dados e estilos cheguem ao servidor sem intervenção manual.

1. Conceito de CI/CD para GeoServer

O objetivo do CI/CD é automatizar a entrega de software ou dados. No contexto do GeoServer, podemos aplicar CI/CD para:

• Publicação automática de camadas vetoriais e rasters.
• Aplicação de estilos (SLD/SE) versionados em repositórios Git.
• Validação de dados antes do deploy.
• Rollback automático em caso de falhas.

Combinando REST API do GeoServer e pipelines CI/CD, conseguimos ter controle total sobre a atualização de dados geoespaciais.

2. Estrutura do pipeline DevOps

Um pipeline típico para GeoServer + PostGIS em CI/CD inclui:

• Repositório Git: versionamento de SLDs, scripts de publicação e, quando aplicável, dados GeoJSON ou shapefiles pequenos.
• Serviço de CI/CD: GitHub Actions, GitLab CI/CD ou Jenkins para executar scripts de publicação.
• Servidor GeoServer: alvo do deploy automático, com REST API habilitada e credenciais de acesso seguras.
• Banco PostGIS: para integração de dados vetoriais, garantindo consistência com o GeoServer.

Visualmente, o fluxo pode ser resumido assim:

Git Repo (dados e SLDs) 
      │
      ▼
CI/CD Pipeline (GitHub Actions / GitLab CI / Jenkins)
      │
      ▼
Scripts de automação → GeoServer REST API
      │
      ▼
Publicação automática de camadas e estilos

3. Exemplo de GitHub Actions para publicar SLDs

Podemos criar um workflow simples que envia estilos ao GeoServer sempre que houver uma atualização no repositório:

name: Deploy GeoServer Styles

on:
  push:
    paths:
      - 'styles/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Enviar SLDs para GeoServer
        run: |
          for file in styles/*.sld; do
            curl -u ${{ secrets.GEOSERVER_USER }}:${{ secrets.GEOSERVER_PASS }} \
                 -XPUT -H "Content-type: application/vnd.ogc.sld+xml" \
                 --data-binary @$file \
                 http://localhost:8080/geoserver/rest/workspaces/cite/styles/$(basename $file .sld)
          done

Esse workflow garante que qualquer atualização de estilo seja aplicada automaticamente no GeoServer sem intervenção manual.

4. Automação de publicação de camadas

Além de estilos, podemos publicar camadas vetoriais e rasters via scripts Python ou Bash integrados ao CI/CD:

• Verificação de novos arquivos em pastas específicas ou repositórios de dados.
• Validação de CRS, atributos e integridade dos dados.
• Uso da REST API para criar stores, featureTypes e coverages.

Exemplo rápido em Python para publicar um shapefile:

import requests
import json

GEOSERVER_URL = "http://localhost:8080/geoserver/rest"
AUTH = ("admin", "geoserver")

# Criar ou atualizar store
store_json = {"dataStore": {"name": "biomas_postgis", "connectionParameters":{"entry":[{"@key":"url","$":"file:data/biomas.shp"}]}}}
requests.post(f"{GEOSERVER_URL}/workspaces/cite/datastores", auth=AUTH, headers={"Content-type":"application/json"}, data=json.dumps(store_json))

# Publicar camada
layer_json = {"featureType":{"name":"biomas","title":"Biomas do Brasil","srs":"EPSG:4674"}}
requests.post(f"{GEOSERVER_URL}/workspaces/cite/datastores/biomas_postgis/featuretypes", auth=AUTH, headers={"Content-type":"application/json"}, data=json.dumps(layer_json))

5. Boas práticas em pipelines CI/CD para GeoServer

• Versionamento de estilos e scripts em Git, permitindo rollback fácil.
• Testes automáticos antes de publicar novos dados ou estilos.
• Segurança: use variáveis de ambiente ou secrets para credenciais da API.
• Monitoramento de logs do GeoServer para detectar erros em tempo real.
• Divisão de ambientes: dev, staging e produção para evitar impactos em serviços críticos.

Conclusão

Integrar o GeoServer a pipelines DevOps transforma o gerenciamento de dados geoespaciais em um processo confiável, repetível e rastreável. CI/CD permite aplicar estilos, publicar camadas e atualizar dados automaticamente, mantendo serviços WMS e WFS sempre consistentes e disponíveis.

Prezado leitor,

Monitorar o GeoServer é fundamental para garantir a estabilidade dos serviços e antecipar falhas. A REST API do GeoServer oferece endpoints que permitem criar healthchecks, consultar status de camadas, conexões e até acompanhar logs em tempo real — tudo de forma automatizada.

1. Healthcheck simples do GeoServer

O endpoint /about/version retorna informações básicas do servidor. É ideal para um healthcheck inicial:

curl -u admin:geoserver \
http://localhost:8080/geoserver/rest/about/version.json

A resposta inclui versão do GeoServer, build e dados do ambiente. Se este endpoint responder com sucesso (HTTP 200), sabemos que o servidor está no ar.

2. Consultando camadas e stores

Para monitorar se um workspace ou store está ativo, podemos listar camadas ou stores disponíveis. Exemplo para listar todos os stores do workspace cite:

curl -u admin:geoserver \
http://localhost:8080/geoserver/rest/workspaces/cite/datastores.json

A resposta retornará a lista de stores configurados. Um script pode percorrer essa lista para verificar se conexões com PostGIS ou arquivos shapefile estão acessíveis.

3. Consultando Logs do GeoServer

O GeoServer permite acessar os logs via REST API, mas esse recurso não vem habilitado por padrão.

Para ativá-lo, siga os passos:

1. Acesse a interface web do GeoServer (http://localhost:8080/geoserver).
2. Vá em Serviços → Logging.
3. Certifique-se de escolher um perfil de log (por exemplo, DEFAULT_LOGGING ou GEOSERVER_DEVELOPER_LOGGING).
4. Marque a opção Enable REST access to logs (se disponível na versão do seu GeoServer).
5. Salve a configuração.

Após habilitar, você poderá consultar os logs via REST:

curl -u admin:geoserver \
http://localhost:8080/geoserver/rest/logs.json

A resposta retorna mensagens recentes do log do servidor, úteis para detectar falhas em publicações de camadas, erros de conexão ou problemas de configuração.

4. Monitoramento em Python

Podemos criar um script em Python para automatizar healthchecks e alertas:

import requests

GEOSERVER_URL = "http://localhost:8080/geoserver/rest"
AUTH = ("admin", "geoserver")

# Healthcheck
r = requests.get(f"{GEOSERVER_URL}/about/version.json", auth=AUTH)
print("Status GeoServer:", r.status_code)

# Listar stores do workspace cite
r = requests.get(f"{GEOSERVER_URL}/workspaces/cite/datastores.json", auth=AUTH)
if r.status_code == 200:
    stores = r.json()
    print("Stores encontrados:", [s["name"] for s in stores["dataStores"]["dataStore"]])

Esse script pode ser integrado a ferramentas de monitoramento como cron jobs, Prometheus ou até sistemas de alerta via Slack/Telegram.

Conclusão

Monitorar o GeoServer via REST API permite detectar problemas rapidamente e automatizar verificações essenciais, reduzindo falhas em produção.

La inteligencia artificial ha transformado la manera en que creamos mapas, haciéndolo más fácil, rápido e intuitivo. En este artículo descubrirás cómo generar mapas con inteligencia artificial de forma sencilla, con ayuda de distintas aplicaciones basadas en IA. 1. BetterMaps.ai Bettermaps.ai es la primera plataforma del mundo para crear mapas con lenguaje natural. Basta con escribir lo ...

Leer más

7 aplicaciones para crear mapas con inteligencia artificial

Prezado leitor,

No dia a dia, é comum termos diversos workspaces configurados, cada um com seus stores, layers e estilos associados. Em ambientes de produção, manter cópias de segurança é fundamental para prevenir perdas em caso de falhas ou para replicar configurações em outro servidor.

1. Exportar (backup) um workspace

O GeoServer expõe endpoints REST que permitem exportar a configuração completa de um workspace em formato .zip.

# Exporta o workspace "meu_workspace"
# -u admin:geoserver → autenticação no GeoServer (usuário:senha)
# -XGET → método HTTP utilizado
# -H "Accept: application/zip" → define que a resposta será um arquivo ZIP
# URL do endpoint com ?recurse=true → inclui stores, layers e estilos associados
# -o meu_workspace_backup.zip → salva o backup no arquivo ZIP local

curl -u admin:geoserver -XGET \
  -H "Accept: application/zip" \
  http://localhost:8080/geoserver/rest/workspaces/meu_workspace?recurse=true \
  -o meu_workspace_backup.zip

Como resultado você terá um arquivo meu_workspace_backup.zip contendo toda a estrutura do workspace desejado.

2. Importar (restore) um workspace

Para restaurar, basta enviar o .zip de volta ao GeoServer via POST:

# Restaura o workspace a partir do backup ZIP
# -u admin:geoserver → autenticação no GeoServer
# -XPOST → método HTTP utilizado
# -H "Content-type: application/zip" → indica que o arquivo enviado é ZIP
# --data-binary @meu_workspace_backup.zip → envia o arquivo binário
# URL do endpoint /workspaces → local onde o workspace será recriado

curl -u admin:geoserver -XPOST \
  -H "Content-type: application/zip" \
  --data-binary @meu_workspace_backup.zip \
  http://localhost:8080/geoserver/rest/workspaces

Esse processo recriará o workspace no GeoServer de destino, com toda a configuração previamente exportada.

3. Conclusão

Com poucos comandos, conseguimos automatizar o processo de backup e restore de workspaces via REST API. Essa prática é indispensável para migrações, ambientes de testes e recuperação rápida em caso de falhas.

GeoDa (Geographic Data Analysis) es un software gratuito y de código abierto creado por el Dr. Luc Anselin para la introducción a la ciencia de datos espaciales. Su objetivo es facilitar el análisis y modelado de patrones espaciales a través de una interfaz gráfica sencilla y potente. No viene a sustituir ningún software GIS, sino ...

Leer más

GeoDa: Una introducción a la ciencia de datos espaciales

En el mundo de los SIG, elegir el lenguaje adecuado es clave para sacar el máximo partido a nuestros datos espaciales. Entre los lenguajes más utilizados destacan Python, R y JavaScript, cada uno con sus puntos fuertes y débiles. En MappingGIS ofrecemos cursos especializados en cada lenguaje aplicado a los SIG, para que puedas aprender ...

Leer más

¿Qué lenguaje de programación es mejor para GIS: Python, R o JavaScript?

El libro «Análisis espacial con R: Usa R como un Sistema de Información Geográfica» ha sido escrito por JEAN-FRANCOIS MAS, publicado en julio de 2025 y está bajo licencia libre CC. R es una plataforma de análisis estadístico con herramientas gráficas muy avanzadas y es un referente en el análisis estadístico desde hace muchos años. A ...

Leer más

Análisis espacial con R: Usa R como un Sistema de Información Geográfica (2025)

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 →

Tenemos Inteligencia Artificial hasta en la sopa y Anaconda no iba a ser menos. Por ello, si abres-instalas este programa verás que te aparece la opción de darte alta como usuario en su propio asistente de IA de ayuda en la programación.

Puedes incluso instalar un navegador específico para trabajar con la IA denominado “Anaconda AI Navigator”

Si lo lanzas verás que podrás trabajar con una variada selección de modelos:

Por otro lado, si nos logueamos en «Anaconda Cloud«:

Lanzamos un “Jupyter notebook”:

Y veremos que el asistente IA de Anaconda está en una ventana en el lado derecho de la interfaz, podemos empezar con una pregunta ejemplo, como, buscar y cargar los datos de volcanes del “Smithsonian Institute”:

Tras un par de correcciones del código, que el asistente realiza, conseguimos incluso visualizarlos:

Este es un ejemplo más de cómo esta ayuda integrada y muchos más específica para una materia determinada, como es el desarrollo de código Python, puede ayudar mucho tanto en la formación como en los proyectos de diferentes profesionales. Ahora a ver cómo responde con otros retos.

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 El uso de la Inteligencia Artificial en Anaconda a la hora de trabajar con Python se publicó primero en Cursos GIS | TYC GIS Formación.

Un problema que se presenta a la hora de añadir un objeto tipo imagen en un documento mediante Google Apps Script es encontrar un método que permita redimensionarla para hacerla visualmente atractiva dentro del documento. Después de buscar por algún … Continue reading →

En posts anteriores se ha considerado la exportación de la información geográfica almacenada en un Hoja de Cálculo como pares de coordenadas Latitud, Longitud a archivos kml de puntos (single o multipoint) o polígonos empleando variables plantilla mediante Google Apps … Continue reading →

La App GeoPosición, disponible en móviles Android, tiene una interfaz amigable para almacenar información geográfica directamente en Google Drive en formato de texto plano. La imagen siguiente contiene una captura de pantalla de la App configurada para abrirse por defecto … Continue reading →

En un post anterior se consideró la exportación de capas kml singlepoint mediante Google Apps Script tomando los datos geográficos de una Hoja de Cálculo en la nube y seleccionando manualmente los datos a ser incorporados en el kml. Si se nos olvida … Continue reading →

En el post anterior ya se mencionaron los cuadros de diálogo en una Hoja de Cálculo con Google Apps Script para introducir variables; en ese caso el nombre del archivo kml de salida. El método usado fue prompt de la … Continue reading →