Dear Reader,

Here is a closer look at GeoNode 5.1.0, the first feature release built on top of the renewed 5.0 architecture. The release notes list everything in detail. Where GeoNode 5 was about rebuilding foundations, 5.1.0 is about putting those foundations to work. It significantly broadens the range of data GeoNode can catalogue and publish, and it tightens the controls around how that data is shared.

Two themes run through this release. The first is reach: GeoNode now handles data that has no geometry at all, and data that never leaves the remote server it is hosted on. The second is control: permissions, authentication for external resources and default access rules all received substantial attention. Alongside these, metadata internationalisation has been generalised across the platform, and the documentation has begun its move to a new MkDocs-based site.

Documents as map layers

Documents can now be placed directly on a map. Geolocation can be set manually from the "Location" tab of the resource panel, or, for images carrying EXIF metadata, GeoNode picks up the coordinates automatically.

A new "Add documents layer" button opens a dedicated resource browser where documents can be searched and filtered by type. Selecting one or several documents and confirming the action creates a "Document Layer" on the map, with one feature for each document chosen. Every document is shown as a marker positioned at the centre of its location, and clicking a marker opens a preview of the resource in the sidebar.

This turns the map into a browsable index of related material, such as photos, reports and scans, anchored to the places they belong to, without leaving the map view to go looking for them.

Beyond geometry: support for non-spatial datasets

GeoNode can now manage tabular data with no geographic component. Non-spatial CSV files can be uploaded and registered in the GeoNode catalogue through the standard resource-management workflow, with the same metadata, permissions, search and download behaviour as any spatial layer.

This opens GeoNode to a much wider set of use cases, where attribute tables, lookup tables and statistical datasets live alongside spatial layers rather than in a separate system.

The resource preview shows the tabular data with filter and export tools. The main catalogue filter panel also offers a new "Tabular" checkbox that allows filtering non-spatial data.

Cloud-native resources: COG and FlatGeobuf remote assets

GeoNode 5.1.0, in cooperation with MapStore (the framework behind the GeoNode client), adds support for two cloud-native formats, both in the client and as remote resources in the catalogue. In both cases, the pattern is the same: you provide a URL, and GeoNode reads only what it needs.

• Cloud Optimized GeoTIFF (COG): register large raster datasets hosted externally simply by providing their URL. Rather than downloading the whole file, GeoNode uses HTTP range requests to read metadata such as CRS and spatial extent directly from the remote source. The result is efficient, cloud-native raster access without storing massive files locally.
• FlatGeobuf (FGB): register external FlatGeobuf datasets as remote vector layers by URL. As with COG, HTTP range requests fetch metadata (CRS, extent, attributes) directly from the source, with graceful fallback when a server does not support range requests.

For organisations already publishing data to object storage, this removes a duplication step that was previously unavoidable: the authoritative file stays where it is, and GeoNode catalogues and serves it in place.

XLSX upload and download

Microsoft Excel (XLSX) is now a supported format for both ingestion and export. Users can upload spreadsheets as datasets and download existing datasets as XLSX, complementing the CSV and other export options introduced previously.

The upload of XLSX files is an optional feature that can be activated as a system setting, so administrators can decide whether to expose it.

Together with non-spatial dataset support, this makes GeoNode a considerably more natural destination for the spreadsheet-shaped data that most organisations actually have in circulation.

Multilingual metadata support

The metadata internationalisation mechanism has been refactored and generalised, so that localised labels and descriptions are no longer confined to the GeoNode app. Metadata fields can now carry translations across the platform.

On the API side, a new opt-in parameter (include_i18n) lets resource APIs (datasets, documents, maps and others) return all available translations alongside the default value, for example, title, title_en and title_fr. Because it is opt-in, full backward compatibility is preserved for existing clients: nothing changes unless you ask for it.

Related improvements include generic use of sparse metadata fields, used to store and handle custom metadata, and improvements to thesaurus management.

The developers' documentation now includes a dedicated section on metadata management and customisation.

Faithful handling of multi and mixed geometries

GeoNode now correctly handles datasets that mix geometry types (Points, MultiPoints, LineStrings, MultiLineStrings, Polygons and MultiPolygons) within the same layer. Previously, upserting data with mixed geometries could leave the stored geometries out of sync with the source. The new handling ensures that source data is reflected in storage and display after update and replace operations, which matters directly for the dataset update workflows introduced in GeoNode 5.

Permissions and security

Authentication for external resources

A generic authentication layer decouples how authentication settings are stored from how they are applied to outgoing requests, via a unified AuthConfig model supporting multiple types: Basic, Token and signed/SAS URLs. Credentials can be reused across integrations instead of being hardcoded per use case. They are used, for example, when generating map thumbnails from datasets hosted on authenticated remote servers.

Default permissions for registered members

Administrators can now configure baseline permissions (view, download, edit, manage) for all authenticated users, mirroring the existing anonymous-user settings. This closes a long-standing asymmetry in how default access was expressed.

Tighter controls on remote resources

Creation of remote resources is restricted to administrators by default, and Remote Services creation actions are hidden in the UI when the user lacks the required permissions. A related fix removes an unexpected password prompt on private datasets.

