Planeta SIG - Portugal

Maps. We are passionate about maps, we like to look at maps, and we love to create maps. There are many options for creating maps: from using traditional desktop GIS software to using a web application for it. Geographic Information Systems (GIS) applications are ideal for analyzing, editing, and visualizing spatial data, as well as ...

Leer más

10 options for creating custom maps online

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

We are living in a time when almost every territorial project is presented alongside concepts such as artificial intelligence, digital twins or advanced analytics. The message is appealing: prediction, automation, intelligent decision-making.

But there is a less visible and far more decisive reality:
these systems only work properly when data is well structured.

AI applied to territorial management does not just require large volumes of information. It requires data that is coherent, comparable and maintainable over time. This is where standards come into play.

INSPIRE is not a “modern” technology, nor does it aim to be one. It is a framework that defines how geospatial data is described, shared and understood across organizations. Precisely for this reason, it becomes essential when the goal is to go beyond isolated, one-off projects.

Without a common framework:

• AI models learn from inconsistent data,
• digital twins become local representations that are difficult to scale,
• each new use case requires integrations and adaptations to be rebuilt from scratch.

With INSPIRE:

• data maintains a shared semantics,
• analyses are reproducible,
• solutions can grow and connect with other systems.

In our case, this foundation has enabled us to integrate artificial intelligence capabilities directly into SDI platforms, to the point of interacting with gvSIG Online using natural language, generating dynamic dashboards, or launching advanced analyses without breaking the coherence of the system.

The more advanced the solutions we want to build on top of the territory, the more we depend on standards that are rarely mentioned.

In upcoming posts, we will go into more detail on how these AI capabilities are being practically integrated into gvSIG Online and how we are applying them across a wide range of projects.

Desde la versión 2.7, gvSIG Desktop se ofrece directamente para descargar como distribución portable, con lo que no se instala nada en el equipo del usuario, simplemente es un fichero ZIP que se descomprime y ya se puede ejecutar. Esta versión se podría tener incluso en una tarjeta SD en el ordenador portátil, o llevarla en un pen-drive y ejecutarla en otros equipos, siempre que tengan el mismo sistema operativo, lo que mantendrá la configuración que teníamos en ella.

Un detalle a tener en cuenta al descomprimir los ficheros .ZIP es que no se debe hacer en rutas con espacios, acentos o eñes ni en rutas largas.

Sobre las rutas largas, un problema que suele haber en la distribución de Windows es que si se descomprime con el descompresor del sistema, se generan dos carpetas con el mismo nombre, por lo que genera una ruta más larga. En este vídeo te mostramos las posibles soluciones:

Por otro lado, en Linux, con el descompresor del sistema no tenemos el problema que había en Windows. En este vídeo te mostramos cómo descomprimir y ejecutar una versión portable de gvSIG Desktop en Linux:

En este caso no se creará por defecto un enlace directo para abrir gvSIG, como sí que hacía la versión instalable. Para la versión portable puedes ver cómo crear un acceso directo tanto en Windows como en Linux desde el siguiente post.

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

Vivimos un momento en el que casi cualquier proyecto territorial se presenta asociado a conceptos como inteligencia artificial, gemelos digitales o analítica avanzada. El mensaje es atractivo: predicción, automatización, toma de decisiones inteligente.

Pero hay una realidad menos visible y mucho más determinante:
estos sistemas solo funcionan bien si los datos están bien estructurados.

La IA aplicada al territorio no necesita únicamente grandes volúmenes de información. Necesita datos coherentes, comparables y mantenibles en el tiempo. Y ahí es donde entran en juego los estándares.

INSPIRE no es una tecnología “moderna”, ni pretende serlo. Es un marco que define cómo se describen, comparten y entienden los datos geoespaciales entre organizaciones. Precisamente por eso resulta clave cuando se quiere ir más allá del proyecto puntual.

Sin un marco común:

• los modelos de IA aprenden de datos inconsistentes,
• los gemelos digitales se convierten en representaciones locales difíciles de escalar,
• cada nuevo caso de uso exige rehacer integraciones y adaptaciones.

Con INSPIRE:

• los datos mantienen una semántica compartida,
• los análisis son reproducibles,
• las soluciones pueden crecer y conectarse con otros sistemas.

