A new major release is available of the open-source WebGL mapping framework MapLibre GL.

This release is a big step for MapLibre GL JS! With more than 500 commits, and almost a year in the making, version 3.0.0 is surely our best release yet.

Notable changes include:

  • The release completes the transition to WebGL2, bringing better interoperability with other WebGL2-based frameworks and better performance through parallelisation,
  • transformCameraUpdate provides a hook that allows you to manipulate the map’s camera state, ideal for use with reactive front-end frameworks where the camera-state properties are stored externally,
  • Better, continuous interpolations when using HCL interpolations via interpolate-hcl,
  • Several improvements to stabilise 3D terrain display.
  • Several performance improvements make MapLibre generally faster.

VersaTiles: An Open-Source Web Mapping Stack

VersaTiles is a set of open-source applications that form a complete stack to create, host, and visualise OpenStreetMap data on the Web using vector tiles.

From the VersaTiles website:

VersaTiles lets you use OpenStreetMap based vector tiles, without any restrictions, locked-in paid services or attribution requirements beyond OpenStreetMap. You can use the freely downloadable tilesets from VersaTiles on your own infrastrure, in any way you like. Our open spec, royalty free and permissively licensed conatainer format works with virtually any webserver or CDN — with no requirement to pay unreasonable prices for “Tiles-as-a-Service”.

It includes a tile generator, based on TileMaker that produces tiles in the Shortbread schema. A converter produces tiles in the custom *.versatiles format from MBTiles. The VersaTiles format results on a smaller footprint—compared to MBTiles—and it doesn’t use SQLite under the hood. That means you can host it pretty much anywhere, either using the VersaTiles server or on a CDN; and clients can utilise HTTP range requests to access a subset of the data. The front-end is based on MapLibre, and includes map styles and a range of open-source fonts. v8.9 introduces interesting new features:

  • OGC Web Map Service (WMS) layers (Yes, they still exist),
  • A terrain extension allows developers to render 2D data on a 3D surface, and
  • Collision filters, hiding overlapping features and resulting in cleaner visualisation of dense data. doesn’t get much recognition, but it looks like a serious web-mapping toolkit.

The market for open-source web-map libraries is getting crowded again. Some classic libraries are still around: OpenLayers, Leaflet, and MapboxGL (technically not open-source). With MapLibre, Gleo, and, some promising new implementations are on the rise. Technology-wise, map front-ends have stalled in the last couple of years. I hope this newfound competition results in advancements in the field.

Planet has published a library of React components to build map user interfaces using OpenLayers:

The @planet/maps library provides components for rendering maps in your React applications. The library acts as a wrapper around OpenLayers, transforming the imperative API into declarative components.

The design goals:

The purpose of this project is to provide a mapping between React’s declarative components and OpenLayers’ imperative API. In other words, this project provides a React renderer for OpenLayers.


  • Components exported by this package map 1:1 with classes exported by OpenLayers.
  • Component props map directly to properties that are settable on instances of OpenLayers classes. Exceptions to this are props like options (passed to the constructor only), listener props (e.g. onChange), and ref.
  • Components accept a ref that provide access to the underlying OpenLayers instance.

The examples only show a small fraction of the whole feature set of the library. I looked through the source code on GitHub, and it seems like many—if not all—OpenLayers classes have a corresponding React component in the library.

Fiona, the Python library for reading and writing features from and to various data sources, has a new release. From the release notes:

The major new features are:

  • A new CRS class identical to Rasterio’s.
  • New Feature and Geometry classes. These are returned instead of dicts but are compatible with version 1.8’s dicts. _ Access to format driver metadata.

Wheels of the new release are also available for M1 Macs now.

Terra Draw, a Cross-Library Drawing API

James Milner released an alpha version of Terra Draw, a JavaScript library that implements adapters centralising drawing functions across different map libraries. Instead of building functionality to draw rectangles, lines, or points for each mapping API, you can now learn Terra Draw and be done with it.

Leaflet, MapboxGL and Google Maps are supported; of the major contemporary libraries, only OpenLayers and MapLibre are currently missing. Terra Draw supports creating and editing points, lines, polygons, and circles and even includes a freehand tool.