Documentation moves to MkDocs

The documentation revision announced with GeoNode 5 is now underway in public. The GeoNode documentation has begun migrating from Sphinx to MkDocs, with a refreshed and easier-to-navigate site. This is still a work in progress, and it can be followed at https://docs.geonode.org/en/latest/.

Software updates

GeoNode 5.1.0 also moves the stack forward:

• The reference version of GeoServer is 2.28.4 (from 2.27.3)
• The GeoNode client application is aligned to the new features from MapStore v2026.01.02
• Django has been updated to version 5.2.15
• pyCSW has been upgraded to the 3.0 series

Improvements and fixes

Beyond the headline features, 5.1.0 collects a range of smaller improvements across the UI, the admin and the API:

• The UI language selection is now synchronised with the user profile settings.
• Thumbnails can be uploaded through the UI for remote spatial datasets.
• The label thesaurus is reloaded when thesauri change.
• Inline links were added inside the Django admin pages for datasets and documents.
• Resource endpoints now also return dirty resources.
• The regenerate_xml management command has been improved.
• Missing entries when searching with the new indexing have been fixed.
• EXIF metadata extraction from documents was fixed, with support for further media types.
• A new update-bbox endpoint is available for datasets.
• Updating permissions through a PUT request now replaces them instead of merging them.
• requirements.txt has been dropped, with dependencies moved to pyproject.toml.

The full list of changes and bug fixes for GeoNode can be found in the changelog.

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

The GeoSolutions team

During a bit of football banter about League 1 over the weekend, Ken said to me “I bet you’ve never been to any of those places either. All a bit far north” – it turned out I had visited 18/24 of the places in the League. That prompted an idea for a geography quiz, could I make a quiz that combined pinning the locations of cities on a map with some general knowledge questions about those cities?

I started out with this prompt:

• I want to make a geography quiz about cities in the world. For each city the user should have to put a pin on an unlabeled map and score points for how close the pin is to the centre of the city. I was thinking about 2-300 cities around the world with each quiz being 10 random cities.
• For each city the user should be presented with 3 questions each with a choice of say 4 answers (number of choices to be refined later). There should be 10 questions about each city so that if the city appears again there will be different questions. Could questions be sourced from wikipedia?
• There should be a scoring model that combines the closeness of the map pin to it’s location, a point for in the right country and points for correct answers. We can work on the scoring later.
• Could we have different difficulty modes? Maybe based on the size of the city e.g. Capital cities are easiest
• I’d like the quiz to have a daily version so that people can share their scores on social media, I guess that will need an email sign up and basic gdpr and unsubscribe
• Needs to work on mobile and laptop
• Can you suggest any other approaches/ideas?
• Tell me how you build the data and questions

Claude replied that it was very buildable and outlined how it would build the data from Wikipedia with cities being ranked by how frequently the Wiki page was accessed and adjusted to ensure distribution across all continents.

Claude built a prototype with 20 cities and a set of questions and answers which quickly let me refine the brief for the agents that would construct the 328 sets of questions and answers and work through most of the functionality

Decisions that changed along the way

• No email sign-up. Sharing works by copying a result, Wordle-style, so the whole thing runs without accounts.
• 10 cities per quiz became 5 once I played it because 10 took too long, there may even be a case for reducing to 3 cities in the future depending on user feedback.
• My usual basemap has labels, so the map is drawn directly from Natural Earth data with labels switched off.
• 3 difficulty levels became 1 daily quiz with a bonus round of 2 “hard” cities for scores over 350/500.
• I added a passport feature that tracks all the cities that you have visited in the quiz and your scores (stored on your device)

Choosing the cities

There are 328 cities across 149 countries, selected by how often their Wikipedia page is read, not by population. I set targets per continent and a cap per country to try and get a good distribution. City names that gave the country away were reworded e.g. “Kingston, Jamaica” became “Kingston (Caribbean)”

Writing 3,266 questions

Writing 3000+ questions and 12,000 answers (9,000 of which are wrong but believable) meant reading a mass of Wikipedia content. Once we had prototyped the questions and answers and selected the cities Claude set a string of agents working to read the articles and compose the questions while I went to sleep. I hit my session/token limit part way through and had to restart in the morning to finish the process.

Every question had to quote the sentence it came from, and a script checked each quote really is in the article. I relaxed the requirement for 10 questions for a few cities with shorter Wikipedia articles .The wrong answers come from Claude’s general knowledge and are not source-checked but they seem pretty good in my tests.

Scoring

100 points a city: 30 for the pin, 10 for the right country, 20 for each question.

A pin in the wrong country scores nothing for accuracy; a country that doesn’t even border the right one costs a penalty of 10 points (that required some proximity checking on the fly). Pin points slide with distance, and the distances stretch for big countries, so in smaller countries (e.g. Thailand) you have to place the pin within 10km of the city centre to score the full 30 points while in large ones (e.g. USA) 30km will score maximum points.

Activating help reduces the points available:

• A large circle showing very roughly where the city is plus the country labels switched on costs the 10 point correct country score and halves the proximity score.
• Users can ask for 1 or 2 wrong answers to a question to be removed, each help halves the question score.

Borders and politics