En nuestro caso, esta base es la que nos ha permitido integrar capacidades de inteligencia artificial directamente sobre plataformas IDE, hasta el punto de poder interactuar con gvSIG Online en lenguaje natural, generar cuadros de mando dinámicos o lanzar análisis avanzados sin romper la coherencia del sistema.

Cuanto más avanzadas son las soluciones que queremos construir sobre el territorio, más dependemos de estándares que rara vez se mencionan.

En próximos posts entraremos en detalle en cómo estas capacidades de IA se están integrando de forma práctica en gvSIG Online y cómo las estamos aplicando en todo tipo de proyectos.

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

In many countries and regions, public administrations are revising their urban planning and land-use legislation with a shared goal: to simplify procedures, reduce administrative burdens, and adapt territorial management to an increasingly complex and dynamic reality.

The Valencian Community (Spain) is a recent example of this process, with the promotion of a new Land Law based on a widely shared diagnosis: excessively long procedures, documentary overload, duplication of information, and difficulties in coordinating data across departments and administrations. A situation that, to a greater or lesser extent, is repeated in many other territories.

Beyond this specific case, the reform highlights a key idea: regulatory modernisation requires solid digital infrastructures.

From paper-based planning to data-driven urban management

New regulatory approaches increasingly point towards:

• More agile procedures
• More flexible planning frameworks
• Greater emphasis on management and monitoring rather than static documents
• Improved coordination of sectoral reports

This represents a paradigm shift: planning is no longer just a collection of approved documents, but a living system, based on up-to-date, interoperable and reusable geographic information.

SDI as an essential public infrastructure

In this context, Spatial Data Infrastructures (SDI) evolve from being a purely technical solution to becoming an essential public infrastructure, comparable to other core corporate systems used by public administrations.

A municipal SDI enables:

• Centralisation of urban and territorial information
• Reduction of duplication and inconsistencies
• Interoperability between administrations
• Better decision-making through an integrated view of the territory

The gvSIG Suite as a practical response

The gvSIG Suite fits naturally into this scenario, offering a comprehensive solution based on open standards:

• gvSIG Online, as the core of the SDI, for managing, publishing and sharing urban and territorial information.
• gvSIG Mapps, to support field data capture, inventories, inspections and the monitoring of actions and interventions.
• gvSIG Desktop, as an advanced tool for data editing, analysis and quality control, when more demanding analytical or cartographic workflows are required.

Together, these tools cover the entire life cycle of geographic information, from data generation to its use in decision-making and communication with citizens.

A shared opportunity for local governments

Although each territory operates under its own legal framework, the message is widely applicable: simplifying urban management requires well-structured and well-organised information — and much of that information is inherently geographic.

Processes such as the one currently taking place in the Valencian Community can therefore be seen as examples that are transferable to other contexts, where SDIs and integrated geospatial platforms become a cornerstone for more efficient, transparent and service-oriented territorial management.

The gvSIG Suite — and in particular gvSIG Online as an integrated solution for territorial information management — is increasingly adopted by local administrations of all sizes, from small municipalities to large cities, provinces and inter-municipal organisations.
Now is the time to join.

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

En muchos países y regiones, las administraciones públicas están revisando su legislación urbanística y territorial con un objetivo común: simplificar procedimientos, reducir cargas administrativas y adaptar la gestión del territorio a una realidad cada vez más compleja y dinámica.

La Comunitat Valenciana es un ejemplo reciente de este proceso, con el impulso de una nueva Ley del Suelo que parte de un diagnóstico ampliamente compartido: procedimientos excesivamente largos, sobrecarga documental, duplicidades y dificultades para coordinar información entre departamentos y administraciones. Un escenario que, en mayor o menor medida, se repite en muchos otros territorios.

Más allá del caso concreto, esta reforma pone de relieve una idea clave: la modernización normativa exige apoyarse en infraestructuras digitales sólidas.

Del urbanismo en papel al urbanismo basado en datos

Las nuevas orientaciones normativas apuntan a:

• Procedimientos más ágiles
• Planeamiento más flexible
• Mayor peso de la gestión y el seguimiento frente al documento estático
• Mejor coordinación de informes sectoriales

Este enfoque supone un cambio de paradigma: el planeamiento deja de ser únicamente un conjunto de documentos cerrados para convertirse en un sistema vivo, basado en información geográfica actualizada, interoperable y reutilizable.

La IDE como infraestructura pública esencial

En este contexto, las Infraestructuras de Datos Espaciales (IDE) pasan de ser una solución técnica a convertirse en una infraestructura pública básica, comparable a otros sistemas corporativos clave de las administraciones.

