What Do Geoinformation Technology Users Really Need?

Guest post by Sadra Matmir¹ | TU Dortmund University / Bochum University of Applied Sciences (Hochschule Bochum)

The Challenge: Making FAIR Research Infrastructure Useful in Practice

Open Science and FAIR principles have made significant progress in improving access to scientific data and computational research. However, an important challenge remains:

Making research outputs FAIR and providing them through research infrastructures does not necessarily mean that potential users will adopt the technologies that make them available.

Geoinformation Technologies (GITs) can provide powerful analytical capabilities, but their adoption in planning and environmental practice depends on much more than technical performance. Usability, perceived benefits, organizational requirements, and users’ technical skills all play important roles. This raises a central question:

How can we better understand the gap between GIT developers’ perspectives and the needs of planning practitioners?

I explored this challenge in my master’s thesis “Evaluating technology adoption by planners using a data-to-knowledge package for flood risk management” in spatial planning at TU-Dortmund University, building on interdisciplinary collaboration within the EU-funded AquaINFRA project. In cooperation with researchers and developers from Hochschule Bochum, Aalborg University, and 52°North, we developed the Elbe Data-to-Knowledge Package (D2KP), building on existing research on dasymetric population mapping by Ida Maria Bonnevie and colleagues². A quick information for those who haven’t heard about the Data-to-Knowledge Package: The main objective of the D2KP is to enhance the reusability of computational research outputs by enabling users to seamlessly trace the process from raw data to analysis and knowledge generation. It contains everything that is needed to reproduce the analysis plus additional products that make reuse and interaction with the analysis easier. Further details can be found in a previous blog post.

Following the D2KP development guideline³ prepared by Markus Konkol at 52°North, we transformed Ida Maria Bonnevie’s original R-based research scripts into a modular and reproducible workflow for the German part of the Elbe River basin. The process involved restructuring the analytical code into reusable functions, preparing a Docker-based computational environment, and collaborating with the AquaINFRA development team to integrate the components into the AquaINFRA Interaction Platform (AIP) and Virtual Research Environment (VRE).

The resulting Elbe D2KP connects FAIR datasets, analytical code, and reproducible workflows. As part of my research, we demonstrated its practical application by combining the population distribution outputs generated by the Elbe workflow with HQ100 flood hazard zones. This analysis was conducted using the QGIS tool integrated into the Galaxy-based VRE, allowing users to explore the potential application of these outputs in flood risk management. During the demonstration, participants tested the Elbe D2KP and explored its results through the AIP and VRE. The entire process was carried out through a standard web browser, without requiring users to install any additional software (Figure 1).

Figure1: Overlay of Elbe D2KP workflow outputs with HQ100 flood hazard zones using the QGIS tool integrated into the AquaINFRA Virtual Research Environment (VRE). The map displays two vector layers: the subbasin population density layer generated by the Elbe D2KP workflow and the HQ100 flood hazard layer for Brandenburg.

However, the main objective of my research went beyond technical implementation. It focused on a broader question: How do different stakeholder groups perceive the adoption of geoinformation technologies ?

To investigate this, I applied Fuzzy Cognitive Mapping (FCM), a participatory, semi-quantitative method used to represent how people understand complex systems. Participants identify factors influencing the adoption of GIT, connect them through cause-and-effect relationships, and assign positive or negative weights indicating the perceived direction and strength of these relationships. The resulting cognitive maps allow different stakeholder perspectives to be visualized and compared. We used the online MentalModeler platform to collaboratively develop and visualise Fuzzy Cognitive Maps (FCMs) and conduct scenario simulations exploring how the introduction of the Elbe D2KP might influence technology adoption from practitioners’ perspectives.

The assessment was conducted through two stages of workshops. First, during the AquaINFRA partner meeting in Oslo in December 2025, developers, researchers, and project managers worked in eight groups to identify factors influencing the adoption of GIT and construct their FCMs. One of the well-connected FCM maps developed by AquaINFRA partners is presented in Figure 2.

Figure 2 . A well-connected Fuzzy Cognitive Map (FCM) developed by AquaINFRA partners during the workshop in Oslo, Norway.

In the second stage, workshops and guided sessions were conducted with planning practitioners from Stadt Bochum and Emschergenossenschaft⁴ in Germany in January 2026. Participants developed cognitive maps representing their perspectives on GIT adoption and were introduced to the Elbe D2KP through its analytical workflow and practical flood risk management application. Figure 3 presents the FCM developed during the Emschergenossenschaft session.

Figure 3: Fuzzy Cognitive Map (FCM) developed with water management practitioners from Emschergenossenschaft during the workshop in Germany.

Following this introduction and testing the Elbe D2KP, FCM scenario simulations were conducted to explore how the perceived introduction of the D2KP might influence different adoption-related factors within the practitioners’ cognitive maps. This approach allowed us to compare the perspectives of the AquaINFRA team and potential users while investigating the perceived benefits and challenges associated with adopting the D2KP concept by planning practitioners.

What Did We Learn?

The findings revealed an interesting difference between the perspectives of GIT developers and practitioners. While both groups recognized factors such as cost, usability, and perceived benefits, they understood their relationships differently. AquaINFRA partners generally described adoption through interconnected technical and organizational factors, whereas practitioners focused more directly on usability, integration, and benefits for their daily work.

Interestingly, substantial differences were also observed among the AquaINFRA partners themselves. Although they were directly involved in developing and implementing the AquaINFRA infrastructure, their FCMs revealed different understandings of GIT adoption. Even when participants identified similar influencing factors, they often perceived the relationships between these factors differently. This highlights that involvement in developing a GIT does not necessarily lead to a shared understanding of its adoption.

Scenario simulations introducing the Elbe D2KP into the practitioners’ cognitive maps suggested positive changes in perceived benefits and ease of integration. However, both models also indicated challenges related to user-friendliness. These results represent stakeholder perceptions and modelled scenarios rather than measured technology performance, but they highlight an important potential trade-off between analytical capabilities and accessibility.

The Takeaway: FAIR-based GIT Needs User Perspectives

This research highlights two important lessons for developing and adopting new GITs.

First, technology adoption is shaped not only by individual factors, such as usability, cost, and perceived benefits, but also by how these factors interact. Using Fuzzy Cognitive Mapping (FCM), we identified both shared concerns and differences in how stakeholders understand the relationships between them. This revealed patterns of agreement and fragmentation that might otherwise remain hidden, even among people directly involved in developing the same research infrastructure.

Second, successful adoption requires bridging the gap between developers’ perspectives and practitioners’ needs. While developers often focus on technical infrastructure and system functionality, practitioners place greater emphasis on practical benefits, usability, and integration into their existing workflows. Our findings highlight the importance of understanding these different perspectives and aligning them throughout the technology development process.

The experience within AquaINFRA demonstrates that technical quality, reproducibility, and FAIR compliance alone are not sufficient to ensure successful adoption. Equally important are clear communication of how technologies work, accessible training materials, and continuous engagement with potential users.

Ultimately, making research infrastructure FAIR is an essential step toward reusability, but turning reusable research into technology that people can confidently adopt requires a shared understanding between developers and practitioners.

 

 

References

¹ Sadra Matmir is a research associate at Bochum University of Applied Sciences (Hochschule Bochum), working on the EU-funded AquaINFRA project, focusing on reproducible geospatial workflows, Open Educational Resources (OERs), and technology adoption. He holds master’s degrees in Geoinformation Science from the University of Twente in the Netherlands and Spatial Planning from TU Dortmund University in Germany.

² Bonnevie, I. M., Hansen, H. S. and Schrøder, L. (2024): Dasymetric Algorithms Using Land Cover to Estimate Human Population at Smaller Spatial Scales. ISPRS International Journal of Geo-Information, 13(12), p. 427. https://doi.org/10.3390/ijgi13120427

³ Konkol, M. (2024): User Guide: Creating a Data-to-Knowledge Package. Zenodo. https://doi.org/10.5281/zenodo.15772477

⁴ The Emschergenossenschaft is a public water management association responsible for the Emscher River Basin in Germany’s Ruhr region. Founded in 1899, it focuses on wastewater management, flood protection, river restoration, and sustainable water resource management.

Dear all,

The CRO is pleased to announce the list of new OSGeo Charter Members.

• Dirk Stenger from Germany
• Jin Igarashi from Japan
• Matthias Mhor from Germany
• Luiza Marques Fonseca dos Santos from Brasil
• Berit Mohr from Germany
• Dominik Weckmüller from Germany
• Jonathan Beliën from Belgium
• Roel Huybrechts from Belgium
• David García from Uruguay
• Ignacio Talavera from Uruguay
• Yasuto Furukawa from Japan
• Alen Mangafić from Slovenia
• Kilian Paenen from Belgium
• Kaue de Moraes Vestena from Brasil
• Corey T. White from United States of America
• Hinako Iseki from Japan
• Colin Mazengarb from Australia [0]
• Alexander Kmoch from Germany
• Salvatore Fiandaca from Italy
• Patrícia Iribarrem from The Netherlands
• Adam Stewart from Germany
• Isaac Ullah from United States of America
• Charlotte Flasse from Belgium
• Denilson de Jesus from Brasil

You may visit the nominations page [1] to learn more about the candidates.

This year there were 24 valid nominations and all were accepted. 260 charter
members cast their vote, with each nominee attaining more than 130 votes. The
OSGeo Foundation now counts 491 active Charter Members [2].

The board approved the new members days ago [3].

Warm regards,

Luís de Sousa
(Your 2026 OSGeo CRO [4])

[0] Pending
[1] https://wiki.osgeo.org/wiki/New_Member_Nominations_2026
[2] https://www.osgeo.org/about/charter-members/
[3] https://www.loomio.com/d/UNcQTlOw/motion-to-approve-the-new-charter-members
[4] https://wiki.osgeo.org/wiki/Chief_Returning_Officer

1 post - 1 participant

Read full topic

Tested QGIS raster calculator formulas for NDVI, masks, reclass and slope, plus four traps that silently write wrong numbers without raising an error.

How to use the QGIS Field Calculator for area, length, CASE WHEN classes, text cleanup and spatial counts, tested on 8,709 buildings with the silent traps.

Batch processing, the Graphical Modeler, a PyQGIS script, and an AI agent: we ran the same multi-step QGIS workflow on two German cities and timed the re-run.

There is no official Claude plugin for QGIS. Here are the three ways to use Claude with QGIS, tested on the same mapping task, and which one to pick.