While testing I hit some inevitable geopolitical disputes. I tried to adopt a neutral position on disputes about the cities in the quiz. Jerusalem accepts either Israel or Palestine, Nicosia is classed as being in Cyprus (both), Crimea is drawn as part of Ukraine, Kashmir follows the line of control. The info panel says borders are a guide for the game and imply no political position.

What I Learnt

A lot of this project was decisions, not code: what counts as a fair question, how harsh the scoring should be, how to select and classify cities. From idea to launch took 2 days with some agents whirring in the background.

The quiz runs with no server at all, apart from a small script for the anonymous daily leader board so it should be pretty scalable if it gets a lot of interest.

<p>The post World Cities Quiz first appeared on KnowWhere.</p>

Laax, Switzerland, 10 October 2026. More than 420 people from over 30 countries and five continents gathered in Laax from 4 to 9 October for the QGIS User Conference 2026, the largest event ever held on Crap Sogn Gion at 2222 metres above sea level.

Two conference days at the Galaaxy venue carried around 90 talks and six keynotes. Swiss MP Gerhard Andrey opened with Switzerland’s turn towards open source, ETH Zurich cartography professor Lorenz Hurni spoke on maps as instruments of power, Anita Graser on AI in the QGIS ecosystem, and Johannes Kanonier on fifteen years of QGIS at the State of Vorarlberg. Ivan Minčík, Lova Andriarimalala and Tim Sutton made the case for sustaining the infrastructure the whole project depends on. Twelve short hands-on workshops ran alongside the talks across those two days.

Wednesday brought ten full-day workshops in the valley with 120 participants, ranging from point clouds and data processing to plugin development, workflow automation, team collaboration and field data infrastructure with QFieldCloud and Mergin Maps, alongside the QField Day, where 71 participants mapped the area around Laax in guided groups using QField, the mobile companion app born a few kilometres away in Sagogn. From Wednesday to Friday the 29th QGIS Contributor Meeting put developers, documenters and translators around the same tables to work on the software itself.

The recurring theme of the week was what happens when decision makers and developers share a room.
Procurement officers, cantonal GIS leads, researchers and core developers spent three days in the same
corridors, and the conversations that followed are the kind that rarely happen over a mailing list.

“Digital sovereignty is not a slogan, it is what you get when the people who fund the software and
the people who build it actually meet. That is what this week was for.” Marco Bernasocchi, Chair,
QGIS.org Association

OPENGIS.ch was the lead organiser of the conference, together with QGIS.org and QGIS Switzerland. The
week was made possible by its sponsors, whose support kept ticket prices within reach of public bodies and
students alike: Happy Survey on platinum, EBP and Lutra Consulting on gold, Arx iT, Ocean Winds and the
Province of South Holland on silver, together with the bronze sponsors and supporters. The conference was also financially supported by QGIS.org using funds provided by its donors and sustaining members.

About QGIS

QGIS is a free and open source geographic information system for creating, editing, analysing and publishing
spatial data. It runs on desktop, server, web and mobile, is released under the GNU General Public License, and
is used worldwide by public administrations, companies, universities and NGOs. It is built by an international
community of volunteers and companies and governed by the QGIS.org Association. qgis.org

We see loads in the news about oil prices, the potential shortages caused by wars involving Iran and Russia and whether the UK should licence further oil extraction from existing oil fields in the North Sea. I wondered whether there was a mappy project opportunity around oil production and consumption. I started out with this prompt:

• “I want to make a map based dashboard about oil production, consumption, refining and the flows between countries. before we start can you research what data is available at country level”

Claude found me these sources:

• US EIA (public domain) for production and consumption
• JODI for refinery throughput (free, with a required citation)
• UN Comtrade for trade between countries (I asked; they replied that no licence was needed)
• World Bank for population
• Natural Earth for boundaries.

Claude reminded me that I needed to double check that open data was actually open for my use case after the debacle with IUCN data for my Endangered Species map and even drafted the request emails for me. The Energy Institute’s Statistical Review would have been very useful but it only allows “brief quotation”, so I used it just to cross-check my data. There are trade data for 211 countries, 1993–2024, 32 yearly trade files, all rebuilt by two Python scripts that I can rerun. Nobody publishes refinery capacity by country for free, so the map shows what refineries actually processed using the JODI data.

While I was waiting for the data approvals, Claude suggested that we build a prototype with some fake data to explore how the dashboard and map might interact. This helped me to realise early on that this would be more dashboard with the map showing trade flows and being a way of selecting countries in the dashboard. As I asked for more variables and measures (eg oil consumption per capita) and percentages of world totals and rankings the dashboard became more complex and needed a slight redesign to make it more intuitive (I am sure that there is more to do on this). I decided that I didn’t need base map tiles, because plain country shapes are enough and there is no reason to want to zoom into city level or below.

The initial build was pretty simple because most of the decisions had been worked out in the prototyping and turning that into an app with all the real data only took a few minutes as Claude knows my pretty simple architectural choices and just gets on with it. Most of the functional testing got done by Claude and it was pretty amazing to watch Claude open a browser tab and start whizzing through a series of tests, I found a few issues that needed a rerun but they were pretty minor.