Una IDE municipal permite:

• Centralizar la información urbanística y territorial
• Reducir duplicidades e incoherencias
• Facilitar la interoperabilidad entre administraciones
• Apoyar la toma de decisiones con una visión integrada del territorio

La Suite gvSIG como respuesta práctica

La Suite gvSIG encaja de forma natural en este escenario, ofreciendo una solución completa y basada en estándares abiertos:

• gvSIG Online, como núcleo de la IDE, para la gestión, publicación y difusión de la información territorial y urbanística.
• gvSIG Mapps, para llevar a cabo tareas de captura de información en campo, inventarios, inspecciones y seguimiento de actuaciones
• gvSIG Desktop, como herramienta avanzada para la edición, el análisis y el control de calidad de los datos para aquellos casos en que se requiera..

Conjuntamente, estas herramientas cubren todo el ciclo de vida de la información geográfica, desde su generación hasta su uso en la toma de decisiones y la comunicación con la ciudadanía.

Una oportunidad compartida para la gestión local

Aunque cada territorio tiene su propio marco normativo, el mensaje es común: simplificar la gestión urbanística requiere ordenar y estructurar bien la información. Y esa información, en gran medida, es geográfica.

Por ello, procesos como el que se está viviendo en la Comunitat Valenciana pueden leerse como un ejemplo extrapolable a otros contextos, donde las IDE y las plataformas geográficas integradas se convierten en un pilar fundamental para una gestión territorial más eficiente, transparente y orientada al servicio público.

La Suite gvSIG y, en especial gvSIG Online como solución integral de gestión de información territorial, está implantada cada vez en más y más administraciones locales (ayuntamientos grandes, medianos y pequeños, diputaciones, mancomunidades… ).

Es el momento de unirte.

El nuevo plugin «QGIS Dual Viewer» permite trabajar con dos vistas de mapa sincronizadas, facilitando la comparación visual lado a lado de distintos conjuntos de datos espaciales. Esta funcionalidad resulta especialmente útil en análisis donde el contexto temporal o temático es clave, como la detección de cambios o la validación de resultados. El plugin ofrece dos ...

Leer más

QGIS Dual Viewer: comparación visual avanzada en QGIS

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

For years, at gvSIG we have insisted on a concept that was often dismissed as ideological, romantic, or even naïve: technological sovereignty.

Today, in a context marked by geopolitical tensions, supply chain disruptions, and structural dependence on external technologies, this concept has moved beyond academic debate to become a strategic necessity.

Europe imports around 80% of its digital infrastructure and technologies. This is not only an economic issue: it is a political, operational, and democratic vulnerability. We depend on decisions taken outside our legal frameworks, our interests, and, in many cases, our values.

The question is no longer whether we want technological sovereignty.
The question is what happens if we do not have it.

Sovereignty is not about borders, it is about control

Talking about technological sovereignty does not mean isolation, building digital walls, or abandoning international collaboration. It means something far more concrete and practical: maintaining control.

Control over:

• how the technologies we use actually work,
• who can audit them,
• who decides their evolution,
• and what happens if tomorrow the provider disappears, changes the rules, or responds to external interests.

Hosting data in a European data centre is important, but it is not enough.
Real sovereignty is not achieved by simply moving servers.

The four pillars of real technological sovereignty

European discussions increasingly refer to four key dimensions that align remarkably well with what gvSIG has defended for years:

1. Security sovereignty

Trust is not enough: verification is essential. The ability to audit code, processes, and security mechanisms is critical, especially in public and regulated sectors.

2. Operational sovereignty

Who operates the system, who deploys it, who can modify it, and under what conditions. Without operational control, sovereignty remains purely theoretical.

3. Data sovereignty

Where data is stored, how it is processed, and—crucially—which external legal frameworks may affect it, often without users even realising it.

4. Technical sovereignty

Perhaps the most overlooked—and the most important. Using open standards and open source software is not a philosophical stance; it is the only way to avoid irreversible vendor lock-in.

Open source: a necessary (though not sufficient) condition

Open source software does not automatically guarantee sovereignty, but without open source, sovereignty is simply impossible.

Access to source code:

• enables auditing,
• allows adaptation,
• makes long-term evolution possible,
• and allows changing providers without rebuilding everything from scratch.

