About two months ago I attended a physical FOSS4G for the first time in 3 years. FOSS4G 2020 got cancelled, FOSS4G 2021 was fully remote (and organization was a bit hectic since COVID robbed us of its chairwoman, Malena Libman), but finally FOSS4G 2022 happened.

It was the time to finally unveil the pet project I had been working on for… years. It’s called Gleo, and it made a little smiling logotype for this unveiling:

Gleo logotype

What’s Gleo? In a nutshell, it’s a Javascript, WebGL-first, web mapping display library. It’s kinda reinventing the wheel of Leaflet/Openlayers/MapLibre, if such reinvention involved a lot of OOP architectural thinking.

(There will be a video of the whole 20(ish) minute presentation at https://video.foss4g.org at some point. Video processing always takes a while.)

But I’m not here to write about the Gleo architecture and its technical aspects - there’s some of that in a previous post (wrote before I named Gleo “Gleo”). Instead, I need to express a sigh of relief.

I came to the FOSS4G with a bit of a scare in me. After all, I’m reinventing the wheel of web maps, and every OpenLayers and MapLibre folk would probably judge me, and chastise me, and tell me that Gleo is a useless endeavour. Plus

But… that didn’t happened. The feedback was overwhelmingly positive. It is true that Gleo still doesn’t have feature parity with MapLibre regarding vector tile styling, and performance is a bit janky since I haven’t implemented web workers yet, and it is true that it’s not really “marketable” for some use cases. But that’s not the point of Gleo. The point is being able to understand the architecture of a WebGL map library. Because, as I said several times during the conference, I still don’t understand what a “bucket” is in Maplibre parlance.

I think that the best moment in the whole conference week was the 15-minute chat I had with Andreas Hocevar and Tim Schaub (AKA “The OpenLayers folks”). Again, I expected some chastising (specially since the work I did for the WebGL multispectral raster algebra in OpenLayers got superseded by Tim Schaub’s work), but I found the opposite: mutual peer recognition, and a lot of wonderful brainstorming and ideas sharing.

(By the way, if you use/like OpenLayers, consider supporting Andreas’ work)

A few other notable interactions were:

  • Anita Graser telling me where to find historical AIS data, so I can work on the whole “a time slider controlling the movement speed of thousands of features” use case.
  • Vincent Sarago AKA “the COG tzar” prompting me to add COG and raster algebra support. Obviously. There’s plans in Gleo for that, but it needs scalar field textures and acetate post-processors, and a bunch of other stuff. On the plus side, one of the items in the ultimate plan for Gleo is raster algebra on multiple warped raster files - combining channels from different images in different source projections.
  • Me telling Niene Boejien to read The Book of Shaders. Since Gleo symbols can be extended in a relatively easy way in order to use custom WebGL shaders (see TintedSprite), there’s a lot of undiscovered artistic map renderings to be explored.
  • Most striking, Roman Karavia actually using Gleo to display swiss topo maps (via a WMTS endpoint) and finding and fixing a bug in the process. Which tells me an important thing: Gleo code is readable.

A WMTS endpoint for topo maps (using an “uncommon” map projection) is a nice example of some of Gleo’s capabilities. There’s non-power-of-two scales (AKA “zoom levels”), but Gleo implements smooth scale changes (AKA “constant zooming speed”) and scale snapping - some hardly noticeable features that need an architecture designed for that; they are not features that can be slapped on.

It’s nice to see that the Gleo definition of tile pyramids can be readily adapted. Alas, at some point in the future I intend to parse the WMTS GetCapabilities document and build the pyramid automatically, but it’s kinda low priority.


The list of features to be implemented is huge. There’s clustering, and raster post-processing, and raster warping (“arrugating”), and time-based geometries, more vector tile styling stuff, web workers (which means an acetate message serialization protocol), animations, bugs regarding transparency and blending modes… lots of disparate stuff. But I feel capable of doing all that since I understand all the moving bits.

Which leads to a major point… I’ve been coding Gleo completely solo so far, and I intend to have a dual-licensing scheme (so I can re-license the whole shebang commercially to, you know, pay the bills and stuff) and use a GPL license (to avoid a situation like the MapboxGL2/MaplibreGL schism).

GPL should be fine since contemporary Javascript (leveraging .esm modules) paired with HTTP2/HTTP3 should mean one can publish the source files instead of some bundled & minified flavour (which would count as “compiled” by the GPL). But is it the absolute right choice? Should the whole thing be released under LGPL? Or under MIT/BSD?

I’m a bit undecided on that front, yet. And there’s a mountain of work ahead of me. But (and I cannot stress what a change this is for my mood) I feel optimistic about Gleo.