In late-2025, we received a grant through NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet program to integrate vector tiles in uMap. This is a huge amount of work considering that a few non-trivial steps are required prior to be able to achieve that goal!

What “vector tiles support” means for uMap? At least, being able to render tiles on the Mapbox vector-tiles format (the de-facto standard), but, and that’s the interesting and hardest part, ideally to be able to customize those tiles: what if I can add a vector tiles style, but remove the buildings or change the road colors, to better fit the purpose of my map?

uMap used to be 100% coupled with Leaflet. In fact, it was initially designed as a storage for Leaflet — the first version of uMap was just a wrapper around Laflet.Storage plugin and django-leaflet-storage backend (well, the really first version was called django-chickpea, but that’s archaeology…).

So, our first need is to decouple from Leaflet, and clearly separate the rendering and the data. This is a work we have already started in the last two years but it was still unfinished (is a software ever finished is left as an exercise for the reader). Then, we want to take advantage of ES6 modules to only load the required JS files and speed up maps’ rendering (especially for read only access!). Finally, we currently rely on a lot of Leaflet plugins which are mostly either outdated and/or unmaintained that we need to port or adapt to the new chosen ecosystem.

Given that context, we are ahead of a long run BUT we already started at a good pace! Follow current PRs if you are curious. Now you may wonder why we choose OpenLayers as a target goal for vector tiles rendering over existing alternatives. Here are some of the reasons:

• Leaflet is lacking vector tiles integration and is less active than before which makes us less confident that this feature eventually lands some day; we investigated adding that support by ourselves, through a plugin, but this is huge, it needs:
  • adding a WebGL renderer, which is basically a lot of math and optimizations
  • adding support for mapbox-vector-tiles specs, which is the hard part, specifically the label placing algorithm
  • and as we developers all know: creating a piece of code is the easy part, maintaining it over the time is the hard one
• We of course tested the scenario where we would keep Leaflet as engine, and only use MapLibre for the vector tiles part (through maplibre-gl-leaflet plugin); that immediately sort of work, but:
  • this is a read only scenario (a uMap user would not be able to customize the tiles)
  • this means adding around 700Ko of JS
• We investigated Gleo, we’ve been able to make it “sort of work” (with leaflet-gleo in the middle), but gleo does not have a label placing algorithm yet, so the hard part remains, and we were afraid of the current bus factor (even if Ivan is an amazing member of the community!)
• We first targeted MapLibre but eventually decided for OpenLayers. Here are the main reasons:
  • OpenLayers allows both object-oriented data model (close to Leaflet’s one) and also a more data-oriented data model (source vs. rendering) which is our final target. This allows a smaller first migration step.
  • OpenLayers is a battery included lib, and in the uMap history we had to fight a lot against plugins maintenance. It includes all the edition parts, which is a bit less mature and more fragmented in MapLibre ecosystem.
  • When uMap was born (more than 10 years ago), OpenLayers was already here, but Leaflet was the CoolKid© in the block which motivated Yohan to choose it. Now we are more mature ourselves (read: old) and are looking for a more stable ecosystem like OpenLayers which will be here and stable for a while too (like uMap!).
  • As a bonus, OpenLayers is already ESM ready (MapLibre is not yet) and we try to use modules as much as possible in uMap to be able to load files only on demand.

As always, that kind of decision is some kind of trade-off for maintainers (and also a bet). Trying to choose the correct balance between maintenance, features, community, activity and such. All this for people ~~not keeping the link to their anonymous map~~ trying to share their best mushrooms places (don’t do that :p).

---

Given that we only publish a post per year, another important news: we will slowly be moving to codeberg, hopefully before the end of the year.