Most products are set on one mapping library, and Terra Draw will be less valuable. But there are a couple of scenarios where Terra Draw is useful. Terra Draw could be an option if you’re building a new product and haven’t decided (or don’t want to commit) to one mapping library or base map provider. It allows you to focus on the problem, not the technology. In consulting, when different projects often require a different provider, Terra Draw allows transferring solutions across various projects, potentially freeing up time to work on other things. And TerraDraw enables you to adhere to engineering best practices: The drawing implementation is abstracted away so you can switch libraries later; for example, when a vendor decides to change to a more restrictive proprietary license.

Iván Sánchez Ortega introduces Gleo, a WebGL mapping library he’s been working on for a couple of months now:

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.

Why you ask, if we already have OpenLayers and MapLibre doing pretty much the same thing:

The point is being able to understand the architecture of a WebGL map library. Because, as I said several times during the conference [FOSS4G], I still don’t understand what a “bucket” is in Maplibre parlance.

Building something for the sake of understanding the fundamentals of some technology is a perfectly fine reason to reinvent the wheel.

You can view the code on GitLab or follow Iván on Mastodon or Twitter, where he posts regular updates about his work on Gleo.

There’s some real momentum right now surrounding MapLibre. AWS started sponsoring the project in August; there’s talk about joining the MapLibre and Maputnik communities, and now Stamen is getting involved to work on MapLibre’s native SDK. 

Stephanie May, Damon Burgett, Stamen:

We are happy to share that we have begun work on improving MapLibre Native with technical leadership by Wet Dog Weather and funding from AWS.

The announcement from the MapLibre organisation provides further detail:

A design proposal for the modularization of the map rendering architecture can be found at #547. This modularization will allow new rendering architectures to be implemented quickly and more easily, and we anticipate that the modularization will give us a concrete framework to better interrogate various migration strategies.

I love this approach, gathering feedback from the community before starting the work to make actual changes to the code and architecture.

Polylines are an efficient way to represent line geometries. You provide a geometry, and out comes a scrambled string of letters and numbers that encodes the geometry in just a few characters. Polylines are helpful when you want to efficiently transfer geometry information between services. The Mapbox Static Images API, for example, can overlay complex geometries from Polylines, which wouldn’t be possible otherwise because the request-URL length is limited.

Placemark has released a new Polyline JavaScript library, allowing developers to encode or decode coordinate arrays and GeoJSON objects. It does pretty much the same as existing Polyline utilities from Mapbox or Google. Still, Placemark’s solution is a modernised implementation that includes TypeScript types and a neat autogenerated documentation site; it supports ESM and UMD imports and standardises longitude-latitude order.

A New Major Version for Leaflet Is in the Works; Catching up With Latest Technological Developments

Leaflet was one of these libraries that I thought were done. While there have been constant updates and new releases throughout the years, there were rarely any massive, ground-breaking additions. Leaflet is built perfectly against its small, well-defined scope. Huge changes just weren’t necessary.

Even great software is never done because it needs to keep up with the latest technological developments. And so development of a new major release for Leaflet was announced as part of the 1.9 release notes. The work for the next major version catches up with recent developments in the browser market, the JavaScript landscape and compiler tooling:

  • Dropping support for Internet Explorer.
    This has been a long time coming, but now that Internet Explorer is officially end-of-life, it’s time to say goodbye. Going forward, Leaflet will move to an evergreen strategy that targets browsers like Firefox, Chrome, Edge and Safari.
  • Embracing modern JavaScript.
    To maintain backwards compatibility, Leaflet is written entirely in ES5, a version of JavaScript supported by legacy browsers. So we have not been able to make use of many great JavaScript features (e.g. standardized classes, instead having to rely on our own implementation). By adopting a more modern version of the ECMAScript standard, we can start working towards aligning Leaflet with what is expected from a modern JavaScript library.
  • Standardized modules.
    When we released Leaflet v1, the landscape in the JavaScript world was very different and full of competing module standards such as CommonJS, AMD and UMD. Today, ECMAScript modules have become the clear way forward to unite the JavaScript ecosystem under one banner. Moving forward, Leaflet will only be distributed in a single standardized module system, greatly reducing complexity of our distributed code.
  • Removing the Leaflet global.
    As a developer using Leaflet, the capital letter L is probably intimately familiar to you. This is the Leaflet global where all of Leaflet’s functionality lives. To allow compiler tooling to better eliminate dead-code through a process called tree-shaking, we are removing this global variable. To preserve backwards compatibility with older plugins, we will provide a shim that can be imported manually that will restore this functionality.