At gvSIG, we have always defended that technology should serve people and institutions—not the other way around. That is why we are committed to open standards, real interoperability, and technical communities that do not depend on a single company or country.

This is no coincidence.
It is a political decision in the best sense of the word.

An open ecosystem versus structural dependency

Technological sovereignty is not built with isolated products, but with ecosystems: public administrations, local companies, universities, technical communities, and end users collaborating on equal footing.

This approach:

• strengthens local technological capacity,
• reduces systemic risks,
• fosters real competition,
• and enables long-term evolution without being trapped in closed solutions.

Exactly the opposite of becoming a digital colony, as some European representatives have already warned.

gvSIG: technological sovereignty before it became urgent

When gvSIG was created, the dominant discourse was different. The focus was on efficiency, cost reduction, and “not reinventing the wheel”.

Today, without renouncing any of that, we know that the real value lies in autonomy, resilience, and the ability to decide.

Technological sovereignty is not a recent trend for us.
It is the common thread running through the entire project.

And in the coming years, it will likely become one of the most critical debates for Europe’s digital future.

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

Durante años, en gvSIG hemos insistido en un concepto que muchas veces se despachaba como ideológico, romántico o incluso ingenuo: la soberanía tecnológica.
Hoy, en pleno contexto de tensiones geopolíticas, disrupciones en las cadenas de suministro y dependencia estructural de tecnologías externas, ese concepto ha dejado de ser un debate académico para convertirse en una necesidad estratégica.

Europa importa alrededor del 80 % de su infraestructura y tecnología digital. Esto no es solo una cuestión económica: es una vulnerabilidad política, operativa y democrática. Dependemos de decisiones tomadas fuera de nuestro marco legal, de nuestros intereses y, en muchos casos, de nuestros valores.

La pregunta ya no es si queremos soberanía tecnológica.
La pregunta es qué pasa si no la tenemos.

La soberanía no va de fronteras, va de control

Hablar de soberanía tecnológica no significa aislarse, ni levantar muros digitales, ni renunciar a la colaboración internacional. Significa algo mucho más concreto y práctico: mantener el control.

Control sobre:

• cómo funcionan las tecnologías que usamos,
• quién puede auditarlas,
• quién decide su evolución,
• y qué ocurre si mañana el proveedor desaparece, cambia las reglas o responde a intereses ajenos.

Tener los datos en un centro de datos europeo es importante, pero no es suficiente. La soberanía real no se resuelve moviendo servidores.

Los cuatro pilares de una soberanía tecnológica real

En el debate europeo se habla cada vez más de cuatro dimensiones clave, que encajan sorprendentemente bien con lo que desde gvSIG llevamos defendiendo desde hace años:

1. Soberanía en la seguridad
   No basta con confiar: hay que poder verificar. Poder auditar el código, los procesos y los mecanismos de seguridad es clave en sectores públicos y regulados.
2. Soberanía en las operaciones
   Quién mantiene el sistema, quién lo despliega, quién puede modificarlo y bajo qué condiciones. Sin control operativo, la soberanía es solo teórica.
3. Soberanía en los datos
   Dónde se almacenan, cómo se procesan y, sobre todo, qué legislaciones externas pueden afectarlos, incluso sin que seamos conscientes.
4. Soberanía técnica
   Quizá la más olvidada… y la más importante. Usar estándares abiertos y software libre no es una cuestión filosófica: es la única forma de evitar dependencias irreversibles de proveedor.

Software libre: una condición necesaria (aunque no suficiente)

El software libre no garantiza automáticamente la soberanía, pero sin software libre no hay soberanía posible.

El acceso al código fuente:

• permite auditar,
• permite adaptar,
• permite evolucionar,
• y permite cambiar de proveedor sin rehacerlo todo desde cero.

En gvSIG siempre hemos defendido que la tecnología debe estar al servicio de las personas y de las instituciones, no al revés. Por eso apostamos por estándares abiertos, interoperabilidad real y comunidades técnicas que no dependen de una única empresa o país.

No es casualidad.
Es una decisión política en el mejor sentido del término.

Un ecosistema abierto frente a la dependencia estructural

La soberanía tecnológica no se construye con productos aislados, sino con ecosistemas: administraciones, empresas locales, universidades, comunidades técnicas y usuarios finales colaborando en igualdad de condiciones.

Este enfoque:

• fortalece el tejido tecnológico local,
• reduce riesgos sistémicos,
• fomenta la competencia real,
• y permite evolucionar sin quedar atrapados en soluciones cerradas.

Justo lo contrario de convertirse en una colonia digital, como ya advierten algunos representantes europeos.

gvSIG: soberanía tecnológica antes de que fuera urgente

Cuando gvSIG nació, el discurso dominante era otro. Se hablaba de eficiencia, de costes, de “no reinventar la rueda”.
Hoy, sin renunciar a nada de eso, sabemos que el verdadero valor está en la autonomía, la resiliencia y la capacidad de decidir.

La soberanía tecnológica no es una moda reciente para nosotros.
Es el hilo conductor de todo el proyecto.

Y probablemente, en los próximos años, será uno de los debates más importantes para el futuro digital de Europa.

Las teselas vectoriales o vector tiles son una forma moderna de servir cartografía, que consiste en dividir el mapa en pequeñas porciones o teselas que contienen datos vectoriales en lugar de imágenes. Ya nos hemos ocupado anteriormente de la publicación de las teselas vectoriales con PostGIS y GeoServer, pero debido a sus ventajas y múltiples ...

Leer más

Cómo crear teselas vectoriales con QGIS

El nuevo frontend de gvSIG Online da un paso adelante en usabilidad, claridad y experiencia de usuario.

En este breve vídeo te mostramos, de forma rápida y directa, las principales herramientas y elementos de la interfaz: navegación por el geoportal, gestión de capas, herramientas habituales de consulta, edición, marcadores, etc… y una organización del interfaz pensada para trabajar de forma más ágil y eficiente con información geoespacial.

Ver el vídeo:

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

Una buena oportunidad para conocer, en solo unos minutos, cómo evoluciona gvSIG Online y qué aporta su nuevo frontend al trabajo diario con mapas y datos territoriales. Y esto solo son las herramientas principales…

El nuevo complemento Magnifier para QGIS crea una lupa flotante en la posición del cursor del ratón. El complemento, aun experimental, permite definir: El nivel de zoom del elemento activo en la lupa. El tamaño del área de visualización de la lupa en el mapa. La lupa muestra una capa o un grupo de capas. ...

Leer más

Plugin Magnifier para QGIS

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

A Spatial Data Infrastructure (SDI) works like the nervous system of the digital territory. It is not always visible, but it connects data, people, and decisions. When everything works properly, it goes unnoticed. When it does not exist, problems become chronic.

Outdated layers, unresponsive services, duplicated or inconsistent data… the outcome is well known: wasted time, poor coordination between departments, and decisions made with incomplete information— not to mention the public service role that SDIs play in terms of communication and transparency with citizens.

In this context, the gvSIG Association is committed to SDIs based on open standards, where information is managed in a centralized, interoperable, and accessible way. Solutions such as gvSIG Online, integrated with field data capture tools, case management systems, population register applications, industrial area management tools, cemetery management systems, and more, allow the SDI to truly function as a stable, maintainable infrastructure aligned with the real workflows of public administrations that rely on a territorial component.

SDIs rarely make headlines. Their value lies in what their proper functioning contributes to internal management and to public service delivery.

At gvSIG, we understand the SDI as an essential public infrastructure: open, interoperable, and built to last. Not as a one-off project, but as a common foundation on which to build better services, better decisions, and a more transparent relationship between public administrations and citizens. Because when the SDI works, everything else starts to work better.

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

Una Infraestructura de Datos Espaciales (IDE) funciona como el sistema nervioso del territorio digital. No siempre se ve, pero conecta datos, personas y decisiones. Mientras todo funciona, pasa desapercibida. Cuando no existe, los problemas son crónicos.

Capas desactualizadas, servicios que no responden, datos duplicados o incongruentes… El resultado es conocido: más tiempo perdido, menor coordinación entre áreas y decisiones tomadas con información incompleta… por no hablar del servicio público que aportan las IDE en cuanto a comunicación y transparencia con los ciudadanos.

En este contexto, desde la Asosiación gvSIG apostamos por IDE basadas en estándares abiertos, donde la información se gestiona de forma centralizada, interoperable y accesible. Soluciones como gvSIG Online, integradas con herramientas de captura en campo, con gestores de expedientes, aplicaciones de padrón, de gestión de áreas industriales, de cementerio,… permiten que la IDE sea realmente una infraestructura estable, mantenible y alineada con los flujos de trabajo de las administraciones públicas que implican el uso de la componente territorial.