I had a good functional working release tested on desktop and mobile (slightly more emphasis on the dashboard on mobile version) but it was a bit bland. I asked Claude to liven it up and it gave me 3 options, I ended up choosing a hybrid of 2 of the options and changing the font.

The data isn’t perfect and additionally doesn’t always mean exactly what a lay person might expect.

• “Production” means all liquids (crude, NGLs, biofuels), not just crude. That’s why the US looks 22% of world output but is only 13.2 mb/d on crude alone.
• Trade data comes from customs records but Russia stopped reporting in 2022, additionally sanctioned oil gets relabelled.
• Oil passing through hubs is counted twice.
• Weights are converted from tonnes using fixed barrels-per-tonne figures, so volumes are estimates.
• Consumption includes ships’ fuel and chemical feedstock, which inflates places like Singapore.
• My “refining balance” (does a country have sufficient refining capacity for all of its needs) idea didn’t survive contact with the data: the consumption total includes liquids that never see a refinery. So I built “own fuel supply” from trade data instead.

My stance: “It’s the best open data I could find, and I’ll swap it if you can point me at better open data.”

Surprising Oil Facts

• China was almost self-sufficient in 1993 (a gap of −0.1 mb/d) and now imports about 11 mb/d. In the same year the US was the biggest importer (−7.6); today it has a surplus (+2.4).
• Russia’s pivot: in 2021 Germany and the Netherlands were top buyers of Russian oil. In 2023 China took 2.0 mb/d and India 1.8, and the only European buyers left were the pipeline-fed ones.
• Iran’s oil exports show as zero in 2024, and Malaysia appears to export 1.7 mb/d while producing 0.57. The missing barrels reach China relabelled.
• Venezuela produced 3.4 mb/d in 1998 and 0.9 in 2024.
• Singapore uses about 90 barrels per person a year, (this may be because of its role as a refuelling hub) against a world average of 4.6. Canada slightly beats the US (22.3 vs 22.0), and Australia uses double the UK.
• India refines 9× its own crude and exports fuel
• Nigeria exports crude but imports 46% of its fuel.
• On crude alone the top producers reorder: the US, then Russia, then Saudi Arabia.
• Global crude trade grew from 28 to 47 mb/d between 1993 and 2024.

<p>The post World Oil – who pumps it, who burns it and where it goes first appeared on KnowWhere.</p>

Dear Reader,

From November 2 to 4, 2026, GeoSolutions will be at FOSS4G North America 2026 in Sacramento, California, at the Sheraton Grand Sacramento. Simone Giannecchini and Andrea Aime will be there for the whole conference, from Monday to Wednesday. You will find them at our table in the exhibit area, where GeoSolutions is present as a Bronze sponsor, and in the session rooms for our four talks. If you want to talk about GeoServer, MapStore or GeoNode, write to sales@geosolutionsgroup.com and we will book a slot.

Our talks

This year we bring four talks, all in the Technical track and all presented by Simone and Andrea. Times are Pacific Time. The schedule can still change, so please check the official schedule before you go.

• AI-dministering GeoServer and MapStore, Tuesday, November 3, 2026 at 10:30 AM. An early look at the Model Context Protocol servers we are building for GeoServer and MapStore. They let today's AI assistants help with real administration tasks, such as publishing layers, tuning caches and diagnosing issues, with guardrails to keep production deployments safe.
• State of GeoServer, Tuesday, November 3, 2026 at 11:00 AM. New features, community updates and recent developments of GeoServer, for expert users, developers and anyone curious about what GeoServer can do for them.
• GeoServer VS GeoServer: fight!, Wednesday, November 4, 2026 at 2:00 PM. GeoServer benchmarked against itself. Each experiment measures the real performance cost of a common operator decision: data formats, security, logging, CRS handling, JVM settings and scaling.
• Precision farming with GeoServer: lessons learned and future directions, Wednesday, November 4, 2026 at 3:30 PM. Ten years of experience ingesting, managing and disseminating drone, Earth observation and agricultural machinery data at scale for the precision farming industry, with GeoServer deployed in the cloud.

Come and talk to us

Beyond the talks, we will be at our table from the Welcome Icebreaker on Monday evening to the end of the exhibit hours on Wednesday. We are available for technical discussions of any depth: GeoServer performance and tuning, deployments at scale on premises and in the cloud, raster and Earth observation data, MapStore and GeoNode, and the AI work we present on Tuesday. Bring your questions and your use cases.

To fix a meeting in advance, write to sales@geosolutionsgroup.com.

About FOSS4G North America

FOSS4G North America is the North American edition of FOSS4G, the conference for free and open source software for geospatial. The theme of this year's edition is "Resilience and Innovation". Monday is dedicated to hands-on workshops, followed by two days of plenaries and concurrent sessions across four tracks: Technical, Application, Community of Practice and Business of Open Source. Registration is open at www.foss4gna.org.

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.

If you are interested in learning more about how we can 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,

See also

• FOSS4G North America 2026
• FOSS4G North America 2026 schedule
• GeoServer Corporate Page
• MapStore Corporate Page
• GeoNode Corporate Page
• GeoSolutions at FOSS4G 2026 in Hiroshima

