How to increase the reusability of research outputs?

Sure, Open Science has gained some momentum during the last decade. The Horizon Europe programme supports a number of open infrastructure projects, one of them being AquaINFRA, and the next call is already out. The German National Research Data Infrastructure (NFDI) has just announced that funding will continue until 2038. And let’s not forget the local initiatives in universities, such as Open Science Communities, reproducibility networks, and research data management centers. We also talked about 52°North’s efforts in our blog post on Open Science Capacity Building last week. Ultimately, however, we haven’t yet tapped into the full potential when it comes to publishing research outputs. Let’s say we collect some data and analyze it in an R script. We then implement functions for data pre-processing, analysis, and visualization. The configuration of the function parameters is buried in the code and the computational environment is specified on our local computer. We write a paper and send it to a journal or conference for peer review. At best, the submission requirements ask us to publish all materials in a repository and paste the DOI into the article. While we should appreciate that this is more than it was a few years ago, we also need to acknowledge that this is not the most efficient way to share high-value and easily reusable research outputs such as data and source code. Others need to download the materials, install the right version of the libraries, understand the code, find out how to change the parameters and so on and so forth. Many people tend to avoid these efforts and instead develop something new from scratch. So the challenge we want to address in this week’s blog post is:

How to increase the reusability of research outputs?

We addressed this issue in the EU-funded project AquaINFRA and finally came up with the so-called Data-to-Knowledge Package (D2K-Package) to tackle the following requirements:

• Verifying and reproducing the research results presented in an article
• Exploring the analysis and evaluating its relevance and reusability
• Reusing parts of the analysis in a custom script
• Understanding the role of each function in an analysis, which input parameters are needed, and how the functions are connected

The main objective of the D2K-Package 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 (see Fig. 1). As presented here, the D2K-Package has five components, but it is extensible. Simply speaking, it is a collection of links to digital research assets that together unlock the potential of open reproducible research and open FAIR data.

Figure 1: The Data-to-Knowledge Package with its five components Data, Toolbox, Virtual Lab, Web API Service, Computational Workflow

Let’s start with the first component: Data. Since we want to promote transparency and reusability, data should follow the FAIR principles (findable, accessible, interoperable, reusable) and be available under an open license, e.g., CC0 or alike. Ideally it is made available via a repository providing DOIs and an open data format, though binary formats are also fine if its format is released under an open specification.

Next, the analysis (e.g., written in R or Python) is made available in a Toolbox, which can be also stored in a repository in order to retrieve a DOI. The toolbox contains the entire analysis pipeline split into separate, containerized, and self-containing functions following the input-processing-output mechanism. Data and a parameter configuration (input) go into the function, the data is processed or analyzed (processing), and the result is the processed data, for instance, a table or figure (output). Hence, every function fulfills a certain task thus increasing reusability. We know this mechanism from R libraries or Python packages. The functions are designed such that the output of one function becomes the input of the next function and so forth until we reach the final result of the analysis. We will use this mechanism later to create a workflow. For the containerization of the analysis including the computational environment (versions of the libraries and the runtime), we make use of Docker. Data and Toolbox form the reproducible basis for the next products that aim at supporting the reuse of the materials and the process from data to knowledge generation!

The third component of the D2K-Package is the Computational Workflow using the Galaxy platform. It might be difficult to find out how the functions are connected, how to change the parameter configuration, or maybe you just want to click on run to see the results quickly. For that, we use Galaxy as a platform to make the entire analysis pipeline available as a readily shareable workflow (see Figure 2). Because concrete implementation details are abstracted away, users can utilize the workflow as an initial entry point for understanding the analysis, later reviewing the underlying specifics by accessing the virtual lab or toolbox. They can also run the workflow quickly using different parameter settings and compare the results. Finally, it is also possible to reuse single steps from different workflows and combine them in a new way, provided they are interoperable. The workflow file can be exported from Galaxy and stored in a repository to receive a DOI and increase its findability through metadata. That DOI can be added to the D2K-Package.

Figure 2: The workflow implemented in Galaxy.

We dive one level deeper and take a look at the fourth component, the Web API Service. You might want to reuse the functions in your own script. Copying all relevant code snippets and installing all relevant libraries in the right version might be a daunting task, so we make the toolbox functions available as OGC API Processes – a standardized web service for wrapping computational tasks into executable processes (learn more). Thus, every function can be called via an HTTP-request. This feature doesn’t come for free. We need a server running, for instance, pygeoapi, to make the web processes available. The amount of resources depends mainly on the expected size of the input and output datasets and the computation. A link to that service will also become part of the D2K-Package.

Last but not least, the Virtual Lab is the fifth component of the D2K-Package. Based on the computational environment defined in the toolbox, the virtual lab recreates that environment and provides it as a JupyterLab in the browser. No local installation of the runtime and dependencies is needed, just follow the URL and start working with the source code! We use the MyBinder web application to realize this feature, but please note that MyBinder is just a test instance with limited computational resources. An alternative to MyBinder is Replay, provided by EGI.

As mentioned above, the D2K-Package is a collection of links to the five (or more) components stored in a machine-readable and light-weight JSON-LD file. It can be easily parsed by websites and enriched with metadata. Moreover, the D2K-Package is extensible and not limited to the components described above. It could also contain a link to open educational resources, scientific articles, or webinars.

Of course, we haven’t just developed the theoretical concept of the D2K-Package, we have actively put it into practice. You can explore practical examples on our AquaINFRA Interaction Platform. Additionally, a comprehensive training video created by Sadra Matmir from the Bochum University of Applied Sciences is available online. Sadra also recently earned his Master’s degree; his thesis focused on Evaluating technology adoption by planners using a data-to-knowledge package for flood risk management. Congratulations Sadra! It goes without saying that we’re a little proud that the D2K-Package became an essential component in a thesis ;).

Figure 3: Existing Data-to-Knowledge Packages from the AquaINFRA project.

So, how can you get a D2K-Package for your analysis? We wrote a user guide explaining every single step, but we’re also ready to help and become part of your project. We can help you split your analysis script into separate and self-contained functions, create a virtual lab environment, and make the functions available as OGC API Processes. In addition, we’re also keen to help you put your work on the Galaxy platform in order to create readily shareable workflows. Don’t hesitate to get in touch with us!

See you next week.

References