Las IDE raramente son protagonistas de notas de prensa. Su valor está en lo que su funcionamiento aporta a la gestión interna y como servicio público.

En gvSIG entendemos la IDE como una infraestructura pública esencial: abierta, interoperable y pensada para durar. No como un proyecto puntual, sino como una base común sobre la que construir mejores servicios, mejores decisiones y una relación más transparente entre la administración y la ciudadanía. Porque cuando la IDE funciona, todo lo demás empieza a funcionar mejor.

Un error que se comete con cierta frecuencia en webmapping es utilizar los archivos raster (tif) de trabajo para crear el mapa web. El GeoTIFF es un formato de éxito que ha sido (y es) ampliamente utilizado por sus muchas virtudes. Para muchos propósitos sigue siendo un formato eficaz pero hay contextos donde es mejor ...

Leer más

Por qué deberías dejar de servir GeoTIFF clásicos y empezar a usar COG

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

¡🚀 QField 4.0 “Aare” ya está aquí! Una nueva versión que marca un antes y un después en la experiencia de trabajo SIG en campo. Justo antes de cerrar el año 2025, llega QField 4.0, una actualización mayor centrada en la usabilidad, la simplicidad y la colaboración en la nube. Nunca había sido tan fácil ...

Leer más

¡🚀 QField 4.0 “Aare” ya está aquí!

Prezado leitor,

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

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

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

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

2. Escopo funcional e vocação das ferramentas

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

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

3. Governança e ciclo de vida dos dados

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

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

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

4. Padrões OGC e interoperabilidade

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

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

5. Fluxos operacionais e perfil dos usuários

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

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

6. Escalabilidade: técnica versus institucional

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

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

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

7. Arquiteturas complementares como caminho evolutivo

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

8. Conclusão

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

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

Prezado leitor,

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

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

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

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

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

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

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

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

Milestone 1: Preparação

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

Entre as principais atividades realizadas estão:

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

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

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

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

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

Milestone 2: Migração

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

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

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

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

Essa etapa foi concluída ainda em 2025.

Milestone 3: Entrega

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

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

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

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

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

Fonte: GS3 Project Plan

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

La inteligencia artificial continúa avanzando a gran velocidad y sorprendiéndonos con nuevas capacidades. En esta ocasión es el turno de Gemini 3, la IA desarrollada por Google. En su página oficial la describen como: “Es el mejor modelo del mundo en comprensión multimodal y nuestro modelo de programación más potente hasta la fecha, que ofrece ...

Leer más

Gemini 3 aplicado a los SIG con QGIS y Earth Engine

En este artículo, vamos a mostrarte cómo analizar y representar cartográficamente islas de calor urbanas con QGIS, con el fin de plantear medidas de cara a paliar el efecto del Cambio Climático.  Las islas de calor urbanas son un fenómeno en el que las zonas urbanizadas presentan temperaturas mucho más altas que las áreas rurales ...

Leer más

Análisis del efecto de islas de calor urbanas con QGIS

Como ya viene siendo costumbre, a finales de año os traemos una guía de regalos GIS para estas navidades: ideas y sugerencias relacionadas con el mundo geoespacial para regalar, o para regalarte. 1. Calendario 2026 de GeoHipster El calendario GeoHipster 2026 es el único calendario elaborado por y para profesionales de GIS. El calendario GeoHipster ...

Leer más

Guía de regalos GIS para estas navidades. Edición 2025

Google ha presentado AlphaEarth Foundations, un modelo de inteligencia artificial que promete transformar por completo la forma en que observamos, analizamos y cartografiamos el planeta. Este desarrollo, creado por Google DeepMind junto a Google Earth, no es una herramienta más de visualización: es un verdadero satélite virtual capaz de integrar petabytes de datos de observación ...

Leer más

🌍 AlphaEarth revoluciona la cartografía del planeta

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

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

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

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

1) Verificando o server.xml

Local do arquivo:

$CATALINA_HOME/conf/server.xml

No arquivo, observe:

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

Exemplo:

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

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

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

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

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

2) Deploy automático vs. manual

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

$CATALINA_HOME/webapps

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

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

3) Deploy manual com arquivo de contexto

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

Onde criar:

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

Exemplo de caminho real:

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

Conteúdo do arquivo de contexto:

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

Neste exemplo, o contexto será:

http://localhost:8080/geoserver-admin

