Planned QGIS 3D features for 2027: 3D Gaussian Splatting, atmospheric scattering, 2D/3D keyframe animation and more. Crowdfunding open until 7 Dec 2026.

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.

On 11 November 2026, 18 of 28 AI plugins for QGIS are listed as compatible with QGIS 4. Mapflow and Deepness are not. The table, read from plugins.qgis.org.

Three ways to use Claude with QGIS: PyQGIS from a chat, Claude Desktop or Claude Code through QGIS MCP, or an agent inside QGIS. Setup, limits, which to pick.

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!

420 people on a mountain, and what stayed with me

Last week we brought the QGIS User Conference up to 2222 metres. Four hundred and twenty people from more than thirty countries and five continents got into a gondola in Laax and came up to Crap Sogn Gion, and for two days the Galaaxy was full of talks, six keynotes, twelve short workshops and a lot of coffee. It is the biggest conference that has ever happened on this mountain. A week later I am still a little bit amazed that it worked.

But the logistics are not what stayed with me.

We did not put digital sovereignty on the programme as a track, and still it was everywhere. Gerhard Andrey opened on Monday morning with Switzerland and open source, and from there it simply did not go away. For the people from public administrations in the room this is not philosophy. It is a line in a budget. They have data they must keep readable for thirty years, and tools whose conditions can change from one year to the next.

---

The conversation I keep thinking about was with a man who used to sell proprietary GIS licences for a living. At some point he did the maths on what his country, which is not a rich country, pays every year for software it will never own, and he decided the money would do more good building something his country actually controls. So he quit. Now he works on open national geospatial infrastructure. He did not tell me this like a big story. He told it like you tell someone you changed job.

That one stayed with me for the rest of the week.

Lorenz Hurni came after Andrey with maps as instruments of power, which is a good reminder for anyone who still thinks a basemap is something neutral. Anita Graser talked about AI in the QGIS ecosystem, Johannes Kanonier took us through fifteen years of QGIS at the State of Vorarlberg, and Ivan Minčík, Lova Andriarimalala and Tim Sutton made the least glamorous and most necessary point of the week, which is that somebody has to maintain the infrastructure and that somebody needs to be paid.

---

Here is the thing I keep coming back to. Open source does not give you sovereignty by itself. If you download free software and then nobody in your country can fix it, extend it or answer for it, you have only changed the shape of your dependency. What makes it real is what happened in those corridors, where the people who pay for the software and the people who write it were standing in the same line waiting for lunch.

---

And that is not a nice image, it is literally what happened. On Wednesday we ran ten full-day workshops down in the valley with 120 people, on point clouds, data processing, plugin development, automation, collaboration and field data infrastructure. Seventy-one people spent the QField Day walking around Laax in small groups collecting data. From Wednesday to Friday the 29th Contributor Meeting put developers, translators and documentation people around the same tables, and some of what was discussed on Monday was already a commit by Thursday. Three days from a problem on somebody’s desk to a fix in the code. That loop is the real product.

---

Contributors Meeting

---

And around all of that there was the other programme, the one that never appears as a session in any schedule. On Sunday, before the conference even started, ninety people walked the Ruinaulta and the Segnes plateau with guides. On Monday and Tuesday whoever took the first gondolas could do yoga at eight in the morning on a terrace at 2222 metres, or a short walk, or a QField crash course, or a crash course in Romansh. There were trail runs on Wednesday and Friday for the people who consider six or ten kilometres before breakfast a reasonable idea. And on Tuesday, when the conference was over, a few of us did not take the gondola back down. We flew. Launching off Crap Sogn Gion next to Régis Haubourg from the PSC was how a dream that had come true finally closed.

I am fairly sure more friendships came out of those hours than out of any session.

Thank you to HAPPY SURVEY Sagl, EBP Schweiz, Lutra Consulting, arx iT (GIS Consulting, Implementation and Training), OW Ocean Winds, the Province of South Holland and our other sponsors. Because of you a student and somebody from a cantonal office could sit in the same room. Thank you to Flims Laax Falera Management AG and the Weisse Arena Gruppe, who let us put a conference on top of a mountain without blinking. Thank you to the volunteers, scanning badges at seven in the morning, sending four hundred people to the right gondola and the right lunch table, carrying boxes up and down the mountain. To all the speakers, to my team at OPENGIS.ch, and to everybody at QGIS.org Association and QGIS User Group Switzerland who gave their free-time to this.

The most heartfelt thank-you goes to Anna Randegger, who kept the whole thing running while I was enjoying being on a stage and to my family, who put up with a whole year of me being half somewhere else even when I was sitting at the table with them. Thank you for the patience and for the support, I know it was not always easy.

Finally to everyone who was in the Hangar on Tuesday evening. I still get goosebumps and a knot in my throat when I think back to that standing ovation.

You made a year of work dissolve into tears of joy.

One last thing that makes me smile every time is that one of the next QGIS releases will be called LAAX. Over twenty million application starts every month, each one carrying the name of a village of fifteen hundred people in the Surselva where by now I know every single walkable path. Word of the father of a five month old

Vemo-nos em Portugal!

https://uc2026.qgis.org

https://download.opengis.ch/qgis-uc-2026.zip

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.