1. Konkol M, Labuce A, Domisch S et al. Encouraging reusability of computational research through Data-to-Knowledge Packages – A hydrological use case. Open Research Europe 2025, 5:123 (https://doi.org/10.12688/openreseurope.20221.3)

A long-standing feature request in the QGIS repo has been an option for a ribbon-style GUI to replace the plethora of toolbars that usually characterize the top rows of any QGIS window.

A couple of months ago Eithan published an experimental “Ribbon Toolbar” plugin for QGIS 3 that implemented a first version of this idea.

I recently picked up the threads, ported the plugin to QGIS 4 and continued refining the structure of the tabs and ribbons, cleaning up truncated labels, design logical groups, and making icons for the most commonly used functions (based on my subjective experience, not objectively measured) large / more prominent:

The new updated version 0.5 is now available from the QGIS Plugin Repo for you to give it a spin.

Please note, however, that the code is NOT intended to be production-ready. Consider this a click-dummy that should facilitate discussion.

This version doesn’t implemented any way yet to customize the ribbons. Of course, this could be added at a later stage. In any case, the user can, of course, switch back to good old toolbars at any time.

Overall, the design is heavily inspired by LibreOffice’s ribbon theme option and targets new users / teaching situations. Like in LibreOffice, the idea would be to enable users to pick the type of UI style that they prefer — so there won’t be a on-size-fits-all i.e. fits-nobody situation.

One tricky part will certainly be the handling of plugins. Right now (as of version 0.5), installing a plugin that adds a new toolbar will, initially, add this toolbar and you can place it anywhere (e.g. below or right next to the ribbons):

Once you restart QGIS, the Ribbon Toolbar plugin will pick up on this new toolbar and will integrate it into the plugins ribbon:

Obviously, this behavior is not sustainable for users who have installed a lot of plugins. Therefore, we’ll need a clever way to allow users to customize the handling of plugin toolbars. Maybe just a small button to pop them out of the ribbon or attach them back.

In any case, if you have ideas and/or feedback for the ribbon design, we’d love to hear from you in the related thread.

If you have other design proposal that you want to share, I’d love to read about them. Please drop a link below.

Aujourd'hui j'ai mangé un homme. Cela faisait longtemps que je réfléchissais à réaliser cette expérimentation. Dans mon enfance, le dimanche matin, ma famille se mettait en ordre de marche dans la sérénité pour se rendre à la messe sur le coup des onze heures, accompagnée de la grand-mère, figure tutélaire dont le corps avait été marqué par la répétition des travaux agricoles et dont je revois encore le visage rougi par les braises de l'âtre du fournil alors qu'elle enduisait la galette de l'onction d'une généreuse noix de beurre. Arrivés devant l'église du village, les paroissiens franchissaient le seuil en pierre de taille pour s’assoir sur les bancs, dominés par un Christ en croix qui avant d'effrayer ces âmes paysannes séjournait au Parlement de Bretagne. Pendant une petite heure, la succession de lectures et chants conduisait l'esprit à se vider pour se préparer à la dégustation insipide du corps du Christ, cette hostie qui vous collait au palais pendant de longues minutes malgré les tentatives désespérées de la langue pour l'en décoller, tout en conservant une image de respectabilité extérieure.

Aujourd'hui j'ai mangé un homme. Plus précisément, un petit d'homme. Mes recherches dans la bibliothèque municipale de cette ville cossue de banlieue parisienne m'avaient conduit à déterminer que l'optimalité gustative devait être atteinte pour un enfant entre huit et dix ans, avant que les hormones masculinisantes ne couvrent de leur âpreté le subtil bouquet d'un être pur. Je l'avais choisi avec soin, alors que je l'observais depuis plusieurs semaines s'ébattre au milieu de ses camarades dans la cour de récréation, ses mollets délicats exposés à ma vue, promesses d'une succulence proche. Alors qu'il rentrait chez lui après une partie improvisée de football dans un bosquet dont la municipalité ne faisait tondre l'herbe que deux fois l'an, la lame trancha sa gorge. Je voulais voir l'expression de la terreur, de l'incompréhension et de l'apaisement final dans ses yeux, profiter de ces moments uniques que peu de mes congénère s'autorisent à savourer, et plus pragmatiquement relever le goût trop fade qu'une mort non consciente aurait immanquablement laissé. Je fus confronté au dilemme du choix de la pièce inaugurale de mon festin. Fallait-il que je plonge ma main dans sa poitrine pour me saisir de ce cœur encore brûlant, à la façon dont les natifs nord américains consommaient le bison fraîchement tué ? Trancher sa langue m'apparut comme le meilleur moyen de mettre fin à mes questionnements. Je pouvais désormais détacher le muscle du mollet de l'os, et le faire saisir sur les braises. Je revis une dernière fois ma grand-mère, et une larme coula sur ma joue.

Printing in MapStore and GeoNode still relies on an ageing integration with MapFish Print 2, built around a single map. Dashboards, GeoStories and multi-page documents cannot be printed properly.

This year we built a working prototype of a new Print Composer: design the page, preview it live, print it. Maps, dashboards, GeoStories and atlases with one page per feature, rendered by a new open-source print engine built on GeoTools. You can see it in action in the 5-minute demo.

Atlas mode: one layout, one page per feature. Watch the full demo on YouTube.

Now we want to bring it to production, and we have opened a crowdfunding campaign to do it. GeoSolutions funds part of the work with its own resources, and we are asking the organisations that use MapStore and GeoNode to fund the rest, the same way GeoServer 3 was funded. Everything is released as open source in MapStore and GeoNode.

How it works

• Goal €120,000. GeoSolutions funds part of the work with its own resources. Contributions start at €500, with no fixed levels.
• Nothing is charged now. Work starts progressively as funding is committed, and we send the invoice when the work starts.
• Every contributor gets early access to the builds and a channel to give feedback on the design.
• Already a GeoSolutions customer? Talk to your GeoSolutions contact and we will agree your contribution privately.
• Pledges close on 31 March 2027.

Features, roadmap, FAQ and the pledge form are on the campaign page: Print Composer for MapStore and GeoNode. Questions, or want a walkthrough? Write to info@geosolutionsgroup.com.

See also

• Print Composer crowdfunding campaign
• Print Composer demo on YouTube
• MapStore Corporate Page
• GeoNode Corporate Page

TorchGeo 0.10.1 Release Notes

This is a bugfix and maintenance release. While there are no new features or API changes, this release includes important bug fixes, documentation improvements, and enhancements across datasets, models, tasks, and testing.

Dependencies

• affine: remove direct dependency (#3953)
• prettier: 3.3+ is now required (#4088)
• types-rasterio: 1.5.1+ is now required (#3953, #4029)
• dependabot: group updates, run weekly, update indirect dependencies, and widen constraints (#4071, #4084, #4087)

Datasets

• ADVANCE: fix image dtype for quantile normalization (#4034)
• Cloud Cover: fix RGB plotting (#4035)
• PASTIS: correct fold indices in the dataset description (#4097)
• SpaceNet 4: fix training archive paths (#4072)
• Dataset splits: preserve CRS information in random_grid_cell_assignment (#4101)
• Downloads: use anonymous access when downloading public S3 data (#4052)
• Downloads: detect incomplete downloads using Content-Length (#4053)

Models

• Copernicus-FM: fix dtype handling (#3308)
• DEO: correct Swin window size and update checkpoint (#3994)
• FarSeg: support TorchGeo weights (#3995)
• OlmoEarth: correctly load pretrained weights (#4044)
• ResNet: fix weight metadata (#4031)

Tasks

• MoCo and SimCLR: fix augmentations for standardized inputs (#4055)

Documentation

• Document sampler regions of interest (#4000)
• Reorder the Embeddings tutorial after its prerequisites (#4012)
• Ignore missing Tokenizers API references (#4125)
• Add AI disclosure guidance to AGENTS.md (#4127)

Testing

• Run tests in parallel with pytest-xdist (#3300)
• Group memory-intensive tests and use bfloat16 on macOS (#4016)
• Reduce model and transform test input sizes (#3999)
• Increase MMFlood and BioMassters plotting branch coverage (#3990)
• Replace the ChesapeakeCVPR test fixture with synthetic data (#4026)
• Correct L8Biome, SpaceNet 6, and Substation test fixtures (#4024, #4039, #4040, #4041)
• Test the empty-cell branch of random_grid_cell_assignment (#4060)
• Restrict the OpenStreetMap warning test to the expected warning (#4069)
• Silence an expected SpatioTemporalSampler test warning (#4130)
• Add parameters to I/O benchmark test configurations (#4126)
• Disable caching during continuous deployment (#4085)

Contributors

This release is made possible thanks to the following contributors:

• @adamjstewart
• @borchertn
• @calebrob6
• @evgeniialappo
• @GuiBarradas
• @isaaccorley
• @modaribrahim
• @piperwolters
• @quinnarnold
• @wolfilip
• @yichiac

Full Changelog: v0.10.0...v0.10.1

This post provides a recap of the security advisories published over the summer of 2026, covering recently published Common Vulnerability and Exploits (CVE), along with a supply chain advisory affecting the GeoServer project. This activity has resulted in an update to our security policy covering AI-assisted vulnerability reports.

If you are responsible for a GeoServer instance, the short version is: please update to GeoServer 3.0.1, GeoServer 2.28.5, or GeoServer 2.27.6.

The GeoServer project follows a coordinated vulnerability disclosure policy: vulnerabilities are fixed for both stable and maintenance releases, prior to CVE details being published. The goal is to give everyone an opportunity to update prior to public disclosure.

August zero-day

In August GeoServer experienced a zero-day vulnerability (an exploit in the wild with no known fix). The problem had already been reported privately by several independent researchers, and a fix scheduled for the GeoServer 3.0.1 release.

The zero-day situation arose because a third party (unconnected to the project or to the researchers who had reported the issue) disclosed the vulnerability publicly on social media. The effect was immediately evident, with scans for this vulnerability detected within hours of the public social media post.

The speed of this response was remarkable and resulted in news coverage and an urgent call to update on our user forum. We would like to thank the reporter Ravie Lakshmanan who first notified project leadership via the Open Source Geospatial Foundation.

GeoServer 3.0.1, GeoServer 2.28.5, and GeoServer 2.27.6:

• CVE-2026-76904 Unauthenticated PostGIS SQL injection in the jsonArrayContains filter function (Critical)

  This releases addresses the GeoTools CVE-2026-76904 SQL Injection vulnerability that: requires a Text or JSON column; affects PostGIS 12 and up.

This experience reaffirms the importance of following the coordinated vulnerability disclosure policy, and asking everyone to update when new releases are made available.

Previously published CVEs

The following CVEs were published on June 11, 2026, alongside the GeoServer 3.0.0 release.

GeoServer 2.27.3, and 2.26.4:

• CVE-2025-58175 Server-Side Request Forgery (SSRF) Vulnerability in XML entity resolution (Medium)

• CVE-2025-52465 Arbitrary file write vulnerability in Master Password Dump Page (High)

GeoServer 2.27.0:

• CVE-2024-45747 Server-Side Template Injection (SSTI) vulnerability in processing FreeMarker templates (High)

• CVE-2025-27511 JNDI Vulnerability in DB2 Store Connection (High)

Supply chain advisory

Supply chain advisories have the possibility to affect the integrity of the software you download:

• GHSA-cpc9-c4h3-2jwx GitHub Actions workflow in GeoServer Cloud (April 2026)

  A security researcher Aviv Donenfeld reported an issue in a geoserver-cloud repo GitHub actions workflow.

  While GeoServer uses GitHub for source code management and quality assurance workflows, such workflows are not used to build or publish download artifacts. A review was made to confirm all pull requests during the time of vulnerability were by trusted parties, secrets were rotated, and the workflow issue was addressed.

This was first time the project has worked with an infrastructure advisory like this. We have marked the advisory as “geoserver/geoserver-cloud (GitHub Actions)” as it does not correspond with a release of GeoServer, and as a result does not qualify for a CVE number.

It is important to note that no GeoServer releases were affected. GeoServer releases are made using a Jenkins build server publishing artifacts to both SourceForge and OSGeo infrastructure.

AI-assisted vulnerability reports

Like many other software projects, we are experiencing a wave of vulnerability reports generated with AI assistance.

We have both established a general AI Policy, and updated our Security Policy, to acknowledge the use of these tools and provide guidance:

• The human reporter is responsible for verifying the issue is real and reproducible before submitting.
• Reports must include a working reproduction (code, request, or config) against a supported GeoServer series, not just a plausible-sounding description.
• Reports that turn out to be hallucinated or unverifiable will be closed without further engagement.

Especially with AI reports, which are often very verbose, being on hand to clarify is greatly appreciated.

These reports can take quite some time to review, or even determine when such reports are duplicates. It also helps if you are in a position to test and verify fixes as they are addressed. Anything we can do to make the work of the geoserver-security team easier will be of assistance.

Q: How can I help?

If your organization depends on GeoServer, please consider sponsoring the project, or have your staff directly participate in geoserver-security work.

We are also looking to establish project membership for public institutions facing restrictions on sponsorship and participation.

Q: How often should I upgrade GeoServer?

GeoServer operates with a time-boxed release cycle, maintaining “stable” and “maintenance” releases, over the course of a year.

• GeoServer 3.0.x is the current stable release
• GeoServer 2.28.x is the current maintenance release

Please upgrade to a supported release at least once a year to continue receiving security fixes. See the Upgrading existing versions (User Guide) for guidance.

Q: How do I report a vulnerability?

Please see our security policy for instructions on reporting vulnerabilities privately using GitHub security advisories.

For most of GIS history, the workflow has been the same: find a dataset, download it, unzip it, load it into your desktop software, and then work with it locally. It is a process that has served us well for decades, but it breaks down the moment your datasets are measured in terabytes, your users are spread across continents, and your analysis needs to be reproducible and collaborative.

A quiet revolution has been building in the geospatial community over the past few years. It does not have a single flagship product or a dominant vendor behind it. Instead, it is a collection of open specifications, open source tools, and a shift in thinking about how geospatial data should live in the world. This movement is called cloud-native geospatial, and it is changing the game.

For most of its history, QGIS has been a desktop application. You installed it on your machine, loaded your data, ran your analyses, and produced your maps, all within the four walls of a single window. The browser was a separate universe. If you wanted your maps on the web, you exported them as images or handed them off to a completely different stack.

That boundary is dissolving. Over the past decade, QGIS has been quietly expanding beyond the desktop, first through server-side rendering, then through web standards, and now through WebAssembly. The line between “QGIS” and “the browser” is blurring, and the implications for how we build geospatial applications are significant.

Thanks to Zachary DeBottis

what3words’ 2025 accounts

I am fascinated by what3words, it defies the laws of finance that apply to most businesses and shows how little my old fashioned understanding of business models is relevant in the modern tech economy.

The idea of a verbal description of a 3m square as a proxy for coordinates might have sounded like a good idea a decade ago but adoption seems to have been slow and new technology may be about to overtake the idea.

The 2025 accounts just landed at Companies House, as previously (and here and here) here is this year’s summary.

Headline numbers

The loss has come down a long way from the £31.5m of 2022, a year ago the story was all about progress: turnover had more than doubled from £1m to £2.1m, while headcount fell from 128 to 92. 2025 undoes much of that revenue progress in one go.

Ups and downs

• Lost one major customer which almost halved revenue. There is no reassuring explanation of why a massive customer is no longer using the service.
• UK revenue static at £200k
• Operating loss reduced as they continued to cut admin costs but they are now spending £12.30 per £ of revenue compared with £7.56 in 2024 because of the lost customer.
• Cash and term deposits are almost halved and are less than a year’s losses at current burn rate.
• Overall staff numbers are down slightly with a shift to overseas subsidiaries

Strategy: diversify.monetise.hope

The management summary says that their key focus is diversification across a broader customer base and more revenue streams. These include their Pro product, increased API subscriptions and Swiftcomplete (the address validation business bought at the end of 2024). They report positive results in the current year in revenue streams apart from the big customer loss but the base is so small it is difficult to know whether this will be significant in the coming years.

The Pro product is priced at £29.99 per year (more if you pay monthly) which seems a lot for a product you may not use too frequently, perhaps there are some use cases that I have not understood. They will need hundreds of thousands of Pro users to move the needle on revenues and staunch their operating losses, I suppose it is my lack of vision that prevents me from recognising the appeal.

There is also a risk that the push to monetise free users will have a negative impact on the brand. Every business with a free tier wants to diversify and monetise a larger proportion of its free users, evidence to date from the UK, w3w’s home market, suggests that they have a way to go in this strategy.

A going concern?

With more cost cutting and a moderate increase in revenue there may be a path to break even over the next 3-4 years but that will probably require further investment either from existing investors, whose faith in the business model may have been exhausted, or more rounds of crowd funding, something I have never understood. The most recent crowdfund was at a valuation of £50m, down by 80% on the peak a few years ago. I wonder if the time for a chunky exit to a megacorp has passed?

Whither w3w in an age of location aware AI?

The original use case was that three memorable words was an easier way to communicate location between humans, as we get more used to talking with AI chatbots do we still need three word locations? Location aware AI models can already work out the likely entrance to a building and that kind of capability is only going to become more pervasive in the big location platforms (how will Google further integrate Gemini into its Maps application?).

My take

13 years in, w3w is back to £1m of revenues after burning through over £150m of investors funds. If there was a use case when they started it hasn’t led the company to a sustainable business model yet and it seems unlikely to me that it will eventually. I wonder what investors thought they were buying into with w3w and how they are feeling now?

<p>The post ///rocky.year.survived – for how long? first appeared on KnowWhere.</p>

From November 3 to 5, 2026, GeoSolutions will be at Smart City Expo World Congress in Barcelona, Fira Gran Via, as part of the Italian Pavilion organised by ITA, the Italian Trade Agency. You will find Eleonora Fontana and the GeoSolutions team in Hall 2, Stand C161. If you are planning to attend and want to talk about geoportals, urban digital twins or open data infrastructure for your city, write to sales@geosolutionsgroup.com and we will book a slot at the stand.

From inspiration to implementation

The theme of this year's congress is "From Inspiration to Implementation", and it fits well with what we hear from cities every day. Most administrations already have the data: cadastre, urban planning, mobility, energy, civil protection, 3D surveys. The hard part is not collecting it. The hard part is publishing it through standard services, integrating it with the systems already in place, giving citizens and departments a usable interface, and keeping all of this running for years without depending on a single vendor.

This is the ground we work on with GeoServer and MapStore, two open source platforms that we develop, maintain and support, and that are in production in cities across Europe and beyond.

Urban digital twins and geoportals for cities, built on open source. Meet us in Hall 2, Stand C161.

Cities that are already doing it

A few examples we can share publicly.

Rennes Métropole led the project that made MapStore the viewer of the geOrchestra spatial data infrastructure, together with Communauté d'agglomération du Puy-en-Velay, Région Hauts-de-France, Région Grand-Est and CRAIG. The work brought application contexts, map catalogues and map templates into MapStore, plus dedicated tools for cadastral consultation and urban planning. It is in production in Rennes and the features funded by these organisations are now part of the public MapStore release, available to every city that adopts it.

Rennes Métropole: MapStore as the viewer of the geOrchestra portal, with the cadastre tools built for the project.

The City of Genova runs a hybrid geoportal where MapStore and a clustered GeoServer, with GeoFence for fine grained access control and GeoWebCache for tile caching, sit next to the existing Oracle and Active Directory infrastructure. Citizens log in with SPID, the Italian digital identity. The platform publishes civil protection data, acoustic zoning, cadastral layers and energy efficiency maps, and offers dashboards for snow emergencies, tourism, accessibility and energy. It has handled real time publication of election results on top of the usual traffic. Genova is now moving towards an urban digital twin with the same stack, bringing BIM and IFC models into the 3D city view directly in the browser.

The City of Genova geoportal: maps, dashboards and geostories published on MapStore.

Genova in 3D: waterfront project models placed on the city mesh, in the browser.

For the City of Florence we built a digital twin of the UNESCO city centre, with 3D buildings and features extracted from LiDAR such as roofs and trees. The processing pipeline is our open source Digital Twin Toolbox, which turns point clouds and meshes into OGC 3D Tiles that MapStore streams to any browser, no plugin required.

Bird's-eye view of the Florence UNESCO city centre digital twin with 3D buildings and LiDAR extracted features (roofs, trees).

Beyond our own projects, GeoServer is the engine behind the open geographic data of cities like Helsinki and Vienna, which publish their datasets as WMS and WFS services for developers and citizens. If you want to see what MapStore does with 3D city data, the Genoa city views and the Milan underground demos are online.

The stack

GeoServer publishes raster and vector data through OGC and INSPIRE compliant services, from a single municipal dataset to national infrastructures, with GeoFence for security down to the attribute level and GeoWebCache for fast tiles. MapStore is the web front end: interactive maps, dashboards, 3D views and geostories in one framework, mobile first, embeddable in any city portal. GeoNode adds a catalogue and a data management layer when a city wants a full open data platform. All three are open source and we sit on their steering committees.

Digital sovereignty, in practice

Digital sovereignty is on the agenda of many administrations, and for good reason. For a city it comes down to a few practical questions. Who owns the code that runs your data? Where does the data live? Can you move to another provider, or run it yourself, without rewriting everything? With open source platforms and open standards the answers are simple. The code is public, the services speak OGC, the deployment runs on premises or on the cloud the city chooses, and the know-how stays with the administration. No licence fees that grow with usage and no lock-in.

Software is not enough

Meet us in Barcelona

Hall 2, Stand C161, Italian Pavilion, November 3 to 5. Eleonora and the team will be there for the whole event. To fix a meeting in advance, write to sales@geosolutionsgroup.com.

As always, call on us, the core code developers and experts on:

• GeoServer, the leading open source server to publish geospatial data at scale.
• MapStore, our modular open source WebGIS product to create and publish geospatial data as maps, dashboards and geo stories.
• GeoNode, the open source GIS platform to create a complete and interoperable spatial data infrastructure.

See also

• Smart City Expo World Congress 2026
• MapStore Corporate Page
• GeoServer Corporate Page
• City of Genova case study
• MapStore for geOrchestra, Rennes Métropole
• Digital Twin Toolbox

After I had finished categorising all the posts on Mappery (see this post) it occurred to me that a similar strategy might be used for geocoding ungeocoded posts. If you have been following my vibe coding posts you will know that Arnaud and I built a geocoding and mapping plugin for our WordPress site that we are about to publish.

When we built the plugin, I salvaged the geocodes from the old plugin that we had disabled but that left nearly 1,000 posts ungeocoded (either posts from before the first plugin was installed or posts that had no meaningful location). I decided to try the same approach of parsing the posts’ text for a location reference and then falling back to image assessment to see if the image suggested a location, once I had some location references extracted from the posts I planned to fire these at OpenCage to get coordinates.

Here is a summary of the approach:

• I asked Claude to read through the text of every one of those ~1,000 posts to work out where the map was actually spotted — a museum, a street, a town, sometimes just a country.
• Where a post’s map showed a different place from where it was found e.g. a bottle of Mauritius rum photographed in a UK garden, noted that as a second, separate location.
• Sent each place to the OpenCage geocoder to turn it into coordinates.
• I learned the hard way that OpenCage’s “confidence” score measures how small an area it matched, not whether it got the right place — a wrong result for “British Library” can score higher than the correct one. I thought I understood this but I still got a lot of wrong results on the first pass.
• As i identified some errors, Claude added a layer of sanity-checking: does the result’s name actually match what we asked for, is it a sensible type of place (a village isn’t a building), is it near where we’d expect.
• I excluded pins that would be nearly useless for exploring the map: whole countries, huge regions, and mega-cities like London or Paris, unless the text included a more specific spot within them.
• Claude built a couple of small review tools to go through the results — one to check anything flagged as uncertain, with a search box to look places up by hand when the automatic match was wrong or missing.
• The final stage was for Claude to prepare a SQL import of the extra geocodes, which felt scary (I backed up the WordPress database twice before I was comfortable running the updates).

The final result was 483 posts geocoded with 494 pins (a few have 2 geocodes, where it was found and what the map is focussed on – the plugin allows multiple coordinates per post). 395 posts still have no pin, usually because there’s genuinely no place mentioned — a t-shirt, a bauble, a meme. 118 places were left ungeocoded for now because they were only known at country/region/big-city level, that leaves a project for another day, if we can pin down anything more specific about the posts.

We now have 80% of our posts geocoded and appearing on our maps which feels like a pretty good result.

If you have a lot of text that you want to extract locations from and geocode, this approach may be worth considering. The results are not street or building level but they work for my use case. It worked well on 1000 posts, it might scale up to 5,000, beyond that you would need to be quite trusting of the AI and give up on any high level of manual checking.

<p>The post Geocoding 1000 posts on WordPress – 50% success first appeared on KnowWhere.</p>

Our DeepSeek credit spend has yielded thus far:

• The MapGuide Windows installer successfully migrated over from Wix 3.x to Wix 6.x
• Added missing support for rendering MultiGeometry/GeometryCollection instances in MapGuide
• Added missing support for evaluating spatial predicates involving MultiGeometry instances at the FDO level across various FDO providers. This means the MultiGeometry/GeometryCollections that MapGuide can now render, can now also be selected properly!
• Fixed a 12-year old bug where we couldn't enumerate layers of a DWF drawing source in MapGuide on Linux (it was another 64-bit Linux portability bug!)
• Fixed an OGR provider bug where stale CPL errors were not cleared upon constructing and throwing an FDO exception, resulting in these stale CPL errors repeating the same FDO exceptions being thrown, even if the underlying OGR API calls no longer error.
• A solid action plan on a 14-year old bug with striped raster images. This one has lots of moving parts around testing and/or test data which I still need to figure out, so no actual fix has been prescribed yet.

Prezado leitor,

O intuito do post de hoje é que você aprenda como integrar o GeoServer a um servidor LDAP, autenticar usuários, transformar grupos LDAP em roles e preparar essas roles para utilização nas regras de segurança do GeoServer. O laboratório utiliza GeoServer 3, OpenLDAP e Docker Compose.

Em instalações simples do GeoServer é comum administrar usuários diretamente pela interface da aplicação. Esse modelo funciona bem em laboratórios, treinamentos e ambientes pequenos. Em ambientes corporativos, porém, normalmente a organização já possui uma infraestrutura centralizada de identidade. É nesse cenário que entra o LDAP (Lightweight Directory Access Protocol).

Em vez de manter usuários e senhas dentro do próprio GeoServer, podemos integrá-lo a um diretório LDAP e utilizar os usuários e grupos existentes na organização. A arquitetura passa a ser semelhante a esta:

Uma forma simples de entender essa integração é: O LDAP autentica. O GeoServer autoriza.

O GeoServer possui suporte nativo à autenticação LDAP através de LDAP Bind. Também pode transformar os grupos encontrados no LDAP em roles utilizadas posteriormente nas regras de segurança do GeoServer. A ideia é criar três usuários com diferentes níveis de acesso e, posteriormente, utilizar os grupos LDAP para controlar o acesso dentro do GeoServer.

A versão 3.0.1 do GeoServer também trouxe a melhoria da GEOS-12095 relacionada à conversão entre o nome do membro do grupo LDAP e o nome utilizado na pesquisa de usuários.

1. Estrutura do Laboratório

Neste artigo vou utilizar o GeoServer 3.0.1, que no momento da publicação deste texto é a versão estável recomendada para produção. A versão 3.0.1 também trouxe uma melhoria específica relacionada à conversão de usuários LDAP (GEOS-12095 relacionada à conversão entre o nome do membro do grupo LDAP e o nome utilizado na pesquisa de usuários), além de correções de segurança importantes.

2. Criando o Docker Compose

Neste artigo, eu vou considerar que você já instalou o Docker no seu ambiente, então vamos criar agora o arquivo docker-compose.yml com o seguinte conteúdo:

services:
  geoserver:
    image: docker.osgeo.org/geoserver:3.0.1
    container_name: geoserver
    ports:
      - "8080:8080"
    environment:
      PROXY_BASE_URL: http://localhost:8080/geoserver
      GEOSERVER_ADMIN_USER: admin
      GEOSERVER_ADMIN_PASSWORD: geoserver
    volumes:
      - geoserver_data:/opt/geoserver_data
    depends_on:
      openldap:
        condition: service_started

  openldap:
    image: osixia/openldap:1.5.0
    container_name: openldap
    environment:
      LDAP_ORGANISATION: "Geocursos Lab"
      LDAP_DOMAIN: "geocursos.lab"
      LDAP_ADMIN_PASSWORD: "adminldap"
      LDAP_TLS: "false"
    ports:
      - "389:389"
    volumes:
      - ./ldap/10-geoserver-acl.ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom/10-geoserver-acl.ldif:ro
      - ./ldap/20-geoserver-users.ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom/20-geoserver-users.ldif:ro
    command: ["--copy-service"]

volumes:
  geoserver_data:

A imagem oficial Docker do GeoServer é mantida pelo próprio projeto e publicada no repositório OSGeo. Também estamos expondo a porta 389 apenas para facilitar nossos testes locais. Em produção, não faria sentido necessariamente expor o LDAP dessa forma.

3. Criando nossa estrutura LDAP

Agora precisamos criar os usuários e grupos que serão utilizados. Vamos então criar o arquivo ldap/20-geoserver-users.ldif com o seguinte conteúdo:

dn: ou=people,dc=geocursos,dc=lab
objectClass: organizationalUnit
ou: people


dn: ou=groups,dc=geocursos,dc=lab
objectClass: organizationalUnit
ou: groups


dn: uid=alice,ou=people,dc=geocursos,dc=lab
objectClass: inetOrgPerson
cn: Alice Publico
sn: Publico
uid: alice
mail: alice@geocursos.lab
userPassword: alice123


dn: uid=bob,ou=people,dc=geocursos,dc=lab
objectClass: inetOrgPerson
cn: Bob Restrito
sn: Restrito
uid: bob
mail: bob@geocursos.lab
userPassword: bob123


dn: uid=carol,ou=people,dc=geocursos,dc=lab
objectClass: inetOrgPerson
cn: Carol Admin
sn: Admin
uid: carol
mail: carol@geocursos.lab
userPassword: carol123


dn: cn=geoserver_publico,ou=groups,dc=geocursos,dc=lab
objectClass: groupOfNames
cn: geoserver_publico
member: uid=alice,ou=people,dc=geocursos,dc=lab
member: uid=bob,ou=people,dc=geocursos,dc=lab
member: uid=carol,ou=people,dc=geocursos,dc=lab


dn: cn=geoserver_restrito,ou=groups,dc=geocursos,dc=lab
objectClass: groupOfNames
cn: geoserver_restrito
member: uid=bob,ou=people,dc=geocursos,dc=lab
member: uid=carol,ou=people,dc=geocursos,dc=lab


dn: cn=geoserver_admin,ou=groups,dc=geocursos,dc=lab
objectClass: groupOfNames
cn: geoserver_admin
member: uid=carol,ou=people,dc=geocursos,dc=lab

E agora um segundo arquivo chamado 10-geoserver-acl.ldif com o seguinte conteúdo:

dn: olcDatabase={1}{{ LDAP_BACKEND }},cn=config
changetype: modify
add: olcAccess
olcAccess: {2}to dn.subtree="ou=groups,{{ LDAP_BASE_DN }}" by dn.exact="cn=admin,{{ LDAP_BASE_DN }}" write by users read by * none

Teremos portanto:

Observe que os grupos formam uma espécie de progressão de permissões:

As senhas utilizadas no laboratório são propositalmente simples. Elas não devem ser reutilizadas fora desse ambiente didático.

4. Iniciando os containers

Para subir os containers digite:

docker compose up -d

Depois confira se eles realmente subiram:

docker compose ps

Então acesse: http://localhost:8080/geoserver

Para o laboratório podemos utilizar inicialmente as credenciais padrão.

5. Validando o LDAP antes de envolver o GeoServer

Uma boa prática de troubleshooting é testar primeiro o LDAP isoladamente. Podemos, por exemplo, listar nossos usuários:

docker exec -it openldap \
ldapsearch \
-x \
-H ldap://localhost:389 \
-D "cn=admin,dc=geocursos,dc=lab" \
-w adminldap \
-b "ou=people,dc=geocursos,dc=lab" \
"(objectClass=inetOrgPerson)" \
uid cn

Devemos encontrar as informações dos nossos 3 usuários (alice, bob e carol). Agora pergunte ao LDAP a quais grupos o Bob pertence:

docker exec -it openldap \
ldapsearch \
-x \
-H ldap://localhost:389 \
-D "uid=bob,ou=people,dc=geocursos,dc=lab" \
-w bob123 \
-b "ou=groups,dc=geocursos,dc=lab" \
"(member=uid=bob,ou=people,dc=geocursos,dc=lab)" \
cn

O resultado esperado é: geoserver_publico e geoserver_restrito. Esse teste é importante porque elimina várias dúvidas antes mesmo de configurarmos o GeoServer. Se o LDAP não consegue localizar o usuário ou seus grupos, o problema ainda não está no GeoServer.

6. Configurando a autenticação LDAP no GeoServer

Agora entre no GeoServer como administrador e acesse: Security -> Authentication -> Authentication Providers -> Add new -> LDAP

Nessa mesma tela você configura tanto a autenticação do usuário quanto, opcionalmente, a descoberta dos grupos LDAP usados para gerar roles.

O GeoServer atual permite informar diretamente a URL LDAP, o padrão do DN do usuário e a estratégia utilizada para procurar os grupos desse usuário. Para nosso laboratório utilize:

Name
ldap-geocursos

Server URL
ldap://openldap:389/dc=geocursos,dc=lab

User DN pattern
uid={0},ou=people

Use LDAP groups for authorization:
✓

Bind before group search:
✓

Group search base:
ou=groups

Group search filter:
member={0}

Na própria tela do LDAP Authentication Provider existe a área de teste. Então digite o username bob e a senha bob123, e clique no botão Test Connection, para verificar se a integração entre o LDAP e o GeoServer está funcional.

7. Não esqueça a Authentication Provider Chain

Criar o provider não significa necessariamente que ele esteja participando da autenticação. Volte para Security -> Authentication o localize Provider Chain e adicione ldap-geocursos aos providers selecionados.

Mantenha também o provider loca padrão do GeoServer (GeoServer Local). Essa estratégia mantém, inclusive, uma conta administrativa local para contingência.

Em ambientes corporativos gosto de pensar nela como uma conta break glass: o LDAP pode estar indisponível e ainda precisamos ter uma forma extremamente controlada de administrar o GeoServer.

Após esse passo, faça logout do GeoServer e e tente acessar com o username bob e a senha bob123. O resultado esperado é que você consiga logar com o usuário bob.

8. Do grupo LDAP para a Role do GeoServer

Aqui aparece uma das partes mais interessantes dessa integração.

Quando o GeoServer utiliza grupos LDAP para autorização, ele transforma automaticamente o nome do grupo em uma role: Nome do grupo -> ROLE_ grupo

Esse comportamento é documentado oficialmente pelo GeoServer. Portanto nossos grupos se tornam:

geoserver_publico -> ROLE_GEOSERVER_PUBLICO
geoserver_restrito -> ROLE_GEOSERVER_RESTRITO
geoserver_admin -> ROLE_GEOSERVER_ADMIN

Isso significa que Bob, por exemplo, será autenticado com: ROLE_GEOSERVER_PUBLICO e ROLE_GEOSERVER_RESTRITO.

9. LDAP sozinho não protege nenhuma camada

Esse talvez seja o ponto mais importante deste artigo. Configurar LDAP responde: Quem é o usuário? Mas ainda precisamos responder: O que esse usuário pode acessar?

O GeoServer utiliza roles para controlar acesso às camadas. E existe um detalhe importante: a configuração padrão de Layer Security permite leitura anônima das camadas.

Portanto simplesmente configurar LDAP não torna automaticamente seus dados privados. A arquitetura completa é:

10. LDAP Role Service: quando ele entra? (opcional)

Até aqui utilizamos uma abordagem bastante direta, porém o GeoServer também possui um recurso chamado LDAP Role Service, que é um serviço somente leitura que transforma grupos LDAP em roles. Assim como no provider de autenticação, o nome do grupo é convertido para maiúsculas e recebe o prefixo ROLE_.

Uma configuração para nosso diretório poderia utilizar:

Server URL:
ldap://openldap:389/dc=geocursos,dc=lab

Group search base:
ou=groups

Group user membership search filter:
member=uid={0},ou=people,dc=geocursos,dc=lab

All groups search filter:
cn=*

Authenticate to extract roles:
✓

Username:
cn=admin,dc=geocursos,dc=lab

Password:
adminldap

O caminho na interface é: Security -> Users, Groups, Roles -> Role Services -> Add new -> LDAP

A vantagem desse modelo aparece principalmente quando queremos que as roles LDAP façam parte explicitamente do sistema de roles do GeoServer e estejam disponíveis nas telas de configuração de acesso. O tutorial oficial do GeoServer apresenta exatamente essa segunda etapa.

Para um primeiro laboratório, entretanto, o mapeamento realizado pelo próprio LDAP Authentication Provider já é suficiente para entender o conceito.

Neste laboratório utilizamos o administrador do OpenLDAP apenas para simplificar a demonstração. Em produção, utilize uma conta de serviço somente leitura, com apenas as permissões necessárias para consultar usuários e grupos.

11. O desenho final

Depois de toda a configuração, nosso ambiente fica conceitualmente assim:

Esse é o verdadeiro ganho da integração.

O GeoServer deixa de ser responsável por manter uma base paralela de usuários e passa a trabalhar sobre a estrutura de identidade que já existe na organização.

12. Cuidados para produção

O laboratório utiliza deliberadamente configurações simplificadas. Em produção eu revisaria pelo menos estes pontos:

• Não utilizar LDAP sem criptografia em redes não confiáveis. O GeoServer suporta tanto ldaps://, normalmente na porta 636, quanto STARTTLS sobre LDAP. Há uma particularidade: a documentação informa que o uso de STARTTLS impede o pooling de conexões LDAP, criando uma nova conexão por autenticação e podendo afetar desempenho.
• Não utilizar as senhas deste laboratório, nem admin/geoserver. A imagem Docker oficial também recomenda substituir as credenciais padrão.
• Manter uma conta administrativa local de contingência, fortemente protegida, em vez de tornar a administração completamente dependente da disponibilidade do LDAP.
• Evitar mapear grupos de negócio acidentalmente para ROLE_ADMINISTRATOR. Essa role possui acesso administrativo completo ao GeoServer.
• Revisar explicitamente Layer Security, Service Security e REST Security. Integrar LDAP não torna automaticamente as camadas privadas; por padrão, a leitura de layers é aberta e a configuração de Service Security começa sem regras.
• Em containers, guardar credenciais de bind em Secrets, não diretamente no docker-compose.yml, Deployment ou repositório Git. O usuário usado apenas para pesquisa de grupos deve possuir o mínimo de permissões necessárias.
• Não expor o LDAP sem necessidade. Se GeoServer e LDAP estiverem em uma mesma infraestrutura privada, apenas a comunicação necessária entre eles deve ser permitida.

13. Conclusão

Integrar GeoServer e LDAP não é apenas substituir uma tela de login. Com a combinação de LDAP + grupos + roles + regras de segurança, é possível integrar o GeoServer a uma infraestrutura corporativa de identidade sem precisar manter manualmente usuários e permissões duplicados dentro da aplicação.

E isso torna a administração especialmente interessante em ambientes com vários usuários, diferentes perfis de acesso e dados que não podem simplesmente ficar disponíveis de forma anônima.

Referências oficiais:

GeoServer — Authentication with LDAP
GeoServer — Authentication Providers / LDAP
GeoServer — Layer Security
GeoServer — Service Security
GeoServer — Docker Container

For a while now, my preferred way of installing QGIS has been from conda-forge. However, while we’re waiting for QGIS 4 to become available on conda-forge, there are alternatives:

Option 1: Flatpak

In the Software Manager, you can find QGIS from Flathub in two different versions: stable and lts. And stable should give you 4.2 (even if the Software Manager preview shows an older one):

Option 2: Meet the official QGIS Docker Images

First off, you’ll need Docker. If you haven’t installed it yet, it’s directly available from the Linux Mint Software Manager:

From there on, we just switch to the Terminal for the rest.

If you get “permission denied while trying to connect to the docker API” when running any of the following commands, you may have to add your user account to the docker group:

sudo usermod -aG docker $USER
newgrp docker # or just log out and back in

Afterwards, it should be straightforward to get the image from Docker Hub, e.g.:

docker pull qgis/qgis:4.2.2-questing

And once it’s downloaded, we can launch QGIS:

xhost +local:docker
docker run --rm -it --name qgis \ 
  -v /tmp/.X11-unix:/tmp/.X11-unix \ 
  -e DISPLAY=$DISPLAY \ 
  qgis/qgis:4.2.2-questing qgis
  

Voilá, QGIS 4!

To persist your QGIS profile/settings across container runs, mount a local folder to the config path, e.g.:

docker run --rm -it --name qgis \ 
  -v /tmp/.X11-unix:/tmp/.X11-unix \ 
  -e DISPLAY=$DISPLAY \ 
  -v ~/.qgis-docker-profile:/root/.local/share/QGIS \ 
  qgis/qgis:4.2.2-questing qgis
  

Of course, last but not least, we’ll also need access to our data, so let’s mount a data directory as well, e.g.:

docker run --rm -it --name qgis \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  -e LIBGL_ALWAYS_SOFTWARE=1 \
  -v ~/.qgis-docker-profile:/root/.local/share/QGIS \
  -v /mnt/ssd1/Geodata:/data \
  qgis/qgis:4.2.2-questing qgis
  

Fancy a bit of a stress test? I happened to find a project file written by QGIS 2.19

Yes, my friend, this project file is indeed a litte bit older … but hey, that doesn’t look too bad at all! Some icons seem to be off but, otherwise, looks like winter is coming.

On a side note, whom do I need to ping to the QGIS logo in the System Package / Software Manager updated?

On the Mappery site we have almost 2,400 posts on WordPress and we had never used the Category feature to sort them when we were adding posts. When we built the new Mappery Map Plugin for WordPress we included the option to only map posts in a specific category which we thought would be useful to some users in the future.Yesterday afternoon I wanted to see if there was a smart way to categorise 2,400 posts without stepping through each one in the WordPress edit interface which would have required time and dedication that I didn’t have!

I started out with this prompt:

• There are approx 2400 posts on mappery.org with about 3000-3500 images in total.
• We never used the category feature when adding posts and now I would like to rectify that. Is it possible to scan through all of the posts and assign them a category? I have made a list of some categories as an example: Furniture, Clothing, Alcohol, Street Art, Maps on the Floor, Vehicles, Globes, Humour, Art, Books, Signs – there may be more categories that I have missed and some posts could have multiple categories and some posts may not be easy to categorise. I don’t want the list of categories to get too long and each category should have a reasonable number of posts (to be decided later)
• Can you suggest a way to categorise posts

Claude started by trialling on 300 random posts and came back to me with a slightly enlarged selection of categories which you can see above. Then it ran a test to see how accurately it could categorise posts just from the parsing the text of the posts – answer about 55% with high confidence, the remainder with diminishing confidence. I suggested an approach where Claude would run through all the posts categorising those that it could with high confidence from the text only (the quick part) then follow up on the rest by pulling the image attached to the post and endeavouring to categorise those by a combination of image recognition and the text parse (the slow bit, I went to the theatre and came back to find the job done). I was left with a short list that Claude flagged for me to categorise because it wasn’t sure how to categorise them. The next step was to create the categories in WordPress and update the category for each post while removing the old default category – a good bit of whirring and the whole job was done. A couple of hours at the most and I had 2,400 posts categorised, if I could have maintained a speed of 1 per minute doing these manually that would have been an agonising 40 hours of work.

Next step was to add a Categories menu item to Mappery site with a drop down to select a category and then to create the map pages for each category and add them as another dropdown menu to the site. I am quite good in the WordPress admin dashboard and knew what I needed to do but it would have been a fair bit of repetitive work with potential to make a mistake but since Claude had access to the WordPress API it was easy to ask it to just get on with these tasks. I am learning to push repetitive tasks to Claude and let it get on with them, I guess one day I or it will make a mistake but so far that’s a risk I am ok to accept.

<p>The post How to Categorise 2,400 WordPress Posts first appeared on KnowWhere.</p>

Biodiversity data is most valuable when it is shared. A river survey stored in a single database helps one team, but the same records, shared openly, can inform researchers, conservationists, and policymakers around the globe.

That is exactly what the Global Biodiversity Information Facility (GBIF) is for. It is the world’s largest open network of biodiversity data.

BIMS (the Biodiversity Information Management System) is the open-source platform we build at Kartoza to help organisations collect, manage, and explore biodiversity records. It powers real-world systems such as FBIS , the Freshwater Biodiversity Information System for South Africa, and FADA , the Freshwater Animal Diversity Assessment. A single BIMS installation can host several of these systems side by side, each with its own data and users.

Yesterday I gave a talk at Geomob London on my adventures in vibe coding. The slides are pretty but probably don’t tell the whole story unless you have been reading my regular posts on my projects.

The images in the slides are all cartoons of an old dog learning new tricks and got some praise, the way I made them was interesting, so i thought I would post about it.

I started out by building an empty slide deck on Google Slides, each slide had a title and a few had a handful of words, they all had spaces for an image. I asked Claude:

• I am building a slide deck for a talk about making maps with AI that is called “You CAN teach an old dog new tricks!”
• I want to create about 11 coloured cartoon images to use in this presentation. the style should be light with watercolour style fills (not perfect solid colours)
• The initial one should be based on “You CAN teach an old dog new tricks!” and should have an old dog learning to make a map. This old dog should be the central character in all of the cartoons and should be visibly recognisable as the same dog in most of the cartoons (I will prompt you when the dog should not appear)
• Some cartoons will need to be landscape to fill most of a slide, some should be portrait to fill half of a slide with text filling the other half, I will include this info in each prompt
• What more info do you need? Can you read my slide deck on google slides?

Claude responded by suggesting that it draft prompts for each image and that I use Nano Banana (the image tool in Gemini) to generate the images because it was much better at image generation than Claude!

We then worked through a short process where I uploaded a picture of myself, we refined the spec for the dog character and Claude parsed my slides and suggested a brief summary idea/description of what the dog would be doing in each slide and whether it was landscape or portrait. Very little tuning was needed. Then Claude generated a Character Sheet that I would instruct Nano Banana to use in every image and a prompt for each slide image, here is the first one (the opening slide image at the top of this post):

• Character Sheet (the fixed description — reused in every prompt)
  An old, lean and lanky anthropomorphic dog character, standing or sitting upright like a person. He has grey/silvery fur, and is balding on top of his head with a few wispy grey hairs remaining at the sides. He wears round, black-framed glasses and a red collar. He has a warm, big, toothy grin — friendly and good-humoured rather than fierce. Rendered in a light watercolour cartoon illustration style: soft, loose watercolour washes with visible paper texture and gentle colour bleeds at the edges, not flat solid colours. Plain white background, no scene or setting painted in behind him.
  
• Title slide — “You CAN teach an old dog new tricks!”
  Orientation: Landscape (16:9)
  [Character Sheet] He is sitting at a desk, peering with curious concentration through his round glasses at a laptop showing a simple map on the screen, one paw resting on the keyboard, a pencil tucked behind one ear and a stack of books beside him. His expression is puzzled but determined, like he’s just starting to figure something out. Light watercolour cartoon style, plain background. Landscape orientation, 16:9.

I am particularly impressed at the almost collaborative approach that Claude took to fulfilling this task by drafting the prompts for Gemini.

You can look through the slides and form your own opinion of the images, if I didn’t know better I would almost say that Claude had a sense of humour!

<p>The post You CAN teach an old dog new tricks first appeared on KnowWhere.</p>

When Ed challenged me to make a map of Geomob Events on a podcast, I jumped in scraped the data and produced quite a nice map despite fighting a battle with Gemini to extract the data for the map from the markdown files of the Geomob website. The problem, as Ed pointed out retrospectively was that the events map was going to be difficult to maintain as further events got scheduled, it was very much a snapshot at a point in time and my suggestion that someone could edit the json file of events was not very practical.

Ideally the map needed to auto-update when a new event was added or the details of an event were changed but that would mean detecting changes to the markdown and updating the events file accordingly – that might be possible but it felt complicated and open to errors, I wanted a simpler solution. I thought that a non technical interface to add/update event details that connected to the map might be the way to go. I wondered whether a Google Sheet might be a way to do this, Sheets has a good user access model so that only authorised users can update the events model and avoided having to build a whole admin interface and user management function. Claude suggested that I could publish the sheet as a csv feed/file online and then build the map from that, we tested that and it worked perfectly, there is a lag of a few seconds between updating the sheet and the csv being published but it is as close to real time as most applications would need. I added some validation checks to the sheet to ensure that anyone editing can’t make a deal breaking mistake. Re-using some of the code from the geocoding element of the Mappery WordPress plugin, I added a geocoding app script to the sheet which looks up the event city and geocodes it using the OpenCage Data API.

Once the csv route had been tested it was fairly quick and easy to parse the old json file add it to the Sheet, add the events added to the Geomob website since I built the original and then build a new events map using the styling of the Geomob website and with pretty much the same functionality as the first map. Becaus the data was easy to work with I added a search for a speaker name which shows all of the events at which they have spoken – Ed Freyfogle has spoken at 12 events and is way out in the lead, I am in joint 3rd place at 5 appearances.

The map still doesn’t auto-update but this is a good compromise. More importantly, it opens up the possibility of making more maps in the future using this Google Sheets approach and possibly creating a Form to update the Sheet as an even simpler interface.

<p>The post Mapping a Google Sheet – reworking the Geomob events map first appeared on KnowWhere.</p>

Sorry, this entry is only available in French.

Workshops The conference opened with two days of hands-on workshops. Our team ran five of them, covering the three products end to end: an introduction to GeoNode, an introduction to MapStore, a developer session on building MapStore extensions, and two GeoServer 3 sessions on OGC APIs and on vector tiles. The introductory slides are embedded below, the full workshop material is available on request.

Our Presentations Below you can find all the presentations delivered by our team, grouped by product. If you missed the event or want to revisit some of the content, everything is embedded here for easy access.

Thanks to the organizers of FOSS4G Hiroshima 2026 for a great event, and to everybody who stopped by our booth or joined our sessions. See you at FOSS4G North America 2026 in Sacramento in November.

If you are interested in learning about how we can help you achieving your goals with open source products like GeoServer, MapStore, GeoNode and GeoNetwork make sure to talk to us!

The GeoSolutions team,

I’ve been testing Codeberg for over a year now, with Trajectools being the largest repo that has already moved its headquarters from Github to Codeberg.

I have been very happy with the experience so far and – at the same time – I couldn’t help but notice the further decline of Github performance.

Therefore, in the upcoming weeks, I am planning to move the remaining MovingPandas repos. For anyone who wants to contribute, this means that:

• All further development will move to Codeberg.
  • Codeberg LLM usage policies apply
• GH repos will remain as read-only mirrors for now.
• Issue trackers and pull requests on GH will be deactivated.

5 months ago, I laid down the plans for what was going to happen going forward with my various open source projects. But after that post, it has been nothing but ... silence! If you were to look at my GitHub contribution graph, there was also a noticeable drop-off there too.

So what happened?

What happened was there was a major rug-pull. GitHub copilot changed their pricing model to usage-based billing on June 1 and that completely threw by GH copilot powered plans into complete disarray. The existing subscription at that point pretty much amounted to ~30 spins on the AI slot machine per month, hoping it will produce the outcome I desire and that was just untenable for something I am paying out of my own pocket!

So come June 1, I terminated my GitHub copilot pro subscription and pondered what my next moves were going to be. I wasn't going to give up on the productivity gains that agentic coding gave me, so the option was clearly to look for alternative AI coding provider. Because try as I might (I religiously keep watch on advancements in LocalLlama), locally hosted AI coding models is not (yet) tenable on my personal hardware. I bought that PC to 6 years ago to last a decade at least, and it will still last a decade as long as you give up on locally hosted AI models as desired workload.

I eventually settled on Deepseek and straight away, its payment model was very attractive to me: Just load up your account on credits and reload when credits start running low. This was a low risk approach where I loaded up $20 $10 USD in credits, give it a spin on my various open source projects. If Deepseek didn't pan out for my use cases, no harm, no foul. I simply don't reload with any more credits. But if it did work out for me, I can just load more credits as I go.

So as my initial $20 $10 load is down to its final dollar after several months of sporadic evaluation. I can confidently say that Deepseek adequately meets my AI coding agent needs while maintaining the "bang for buck" that I used to have with GH copilot before their June 1 rug-pull. I will lose some capabilities from GH copilot (cloud agents was nice), but they are acceptable losses.

So what that means in the grand scheme is that I should start ramping up my OSS dev machinery again and resume the plans that I had stated 5 months ago. Our regular broadcasting will resume shortly!

FOSS4G is the annual global event of free and open source geographic technologies and open geospatial data hosted by OSGeo. In 2026 it took place in Hiroshima, Japan.