E o diretório do GeoServer está em:

$CATALINA_HOME/webapps.dist/geoserver

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

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

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

Referências

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

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

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

1. O que é o JDBCConfig

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

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

1.1 O que ele armazena

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

1.2 Vantagens

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

1.3 Quando usar

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

2. O que é o JDBCStore

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

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

2.1 O que ele armazena

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

2.2 Vantagens

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

2.3 Quando usar

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

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

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

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

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

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

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

Resumindo:

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

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

4.1 Baixar os módulos

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

Baixe os arquivos:

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

Extraia os .jar e copie para:

GEOSERVER_HOME/WEB-INF/lib/

4.2 Criar o banco no PostgreSQL

Crie um novo banco vazio, por exemplo:

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

4.3 Configurar o JDBCConfig

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

data_dir/jdbcconfig/

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

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

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

4.4 Configurar o JDBCStore

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

data_dir/jdbcstore/

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

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

Reinicie o GeoServer novamente.

5. Conclusão

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

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

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

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

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

Imagine poder conversar com o seu GeoNode como se fosse um assistente técnico:

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

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

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

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

1. O papel do GeoNode como fonte de conhecimento geoespacial

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

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

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

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

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

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

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

2. Chatbot + GeoNode + IA

Vamos montar um exemplo funcional em Python.

import requests
from openai import OpenAI

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

# Inicializa cliente OpenAI
client = OpenAI()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Aplicações práticas

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

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

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

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

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

4. Conclusão

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

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

Prezados leitores,

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

1. Instalar SDK do MrSID

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

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

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

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

2. Instalação do GDAL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verifique se a biblioteca libgdalalljni.so foi criada:

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

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

> ninja gdalalljni
> sudo ldconfig

Vamos atualiza o cache das bibliotecas:

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

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

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

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

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

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

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

Os mapas de calor (heatmaps) são uma das formas mais intuitivas de visualizar densidade de ocorrências geográficas, seja para representar crimes, atendimentos de saúde, pontos de coleta de resíduos ou eventos climáticos.

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

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

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

1. O conceito de heatmap no GeoServer

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

Exemplo básico de configuração manual:

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

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

2. Onde entra a IA

A IA pode atuar para:

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

3. PostGIS + Python + IA + GeoServer

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

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

import psycopg2
import openai
import requests

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

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

LAYER_NAME = "eventos_ocorrencias"
STYLE_NAME = "heatmap_eventos"

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

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

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

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

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

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

A saída gerada pelo script será:

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

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

Você pode evoluir esse fluxo para:

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

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

4. Conclusão

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

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

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

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

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.

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 4.x usa /api/v2/datasets/)
GEONODE_URL = "http://localhost:8000/api/v2/datasets/"
GEONODE_USER = "admin"
GEONODE_PASS = "geonode"

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

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

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

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

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

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

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

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

Em resumo:

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

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

4. Exemplo prático

Camada original:

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

Após enriquecimento com IA:

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

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

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

Em segundos, o dado fica muito mais informativo.

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

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

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

5. Conclusão

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

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

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

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

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.

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

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

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

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Formación de calidad impartida por profesionales

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

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

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

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

Fuente: Imagen creada a través de la IA

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

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

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

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

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

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

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

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

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

Formación de calidad impartida por profesionales

 

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

Olá pessoal,

Na aula de hoje abordaremos os temas a seguir:

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

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

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

e>

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

Hebert Guilherme de Azevedo - Consultor em Geotecnologias

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Formación de calidad impartida por profesionales

 

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

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

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

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

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

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

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

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

Formación de calidad impartida por profesionales

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

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

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

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

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

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

[1]

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

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

[2]

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

[3]

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

[4]

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

[5]

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

[6]

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

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

[7]

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

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

[8]

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

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

[9]

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

SELECT 
    gid,                             
    geom                              
FROM 
    ranked_polygons
WHERE 
    rank = 1;                         


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

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

[10]

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


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

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

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

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

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

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

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

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

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

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

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

Formación de calidad impartida por profesionales

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

 

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

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

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

Los temas aceptados incluyen:

• Visualización de datos

• Análisis espacial

• Desarrollo de software y aplicaciones

• Webmapping

• Observación de la Tierra

• Ciencia de datos

• Geoestadística

• Machine learning

• Datos abiertos

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

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

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

Publicado por Laura Olivas Corominas.

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

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

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 →