Most AI map generators draw pictures, not maps. I tested two image models and a QGIS agent on one prompt in Recife, Brazil, and checked every name against OSM.

On October 19, 2026 the GeoServer project announced three releases: 3.0.2, 2.28.6 and 2.27.7. For most deployments these are maintenance and security updates. For organizations that must run their geospatial infrastructure under formal cryptographic requirements, 3.0.2 carries something more: a new FIPS community module, developed by GeoSolutions, that lets GeoServer run on top of a FIPS 140-3 validated cryptographic module. In this post we look at what the module enables, the engineering behind it, and what teams should plan before adopting it.

What FIPS compatibility enables

FIPS 140-3 is the United States government standard for cryptographic modules, and a hard requirement in many federal, defense and regulated environments. Software running in those environments is expected to perform all cryptographic operations inside a validated module, operating in its approved mode.

The new FIPS community module makes that possible for GeoServer. It replaces the standard Bouncy Castle library with the FIPS-validated Bouncy Castle build (bc-fips 2.1.2 as the cryptographic provider, bcpkix-fips 2.1.10 for certificates and CMS), registers it ahead of the default Java providers, and runs it in approved-only mode, where requests for non-approved algorithms fail instead of silently falling back. Configuration and user passwords are stored with AES-GCM, the keystore moves to the BCFKS format, and a new FIPS tab under Server Status shows the cryptographic setup at a glance: crypto module state, approved-only mode, operating system FIPS mode, provider position and the algorithms GeoServer needs. The same information is exposed in the module status returned by the REST resource /rest/about/status.json, which is convenient when several instances have to be checked.

The FIPS status page in GeoServer 3.0.2. Image from the GeoServer 3.0.2 release announcement, CC BY.

One distinction matters when evaluating this. FIPS validation applies to the cryptographic module and its conditions of use, not to the products that integrate it. As the NIST CMVP FAQ makes clear, embedding a validated module does not make the embedding product validated. The module gives GeoServer a concrete, reviewable path to FIPS compatibility; compliance of the overall deployment remains something each organization establishes through its own configuration and accreditation process.

The engineering behind it