Quando uma infraestrutura geoespacial começa a ser utilizada por diferentes equipes de uma organização, chega um momento em que manter usuários e senhas diretamente no GeoNode deixa de ser uma boa estratégia.

O usuário já possui uma identidade corporativa. Ele já entra em outros sistemas com a mesma conta. Em muitos casos, seus grupos e perfis também já são gerenciados centralmente.

Nesse cenário, uma alternativa interessante é integrar o GeoNode a um provedor de identidade utilizando OpenID Connect (OIDC).

O objetivo deste artigo é mostrar um exemplo genérico de integração de um GeoNode 5 com um provedor OIDC, incluindo não apenas o login, mas também a utilização das claims retornadas pelo provedor para associar automaticamente o usuário aos grupos do GeoNode.

A arquitetura é aproximadamente esta:

O detalhe interessante é que o GeoNode não precisa saber como o Identity Provider (IdP) autenticou o usuário. Por trás do IdP pode existir LDAP, Active Directory, outro diretório corporativo ou até outro serviço de identidade. Para o GeoNode, isso é transparente.

OIDC, OAuth 2.0 e autenticação

É comum OAuth 2.0 e OpenID Connect aparecerem juntos, mas eles não representam exatamente a mesma coisa.

• OAuth 2.0 foi criado principalmente para autorização.
• OpenID Connect acrescenta uma camada de identidade e autenticação sobre o OAuth 2.0.

É por isso que em uma integração OIDC normalmente aparecem informações como: authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, issuer. Além de scopes como: openid, profile e email.

Para aplicações corporativas, frequentemente aparecem também scopes ou claims relacionadas a grupos e roles.

Ambiente utilizado neste exemplo

Este artigo considera uma instalação do GeoNode 5 baseada no geonode-project e executada com Docker Compose.

Os comandos docker compose devem ser executados no diretório raiz do projeto, onde está o arquivo docker-compose.yml.

Nos exemplos abaixo, utilizarei geonode_project como nome do pacote Django. Caso seu projeto utilize outro nome, substitua geonode_project pelo nome correspondente.

Uma das primeiras informações que devemos solicitar à equipe responsável pelo Identity Provider é a URL de discovery do OIDC. Normalmente ela segue este padrão:

https://idp.exemplo.org/.well-known/openid-configuration ou https://idp.exemplo.org/security/.well-known/openid-configuration

Ao acessar essa URL, recebemos um JSON semelhante a:

{
  "issuer": "https://idp.exemplo.org/",
  "authorization_endpoint": "https://idp.exemplo.org/connect/authorize",
  "token_endpoint": "https://idp.exemplo.org/connect/token",
  "userinfo_endpoint": "https://idp.exemplo.org/connect/userinfo",
  "jwks_uri": "https://idp.exemplo.org/.well-known/jwks",
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "roles"
  ]
}

Esse documento funciona praticamente como um mapa da integração.

No lado do Identity Provider, o GeoNode precisa ser registrado como uma aplicação/client. De maneira simplificada, teremos algo como:

Client ID:
geonode

Client Secret:
**************

Redirect URI:
https://geo.exemplo.org/account/oidc/corp-idp/login/callback/

A URL de callback deve coincidir exatamente com a rota exposta pela versão do GeoNode/django-allauth utilizada. Confirme a URL do seu ambiente antes de registrá-la no Identity Provider.

O nome corp-idp neste artigo é apenas um exemplo. Esse identificador será utilizado posteriormente pelo django-allauth para identificar o provedor. Um cuidado importante: o Client Secret não deve ficar diretamente no código-fonte nem ser enviado ao Git. O ideal é mantê-lo em variável de ambiente:

OIDC_CLIENT_ID=geonode
OIDC_CLIENT_SECRET=xxxxxxxxxxxxxxxx
OIDC_DISCOVERY_URL=https://idp.exemplo.org/.well-known/openid-configuration

Uma estratégia que considero interessante é não alterar diretamente o settings.py original do GeoNode. Podemos criar, por exemplo: src/geonode_project/corporate_settings.py com o seguinte conteúdo:

import os

from .settings import *


OIDC_CLIENT_ID = os.getenv(
    "OIDC_CLIENT_ID",
    "geonode",
)

OIDC_CLIENT_SECRET = os.getenv(
    "OIDC_CLIENT_SECRET",
    "",
)

OIDC_DISCOVERY_URL = os.getenv(
    "OIDC_DISCOVERY_URL",
    "",
)

E então definir no ambiente:

DJANGO_SETTINGS_MODULE=geonode_project.corporate_settings

Isso facilita bastante manutenção, deploy e rollback.

O GeoNode utiliza django-allauth para parte da integração com contas sociais/federadas. O código atual do projeto continua trazendo um GenericOpenIDConnectAdaptere mecanismos próprios para extrair atributos e sincronizar grupos. Podemos registrar o provider desta forma:

OIDC_PROVIDER_APP = (
    "allauth.socialaccount.providers.openid_connect"
)

if OIDC_PROVIDER_APP not in INSTALLED_APPS:
    INSTALLED_APPS += (OIDC_PROVIDER_APP,)