There’s no release date, not even an estimate, and maintenance of the 1.x branch will continue in the meantime.

Felt have hired Erica Fischer and are reviving development of Tippecanoe, which hasn’t seen many updates in the last couple of years. The last release was on over two years ago.

Tippecanoe is an essential tool for geospatial-data providers. It creates vector tile sets from various geospatial formats and optimises the data for visualisation purposes, so the resulting maps allow viewers to understand the density of a data set without clustering or excluding data.

Speaking in the Felt blog, Erica hints at what might be next in store for Tippecanoe:

The special challenge of Tippecanoe at Felt is that it is being applied to user uploads with no opportunity for manual configuration, so it has to be able to make efficient, faithful, good-looking tiles without being given any hints about what kind of data it is tiling. I already know that it doesn’t currently do very well at low zoom levels with topographic contours, or with gridded data represented as individual polygons, or with continuous urban parcel polygons, or with branching systems of rivers, and I’m sure the uploads will also soon reveal other usage patterns that need to be detected and given some special treatment.

Felt will maintain Tippecanoe in a fork; Brandon Liu, of Protomaps fame, has also been working on another fork — and they are planning to unify development going forward.

Excellent open-source citizenship all around.

MapServer 8.0 Adds OGC APIs and FlatGeobuf Data Sources

MapServer 8.0 was announced last night; adding, amongst other improvements, two features that stand out:

MapServer, together with PostGIS, was one of the first open-source GIS libraries I used as a Geography student some 20 years ago. If my memory isn’t too clouded, MapServer was among the first open-source products to implement OGC standards. Fantastic news that it’s still under active development and keeping up with the latest developments in the industry.

OpenLayers 7.0.0 Adds More WebGL Renderers and Drops Internet Explorer

Just in time for FOSS4G next week and the annual OpenLayers Feature Frenzy, the OpenLayers team has released 7.0.0, a new major version. Over 90 pull requests went into this release, but two changes stand out: Internet Explorer is no longer supported. And WebGL rendering has been extended to support lines and polygons alongside points.

A renderer converts geo-data into data structures that browsers can render. In the past, OpenLayers has primarily relied on the Canvas API to render vector data. Compared to Canvas, WebGL is considered more performant, especially when visualising complex geometries or large datasets.

Adding more WebGL-rendering capabilities to OpenLayers has been an ongoing effort in the last few years, and there’s more to come:

The rendering API is still low level and experimental. Future releases will include a higher level styling API.

Technically this is a breaking change, but upgrading should be straightforward, according to the release notes:

[W]e changed the signature for a number of methods on a helper class that had been marked as part of the API in 6.x releases. While this is technically a breaking change, it is unlikely that applications were using this helper class, so upgrades should be straightforward.

Thematic-Mapping Library Bertin.js Reaches 1.0 Milestone

I somehow missed this: Bertin.js has reached a significant milestone with its 1.0 release.

Screenshot of a map created with Bertin.js. It shows the whole world in the Interrupted Goode Homolosine projection, each continent is depicted in a different colour.
A world map produced with Bertin.js. Screenshot from @neocartocnrs.

Bertin.js is a JavaScript library that simplifies creating static thematic maps in SVG, primarily for print, online publications or presentations. You can certainly add a level of interactivity, but Bertin.js isn’t designed to replace, or compete with, interactive-mapping libraries like Leaflet, OpenLayers, or MaplibreGL.

Bertin.js provides a comprehensive API to make thematic maps using classification, cartograms and tooling to add map components, such as titles, footers, legends, or graticules. It is a wrapper around D3’s powerful mapping capabilities, providing reasonable defaults so you can focus on designing your map and don’t have sweat intricate details such as creating a legend and specifying individual pixel coordinates to perfectly align symbols and labels.

The examples are impressive.

Following last week’s post explaining the tile-addressing schema in PMTiles version 3, Brandon Liu now discusses its compression approach reducing the disk space required to store a global tile dataset to only 91.6 MB.

Update: Brandon clarified on Twitter, the 91.6 MB mentioned above only holds the data required to map Z,X,Y coordinates to the corresponding Tile ID. The actual global map data set is 80GB. (15 August 2022)