Making a large Java application work under approved-only cryptography is not a matter of swapping a library. GeoSolutions developed the module together with the core changes and the build-level testing needed to support it. The work, led by Andrea Aime and visible in the public pull requests on the GeoServer repository (#9855 for the main branch and #9880 for the 3.0.x backport, both merged on August 27, 2026), covers three areas:

• Changes across the GeoServer core to make encryption pluggable and compatible with different algorithm sets, including the move from DES to AES for URL parameter encryption and a keystore named after its format.
• The module itself, which installs the validated provider through a new core extension point, reports what it found, and adds the status tab, together with the AES-GCM password encoder and master password provider that the core now offers next to the existing ones.
• The machinery to build and test under FIPS constraints: a Maven profile that builds GeoServer against the FIPS provider across the whole tree and fails if any dependency pulls the regular library back in, a second profile that makes a normal development machine behave like a FIPS one, and scripts for a virtual machine where the real thing is checked.

That last point deserves a word. The module is compiled and tested inside a Rocky Linux 9 virtual machine with FIPS mode enabled. A container is not enough: FIPS mode is a property of the kernel, and a container uses the kernel of its host. On the VM the build runs with FIPS mode active and executes the tests of every module, then the CITE suite (the OGC conformance tests) runs with the kernel, the system crypto policy and the Red Hat Java runtime all in FIPS mode. This is where modules using non-approved algorithms show up. Rocky Linux is a rebuild of RHEL and is fine for testing; organizations that need to pass an accreditation should run on a validated distribution.

Andrea Aime, who led the work, puts it this way: "Making GeoServer run under approved-only cryptography was less about the module and more about the core: encryption had to become pluggable, the tests had to stop assuming a particular set of algorithms, and we needed a build that fails the moment a dependency pulls non-FIPS cryptography back in. The FIPS virtual machine is what catches that; a container cannot, because FIPS mode is a property of the kernel."

A GeoServer FIPS deployment: the module, the validated provider, and the operating environment. Deployment configuration and validation remain the responsibility of the organization.

The work was commissioned by a leading public safety and security technology company with formal FIPS requirements, which deployed the module in their development and staging environments and ran their own test suite against it before the public release. The result went upstream as a community module rather than staying a private fork, which is the approach we take whenever a customer requirement is of general interest: the customer gets a maintained feature, and every GeoServer user gets the option.

The release announcement also credits GeoSolutions engineers for release testing and the OGC API Maps work by Andrea Aime, and for the GeoFence integration for GeoServer 3 by Emanuele Tajariol. The releases themselves are a community achievement, with contributions and release duties shared with GeoCat, Camptocamp and the other organizations listed in the announcement.

What teams need to plan

The documented path for running GeoServer under FIPS is on Linux, with the operating system and the Java runtime properly configured and the module operating in approved-only mode. Three points deserve attention.

First, a FIPS instance requires a new data directory. An existing data directory cannot be opened in place, because password encoding and keystore format change, and there is no migration tool yet. Unencrypted configuration such as layers, styles and service settings can be carried over, while the security configuration is rebuilt. Second, the module does not configure the operating system: enabling FIPS mode at the OS level is a separate step, and the FIPS status page tells you whether it is active. Third, this is a community module: it is not part of the 3.0.2 extension downloads and is distributed through the GeoServer community builds, so plan the deployment with that in mind, and review extensions and external integrations, since anything performing cryptography outside the validated provider needs to be checked against your requirements.

Maintaining GeoServer in production

Work like this is one example of what it takes to keep GeoServer dependable in demanding environments: changes in the core, upstream maintenance, testing infrastructure, and the follow-through across releases. It is the same engineering that backs our day-to-day support work, from diagnosing production incidents to planning upgrades across versions. Our thanks go to everyone in the GeoServer community who contributed to these releases.

If you are interested in learning more about how we can help you achieve your needs with GeoServer, MapStore, GeoNode and GeoNetwork through our Enterprise Support Services, Professional Training Services and Subscription Services please contact us!

The GeoSolutions team

Empowering Conservation Through Open Technologies with 52°North and PEOPLE-ECCO

The Challenge

Non-Governmental Organizations (NGOs) are key actors in the conservation and restoration of ecosystems worldwide. However, practice-oriented conservation groups face a major hurdle: evaluating the real-world impact of their management activities over large geographic areas. Traditional monitoring methods rely on labor-intensive on-the-ground surveys, which are difficult to sustain at scale. While satellite Earth Observation (EO) data, such as Copernicus Sentinel-2, offer wide-scale coverage and long-term time series, using them effectively requires complex domain knowledge, spatial data handling, and specialized data processing skills.

This week’s challenge is:

How can we build an accessible, cloud-native web platform that transforms complex satellite Earth Observation data into intuitive environmental indicators and actionable metrics for non-technical conservation experts?

The Stakeholders and Co-Design

To bridge the gap between space infrastructure and ground-level species conservation, the European Space Agency (ESA) funded the PEOPLE-ECCO (Enhancing Ecosystems Conservation through Earth Observation Solutions, Capacity Development and Co-design) project under its EO4Society program. Led by the University of Twente (ITC), the consortium brings together technical and domain partners – 52°North, Hatfield Consultants, and DHI Consulting – alongside six key NGO “Early Adopters” across four continents:

• African Parks: Monitoring protected areas across multiple African nations.
• Bulgarian Society for the Protection of Birds (BSPB): Preserving critical bird habitats and grassland ecosystems in Bulgaria.
• IUCN Vietnam: Protecting forest and wetland ecosystems.
• Lebanon Reforestation Initiative: Restoring forested landscapes and building community resilience in Lebanon.
• Prince Edward Island Watershed Alliance (Canada): Tracking watershed health and cold-temperate aquatic ecosystems.
• Reef Check Malaysia: Conserving high-biodiversity coral reefs, seagrass beds, and coastal marine habitats.

Figure 1: Early Adopters and their regions

Through hands-on Living Labs (such as at BioSpace25 conference) and targeted regional co-design workshops (e.g., in Kuala Lumpur and Plovdiv), these non-technical stakeholders worked directly alongside the technical developers to co-design the system requirements, refine workflows, and shape the user interfaces.

The Technical Architecture

As the software architecture and platform engineering lead, 52°North designed, implemented and deployed the technical foundation.

Figure 2: High-level architecture of the PEOPLE-ECCO platform

We also developed the open-source PEOPLE-ECCO Platform to address the needs of GIS professionals, domain specialists, and public stakeholders:

• Central API (ecco-api): Designed as a RESTful API, ecco-api serves as the primary backbone of the system. It enforces access permissions, handles OpenID Connect (OIDC) authentication via Keycloak, manages conservation sites configurations (area of interest, applicable algorithms), while handling algorithm execution and result retrieval.
• Hybrid Processing Engine: Heavy satellite processingEO data processing – such as the discovery and retrieval of Sentinel-2 data, cloud masking, band sub-setting, spatial resampling and calculating spectral indices (e.g., NDVI, SAVI, NBR) – is offloaded directly to the openEO Platform within the Copernicus Data Space Ecosystem (CDSE). The Prefect workflow engine, Garage S3 storage and PostgreSQL/PostGIS databases enable seamless custom statistical analyses and post-processing. The engine tracks asynchronous batch jobs, automates credentials management for the CDSE using dedicated service accounts (so users do not need to manage these on their own) and provides outputs and results via standardized SpatioTemporal Asset Catalogs (STAC).
• Web User Interface (ecco-web): Built with the Open Pioneer Trails framework, This browser-based web application enables non-technical users to run pre-defined, parameterizable PEOPLE-ECCO solutions. They can visually explore time series, inspect Cloud Optimized GeoTIFFs, monitor execution progress and download indicator datasets (see figure 3).
• Standardized Integration and FAIR Execution: Custom models from consortium partners are packaged as Docker containers (ecco-algorithm-base) using Common Workflow Language (CWL) and OGC Earth Observation Application Packages (EOAP). Outputs are served via standardized SpatioTemporal Asset Catalogs (STAC), adhering to ESA APEx guidelines for long-term sustainability.

Figure 3: User Interface of the PEOPLE-ECCO platform

Today’s Take Away

The PEOPLE-ECCO project demonstrates how open source software, cloud-native standards and collaborative co-design can enable the power of satellite data for ecosystem conservation. By combining openEO cloud processing, dockerized CWL workflows and an intuitive web platform, the PEOPLE-ECCO project has provided NGOs with a modern and scalable toolset to support monitoring, restoration and conservation of ecosystems. All platform components, algorithms, and demonstration outputs developed under PEOPLE-ECCO are open-source and freely accessible to the broader community.

Explore, use, and build upon these contributions directly!

• PEOPLE-ECCO Software Repositories: Access the open-source platform components and containerized algorithm definitions on GitHub: PEOPLE-ECCO.
• User Handbook: Read the operational guidelines and workflow explanations in the PEOPLE-ECCO User Handbook
• Project Results Browser: Inspect actual demonstration site results via the ESA STAC Project Result Repository
• Webinar: Watch the data.europa.eu session “From Space to Species”
• Official Website: Visit the PEOPLE-ECCO Website for project overviews and updates.

As part of our Security project for QGIS initiative, we identified a work package titled “Improve Memory Safety.”

Having worked on this topic over the last few months, here is a summary of the issues involved and what has been accomplished so far.

It’s not an easy thing to present this topic. I’ll try not to dive into too much technical details to focus instead on the broader objectives and implications.

Once upon a time, in the United States…

In November 2022, the NSA published a report on software security, in which it stated:

Microsoft and Google have each stated that software memory safety issues are behind around 70 percent of their vulnerabilities. Poor memory management can lead to technical issues as well, such as incorrect program results, degradation of the program’s performance over time, and program crashes.

In other words: 70% of software vulnerabilities stem from memory management issues.

NSA recommends that organizations use memory safe languages ​​when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations.

The NSA recommends using “Memory Safe Languages” (MSLs) or “hardening” the code. QGIS consists of approximately 1.5 million lines of C++ code, a language not “memory safe” by default. I am therefore opting for the “harden the code” approach, rather than a rewrite which, I have to admit, would have had the “advantage” of keeping me employed until retirement.

What’s the problem?

C++ is not a “memory-safe” language by default, as it does not require the explicit management of the lifecycle of the memory segments it uses.

 

That sentence didn’t make any sense to you, don’t worry, it won’t hinder your understanding of what follows.

C++ developers are expected to be careful: they must ensure they don’t forget to deallocate memory that was previously allocated, while also avoiding deallocating the same memory multiple times, errors that can lead respectively to memory bloat or program crashes.

These memory management issues can be exploited by malicious actors to inject code into a program, potentially allowing them to steal passwords or gain unauthorized access.

 

A malicious actor

Work performed

Fortunately, C++ offers control structures known as smart pointers, which help manage the memory lifecycle. Using them helps prevent memory leaks and crashes, while also limiting the attack surface.

QGIS currently makes limited use of these. The goal, therefore, is to expand their adoption throughout the codebase and prevent the addition of any new code that fails to utilize them.

To achieve this, I developed a program that rewrites the code to incorporate smart pointers, followed by an extensive review process to ensure no new errors were introduced.

A QGIS contributor in the middle of reviewing a pull request

Why not use AI?

Nowadays, it’s hard to discuss any software engineering topic without bringing up AI (at least we don’t hear about blockchain anymore!), so I feel compelled to answer the question: “Could AI have been used for this task?”—or, to use the terminology favored by “tech-bros,” could it have been “AI-powered”?

The answer is YES. But also NO. For one thing, the QGIS project is still determining its policy regarding AI; for the time being, a moratorium is in place that prohibits its use within the QGIS core.

Furthermore, it would have required a more thorough review. My migration program is deterministic—when it makes a mistake, it always does so in the same way. The same cannot easily be said for a probabilistic machine.

So, does this mean we’re now “memory safe”?

Not quite. We’ve reached a significant milestone, but there’s still more to do. This work will continue over the coming months.

In parallel, I’ve also begun a related project, supported by a QGIS.org grant. The goal is to replace SIP_FACTORY annotations with unique pointers. Explaining the technical details of this, however, would likely scare off the few readers who have made it this far!

This initiative is part of a broader effort, as we believe that all security-related issues must be addressed simultaneously and with equal rigor. After all, what’s the point of installing a reinforced front door if you leave the garage door wide open?

To be continued…

We are committed to a process of continuous improvement—both for the QGIS codebase itself and for the workflows surrounding how the software is contributed to and distributed. It is worth noting that this initiative is not just about security; it also helps to reduce software crashes and memory footprint.

It requires financial support. If you would like to contribute, or if you have any other questions regarding QGIS, please do not hesitate to contact us at mailto:infos+qgis@oslandia.com.

You can stay informed by subscribing to our newsletter and following us on LinkedIn.

Soon after I posted my One Hundred Famous Views of Edo Map, Keir Clarke posted about another map of Japanese woodblock prints on his Maps Mania blog, well worth a read if you want to learn a bit about Japanese landscape art in the 19th C. It turns out that there are a lot more than Hiroshige’s One Hundred (which are actually 119) and someone had made a map of 297 of these prints across 5 series which had lost its base map and had a couple of other glitches. Keir threw down a challenge “Perhaps Steven could take a sneak peek at the map’s JavaScript, which contains the coordinates of all the woodblock prints featured, and use them to expand the scope of his own map.” “How difficult could that be?”, I thought.

I searched Wikipedia and found articles on each of the other series and I used the Ukiyo-e map to get the locations (thanks to whoever made that) and Claude checked every one against Wikipedia and Wikidata. 12 were clearly wrong (e.g. the Naruto Whirlpools sat in Tokyo Bay), so we fixed those. Accuracy is moderate, which is all it needs to be.

While building this expanded version Claude suggested adding a couple of quite neat features that I probably wouldn’t have thought of:

• The Tōkaidō road is drawn station to station
• The sightlines from each of Hokusai’s viewpoints to Fuji’s summit are drawn and an exaggerated Mount Fuji is inserted
• Each series has the option to step through all the cards in that series
• Each image has a shareable link and can be expanded to full size
• I added a couple of new features – wherever possible the clusters unpack in one click and selecting a series zooms to the limits of that series

Known issues: some viewpoints are disputed or only placed at the town or province shown, and only 107 of the 178 new prints have a Wikipedia “About” text.

I thought this would be really easy after making the first map, but adding 4 more series turned out to add a bit of complexity and needed more thought and input from me rather than sitting back and letting Claude do it all.

I like the way the clusters are represented and wandering the Tokaido route is neat. I think it has worked out very well and is probably an improvement on the original map that prompted this afternoon’s fun.

<p>The post Ukiyo-e “Pictures of the Floating World” first appeared on KnowWhere.</p>

From raster to histogram

Visualisation is a key part of any analysis. It is useful not only at the end, when presenting the results, but also throughout the analysis itself. A quick plot can help you interpret intermediate results and decide what to do next.

R and Python offer excellent tools for creating visualisations. When working in GRASS, however, I do not always want to export or reshape the data, or have to remember, or look up, the code needed to create a simple figure. Sometimes, I just want to create a plot directly from within GRASS. At the same time, it should offer enough options to fine-tune the result for online or print publication.

At some point, I realised that it was sometimes easier to spend a little time creating an addon for exactly that purpose. Over time, this has resulted in a series of addons for creating different types of visualisations, including bar plots, line plots, and scatterplots.

The latest addition is r.histogram, which creates histograms based on raster values. GRASS actually already provides two modules for creating histograms. This new addon, however, offers more options for fine-tuning their appearance by taking advantage of Matplotlib’s powerful plotting capabilities. Below are a few examples from the manual page.

Examples

The examples below use the data from the Raleigh, North Carolina sample dataset.

The first example draw a histogram of the elevation raster, setting the plot dimensions and DPI.

g.region raster=elevation
r.histogram map=elevation plot_dimensions=5,4 \
  dpi=100 output=r_histogram_01.png

To change the appearance of the plot, you can tweak individual elements, but also apply a matplotlib style. Below, the ggplot style is used.

r.histogram map=elevation plot_dimensions=5,4 \
  dpi=100 frequency=percent style=ggplot \
  output=r_histogram_02.png

For a bit more colorfull result, we can draw the histogram with each bar colored based on the corresponding elevation raster color table. And we can express the frequencies as percentages.

r.histogram -c map=elevation plot_dimensions=5,4 \
  dpi=100 frequency=percent style=_mpl-gallery \
  output=r_histogram_03.png

And one last example, let’s draw a horizontal histogram with a grid, a reduced relative bar width, and a dark background:

r.histogram -hc map=elevation plot_dimensions=5,4 \
  dpi=100  rwidth=0.9 style=dark_background \
  x_label="Number of cells" y_label="Elevation (m)" \
  output=r_histogram_04.png

The addon lets you modify more elements of the plot, including plot title, x- and y-axis labels, fontsize, border line width, relative bar width, transparent background, and colors of the bars and bar borders. And you can create your own Matplotlib styles and apply them to the plot.

The GeoTools team is pleased to announce the release of the latest maintenance version of GeoTools 33.7: geotools-33.7-bin.zip geotools-33.7-doc.zip geotools-33.7-userguide.zip geotools-33.7-project.zip This release is also available from the OSGeo Maven Repository and is made in conjunction with GeoServer 2.27.7 and GeoWebCache 1.27.6. This release includes security fixes. Details will

The GeoTools team is pleased to announce the release of the latest stable version of GeoTools 35.1: geotools-35.1-bin.zip geotools-35.1-doc.zip geotools-35.1-userguide.zip geotools-35.1-project.zip This release is also available from the OSGeo Maven Repository and is made in conjunction with GeoServer 3.0.1 and GeoWebCache 2.0.1. This release addresses security vulnerability

The PostGIS Team is pleased to release PostGIS 3.7.0! Best Served with PostgreSQL 19 RC 1 , GEOS 3.15.0 , postgis_tiger_geocoder 2025.2 , and address_standardizer.

This version requires GEOS 3.10+, PostgreSQL 14-19, Proj 6.1+, and libgmp. To take advantage of all postgis extension features, GEOS 3.15+ is needed. To take advantage of all postgis_sfcgal extension features SFCGAL 2.3+ is needed. Python 3 is a new requirement to build the documentation images. Visual examples in the docs are off by default. To build docs with them, configure with --with-visual-examples and make sure you have a running PostgreSQL instance; they are then generated automatically when building the docs (or explicitly with make -C regress visual-examples).

This release contains fixes since 3.7.0rc3 release.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

This release is a major release, it includes bug fixes since PostGIS 3.6.4 and new features.

The GeoTools team is pleased to announce the release of the latest maintenance version of GeoTools 34.6: geotools-34.6-bin.zip geotools-34.6-doc.zip geotools-34.6-userguide.zip geotools-34.6-project.zip This release is also available from the OSGeo Maven Repository and is made in conjunction with GeoServer 2.28.6 and GeoWebCache 1.28.6. This release includes security fixes. Details will

The GeoTools team is pleased to announce the release of the latest stable version of GeoTools 35.2: geotools-35.2-bin.zip geotools-35.2-doc.zip geotools-35.2-userguide.zip geotools-35.2-project.zip This release is also available from the OSGeo Maven Repository and is made in conjunction with GeoServer 3.0.2 and GeoWebCache 2.0.2. This release includes security fixes. Details will be

Doug Greenfield posted his Map of the Week – Map of the 100 Famous Views of Edo saying “The Wikipedia listing has a table listing each print with an image, title and geographic coordinates. Somebody with more time and better programming skills could make a nice interactive map from this table with popups at each location.”

Well I have the time and an AI with some programming skills so I thought “Why not?”

So I asked Claude:

• One Hundred Famous Views of Edo
• Have a look at the table on https://en.wikipedia.org/wiki/One_Hundred_Famous_Views_of_Edo. It has a link to each of the woodblock images and coordinates. Can you make an interactive web map of these locations and images in the style of Hiroshige woodblocks. Use my standard architecture, tools and place in a project folder named “edo”
• Tell me what else you need from me to start

Claude asked me a couple of questions, suggested a way to style the map and pop-ups and suggested that it add a season selector following the classification of the Hiroshige woodblocks and also including the Japanese text from the wiki page to add an authentic feel. I gave it the go ahead and left it whirring while I jumped on a call.

An hour later I had this map which needed a slight tweak to the pop-ups and I decided to add an inset map to give users a sense of where Edo (Tokyo) is in Japan, this isn’t visible in the mobile version.

Claude gave me a summary of what it had done:

• All 119 prints. I wrote a script, extract.py, that reads Wikipedia’s table into data/prints.geojson. You can rerun it if the article changes.
• One location is mine, not Wikipedia’s: print 64, Horikiri Iris Garden, has no coordinates on Wikipedia, so I placed it at today’s Horikiri Iris Garden. The card and the info modal both say so.
• Hiroshige styling:
  • the Atlas Canvas basemap faded onto washi-paper colour, with a faint grain;
  • a Prussian-blue sky band across the top of the map;
  • season-coloured hanko seals with the print numbers;
  • a red vertical 名所江戸百景 cartouche beside the title;
  • Shippori Mincho for headings.
• Print cards are fixed-size and show the English, 日本語 and romaji titles, the date, the place and notes. The date is in the old lunisolar calendar, e.g. “Intercalary 5th month, 1857”. Click the image to enlarge it, or follow the link to the full-size scan on Commons.
• Overlapping prints step through with ‹ › and an “X OF Y” pager; the arrow keys work too. On phones this becomes a bottom sheet with a dimmed backdrop.
• Search ignores accents, so “ryogoku” finds Ryōgoku. It also accepts Japanese titles and print numbers.

There is a lot of functionality and design in this that I did not explicitly request but that is 100% in the spirit of what I wanted. My input time for this simple map was about 15-20 minutes, it helped that the data on the wiki page is so easy to work with. I think the results are pretty good and a few years ago would have been considered great which is an indication of how fast the tech is advancing. The styling is really neat, particularly when you see how little prompt I gave Claude.

<p>The post One Hundred Famous Views of Edo first appeared on KnowWhere.</p>

Insights from the DIRECTED Data Fabric

The Challenge: Building Software That Users Actually Need and Use

In geospatial research and software engineering, we frequently encounter a persistent paradox: sophisticated platforms, cutting-edge hazard models, and rich spatial data infrastructures are built with tremendous technical skill and effort – but lack uptake. Why? Because the development process often occurs in isolation from the operational realities, decision-making pressures, and daily workflows of end-users.

When addressing complex crises like climate change adaptation (CCA) and disaster risk management (DRM), a purely top-down or tech-driven development approach routinely fails. Emergency responders do not need generic GIS viewers with a multitude of layers and tools; civil protection officers require clear, actionable, and rapid information products that answer specific questions during an evolving crisis.

This leads to this week’s challenge:

How can we design and develop geospatial information systems that genuinely address user needs, bridge organizational silos, and adapt as real-world requirements evolve?

1. Requirements & Personas: Bilateral interviews, world-café workshops, pain-point mapping
2. Visual & Architectural Mock-ups: Low/high-fidelity UI mock-ups, API design
3. Prototyping & Sprint Reviews: Agile development, continuous cloud deployment
4. Operational Validation: Tabletop exercises (TTX), multi-agency drills
5. Asynchronous Refinement: Annotated slide decks, GitHub tracking, direct iterations

52°North tackled this exact challenge in the Horizon Europe DIRECTED project, working with an interdisciplinary consortium including stakeholders from Real World Labs. By establishing a structured Co-Design Framework around the DIRECTED Data Fabric, we turned end-users from passive recipients into active co-creators of the software platform.

Our Approach: Co-Design in Action

Co-design is far more than asking stakeholders what features they want at the beginning of a project, re-visiting design choices with them once in a while and presenting a finished tool later. It is a continuous, agile conversation that aligns technical possibilities with operational needs.

To turn co-design principles into a tangible engineering process, we structured our work around four key pillars:

1.  Dedicated Task Forces and Product Ownership
For each of DIRECTED’s four Real World Labs (RWLs), we established a compact, cross-disciplinary Task Force. Crucially, a representative from the local RWL host acted as the Product Owner. The Product Owner prioritized the development based on the real thematic needs of local practitioners, while developers, modelers, and experts in governance and knowledge co-production supported the technical execution.

2. Iterative Interface Evolution (Mock-ups to Production)
Before committing to backend pipeline engineering, we created interactive Graphical User Interface (GUI) mock-ups based on initial user stories. Presenting these mock-ups during early stakeholder workshops allowed us to refine UI elements, data layer groupings, and decision-support widgets early. This saved plenty of redundant development time.

3. Agile, Sprint-Based Increments
Borrowing from Scrum, development moved in short, bi-weekly sprints. Every iteration delivered a testable software increment. Stakeholders were not evaluating static specification documents; they were interacting with specific and live solutions, enabling continuous feedback and quick pivots when assumptions met reality.

4. Continuous Feedback Loops and Operational Drills
For the DIRECTED project, we tested prototypes directly within real-world emergency management workflows. From Tabletop Exercises (TTX) in flood management to full-scale multi-agency field drills with firefighters and rescue teams, software components were evaluated under operational pressure.

Co-Design Phase

Core Activities

Key Outputs

1. Requirements and Personas

Bilateral interviews, world-café workshops, pain-point mapping

User stories, priority matrices, target personas

2. Visual and Architectural Mock-ups

Low/high-fidelity UI mock-ups, API design

Wireframes, layer panel layouts, dashboard specs

3. Prototyping and Sprint Reviews

Agile development, continuous cloud deployment

Live web client builds, integrated OGC APIs

4. Operational Validation

Tabletop exercises (TTX), multi-agency drills

Stakeholder feedback, acceptance checklists

5. Asynchronous Refinement

Annotated slide decks, GitHub tracking, direct iterations

Final production releases

Real-World Impact Across the DIRECTED Labs

Our co-design methodology was put to the test across four diverse European regions, each presenting unique hazard profiles, institutional contexts, and user requirements:

• Capital Region of Denmark (Roskilde Fjord): Local municipalities and fire departments needed to evaluate combined storm surge and heavy rainfall risks. Through iterative workshops, we implemented interactive rainfall/coastal water sliders, local groundwater levels, and a Multi-Criteria Decision-Making (MCDM) process backed by CLIMADA to weigh adaptation measures.
• Emilia-Romagna Region (Italy): Civil protection officers and firefighters needed rapid forecasting tools during emergencies. The Data Fabric integrated real-time radar (HERA), weather forecasts (ICON), and live sensor streams to trigger automated pluvial/coastal flood mapping (SaferPlaces) and wildfire spread simulations (PropagatorCIMA) intersecting with sensitive receptors like schools and hospitals.
• Danube River Basin (Vienna & Zala County): In Vienna, insurance and public sector actors focused on urban pluvial flash floods and shifting return intervals under climate projections. In Hungary’s Zala region, volunteer rescue teams and municipal planners co-designed a multi-hazard dashboard featuring historical disaster catalogs, local sensor feeds, and crop yield projections.
• Rhine-Erft Region (Germany): Following the catastrophic 2021 floods, the Erftverband and district emergency authorities required tools to test non-structural measures. We co-developed hydrodynamic simulation sandbox workflows (RIM2D) for different scenarios.

5 Questions for 52°North’s Development Team

1. What was the biggest surprise during the co-design process in DIRECTED? How quickly stakeholders’ focus shifts from complex backend model mechanics to visual clarity and user experience. Modeler teams often want to highlight technical precision, but operational users care most about transparency: Where does this data come from, how old is this simulation, and how uncertain is this prediction?

2. Is co-design more time-consuming than traditional software engineering? Initially, yes. It requires significant effort upfront to build trust, organize workshops, and run feedback loops. However, it saves immense time in the long run by preventing us from building features that nobody uses or understands. It’s a demanding, yet insightful process for everyone involved.

3. How do you manage conflicting feature requests from different user groups? That is where the Task Force Product Owner is essential. By establishing clear acceptance criteria and prioritizing items based on actual operational gaps, we ensure the platform remains focused rather than bloated.

4. How does Open Science play a role in this co-design approach? Open Science and FAIR data principles are the foundation. By relying on open standards (like OGC APIs) and open-source frameworks and solutions, any component co-designed in one region can be reused or extended by another without vendor lock-in.

5. What is the main takeaway for future research and software projects? Don’t build for users in a silo; build with them. Prototype early, test under real conditions, and accept that user feedback will—and should—change your original development plan.

Your Take Away Today

Co-design is not just a theoretical framework; it produces modular, highly reusable open-source software. As part of our commitment to Open Science, the tools and building blocks created during the DIRECTED project are openly available for your own applications:

• Open Pioneer Trails: An open-source framework maintained by 52°North and con terra for building modular, modern geospatial web clients. It served as the frontend foundation for the Data Fabric (on GitHub).
• Pygeoapi Kubernetes Manager: An open-source extension co-developed in DIRECTED to execute OGC API processing jobs dynamically in cloud environments (on GitHub).
• Data Fabric Web Client Repositories: Explore our open-source frontend code directly on GitHub.

Are you planning a geospatial platform or looking to incorporate co-design methodologies into your research infrastructure? Reach out to our team to explore collaboration opportunities!

Build a tree inventory in QGIS: one point per tree from aerial imagery or LiDAR, with ID, crown size and height, then species and condition from the field.

AI GIS is software that does GIS work from imagery or a plain request. The five jobs it handles in 2026, the tools for each, and where it still fails.

Sorry, this entry is only available in French.

Remote sensing is measuring the ground from satellites, planes and drones. The sensors, the free data, and a Sentinel-2 workflow in QGIS, step by step.

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They allow unauthenticated remote code execution on web servers running PHP. Exploitation attempts were observed even before public disclosure. The UK NCSC has issued an alert asking organisations to find and patch every PHP installation, and to take offline what they cannot fix.

Since then we have been receiving questions from organisations running our open source products. Here is the short answer, and what we suggest you check.

Are MapStore, GeoServer and GeoNode affected?

No since none of them uses PHP.

• MapStore is a Java web application. Its frontend is JavaScript running in the browser.
• GeoServer is a Java web application.
• GeoNode is a Python (Django) application, with GeoServer as its map server.

The official distributions and Docker images do not include or depend on PHP. PHP2Shell is not relevant to MapStore, GeoServer or GeoNode as released.

Your installation is a different question

The products are not affected, but your deployment might still be exposed. Every installation is different, and we usually have no visibility on how yours was set up. So take a look at the whole stack around your maps.

• Web servers and reverse proxies. MapStore, GeoServer and GeoNode are often published behind Nginx or Apache httpd. Nginx and Apache are not affected by PHP2Shell on their own, but the same server often also hosts PHP applications through PHP-FPM or mod_php. Check what else runs there. Nginx itself needs attention too: on 21 October 2026, the same day as PHP2Shell, F5 disclosed three critical Nginx vulnerabilities (CVE-2026-15176, CVE-2026-97205, CVE-2026-93479), after NGINX Rift (CVE-2026-42945) in May. If you run Nginx in front of your maps, including as a container in Docker based deployments, update it to the latest security release.
• Other applications on the same hosts or network. Content management systems, intranet portals and websites embedding your maps are often PHP based. WordPress, Drupal, Joomla and Moodle are all PHP.
• Appliances and third party products. PHP is embedded in many products, including some firewalls and VPN gateways. Follow your vendors' advisories.
• Hosting providers and managed services. If someone else runs part of your infrastructure, ask them.

Security is ongoing work for us

GeoSolutions leads the development of MapStore and takes part in the security work of the GeoNode and GeoServer projects. When an issue is reported, we help analyse it, prepare and test the fixes, and coordinate the releases with the rest of the community. We are certified ISO 27001. We are doing our best to strengthen security in everything that we do.

How we can help

Running open source in production does not mean running it alone. With our Enterprise Support Services, Enterprise Subscription Services and Professional Training Services we help organisations:

• understand whether a security issue is relevant to their installation
• plan and apply upgrades
• review their deployments, including the web servers and proxies in front of them
• train their teams

Want to talk about your MapStore, GeoServer or GeoNode installation? Write to sales@geosolutionsgroup.com.

This post is general guidance on the products as published. It is not an assessment of any specific installation.

Sources

• NCSC: Critical security issue affecting PHP
• Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
• CSA Singapore: Critical vulnerabilities in F5 NGINX products
• Beazley Security: NGINX Rift (CVE-2026-42945)

Explore Lutra Consulting's highlights from FOSS4G Belgium 2026, featuring QGIS and Mergin Maps presentations, mobile GIS workshops, and community engagement.

Discover Lutra Consulting and Mergin Maps' highlights from FOSS4G:UK 2026 in Leeds, featuring insights on AI in GIS, CRAG integration, and QGIS advancements

Stem op OSGeo.nl voor de Geo Prestige Award!

TLDR; Direct stemmen via https://geomares.typeform.com/to/YUyu9jo8 .

De vakvereniging Geo-Informatie Nederland (GIN) reikt jaarlijks vakprijzen uit, de Geo Prestige Awards. Er zijn drie categorieën: Professional, Startup en Organisatie. OSGeo.NL is genomineerd in Organisatie.

Genomineerd…, maar nu willen we natuurlijk ook winnen! Daarom vragen wij iedereen die OSGeo.nl, FOSS4G.nl, de PostGISdag en alle open source geo software een warm hart toe draagt om op ons te stemmen!

Here is a closer look at the highlights of the new series 2026.02 of MapStore, our flagship Open Source WebGIS product. On GitHub it is possible to consult the full list of new features, enhancements and fixes we have provided in version 2026.02.00. You can try it right away on the MapStore demo.

We would like to thank all contributors who made this release possible, in particular Municipality of Genoa, TotalEnergies, Open Groupe, University of Naples, KfW and Deutsche Bahn for their valuable contributions (the full list is available at the v2026.02.00 release page in Github). The 2026.02.00 version introduces a wide range of enhancements focused on data source integration, catalog usability, projection management, and widgets flexibility. It represents another important step forward in evolving MapStore into a comprehensive platform not only for geospatial visualization, but also for the seamless integration of heterogeneous data sources and modern web-based analytical workflows.

Expanded Data Source Support

The v2026.02.00 release significantly broadens the range of data sources that MapStore can natively consume, further strengthening its role as an interoperable WebGIS platform. A major addition is the introduction of ArcGIS FeatureService support, which allows vector data exposed through dedicated ArcGIS query endpoints to be visualized directly within MapStore. The implementation targets both OpenLayers and CesiumJS, and adopts a tile-based loading strategy that fetches features incrementally per grid cell rather than downloading the entire dataset at once. This approach provides natural spatial partitioning and ensures a good balance between performance and user experience, even when working with large FeatureServer datasets. This feature was made possible thanks to the contribution of the Municipality of Genoa. [caption id="attachment_13854" align="aligncenter" width="526"] ArcGIS Feature Service[/caption] Alongside ArcGIS, the release also brings support for the FlatGeobuf format as a read-only remote layer type, with consistent behavior across the catalog, layer tree, map identify, and styling, including dynamic updates to feature styles. FlatGeobuf datasets can now be visualized both in 2D and 3D environments, thanks to the integration in both OpenLayers and CesiumJS map components. Complementing the initial integration, a set of dedicated FlatGeobuf enhancements introduces a configurable maxFeaturesInView option, which limits the number of features rendered in the current view to avoid performance issues when a map extent covers an entire large dataset. The setting is available both in the TOC layer settings and in the catalog's advanced settings, and applies uniformly to OpenLayers and CesiumJS. The "Zoom to" action has also been enabled directly in the TOC for FlatGeobuf layers, aligning it with the existing user experience of the other layer types. Both the initial integration and these refinements were made possible thanks to TotalEnergies. [caption id="attachment_13855" align="aligncenter" width="515"] Support for the FlatGeobuf format[/caption] Furthermore, Panoramax is now available as a new provider for the Street View plugin, enabling users to explore street-level imagery served by the Panoramax API. The integration includes dedicated configuration options, localization support and proper attribution handling, further diversifying the sources of contextual imagery available in MapStore. This addition was contributed by Open Groupe. [caption id="attachment_13856" align="aligncenter" width="803"] Panoramax as the new provider of the Street View plugin[/caption]

A Redesigned Layer Catalog

With v2026.02.00 the layer catalog receives one of the most significant reworks of the release cycle, driven by both a UX and an architectural perspective. The legacy MetadataExplorer plugin has been completely reworked and renamed to Catalog, adopting a refreshed layout and theme that reuses the resources catalog components already available in the platform. On top of the visual and structural rework, the new Catalog now natively supports the GeoNode API as a catalog service, alongside the other supported source types (e.g.  WMS, WFS, WMTS, TMS etc.). This lays the groundwork for eventually retiring the separate custom catalog historically maintained inside GeoNode itself, moving toward a more unified experience across the two projects. The Catalog rework was made possible thanks to TotalEnergies. [caption id="attachment_13857" align="aligncenter" width="893"] New Layer Catalog[/caption] The refactor is complemented by a set of targeted refinements, including:

• Improved spacing and layout in the catalog's dialog mode.
• Removal of duplicated legacy catalog components, now centralized in the core.
• A fix preventing the catalog page from reloading and resetting when switching layout.
• Alignment of template and default catalog configuration, including the removal of the default COG service entry.
• A fix for GeoNode services showing the category identifier instead of its human-readable label on catalog cards.

 

Advanced CRS and Projection Management

Building on the CRS improvements delivered in the previous series, the 2026.02.00 release introduces the Dynamic Projection Definitions, a feature that connects MapStore's coordinate reference system management directly to a GeoServer endpoint exposing thousands of standardized CRS definitions. [caption id="attachment_13858" align="aligncenter" width="597"] Dynamic Projection Definitions[/caption] Administrators and users with appropriate edit permissions can now search, add, and remove projections on demand directly from the CRS selector, without redeploying the application or manually editing configuration files. Existing statically configured projections continue to work exactly as before, ensuring full backward compatibility with current deployments. This is a particularly valuable improvement for organizations dealing with a large or evolving set of coordinate systems, where flexibility and rapid iteration are essential. This feature was made possible thanks to TotalEnergies.

Widgets and Timeline

The 2026.02.00 release continues to evolve MapStore's widget experience, with a focus on flexibility, layout consistency and customizability. This is especially useful for developing custom widgets thanks to a new Custom Widget type, now available thanks to the contribution of the University of Naples. Unlike the existing predefined widgets, each with its own dedicated builder, the new custom widget can render any component exposed by another plugin inside the Widgets container. Custom widgets can be expanded and minimized like any other widget, opening the door to fully bespoke dashboard content and enabling advanced customization scenarios for both developers and end users. The Timeline plugin has also received a layout review, aligning it with the newly introduced layout structure delivered in recent releases. The plugin is now positioned in the bottom section rather than floating over the map, and both the expand/collapse control and the layout used when a time range is enabled have been refined for improved usability and visual consistency. [caption id="attachment_13859" align="alignnone" width="803"] Timeline plugin[/caption]

Greater Flexibility in Data Access and Configuration

Several improvements in this release address the way MapStore interacts with services and manages user access, providing administrators with finer-grained control. Key highlights include:

• WMS Layer Extent Cropping Control: by default, MapStore crops WMS layers to the current map projection extent. A new option now allows users to let OpenLayers request tiles beyond that extent, configurable from the TOC display settings, the catalog's advanced settings, and the background layer editor. This improvement was contributed by TotalEnergies.

[caption id="attachment_13860" align="aligncenter" width="402"] WMS Layer Extent Cropping Control[/caption]

• Configurable Nominatim Geocoding Endpoint: the way the Nominatim geocoding endpoint URL is built has been restructured so that hostname and protocol can be overridden rather than remaining hardcoded. This makes it much easier for deployments to point to a custom Nominatim instance. This enhancement was contributed by Wolfgang Kaltz (@jwkaltz).
• Granular Permissions Control: mostly targeting GeoNode UI control, permissions now support a disabled property that allows administrators to prevent selection, deletion, and modification of GeoLimits on specific permission rules when required. This feature was contributed by KfW.

All together, these changes make MapStore more adaptable to complex deployment scenarios and easier to integrate into enterprise environments with specific security and configuration requirements.

System and Infrastructure Updates

Beyond new features, the v2026.02.00 release brings a number of under-the-hood improvements aimed at making MapStore even more robust, maintainable, and easier to operate:

• User Session Cleanup on Account Deletion: deleting a user now automatically triggers the cleanup of any associated session records via a new backend cascade-delete parameter, preventing orphaned session data from accumulating in the database. This improvement was contributed by Deutsche Bahn.
• Official Project Entry Page: MapStore now has a more official project entry page at mapstore.io, acting as the project's official landing page with relevant links and pointers, in line with similar entry points already available for other open source geospatial projects. An automated process has also been introduced to keep the page up to date across releases.
• Dependency Upgrades: the mapfish-print component has been updated to version 2.3.5 in line with the release calendar, and the GeoStore backend dependency used by MapStore has been migrated to version 2.6, together with revised authentication and setup documentation. A dedicated guide has been added and/or improved for configuring authentication (OIDC/Azure/Keycloak) for MapStore deployments.

All these updates contribute to a more robust, maintainable and transparent platform, while also improving the overall developer workflow and operational efficiency. These are just some of the many improvements introduced in the 2026.02 series, which continues to expand MapStore's capabilities as a modern, flexible, and powerful WebGIS platform. Stay tuned for future updates as we continue to enhance the MapStore project with new features and improvements in upcoming releases.

If you are interested in learning more about how we can help you develop a WebGIS using MapStore or help you achieve your needs with MapStore, GeoServer, GeoNode and GeoNetwork through our Enterprise Support Services, Professional Training Services and Subscription Services  please contact us!

The GeoSolutions team,

As you all know by now, the php2shell vulnerability was disclosed and is wreaking havoc all across the technology landscape wherever a PHP installation is involved as everybody is frantically patching their PHP installs to mitigate this vulnerability.

Since MapGuide bundles PHP, this vulnerability sadly also affects us as well and I feel obligated to at least post something about this.

So here's the current situation of this vulnerability in the context of MapGuide.

1. The next release

2. Mitigating your MGOS 4.0 install (Windows)

Then rename your current Php directory in your web tier installation directory to something like PhpOld.

ACE.dll

GEOS.dll

lib_json.dll

MgFoundation.dll

MgGeometry.dll

MgHttpHandler.dll

MgMapGuideCommon.dll

MgMdfModel.dll

MgMdfParser.dll

MgPlatformBase.dll

MgRenderers.dll

MgStylization.dll

MgWebApp.dll

MgWebSupport.dll

php.ini

xerces-c_3_1mg.dll

ext/ACE.dll

ext/GEOS.dll

ext/lib_json.dll

ext/MgFoundation.dll

ext/MgGeometry.dll

ext/MgHttpHandler.dll

ext/MgMapGuideCommon.dll

ext/MgMdfModel.dll

ext/MgMdfParser.dll

ext/MgPlatformBase.dll

ext/MgRenderers.dll

ext/MgStylization.dll

ext/MgWebApp.dll

ext/MgWebSupport.dll

ext/php_MapGuideApi.dll

ext/xerces-c_3_1mg.dll

Discover how Winterthur's Stadtgrün department uses Mergin Maps to coordinate municipal forestry, salvage logging, and invasive species tracking across 14 projects.

Discover Lutra Consulting's highlights from the QGIS User Conference 2026 in Laax, Switzerland. Explore our talks on QGIS 3D, point clouds, Mergin Maps, and more!

52°North and Open Science? Nothing new here, but we’re not interested in a casual relationship. We want to make it official. Therefore, this week’s blog post isn’t about how we address a particular challenge, it’s about making a formal commitment to Open Science practices! To show our dedication, we are signing the NFDI4Earth FAIRness and Openness Commitment.

The NFDI4Earth FAIRness and Openness Commitment aims to promote the implementation of open practices and is composed of twelve items. Signing this commitment publicly signals agreement with the goals, mission, and products of NFDI4Earth.

In the following paragraphs, we will elaborate on 52°North’s commitment to the twelve items.

(1) Commit to the mission of NFDI in bringing together research communities to provide data for the common good, and the role of NFDI4Earth as a facilitator of sustainable, collaboratively developed solutions in Earth System Sciences.

We’re proud that the cooperation between NFDI4Earth and 52°North spans several years. An important milestone was the release of the OneStop4All, a search user interface increasing the findability and accessibility of earth system science resources such as data, software, and educational resources. Hence, we commit to the mission of both NFDI and NFDI4Earth, while also extending our cross-disciplinary integration across various domains through our spatial information systems.

(2) Support and uphold, where appropriate and possible, the principles and values outlined in existing Open Science declarations and statements.

As outlined in a recent post, Open Science services are part of 52°North’s portfolio . We actively monitor relevant Open Science declarations and statements such as GEO’s statement on open knowledge and adhere to the principles and values whenever possible.

(3) Be familiar with relevant data laws and acts, especially those related to geospatial data, in both national and European jurisdictions. These laws facilitate data sharing at both national and international levels.

We regularly inform our staff of relevant data laws and regulations. Given recent developments in AI, we see this as an essential aspect of our work. Moreover, we stay well-informed about regulations for data sharing, such as High-value datasets, and policies created by Infrastructure for Spatial Information in the European Community (INSPIRE).

(4) Give credit to all sources underlying our research findings and, whenever possible, credit is given through proper citations.

Seeing this as good scientific practice, we always cite the foundational work (including research data, software, publications, educational resources, etc.) that build the basis for our deliverables.

(5) Choose to publish Earth System Sciences data in Earth System Sciences domain repositories and other suitable research infrastructures that meet all four aspects of FAIR principles and consider the specific characteristics of Earth System Sciences data.

The discovery of such domain repositories is greatly facilitated by the OneStop4All’s repository guide. We will use and promote this feature in our projects and publish in relevant repositories.

(6)  Strengthen FAIR and Open Data practices by supporting educational networks, robust training programs, and the production of educational materials that promote transparency and accessibility of research outputs.

As mentioned in a recent post, Open Science capacity building is a service we already deliver and plan to extend in the future. We have also been offering seminars and workshops promoting the use of open standards and software at universities and research organizations for several years.

(7) Adopt Data Management Plans as important tools for all research projects. These plans are invaluable for strategically planning data documentation, publication, and collaboratively monitoring data management activities. We seek and consider expert curation and guidance for them.

We will regularly include Data Management Plans in funding proposals to demonstrate solid scientific practice and a well-thought-out strategy for sustainable data management.

(8) Where possible, use open and permissive data and software licences that legally enable the envisioned free and open sharing of Earth System Sciences data.

Most of our work centers around software development and we’re keen to release it, whenever possible, under open licensing models (such as the Apache License 2.0) as stated on our homepage.

(9) Support and align scientific work with governing bodies and organizations that advance the underlying causes of this commitment.

Rather than working in isolation, we strive to align and integrate our work with broader initiatives such as the European Open Science Cloud, NFDI and GEO.

(10) Recognize the vital role that Earth System Sciences domain repositories and their curation services play in achieving and preserving the highest possible FAIRness and Openness in the Earth System Sciences. As researchers, institutions, and funding agencies, we endeavour to ensure the sustainability of these repositories and other relevant research infrastructures.

We contribute to ensuring the sustainability of the domain repositories by promoting their use through, for instance, the OneStop4All in our projects.

(11) Collaborate with data curators and repository managers and leverage their expertise to make Earth System Sciences research outputs transparent, machine-readable, interoperable, and re-usable in the long term. They use diverse approaches, such as the NFDI4Earth Label, to document and advance interoperability across data repositories.

Working closely with data curators and repository managers is important, particularly when it comes to providing high-quality metadata, which is key to fulfilling the FAIR principles. Beyond supporting this effort, we actively engage with OGC bodies to improve open access and machine readability of both data and metadata.

(12) Adhere to and contribute to international standards for harmoniing Earth System Sciences data, metadata, data quality, and application programming interfaces (APIs). Support their implementation and development across research infrastructures, as this is crucial for effective interdisciplinary research and advancements in novel analysis methods such as Artificial Intelligence or Machine Learning (AI & ML). 

Interoperability has been one of 52°North’s core topics since day one, twenty years ago. With the advent of (agent-based) AI, ensuring transparency and machine-readability is more important than ever, and we regularly contribute to OGC initiatives.

So, this looks like a handshake between 52°North and the NFDI4Earth FAIRness and Openness Commitment! Fortunately, this commitment doesn’t require us to make any drastic changes to our internal workflows. It does, however, raise the awareness of the importance of adhering to FAIR and open principles. Do you also see the importance of this commitment? Are you ready to sign it, too?

The PostGIS Team is pleased to release PostGIS 3.7.0rc3! Best Served with PostgreSQL 19 RC 1 , GEOS 3.15.0 , postgis_tiger_geocoder 2025.2 , and address_standardizer.

This version requires GEOS 3.10+, PostgreSQL 14-19beta3, Proj 6.1+, and libgmp. To take advantage of all postgis extension features, GEOS 3.15+ is needed. To take advantage of all postgis_sfcgal extension features SFCGAL 2.3+ is needed. Python 3 is a new requirement to build the documentation. Visual examples in the docs are off by default. To build docs with them, configure with --with-visual-examples and make sure you have a running PostgreSQL instance; they are then generated automatically when building the docs (or explicitly with make -C regress visual-examples).

This release contains fixes since 3.7.0rc3 release.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

This release is a release candidate of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.

In water resources administration, the difference between reactive management and sustainable governance lies in data quality, process efficiency, territorial vision, and technological autonomy. With the launch of our new dedicated website at sirh.icarto.es, we want to highlight the main reasons why river basin authorities choose the Water Resources Information System (SIRH) by iCarto.

1. GIS Power and a Geospatial “Single Source of Truth”

Many public institutions suffer from scattered data stored in physical files, paper registries, and disconnected spreadsheets across departments. SIRH stems from the integration of administrative management and Geographic Information Systems (GIS). It centralizes water administration into a single geospatial database, enabling authorities to locate, analyze, and query abstraction points, discharges, distribution networks, agricultural plots, and administrative boundaries on interactive maps within a unified operational environment.

2. Technological Sovereignty and 100% Open Source Philosophy

Governing a strategic resource like water should not entail vendor lock-in or prohibitive recurring software licensing fees. With SIRH, 100% of code and data ownership remains strictly with the institution. This means zero recurring license costs and total freedom to scale the number of users, servers, or regional offices without financial penalties, all built on open standards and leading open-source GIS technologies.

3. Complete Lifecycle Coverage: From Permitting to Revenue Collection

SIRH connects spatial insights with every administrative stage necessary to ensure the operational and financial sustainability of river basins. It enables automated workflows and transparent tracking for application status, renewals, and official permit issuance, combined with automated consumption estimates based on institutional and spatial parameters. Furthermore, it professionalizes revenue collection through batch invoicing and payment tracking by geographic zones or basins.

4. A Methodology Focused on Real-World Adoption

Most technology projects in the public sector fail not because of code, but due to a lack of day-to-day user adoption. At iCarto, we do not deliver off-the-shelf or rigid software: we configure the platform alongside technical teams through collaborative co-design and dedicate 40% to 50% of total project effort to hands-on workshops and capacity building. Our three-phase roadmap (Registry & Mapping, Procedures, and Billing) ensures a gradual rollout tailored to local institutional and territorial realities.

5. Scalable Ecosystem Built for Field and User Engagement

Once the core registry and billing foundation is consolidated, SIRH expands through advanced modules. SIRH Mobile, a field inspection tool leveraging GPS positioning for paperless data collection synchronized with the central database, and the Digital Customer Portal, a web environment where water users can transparently check permit statuses, submit online applications, and review billing statements.

6. Proven Track Record and Documented Impact

SIRH brings 10 years of experience enhancing spatial management for water concessions and users. Its effectiveness is proven through consolidated national and regional deployments across 2 countries (Mozambique since 2018 and Eswatini since 2024), supporting 5 water authorities. Today, SIRH manages over 5,000 georeferenced licenses, 4,000+ registered water users, and 100+ active institutional users.

Explore All the Details on Our New Website!

We invite you to explore SIRH’s modular architecture, view GIS map interface previews, and learn more about our ongoing projects at https://sirh.icarto.es.

---

La entrada Why Choose SIRH for Integrated Water Resources Management? se publicó primero en iCarto.

Urban infill means building on vacant or underused land inside a city. The five kinds of lot, how to find them in QGIS, and one lot rendered three ways.

The IGN Geoplateforme URLs that answer on 19 October 2026, the exact layer names, WMS vs WMTS measured in QGIS, and why a French layer stays blank.

A figure ground map shows buildings in black and the rest in white. How to make one in QGIS from open footprints, or from an aerial image without them.

AI Agent, a free QGIS plugin, scored 43.8 out of 100 on Google's geospatial benchmarks, against 24.9 for Claude Sonnet 5.5 with a QGIS MCP server.

Prezados leitores,

Sempre que preciso instalar uma nova instância do GeoNode, sigo os procedimentos que já compartilhei aqui no blog:

– Instalação do GeoNode 5 no Ubuntu 24.04
– Instalação do Certificado SSL no GeoNode
– Atualizar camadas do GeoServer para o GeoNode automaticamente

O passo a passo ajuda bastante, mas, a cada instalação, lá estava eu novamente: preparando o servidor, instalando dependências, criando o projeto, ajustando configurações e habilitando o HTTPS.

Ao preparar um ambiente para mais um curso, pensei: por que não automatizar esse processo?

A ideia foi transformar essa sequência em um instalador reutilizável. Agora, basta preencher um arquivo de configuração e executar um comando para iniciar a instalação.

Testei o procedimento em uma máquina nova, utilizando o GeoNode 5.1.0, e o resultado foi a aplicação funcionando com HTTPS habilitado.

Vamos ver como utilizar!

1. O que o instalador faz?

O instalador utiliza o projeto Docker oficial do GeoNode e automatiza as principais etapas de preparação do ambiente:

• Instala as dependências do sistema, o Docker e o plugin Docker Compose.
• Cria um usuário dedicado para os arquivos do projeto.
• Obtém a versão selecionada do geonode-project.
• Gera a estrutura da aplicação e o .env do GeoNode.
• Cria senhas aleatórias para os serviços.
• Configura as URLs de acesso e a emissão do certificado HTTPS.
• Aplica ajustes iniciais de memória e quantidade de processos.
• Constrói as imagens e inicia os containers.
• Verifica a resposta da aplicação, o certificado e o estado dos principais serviços.
• Configura, opcionalmente, uma tarefa agendada para detectar alterações no workspace do GeoServer e atualizar as camadas no GeoNode.
• Oferece comandos para desinstalar o projeto ou realizar uma limpeza completa do Docker em uma VM de laboratório.

O pacote contém um script de entrada em Bash, o instalador em Python, um arquivo de parâmetros e as instruções de uso.

2. Antes de começar

O instalador foi preparado para uma máquina nova com Ubuntu 24.04 e arquitetura x86_64. O perfil padrão considera uma VM com aproximadamente 16 GB de RAM, com ajustes iniciais para os serviços.

Por padrão, a instalação verifica um mínimo de 14 GiB de RAM e 30 GiB livres no disco de destino. Esses limites podem ser alterados no arquivo de parâmetros, permitindo utilizar máquinas menores para testes e atividades acadêmicas. Veja os exemplos no tópico 11.

Para instalar com HTTPS, você também precisará de:

• Um domínio ou subdomínio apontando para o IP público do servidor.
• Portas TCP 80 e 443 liberadas.
• Acesso administrativo por SSH.
• Conexão com a internet para baixar os pacotes e as imagens.

O instalador prepara o software dentro da máquina. A criação do servidor, os registros de DNS e a liberação das portas devem ser feitos previamente.

Utilize uma máquina nova, sem outra aplicação ocupando as mesmas portas.

3. Baixe e descompacte o pacote

Baixe o arquivo geonode-installer-0.1.12.zip, disponibilizado junto a este post, ou acesse o repositório no GitHub, e transfira-o para o servidor. Em seguida:

unzip geonode-installer-0.1.12.zip
cd geonode-installer-0.1.12

4. Configure a instalação

Abra o arquivo de parâmetros:

nano geonode-install.env

Ele contém as seguintes opções:

GEONODE_PROJECT_REF=5.1.0
GEONODE_VERSION=5.1.0
DJANGO_BOOTSTRAP_VERSION=5.2

SYSTEM_USER=geonode
PROJECT_NAME=curso_geonode
INSTALL_DIR=/opt/geonode/curso_geonode

HOSTNAME=geonode.seudominio.com.br
ENABLE_HTTPS=true
LETSENCRYPT_EMAIL=contato@seudominio.com.br
SERVER_IPV4=

UPDATE_LAYERS_ENABLED=true
UPDATE_LAYERS_INTERVAL_HOURS=1
MIN_RAM_GB=14
MIN_DISK_GB=30

GEOSERVER_XMS=2G
GEOSERVER_XMX=4G
UWSGI_PROCESSES=4
CELERY_WORKERS=2
WAIT_SECONDS=1800
STARTUP_GRACE_SECONDS=600

O parâmetro STARTUP_GRACE_SECONDS define o período inicial de tolerância das verificações de saúde do Django e do GeoServer. Por padrão, são 600 segundos, ou seja, 10 minutos.

Isso não significa que o instalador ficará parado durante todo esse período: se os serviços estiverem saudáveis antes, ele continuará a instalação.

Em computadores mais lentos, esse valor pode ser aumentado. Por exemplo:

STARTUP_GRACE_SECONDS=1200

Nesse caso, a tolerância inicial será de 20 minutos.

O parâmetro WAIT_SECONDS define o prazo total de inicialização e verificação dos serviços após o build. Seu valor padrão é 1800 segundos, ou 30 minutos. Se necessário, ele também pode ser ajustado para instalações novas.

Para uma instalação semelhante à deste exemplo, os principais campos a alterar são:

Atenção à versão do Django: DJANGO_BOOTSTRAP_VERSION controla apenas o Django utilizado para gerar a estrutura inicial do projeto. A versão que executa dentro dos containers é determinada pelas dependências da aplicação.

Os parâmetros de versão permitem selecionar outras referências, mas isso não garante compatibilidade automática entre todas as combinações. A instalação apresentada neste post foi testada com o GeoNode 5.1.0.

5. Confira a configuração

Antes de instalar, execute:

python3 instalar.py --env geonode-install.env --check

Esse comando valida os parâmetros e consulta a resolução DNS do endereço informado, sem instalar pacotes.

Se você preencher SERVER_IPV4, ele também confere se esse IP aparece na resolução do domínio.

Essa checagem não testa a liberação das portas nem o acesso externo ao servidor.

6. Inicie a instalação

Com os parâmetros preenchidos, execute:

sudo bash instalar-geonode.sh --env geonode-install.env

Pronto! A partir desse ponto, o instalador executa as etapas automaticamente.

A primeira construção das imagens pode demorar, dependendo do processamento da máquina e da velocidade dos downloads. Mantenha a sessão SSH aberta enquanto acompanha a execução.

Embora o comando seja iniciado com sudo, o download do projeto e sua geração são executados com o usuário definido em SYSTEM_USER. As operações administrativas, como instalar pacotes e executar o Docker, continuam sob responsabilidade do root.

O usuário criado não recebe senha habilitada, acesso ao sudo ou inclusão automática no grupo Docker.

Durante a inicialização, o instalador acompanha o estado dos serviços e respeita a ordem de suas dependências. Isso é importante porque, na primeira execução, o Django ainda precisa preparar o banco de dados, carregar configurações e organizar os arquivos estáticos.

A partir da versão 0.1.12, o instalador tolera uma situação temporária de `unhealthy` enquanto aguarda a recuperação do serviço, dentro do prazo configurado em `WAIT_SECONDS`.

O progresso é informado no terminal. Um container aparecer como `Started` indica que ele foi iniciado, mas não necessariamente que já terminou sua preparação.

Ao final, o instalador também verifica a resposta HTTP ou HTTPS da aplicação.

Com HTTPS desativado, o serviço Let’s Encrypt fica em um perfil inativo e não é exigido na verificação final. Após a validação dos serviços, o instalador configura a tarefa de atualização automática de camadas, caso ela esteja habilitada.

7. E o certificado SSL?

Com esta configuração:

ENABLE_HTTPS=true

o instalador gera as URLs HTTPS e habilita o mecanismo de emissão de certificados Let’s Encrypt incluído no projeto Docker.

Assim, não é necessário executar separadamente a instalação do Certbot no host nem copiar manualmente os certificados para o Nginx.

O domínio precisa estar apontando corretamente para o servidor, e a porta 80 deve permanecer acessível para a validação e renovação do certificado. Se houver um registro DNS IPv6, ele também precisa estar correto.

8. Posso instalar em localhost ou acessar por IP?

Sim! Para usar HTTP localmente, configure:

HOSTNAME=localhost
ENABLE_HTTPS=false
LETSENCRYPT_EMAIL=
SERVER_IPV4=

Nesse caso, a solicitação de certificado fica desativada e o endereço será:

http://localhost/

Também é possível instalar em uma VM e acessar pelo IP da rede interna. Por exemplo:

HOSTNAME=192.168.186.142
ENABLE_HTTPS=false
LETSENCRYPT_EMAIL=
SERVER_IPV4=

Nesse caso, o endereço será, por exemplo:

http://192.168.186.142/

Use um IP fixo ou uma reserva DHCP e permita o acesso à porta TCP 80 na rede.

O instalador ajusta automaticamente os cookies de sessão e CSRF: em HTTP, eles não exigem HTTPS; em HTTPS, essa exigência permanece habilitada. A proteção CSRF continua ativa nos dois modos.

Lembre-se de que localhost representa a própria máquina. Para acessar uma VM de outro computador, utilize o IP ou domínio dessa VM. Os limites de memória e disco podem ser ajustados conforme o tópico 11.

9. Como acessar pela primeira vez?

Após a conclusão, abra no navegador o domínio, IP ou endereço local configurado.

O usuário inicial é:

admin

A senha é gerada automaticamente e fica no .env da aplicação. Para consultá-la, considerando o diretório deste exemplo:

sudo awk -F= '/^ADMIN_PASSWORD=/{print $2}' \
  /opt/geonode/curso_geonode/.env

Existem, portanto, dois arquivos com funções diferentes: geonode-install.env contém os parâmetros do instalador; o .env criado no diretório da aplicação contém as configurações e senhas dos serviços. Não compartilhe esse segundo arquivo.

10. Como acompanhar os serviços?

Para consultar os containers, informe explicitamente os caminhos da instalação:

sudo docker compose \
  --project-directory /opt/geonode/curso_geonode \
  --env-file /opt/geonode/curso_geonode/.env \
  -f /opt/geonode/curso_geonode/docker-compose.yml \
  ps -a

Para acompanhar o consumo de recursos:

sudo docker stats

Para consultar os logs:

sudo docker compose \
  --project-directory /opt/geonode/curso_geonode \
  --env-file /opt/geonode/curso_geonode/.env \
  -f /opt/geonode/curso_geonode/docker-compose.yml \
  logs --tail=100 django geoserver celery geonode letsencrypt

Esses comandos funcionam mesmo quando seu usuário não tem permissão para entrar na pasta do projeto. Ajuste os caminhos se tiver utilizado outro INSTALL_DIR.

Se a instalação for interrompida depois que o projeto já tiver sido gerado, é possível retomar a inicialização com:

sudo python3 instalar.py --env geonode-install.env --resume

Execute o comando na pasta do instalador, utilizando o arquivo de parâmetros original da instalação.

A opção `–resume` reaproveita as imagens já construídas, verifica os serviços, reaplica os ajustes de execução necessários e configura a tarefa de atualização de camadas ao final, caso esteja habilitada. Ela pode recriar containers para aplicar as configurações, preservando os volumes e as senhas existentes.

O instalador não realiza atualização automática da versão do GeoNode.

11. Como ajustar memória e disco para testes?

Os limites mínimos ficam no arquivo geonode-install.env:

MIN_RAM_GB=14
MIN_DISK_GB=30

Eles representam critérios de validação do instalador, não o consumo fixo do GeoNode. Para uma VM de testes com menos recursos, você pode reduzir esses valores e ajustar os serviços. Por exemplo:

MIN_RAM_GB=7
MIN_DISK_GB=20
GEOSERVER_XMS=512M
GEOSERVER_XMX=1G
UWSGI_PROCESSES=2
CELERY_WORKERS=1

Esse exemplo é um ponto de partida para testes, não uma garantia de capacidade para qualquer conjunto de dados. Também é possível desativar as checagens:

MIN_RAM_GB=0
MIN_DISK_GB=0

OBS: Desativar a validação não reduz o consumo dos serviços nem evita falta de memória ou disco. Configure os recursos conforme o uso previsto.

O comando –check valida o formato desses parâmetros. A comparação com a memória e o espaço disponíveis ocorre durante a instalação.

12. Como atualizar as camadas automaticamente?

Quando utilizar esta automação?

Esse recurso é útil principalmente quando você publica camadas diretamente no GeoServer, por exemplo, conectando um banco PostGIS externo, e deseja incorporá-las ou atualizar suas informações no catálogo do GeoNode.

As camadas enviadas e gerenciadas pelo próprio GeoNode já seguem seu fluxo integrado de publicação no GeoServer e não dependem dessa tarefa adicional.

A automação também não é responsável por atualizar os registros do banco: quando uma camada consulta uma tabela PostGIS, os dados são lidos pelo GeoServer diretamente dessa fonte. O updatelayers atua na integração das camadas com o catálogo do GeoNode.

O instalador incorpora essa automação baseada no procedimento apresentado no post: Atualizar camadas do GeoServer para o GeoNode automaticamente.

Para habilitar, configure:

UPDATE_LAYERS_ENABLED=true
UPDATE_LAYERS_INTERVAL_HOURS=6

Nesse exemplo, o workspace é verificado às 00h, 06h, 12h e 18h, conforme o horário do servidor. São aceitos intervalos de 1, 2, 3, 4, 6, 8, 12 ou 24 horas.

Na primeira execução, a tarefa executa updatelayers. Nas seguintes, compara um checksum dos arquivos do workspace geonode e executa o comando somente quando identifica alterações. O novo checksum é salvo apenas após uma atualização bem-sucedida, e um bloqueio evita execuções simultâneas.

Essa detecção acompanha arquivos do workspace; alterações apenas nos registros de uma tabela PostGIS não acionam a atualização.

Após a instalação, o agendamento pode ser alterado diretamente:

sudo nano /etc/cron.d/geonode-updatelayers-curso_geonode

Para consultar os registros:

sudo tail -n 100 \
  /var/log/geonode-updatelayers-curso_geonode.log

Os nomes desses arquivos acompanham o PROJECT_NAME.

Se o GeoNode já estiver instalado por uma versão compatível deste instalador, você pode configurar somente essa tarefa, usando os parâmetros originais da instalação:

sudo python3 instalar.py --env geonode-install.env \
  --configure-updatelayers

Esse comando não reconstrói as imagens nem reinicia a aplicação. Para remover o agendamento, configure UPDATE_LAYERS_ENABLED=false e execute novamente a mesma opção.

13. Como desinstalar e repetir a instalação?

Para facilitar os testes e atividades acadêmicas, o pacote também oferece comandos de desinstalação.

Execute a partir da pasta do instalador, fora do diretório da aplicação, utilizando o arquivo de parâmetros original da instalação.

Para visualizar o plano sem apagar nada:

sudo python3 instalar.py --env geonode-install.env \
  --uninstall-geonode --preview

Para remover o GeoNode:

sudo python3 instalar.py --env geonode-install.env \
  --uninstall-geonode

O script solicita o nome do projeto para confirmar e remove os containers, redes e volumes identificados do projeto, o diretório da aplicação e os componentes do updatelayers criados pelo instalador. A pasta pai, como /opt/geonode, também é removida se estiver vazia.

Banco de dados, camadas e arquivos enviados são apagados definitivamente, sem backup automático.

Nesse modo, o Docker, as imagens e os caches permanecem disponíveis. Por isso, uma nova instalação pode ser mais rápida.

Para solicitar também a remoção do Docker, preservando o bloqueio caso existam recursos de outros projetos:

sudo python3 instalar.py --env geonode-install.env \
  --uninstall-geonode --remove-docker

Limpeza completa da VM. Em uma VM descartável e exclusiva para testes, existe uma opção mais abrangente:

sudo python3 instalar.py --env geonode-install.env \
  --uninstall-geonode-completely

Será necessário digitar:

APAGAR TODO O DOCKER

Esse modo remove todos os containers, volumes, redes personalizadas, imagens e caches do Docker local, inclusive de outros projetos**, além da aplicação, dos componentes do seu updatelayers e dos pacotes Docker.

Para conferir o plano antes, acrescente –preview.

O modo completo atende à instalação Docker local padrão usada neste tutorial. Configurações como Docker remoto, armazenamento personalizado, Swarm ou namespaces de outros runtimes continuam bloqueadas.

O usuário do sistema, seu diretório pessoal e dependências gerais, como Python e Git, permanecem. Arquivos usados como bind mounts fora do diretório da aplicação também não são apagados. Portanto, essa limpeza não equivale a restaurar o sistema operacional.

Após concluir, para instalar novamente:

sudo bash instalar-geonode.sh --env geonode-install.env

14. Do servidor vazio ao GeoNode funcionando

Na instalação que motivou este post, utilizei uma máquina nova e o GeoNode 5.1.0. Ao final, o portal estava acessível pelo navegador com HTTPS funcionando.

Antes de utilizar o ambiente em um curso ou projeto, vale realizar os testes do seu fluxo: carregar camadas, abrir os dados, criar mapas e dashboards e conferir as permissões de acesso.

A automação reduz o trabalho repetitivo de preparar o ambiente. A validação com os dados e as atividades que serão utilizados continua sendo uma etapa importante.

Agora, na próxima instalação, o procedimento será bem mais curto: preencher o arquivo de configuração, executar o comando e acompanhar a criação do ambiente.

Até o próximo post!