Events in room H.1301 (Cornil)

Welcome to the Geospatial devroom

PyQGIS. A not so well guarded secret in the most popular open-source geospatial system. You struggle doing a thing, and then open this one panel... And turns out, every single thing that you can click on, is available for programmatic calls. Load data, style it and process, prepare layouts for exporting, add panels and interactive modes, even add games using the GIS user interface. Everything.

Geospatial is hard. Software is hard. Making a new software for a one-time or an obscure process would be prohibitively complex. So no wonder many people turn towards QGIS for its extensive plugin capabilities. But what if we need to make something for the mobile?

This talk is about Every Door plugins. Every Door is an OpenStreetMap editor for going outside and collecting data. It's been custom designed for the OSM schema. But turns out, we've got thousands other services and processes on top of OSM, and many people would like "just one more button" or a panel. Let's see what has changed in Every Door over the winter that enables you to do so.

The MapLibre community is currently in the midst of developing the MapLibre Tile Format, a modern, open, and fully community-governed successor to the ubiquitous Mapbox Vector Tile (MVT) format. While MVT has served the mapping ecosystem well for over a decade, it also carries historical constraints that limit interoperability, formal specification quality, extensibility, and independence from proprietary platforms. As MapLibre continues to grow as the central open-source foundation for web-based map rendering, it has become increasingly clear that a future-proof, openly specified, and collaboratively designed tile format is essential.

This talk will offer a look into why we initiated this engineering effort and what gaps the new format aims to close. I will explain the core design principles behind the specification—clarity, strictness where needed, optionality where useful, and full transparency throughout the process. Attendees will gain a technical understanding of how the format works, including its data model, feature encoding strategy, metadata approach, and compatibility considerations for existing infrastructure.

Beyond the current specification draft, I will outline the major areas still under active development. These include discussions about schema evolution, advanced geometry representations, compression strategies, and interoperability with raster, elevation, 3D and non-geographic datasets. I will also provide insight into the collaborative workflow between maintainers, researchers, vendors, and the wider open-source community, highlighting where contributions and feedback are particularly welcome.

Finally, the talk will cover how the rollout is progressing in practice. This includes early tooling support, reference implementations, testing frameworks, and real-world trials by organizations exploring migration paths away from MVT. The session will present an honest, up-to-date snapshot of the project’s status and a forward-looking roadmap for the next stages of development, helping the community understand both what is ready today and what is still on the horizon.

Boost.Geometry is a C++ library defining concepts, primitives and algorithms for solving geometry problems. It contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, on top of which algorithms are built: area, distance, convex hull, intersection, within, simplify, transform etc.

The library contains instantiable geometry classes, but library users can also use their own legacy geometry types. It also contains spatial index allowing to perform spatial and knn queries on a collection of geometries.

In this talk we will introduce Boost.Geometry focusing on mapping and GIS. Boost.Geometry is the engine behind MySQL’s spatial query capabilities. The presentation will highlight recent developments in the library and conclude with a roadmap of the future work in Boost.Geometry.

OpenStreetMap community often seek for tooling to organize topic-focused contribution projects and monitoring is crucial to set appropriate encouragement in the areas were it's most needed. Dealing with significant amount of daily change files or oversized historical data can be challenging if you want to focus on a given topic among the whole OSM changelog like the needle in the haystack. Podoma is a free software intended to do this hard work for you, guiding you through the change log and counting as quick as no one. It provides web interface, useful API and KPI to be at ease with monitoring specific topics worldwide or around your house in OpenStreetMap.

This talk will introduce Podoma, its basic functionalities and showcase the build of a monitoring project live from the raw OpenStreetMap data.

