This year’s FOSS4G Europe took me to Timișoara, the largest city in western Romania. The event was hosted by the West University of Timișoara (Universitatea de Vest din Timișoara).
I travelled there for 52°North to listen, to talk to people, and to present “Optimizing Resource Usage of Interoperable Geospatial Processing Infrastructures with Kubernetes.”
More on that below. The journey took me from the heat dome in Germany to the heat dome in Romania.But now, let’s set the scene.

A city with a talent for new beginnings

Timișoara is not a neutral backdrop for a conference about geospatial Free and Open Source Software. This is the city where the Romanian Revolution of 1989 began: the protests that started here spread across the country and brought down the Ceaușescu regime within weeks. The city still carries that memory visibly — in memorials, street names, and how readily people will tell you about it.

It is also a city that has been Hungarian, Ottoman, Habsburg and Romanian in turn, with Orthodox, Catholic, Protestant, Jewish and Serbian communities living side by side for centuries. The result is a population that is genuinely multilingual and, as far as I could tell from a week of conversations, remarkably open-minded and welcoming.
The restored baroque city center, with its three great squares strung together, is worth the trip on its own.

Here is a nice piece of history for the geospatial crowd: János Bolyai, one of the founders of non-Euclidean geometry, was stationed in Timișoara as a military engineer in the early 1820s. He was born in Cluj and died in Târgu Mureș, but it was from Timișoara, in 1823, that he wrote the famous letter to his father announcing his result: “out of nothing I have created a strange new world.” Two hundred years later a few hundred people came to the same city to argue about the latest developments in the geospatial FOSS community. A smaller but sincerely felt observation: Romanian universities have air conditioning in the lecture rooms — all of them.

My takeaways

The conference brought together a large part of the European geospatial FOSS community, with a healthy number of international guests. What follows are the threads I followed; it is not a summary of the full program and I certainly missed some good talks in parallel tracks.

Inspiring keynotes

Of all keynotes I attended, the following are my most important takeaways for quite different reasons.

The first was a call to action on European digital sovereignty! Open source geospatial software has become part of the European policy conversation and the community has more influence on it than it tends to assume — but that influence has to be actively maintained. Responding to consultations, showing up in standardization bodies, making the case to public procurement that FOSS is not a risk to be managed, but the mechanism by which you keep control of your own data and infrastructure. If you work for a public body, a university or a company in this field, that is part of the job now, not an extracurricular activity.

The second offered insights into UK and global crime prevention studies built on open geospatial intelligence and open data. The methodology was interesting in itself, but the design lesson is the one I kept repeating to people afterwards: keep the interfaces for non-geo-experts as simple and minimalistic as possible. The analysts, officers and policy people using these systems do not want a GIS. They want one map, one question, one answer. Every affordance added for expert users is a cost paid by everyone else.

AI in geospatial FOSS projects — pros and cons

Unsurprisingly, AI was everywhere, but the tone was more sober than at previous editions. The better talks were less “we added a chatbot” and more about where machine learning actually earns its place in a FOSS stack: feature extraction, data cleaning, assisted digitizing, natural-language entry points to catalogs and APIs. The counter-arguments got real airtime too — reproducibility, energy and infrastructure cost, opaque training data, and the risk of pushing communities back into dependency on a handful of non-European providers just as we are arguing for sovereignty elsewhere. DGGS (Discrete Global Grid Systems) came up repeatedly in this context, as a way to give analysis and ML pipelines a consistent, hierarchical spatial index instead of ad-hoc tiling.

QGIS, QField and QFieldCloud

The QGIS ecosystem showed how far the field-to-desktop-to-cloud loop has come: QField and QFieldCloud are being used as the data capture layer for digital twin projects, with 3D scenes and live sensor streams feeding into the same projects.

GeoServer 3, and GeoServer in production

I attended several GeoServer related sessions. One covered the GeoServer 3 upgrade in detail: what changes, what breaks, the Spring/Java baseline, and the migration issues people have already run into. The honest answer to “should we upgrade now?” was, as usual, “test with your own data directory first, but ASAP to stay safe”.

The second was about running GeoServer in production, and turned into one of the most practically useful discussions of the week: authentication and authorization setups (OIDC/Keycloak in front, per-layer rules behind), and which plugins are actually worth having in a production deployment versus which ones quietly cost you stability. All details are available from Geosolution’s own blog post about their FOSS4G EU attendance.

pygeoapi updates — and my own talk

pygeoapi project updates covered the current state of OGC API support and the growing set of backends and plugins.

My own talk followed directly afterwards, which was convenient: “Optimizing Resource Usage of Interoperable Geospatial Processing Infrastructures with Kubernetes.”

The problem

The work is driven by three projects. In I-CISK, which supports local communities in building tailored climate services, we ran scheduled import and pre-processing tasks as CronJobs triggering an OGC API – Processes endpoint. Everything was Python, everything ran in a single execution environment behind a simple process manager and to survive peak load, the whole deployment had to be sized for the heaviest job it might ever run. That works, but it is wasteful for most of its lifetime. DIRECTED, which works on interoperability across disaster risk management and climate adaptation, made the point unavoidable: one of its processes is a GPU/CUDA pluvial flood model that runs for about 45 minutes, another is a Python multi-criteria analysis for adaptation measures that finishes in roughly ten seconds. Sizing one environment for both is hopeless. TwinShip needs an API in front of a long-running weather routing tool. The requirement we distilled from all three: execute data processing workflows in heterogeneous environments in a cost-efficient and resource-efficient, FAIR way.

The ingredients

pygeoapi, which we already use across projects for process management, data serving and as a library, is an OGC-certified reference implementation for Features, EDR, Tiles and Processes. And Kubernetes, whose Job and CronJob primitives, resource requests and limits, node pools with taints and tolerations, and cluster autoscaler happen to map remarkably well onto “run this geospatial process somewhere appropriate, then stop paying for it.”

The solution

We implemented two pygeoapi extension points — a job manager and two processors (a hello-world one and a configurable Generic Image Processor). The manager translates incoming OGC API – Processes requests into Kubernetes API objects. From there, the API server does the heavy lifting and effectively acts as the job store, holding job metadata, state and results. The pygeoapi deployment itself stays small and dispatches load to job pods, which are scheduled onto node pools offering more CPU, more memory or GPUs as the individual process requires.

Two details worth highlighting:

• No code to add a process: Which processes are offered is configuration, applied at deployment time or at runtime — so a new containerized process does not mean a new implementation.
• Getting results out of an ephemeral pod: Job output has to live somewhere other than the pod that produced it. We either link to external storage or JSON-encode results in the pod logs, and use a finalizer as a pre-delete hook to extract that information from the logs and store it in annotations before the pod disappears.

A documented service account with explicit RBAC rules is the price of admission for talking to the API server, and worth spelling out properly rather than discovering later.

All details can be found in the public slides and the project’s repository.

Thanks to everyone who came, asked questions and pushed back afterwards!

Thank you

Many thanks to the local organizing committee, the volunteers and the West University of Timișoara for a well-run, warm and genuinely enjoyable conference — and to everyone who spent a coffee break explaining their stack to me.

A teaser of the future “FOSS4G 2027 in Bristol, UK”:

If you are interested in learning about how we can help you achieving your goals with open source products make sure to talk to us! Check out our solutions portfolio and get in touch. And if you want to get even more involved, check the latest career-opportunities.