SOCIALACCOUNT_PROVIDERS = dict(
    SOCIALACCOUNT_PROVIDERS
)

SOCIALACCOUNT_PROVIDERS["openid_connect"] = {
    "OAUTH_PKCE_ENABLED": True,

    "SCOPE": [
        "openid",
        "profile",
        "email",
        "roles",
    ],

    "APPS": [
        {
            "provider_id": "corp-idp",

            "name": "Login Corporativo",

            "client_id": OIDC_CLIENT_ID,

            "secret": OIDC_CLIENT_SECRET,

            "settings": {
                "server_url": OIDC_DISCOVERY_URL,
            },
        }
    ],
}

O scope roles utilizado neste exemplo não é obrigatório no padrão OIDC. Os scopes e claims disponíveis dependem do Identity Provider. Alguns provedores retornam grupos/roles com outros scopes ou apenas pelo endpoint userinfo.

Também podemos permitir criação automática da conta local:

SOCIALACCOUNT_AUTO_SIGNUP = True

Durante homologação, particularmente prefiro manter o login local disponível:

SOCIALACCOUNT_ONLY = False

Assim, caso algo dê errado com o IdP, ainda existe uma forma administrativa de entrar no GeoNode.

Neste momento eu ainda não me preocuparia com grupos. O primeiro objetivo é provar apenas este fluxo:

Depois de reiniciar a aplicação:

docker compose up -d --build django celery

Valide:

docker compose exec django python manage.py check

Podemos também acompanhar o log:

docker compose logs -f --tail=200 django

Ao clicar em Login Corporativo, devemos ser redirecionados ao IdP e, após a autenticação, voltar para algo semelhante a: /account/oidc/corp-idp/login/callback/

Se o usuário for criado e entrar no GeoNode, a primeira etapa está concluída.

Depois da autenticação, uma das etapas mais importantes é verificar o conteúdo recebido. Um conjunto de claims pode ser parecido com:

{
  "sub": "5d823759-3dc0-4414-a936-2ef659829321",

  "name": "Fernando Quadro",

  "preferred_username": "fernando.quadro",

  "email": "fernando.quadro@exemplo.org",

  "given_name": "Fernando",

  "family_name": "Quadro",

  "role": [
    "gestores"
  ]
}

O campo mais importante do ponto de vista de identidade é normalmente o sub, ou Subject Identifier, que é o identificador estável daquele usuário dentro do provedor. Nome, username e até e-mail podem mudar. O sub não deveria.

Podemos verificar exatamente o que ficou armazenado no SocialAccount. Por exemplo:

docker compose exec django python manage.py shell -c "
import json

from allauth.socialaccount.models import SocialAccount

for account in (
    SocialAccount.objects
    .filter(provider='corp-idp')
    .select_related('user')
):
    print('GeoNode:', account.user.username)
    print('UID/sub:', account.uid)

    print(
        json.dumps(
            account.extra_data,
            indent=2,
            ensure_ascii=False
        )
    )

    print()
"

Esse comando é extremamente útil durante uma homologação. Antes de escrever qualquer lógica de grupos, vale confirmar:

• sub
• email
• preferred_username
• given_name
• family_name
• role / roles
• groups

E principalmente os tipos desses atributos. Uma role pode chegar como: “role”: “gestores” ou “role”: [“gestores”]

Essas diferenças parecem pequenas, mas fazem bastante diferença no código.

Aqui existe uma parte interessante do GeoNode que nem sempre é muito conhecida. O projeto possui um mecanismo de Profile Extractors. A própria classe base explica que extractors customizados podem ser registrados através de: SOCIALACCOUNT_PROFILE_EXTRACTORS

Existe também um OpenIDExtractor. Entre outras coisas, ele possui:

def extract_groups(self, data):
    return data.get("groups", "")

def extract_roles(self, data):
    return data.get("roles", "")

Perceba um detalhe. Ele procura roles no plural. Mas nosso Identity Provider fictício retorna role no singular. É exatamente aí que um pequeno extractor customizado pode ser útil.

Vamos criar esse extractor na pasta src/geonode_project/corporate_auth.

Primeiro o arquivo profileextractors.py:

import logging

from geonode.people.profileextractors import (
    OpenIDExtractor,
)


logger = logging.getLogger(__name__)


class CorporateOpenIDExtractor(OpenIDExtractor):

    ROLE_MAPPING = {
        "publico": "publico",
        "analistas": "analistas",
        "gestores": "gestores",

        # Compatibilidade com outra nomenclatura
        "role_publico": "publico",
        "role_analistas": "analistas",
        "role_gestores": "gestores",
    }

    def extract_roles(self, data):

        roles = data.get("role", [])

        if isinstance(roles, str):
            roles = [roles]

        mapped_roles = [
            self.ROLE_MAPPING[role]
            for role in roles
            if role in self.ROLE_MAPPING
        ]

        unknown_roles = [
            role
            for role in roles
            if role not in self.ROLE_MAPPING
        ]

        if unknown_roles:
            logger.warning(
                "OIDC retornou roles não mapeadas: %s",
                unknown_roles,
            )

        return mapped_roles