This talk presents a FOSS stack for building, rendering, and using OpenStreetMap vector tiles. Ascend Maps ( https://github.com/styluslabs/maps ) is a cross-platform application for interactive maps. It is extremely customizable, with hiking, cycling, and transit views for the base map, user-editable sources, styles, and shaders for custom maps and overlays, and plugins for search, routing, and map sources.

tangram-ng ( https://github.com/styluslabs/tangram-ng ) extends the Tangram ES map engine originally created by Mapzen, adding support for 3D terrain, embedded SVG, and additional raster formats, along with substantial performance and stability improvements.

geodesk-tiles ( https://github.com/styluslabs/geodesk-tiles ) builds vector tiles on demand from a GeoDesk library, making it possible to start serving tiles for the whole world instantly.

For a year Citybikes has been publishing bike share time-series data, as monthly parket files.

Join me in this demo session on which we will explore bike share data, both official trip data and citybikes data, using duckdb to generate usage heatmaps, all around the world!

Writing scripts that involve spatial data often gets messy fast, because of the number of formats, plethora of tools, and volume of data.

Jupyter and similar notebook environments help with some of these problems, but can tend to favor one language at a time, and require a GUI or other environment for execution rather than a single "script".

In this talk we introduce a new experimental console-based tool -- samaki -- which provides

• a simple text format for combining source code and tools from multiple languages

• a flow for iteratively generating files in many data formats that are interdependent

• a mechanism for adding bespoke visualization and other tooling during the coding lifecycle

And we look at examples of using this fast flow for doing things like pulling from OpenStreetMap, manipulating geoJSON, analyzing with DuckDB, leveraging PostGIS and using LLMs judiciously.

https://github.com/bduggan/raku-samaki

https://raku.land/zef:bduggan/App::samaki

⚠️ Spoiler Alert ⚠️ One day, you are going to die.

You may not get a blue plaque on the side of a building, or a statue, or even a Wikipedia entry. But perhaps you’ll get a memorial bench?

We built https://openbenches.org where anyone can add to a collection of open data.

We’ll show you why & how we built this collection of >39,000 memorial benches from around the world, how it integrates with OSM, and what we learned along the way.

BIMS is an open-source platform for serving, analysing and sharing biodiversity data, built on top of the Django framework. It started as the Freshwater Biodiversity Information System (FBIS) in South Africa and has since grown into a family of portals across Africa and beyond, supporting water resource managers, conservation agencies and researchers. One of the long-running public instances is freshwaterbiodiversity.org. BIMS is a multi-tenant application, so a single deployment can host multiple, independent biodiversity portals on the same codebase.

It started as a simple idea — teaching colleagues how to use OpenStreetMap. A few sessions later, more than a hundred people had learned not just how to map, but why it matters.

This talk follows two parallel stories: the trainees who discovered new tools, confidence, and purpose through digital mapping, and the company that found a new way to connect its volunteer days with growth and community impact.

Together, they show how learning to map the world can also reshape how we see our own roles, our teams, and our shared capacity to make a difference.

Geospatial analysis and GIS workflows are traditionally tied to heavy desktop applications, steep learning curves, and complex toolchains. JupyterGIS transforms this paradigm by enabling fully interactive, browser-based GIS workflows inside JupyterLab. Researchers, educators, and developers can now visualize, analyze, and edit spatial data collaboratively, leveraging modern web technologies while retaining the power of native geospatial engines.

This talk presents how the Project Jupyter, WebAssembly, and GDAL communities collaborated to build a complete, interactive GIS environment for both desktop and browser platforms. JupyterGIS integrates OpenLayers, GDAL compiled to WebAssembly, and Python or non-Python kernels to deliver: - Real-time collaborative editing of GIS datasets, including QGIS formats - Fully client-side geospatial analysis pipelines with raster and vector support - Customizable symbology and interactive visualizations, including graduated, categorized, and multi-band styling - Notebook integration for embedding, documenting, and sharing workflows - Support for cloud-based and local spatial datasets, as well as STAC asset catalogs

Technical Highlights: - WebAssembly (WASM): GDAL compiled to WASM enables high-performance spatial operations directly in the browser, without server dependencies. - Collaborative Editing: Built on Jupyter’s collaborative document model (PyCRDT & Y.js), multiple users can edit layers simultaneously with conflict-free synchronization. - Extensible Architecture: Modular command system allows custom tools, plugins, and integration with Python or other kernels. - Integration with Modern Stacks: Seamless support for xarray, Pangeo ecosystem, and upcoming features like story maps and R kernel integration.

Demos & Use Cases: - Interactive vector and raster layer editing with live symbology updates - Performing geospatial analysis entirely in-browser using GDAL WASM pipelines - Collaborative multi-user editing sessions with conflict-free layer management - Story maps and visualization dashboards for environmental, policy, and STEM applications

Target Audience: Researchers, educators, geospatial developers, students, and open source enthusiasts interested in GIS, WebAssembly, or interactive computing.

In an era of unprecedented availability of Earth Observation (EO) data, the Copernicus Data Space Ecosystem (CDSE)(https://dataspace.copernicus.eu/) plays a key role in bridging the gap between data accessibility and actionable insights. Despite the availability of freely accessible satellite data, the widespread adoption of EO applications remains limited due to challenges in extracting meaningful information. Many EO-based projects struggle with non-repeatable, non-reusable workflows, mainly due to the lack of standardized, scalable solutions. CDSE tackles these barriers by adopting common standards and patterns, most notably through openEO(https://dataspace.copernicus.eu/analyse/openeo). This open-source solution is a community-driven standard that simplifies access to, processing, and analysis of remote sensing data by offering a unified platform. It empowers developers, researchers, and data scientists to use cloud-based resources and distributed computing environments to tackle complex geospatial challenges. Adhering to the FAIR principles (Findable, Accessible, Interoperable, and Reusable), it supports the global sharing and reuse of algorithms, enhancing collaboration and scalability.
Furthermore, by promoting the development of reusable, scalable, and shareable workflows, openEO enhances the efficiency and reproducibility of the EO workflow. Its feature-rich capabilities have also been used and validated in large-scale operational projects such as ESA WorldCereal and the JRC Copernicus Global Land Cover and Tropical Forestry Mapping and Monitoring Service (LCFM), which relies on its robust and reliable infrastructure. Through this session, we aim to present users with openEO and its capabilities. We will highlight how users can seamlessly convert algorithms into a process graph, thereby creating reusable services.

Frontline health managers are on the sharp end of climate change, yet rarely have practical ways to use local climate signals in routine planning. Climate × Health Pulse (Climate Pulse, pulse.datakind.org) is an early-stage open prototype that fuses localized climate and health datasets into sub-county geospatial views and decision cues for county health teams.

In this talk and demo we’ll show an end-to-end, FOSS-first workflow: ingesting heterogeneous climate (e.g., temperature, rainfall, drought indices) and health indicators (facility reports, disease surveillance, vulnerability proxies), harmonizing them with open standards, and publishing actionable map layers for operational use. The initial pilot focuses on Kajiado County, Kenya, where heat stress, water scarcity, and shifting vector-borne disease risk create urgent planning needs.

We’ll highlight what works, what’s hard, and what’s next: data interoperability, scalable analytics, offline-friendly UX for low-bandwidth contexts, and governance for sustainable local ownership. We’re actively seeking collaborators to co-develop Climate Pulse—especially on geospatial data layers, standards alignment, and field testing—so that open climate intelligence can meaningfully support health systems under pressure.

In this session, we'll create an analytical application from the ground up, covering the entire workflow: data collection, processing, and visualization. It will use Leaflet, ClickHouse, and a bunch of shell scripts. The result is published at https://adsb.exposed/, and I will uncover how it's done.

Caves surveying is a pretty obscure niche in mapping, with its own set of software. There have been great FLOSS tools since the 1980s, and in the last few years cavers realised that they could use 'normal GIS' too, so a slow convergence is underway. This talk will give a brisk tour of the FLOSS tools we use, and also talk about the complicated problem of managing datasets spanning 40, 50 or even 100 years, with changing equipment, formats, personnel and computing kit.

And we'll touch on the future of Lidar and VR for 3D space modelling.

Prominent projects are Survex: http://survex.com Therion: https://therion.speleo.sk/ Loser Expo/Troggle: expo.survex.com Tunnelx/Tunnelvr: https://github.com/goatchurchprime/tunnelx/ SexyTopo: https://github.com/richsmith/sexytopo Topodroid: https://sites.google.com/site/speleoapps/home/topodroid

• review of current GNSS-based positionning systems
• what's RTK (Real-time Kinematic)
• RTCM and NTRIP : industry classics, walled gardens...
• Centipede-RTK: a collaborative global open-data RTK network
• RTKBase: a free/open-source RTK Base station software
• Create your own base and participate!
• Millipede: a scalable/free/open-source RTCM caster for the next step
• C-based
• libevent, multithreaded, TLS
• RTCM streams: ideal use-case for IP anycasting
• return of experience on Millipede development
• multithreading + event-based: best of both worlds
• tests
• valgrind
• returns about AI assistance during development
• what's next?

https://github.com/pbeyssac/millipede-caster https://www.centipede-rtk.org/fr

The open-source tool OSM2World turns OpenStreetMap data into detailed 3D models of the world. This talk presents the current state of the project.

3D visuals are increasingly becoming a standard feature of geospatial applications. Whether you want to explore the world in your browser, build games and virtual reality applications, or export content to modelling software as a starting point for creative projects, you need software tools which fully support the third dimension.

OSM2World makes it possible to generate 3D content for these kinds of applications from freely available OpenStreetMap data. Usable as a library or stand-alone application, it generates seamless outdoor and indoor representations of buildings, displays road and railway networks, and creates models for a large number of other feature types found in OpenStreetMap data. With support for the glTF standard, physically based rendering (PBR) and 3D tiles displayed in the browser using WebGL, models produced by OSM2World serve a wide range of uses.

Nowadays, in the software industry, we already have a lot of ways to improve performance of our applications: compilers become better and better each year in the optimization field, we have a lot of tools like Linux perf and Intel VTune to analyze performance. Even algorithms are still improving in various domains! But how many of these improvements are actually adopted in the industry, and how difficult it is to adopt them in reality? That's an interesting question!

In this talk, I want to show you:

• Why accessibility of software performance matters
• How various software optimization approaches are different from the adoption easiness perspective: from different compiler optimizations to semi-automatic optimizations to a manual approach
• What things can be improved and how
• Many related open-source examples from my practice
• Share with you an idea behind the "Software performance" devroom

I hope after the talk you get an interesting perspective on software performance to think about.

Relying only on nvidia-smi is like measuring highway usage by checking if any car is present, not how many lanes are full.

This talk reveals the metrics nvidia-smi doesn't show and introduces open source tools that expose actual GPU efficiency metrics.

We'll cover:

1. Why GPU Utilization is not same as GPU Efficiency.
2. Deep dive into relevant key metrics: SM metrics, Tensor Core metrics, Memory metrics explained.
3. Practical gpu profiling and monitoring setup.
4. Identifying bottlenecks in inference workloads.

Attendees will leave understanding how to identify underutilized GPU and discover real optimization opportunities across inference workloads.

In scientific computing on supercomputers, performance should be king. Today’s rapidly diversifying High-Performance Computing (HPC) landscape makes this increasingly difficult to achieve however...

Modern supercomputers rely heavily on open source software, from a Linux-based operating system to scientific applications and their vast dependency stacks. A decade ago, HPC systems were relatively homogeneous: Intel CPUs, a fast interconnect like Infininand, and a shared filesystem. Today, diversity is the norm: AMD and Intel CPUs, emerging Arm-based exascale systems like JUPITER, widespread acceleration with NVIDIA and AMD GPUs, soon also RISC-V system architectures (like Tenstorrent), etc.

This hardware fragmentation creates significant challenges for researchers and HPC support teams. Getting scientific software installed reliably and efficiently is more painful than ever, and that’s before even considering software performance.

Containers, once heralded as the solution for mobility-of-compute, are increasingly showing their limits. An x86_64 container image is useless on a system with Arm CPUs, and will be equally useless on RISC-V in the not so distant future. What's worse is that portable container images used today already sacrifice performance by avoiding CPU-specific instructions like AVX-512 or AVX10, potentially leaving substantial performance gains on the table. Containerization also complicates MPI-heavy workloads and introduces friction for HPC users.

This talk introduces the European Environment for Scientific Software Installations (EESSI), which tackles these challenges head-on with a fundamentally different approach. EESSI is a curated, performance-optimized scientific software stack powered by open source technologies including CernVM-FS, Gentoo Prefix, EasyBuild, Lmod, Magic Castle, ReFrame, etc.

We will show how EESSI enables researchers to use the same optimized software stack seamlessly across laptops, cloud VMs, supercomputers, CI pipelines, and even Raspberry Pis—without sacrificing performance or ignoring hardware differences. This unlocks powerful workflows and simplifies software management across heterogeneous environments.

EESSI is already being adopted across European supercomputers and plays a central role in the upcoming EuroHPC Federation Platform.

Come learn why EESSI is the right way to keep the P in HPC.

Slow performance is often a major blocker of new visionary applications in scientific computing and related fields, regardless of whether it is embedded or distributed computing. This issue is becoming more and more challenging to tackle as it is no longer enough to do only algorithmic optimisations, only hardware optimisations, or only (operating) system optimisations: all of them need to be considered together.

Architecting full-stack computer systems customised for a use case comes to the rescue, namely software-system-hardware co-design. However, doing this manually per use case is cumbersome as the search space of possible solutions is vast, the number of different programming models is substantial, and experts from various disciplines need to be involved. Moreover, performance analysis tools often used here are fragmented, with state-of-the-art programs tending to be proprietary and not compatible with each other.

This is why automated full-stack system design is promising, but the existing solutions are few and far between and do not scale. Adaptyst is an open-source project at CERN (the world-leading particle physics laboratory) aiming to solve this problem. It is meant to be a comprehensive architecture-agnostic tool which:

• unifies performance analysis across the entire software-hardware stack by calling state-of-the-art software and APIs under the hood with any remaining gaps bridged by Adaptyst (so that performance can be inspected both macro- and microscopically regardless of the workflow and platform type)
• suggests automatically the best solutions of workflow performance bottlenecks in terms of one or more of: software optimisations, hardware choices and/or customisations, and (operating) system design
• scales easily from embedded to high-performance/distributed computing and allows adding support for new software/system/hardware components seamlessly by anyone thanks to the modular design

The tool is in the early phase of development with small workforce and concentrating on profiling at the moment. Given that Adaptyst has broad application potential and we want it to be for everyone’s benefit, we are building an open-source community around the project.

This talk is an invitation to join us: we will explain the performance problems we face at CERN, tell you in detail what Adaptyst is and how you can get involved, and demonstrate the current version of the project on CPU and CUDA examples.

Project website: https://adaptyst.web.cern.ch

Reliable performance measurement remains an unsolved problem across most open source projects. Benchmarks are often an afterthought, and when they aren't they can be noisy, non-repeatable, and hard to act on.

This talk shares lessons learned from building a large-scale benchmarking system at Datadog and shows how small fixes can make a big difference: controlling environmental noise, designing benchmarks, interpreting results with sound statistical methods, and more.

Attendees should leave with practical principles they can apply in their own projects to make benchmarks trustworthy and actionable. We'll illustrate each principle with real data — for instance, environment tuning that cut variance by 100x, or design changes that turned a flaky benchmark into a reliable one.

Mercurial is a distributed version control system whose codebase combines Python, C and Rust. Over its twenty years of development, significant effort has been put into its scaling and overall performance.

In the recent 7.2 version, the performance of exchanging data between repositories (e.g. push and pull) has been significantly improved, with some of our most complicated benchmark cases moving from almost four hours down to 2 minutes, a speedup of over 100x.

This talk uses this work as a case study of the multiple places where performance improvements lie. It goes over the challenges that arise from exchanging data in a DVCS, and the levers we can pull to overcome them: higher level logic changes, lower level algorithmic improvements, programming language strengths, modern CPU architecture, network protocol design, etc.

Despite the great results, exchanging data in version control remains a complex matter, and we lastly expose our ideas to further tackle its inherent complexity.

Database vendors often engage in fierce competition on system performance – in the 1980s, they even had their "benchmark wars". The creation of the TPC, a non-profit organization that defines standard benchmarks and supervises their use through rigorous audits, spelled an end to the benchmark wars and helped drive innovation on performance in relational database management systems.

TPC served as a model for defining database benchmarks, including the Linked Data Benchmark Council (LDBC, https://ldbc.org/), of which I've been a contributor and board member for the past 5+ years. Through LDBC's workloads, graph database systems have seen a 25× speedup in four years and a 71× price-performance improvement on transactional workloads.

Defining database benchmarks requires a careful balancing of multiple aspects: relevance, portability, scalability, and simplicity. Most notably, the field in the last few years has shifted toward using simpler, leaderboard-style benchmarks that skip the rigorous auditing process but allow quick iterations.

In this talk, I will share my lessons learned on designing database benchmarks and using them in practice. The talk has five sections:

1. The need for database benchmarks
2. TPC overview (Transaction Processing Performance Council)
3. LDBC overview (Linked Data Benchmark Council)
4. The current benchmark landscape (ClickBench, H2O, etc.)
5. Takeaways for designing new benchmarks

In the past 30 years we've moved from manual QA testing of release candidates to Continuous Integration and even Continuous Deployment. But while most software projects excel at testing correctness, the level of automation of performance testing is still near zero. And while it's a given that each developer writes tests for their own code, Performance Engineering remains the domain of individual experts or separate teams, who benchmark the product with custom tools developed in house, often focusing on beta and release candidates, with zero performance tests happening in the Continuous Integration work stream.

This talk is your guide to Continuous Performance Engineering, aka Continuous Benchmarking. We will cover standard benchmarking frameworks and how to automate them in CI, automating deployments of large end-to-end environments, how to tune your infrastructure for minimum noise and maximum repeatability, and using change point detection to automatically alert on performance regressions with a minimal amount of those annoying false positives.

JSON is one of the most popular data exchange formats. Parsing routines for it exist in every modern programming languages, either built-in, or included in popular libraries such as RapidJSON for C++ or json for Rust.

The task of conversion between JSON strings and Lua objects has been solved plenty of times before, but either the solutions are not focused on performance, or the parsers are too strict for the "relaxed" format we use at BeamNG.

What if we want to have the fastest Lua table <-> relaxed JSON conversion possible? We came up with a highly optimized LuaJIT code we use for handling JSONs at BeamNG since a few years. But there is a way to go further -- hacking on the C source code of the interpreter itself to add compiled built-in JSON support. How much extra performance can we squeeze out by going a level deeper?

Get ready for juicy benchmarks and an optimization story from a real usage perspective.

If you take a random program and start profiling it, you'll usually find that the memcpy function is at the top. However, this doesn't necessarily mean memcpy is slow. The most hopeless thing a C++/Rust developer can do (while no one is watching) is optimize memcpy to move bytes faster. That's exactly what we'll do.

Driven by application, compliance, and end-user requirements, companies opt to deploy multiple Kubernetes clusters across public and private clouds. However, deploying applications in multi-cluster environments presents distinct challenges, especially managing the communication between the microservices spread across clusters. Traditionally, custom configurations, like VPNs or firewall rules, were required to connect such complex setups of clusters spanning the public cloud and on-premise infrastructure. This talk presents a comprehensive analysis of network performance characteristics for three popular open-source multi-cluster networking solutions (namely, Skupper, Submariner and Istio), addressing the challenges of microservices connectivity across clusters. We evaluate key factors such as latency, throughput, and resource utilization using established tools and benchmarks, offering valuable insights for organizations aiming to optimize the network performance of their multi-cluster deployments. Our experiments revealed that each solution involves unique trade-offs in performance and resource efficiency: Submariner offers low latency and consistency, Istio excels in throughput with moderate resource consumption, and Skupper stands out for its ease of configuration while maintaining balanced performance.

In this talk, we'll explore how we built comprehensive load testing for React applications at Mattermost, achieving 100,000 concurrent users in production-like environments. We'll begin by revealing why traditional API testing missed critical browser issues that only emerged at scale. Next, we'll demonstrate our open-source tool that uses Playwright to run thousands of real browsers, measuring React-specific metrics like component render times, memory leaks, and state management bottlenecks. Finally, we'll share the optimization journey that reduced browser memory and enabled true production readiness, ensuring our React application performs flawlessly for enterprise customers.