Perceba que esse código não implementa autenticação. Ele também não implementa a associação ao grupo. Sua única responsabilidade é:

claim do IdP
↓
normalização
↓
slug conhecido pelo GeoNode

Vamos registrar o extractor no arquivo src/geonode_project/corporate_settings.py:

SOCIALACCOUNT_PROFILE_EXTRACTORS = dict(
    SOCIALACCOUNT_PROFILE_EXTRACTORS
)

SOCIALACCOUNT_PROFILE_EXTRACTORS[
    "corp-idp"
] = (
    "geonode_project."
    "geonode.corporate_auth."
    "profileextractors."
    "CorporateOpenIDExtractor"
)

Para testar se funcionou, você pode usar o comando abaixo:

docker compose exec django python manage.py shell -c "
from geonode.people.adapters import get_data_extractor

extractor = get_data_extractor('corp-idp')

print(
    extractor.__class__.__module__
    + '.'
    + extractor.__class__.__name__
)
"

O resultado esperado é: geonode_project.corporate_auth.profileextractors.CorporateOpenIDExtractor

Por último, vamos validar o adapter:

docker compose exec django python manage.py shell -c "
from django.conf import settings
from geonode.people.adapters import get_data_extractor

print(
    'SETTINGS:',
    settings.SETTINGS_MODULE
)

print(
    'ADAPTER:',
    settings.SOCIALACCOUNT_ADAPTER
)

print(
    'EXTRACTOR:',
    get_data_extractor('corp-idp')
)
"

O resultado esperado é:

SETTINGS:
geonode_project.corporate_settings

ADAPTER:
geonode.people.adapters.GenericOpenIDConnectAdapter

EXTRACTOR:
<...CorporateOpenIDExtractor object...>

No GeoNode, acesse Grupos → Criar um Novo Grupo e crie Público, Analistas e Gestores, garantindo que os slugs sejam respectivamente publico, analistas e gestores.

Agora criamos os GroupProfile: Público, Analistas e Gestores com os seguintes slugs: publico, analistas e gestores. Esse detalhe é importante. O mecanismo de associação procura o grupo pelo slug, não pelo título visual.

Então: role = gestores

Precisa resular em: slug = gestores

O GeoNode possui uma rotina interna para sincronizar grupos provenientes da conta social. O código atual busca o extractor correspondente ao provider, extrai groups ou roles, localiza o GroupProfile pelo slug e executa join(user).

O GenericOpenIDConnectAdapter chama essa sincronização tanto na criação da conta quanto em logins posteriores. GitHub O fluxo fica:

É uma solução interessante porque aproveita a infraestrutura que já existe no GeoNode em vez de criar um segundo sistema paralelo de autorização.

Essa parte é especialmente importante em ambientes corporativos. Imagine:

Na segunda-feira o usuário “fernando.quadro” foi colocado na role analistas. O usuário acessa o GeoNode e é inserido no grupo Analistas. Posterior a essa data o administrador alterar o perfil desse usuário para a role gestores.

No próximo login, a associação pode ser sincronizada novamente. Na versão atual do código do GeoNode, inclusive, existem estratégias explícitas para sincronização dos grupos sociais, e o adapter continua executando essa lógica no pre_social_login.

Isso permite tratar o provedor corporativo como fonte da verdade da associação de grupos.

Atenção

Na estratégia nativa apresentada, durante o login social o GeoNode pode remover os
GroupProfile atualmente associados ao usuário e recriar as associações com base nos grupos ou roles recebidos do Identity Provider.

Portanto, esta abordagem é apropriada quando o Identity Provider é realmente
a fonte de verdade dos grupos corporativos. Se a mesma conta também precisar
pertencer a grupos do GeoNode administrados localmente e que não são enviados pelo IdP, a estratégia de sincronização deverá ser customizada.

Eu separaria duas coisas: grupo funcional e privilégio administrativo do GeoNode. Um grupo chamado Gestores não significa necessariamente que esse usuário tem privilégios de Staff e/ou Superusuário.

Você pode criar uma role especial chamada admin, com isso é possível implementar uma pequena lógica adicional, por exemplo usando um signal do django-allauth, para controlar explicitamente:

user.is_staff = True
user.is_superuser = True

Essa separação evita transformar um grupo corporativo em sinônimo de superusuário da aplicação.

O tratamento de administradores é uma política adicional e não faz parte da configuração mínima necessária para autenticação OIDC e sincronização de grupos deste artigo.

Depois da implementação acima, é interessante realizar alguns testes de auditoria rápida:

docker compose exec django python manage.py shell -c "
from allauth.socialaccount.models import (
    SocialAccount,
)

for account in (
    SocialAccount.objects
    .filter(provider='corp-idp')
    .select_related('user')
):
    user = account.user
    data = account.extra_data or {}

    print(
        user.username,
        '| role(s):', data.get('role') or data.get('roles'),
        '| grupos:',
        [
            (g.title, g.slug)
            for g in user.group_list_all()
        ],
        '| staff:', user.is_staff,
        '| superuser:', user.is_superuser,
    )
"

A saída será algo semelhante a:

fernando.quadro
| role(s): ['gestores']
| grupos: [('Gestores', 'gestores')]
| staff: False
| superuser: False

Isso permite verificar em uma única consulta claim recebida, role, grupo no GeoNode e status administrativo.

Integrar o GeoNode a um Identity Provider via OpenID Connect não precisa significar criar uma grande camada customizada de autenticação. Boa parte da infraestrutura já existe no próprio GeoNode e no django-allauth. O ponto mais importante é entender o contrato entre os dois sistemas:

• Qual provider?
• Qual callback?
• Quais scopes?
• Quais claims?
• Qual identificador do usuário?
• Como chegam grupos e roles?
• Qual slug existe no GeoNode?

A partir daí, um pequeno extractor pode ser suficiente para adaptar as claims corporativas à estrutura de grupos utilizada pelo GeoNode.

O resultado é uma arquitetura em que a identidade fica centralizada no serviço corporativo e o GeoNode continua responsável pelo que faz melhor: controlar o acesso aos recursos geoespaciais.

Dear QGIS community

We know that many of you were waiting patiently for the next LTR release based on QGIS 4.x and Qt6.

However, there are still a number of issues with the 4.x builds which leave us hesitant to assign LTR status to a 4.2.x release as originally planned. To address this, we will be taking the following steps:

• Create a new LTR 4.x Blocker tag for issues that need to be resolved
• Request developers to tag any breaking features with the new blocker tag so we have a clear sense of what needs to be done
• Keep feature freeze until all blockers are gone.
• Stick to current schedule — but QGIS 4.2 will no longer be LTR
• Extend the QGIS 4.4 paid bug fixing period to 6 weeks instead of 4 (and retain 4 week feature freeze)
• Disable broken features if needed and communicate the feature regressions as part of the changelog
• If there are still remaining blockers that we cannot simply disable at the end of the 6 weeks we will extend the release (last resort option)

As per the table above, the currently anticipated date for the QGIS 4.4.4 release (which is scheduled to become LTR) is 5 March 2027.

For now, future LTR releases are keeping their original schedule. Please watch the news feed in QGIS for further updates if you want to keep track of our progress. You can also follow our plans on the release roadmap page.

Thank you,

Tim Sutton, on behalf of the QGIS PSC

I finished my final race of the season and had fun doing it in spite of tough conditions. Here are the numbers for weeks seventeen and eighteen, including the Run Rabbit Run 50 mile:

• 31 hours, 12 minutes all training

• 75.93 miles running and hiking

• 11,929 feet D+ running and hiking

In week seventeen I tried to maintain a reasonable volume of training and do quality workouts. I ran four times, with some modest hills, and a fast group run at Pineridge. This was my last week of unemployment this summer, so I tried to enjoy going to bed early and sleeping late.

Week eighteen was race week, and also the start of a my job (subject of a future post). I biked eleven miles each day, Monday through Friday, and did one lunchtime run from work on trails going north to Reservoir Ridge Open Space. I slept well, ate well, and on Friday afternoon I drove to Steamboat Springs to prep for Run Rabbit Run. Picked up my bib, checked in drop my bag, and went to my hotel room to pack for Saturday. I expected rain during the race. My drop bag had spare shirt, socks, and shoes, and I would have access at miles 18 and 32.

I heard rain Friday night, and that would be Saturday's theme. There were some flashes of lightning as we gathered at the start line before 6 a.m., and ten minutes in the skies opened up. It poured for over an hour, stopping just before I reached the Mount Werner Aid Station (6.4 miles, 10,372 feet). It wasn't cold, because this was the last summer monsoon event of the year, so I left my rain jacket inside my pack, in its waterproof stuff sack, and resigned myself to being wet.

It rained intermittently all day. Flat sections of trail were often flooded. My feet were wet for the duration of the race. My shoe choice worked out well. The NNormal Kjerag 2 that I wore have less material than most trail shoes, and do not absorb much water. I lubed my feet before the start, wore my thin Darn Tough socks, and was fine. I fully plunged into puddles in the second half of the race instead of dancing around them, and had no regrets. No blisters, no trench foot.

During the middle third of the race there were some sunny breaks. My hat and gloves dried out a bit. The aid stations were serving hot food and hot drinks. I found some fun folks to run and chat with. The Dumont Lake Aid Station (23 and 27 miles) was packed with volunteers, crew, and spectators, an enjoyable spectacle. I reached the Rabbit Ears rock formation, the turn-around point, in the best conditions of the day. I'll remember this every time I drive past on US-40.

Rain returned in the last third of the race. I unpacked my rain jacket and it stayed on for the duration. It was a wet slog from mile 32 until Mount Werner, again (mile 44), and slippery in places, and then there was another thunderstorm at the finish. I had fun out there, but was also super glad to be done.

It's always good to see Baby Yoda on the course. Mile 37.

The slow 50 mile and 100 mile runners share the last 10 miles of the race. I took every opportunity to pump up the folks who were going to finish the 100 mile race after 33-36 hours. That's going to be me, one day.

Run Rabbit Run was well organized and fun. The aid stations were first class and the Park Range backcountry is beautiful. I'll return to this, happily.

Me, in sweater, hat, and gloves, with the last rain of the day in the background at the Four Points Lodge. MIle 46.

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