MapLibre

MapLibre Newsletter September 2026

Thu, 01 Oct 2026 00:00:00 GMT

Welcome to the September 2026 edition of the MapLibre newsletter! A special thanks to our sponsor, Mapme, for their renewed sponsorship and steadfast support since 2024. This month is packed with major milestones across projects. Let’s dive right in!

Sincere thanks to Mapme for their continuous backing since 2024 🤝.

MapLibre Native

Cross-platform Plugin System

An update on the new cross-platform plugin system for MapLibre Native.

🚀 A first version of the C Plugin API has landed this month!

We also already saw various PRs (#4654, #4692, #4665) that extended the capabilities of the plugin system. This is exactly the approach that we want to take: gradually expand the scope of the plugin system to make sure it fits all the use cases that our users have.

It should be noted that during this development phase the plugin system is not stable yet. Regular builds also do not include it yet (all integration code is guarded with a MLN_WITH_PLUGINS build flag). However, for those that want to experiment with the plugin API already, we did put out a pre-release for MapLibre Android that includes it. Please see this repository for an example. MapLibre iOS will follow suit.

Note that these plugins tie directly into the core. The plugins are cross-platform, and thanks to the C API, once the API is stable, people will be able to publish plugins that will continue working across versions. We believe that this has the potential to create a true plugin ecosystem for MapLibre Native. By having a powerful plugin system, we allow people to extend the library and experiment, while keeping the core library stable (and small). Below you can find a small taste of some interesting ideas.

Examples of plugins that the new plugin API enables: waves, an n-gon layer, custom location indicators, 3D models, fireworks, flow direction, snow and animated symbols (click to enlarge). Thanks to Sargun Vohra for sharing his experiments. Map data from OpenStreetMap and styles based on OpenMapTiles shown.

Ongoing Terrain3D work

Terrain3D is a work-in-progress, with people still hacking away at the feature/terrain-3d branch until it can be declared feature complete and stable. Patrik Drhlik decided to become an early adopter and try it out. He shared the following promising video:

Terrain3D in Patrik’s MapRiot app.

OpenHarmony Platform

With #4315 merged we now have a new platform: OpenHarmony. OpenHarmony has about 20% smartphone market share in China and about 5% globally. What makes this platform interesting as well is Oniro. This is an Eclipse Foundation Project that builds on OpenHarmony and is “dedicated to the development of an open source vendor-neutral Operating System (OS) platform”.

MapLibre Native running on OpenHarmony, this interactive sample is included in the platform and can use either Vulkan or OpenGL ES.

Call for MapLibre Accessibility Features

Tim Sylvester implemented the ability to introspect rendered features in #4460 this month. While this functionality was built primarily with testing purposes in mind, it might offer some opportunities for MapLibre Native to better integrate with accessibility tools such as screen readers. We would be very eager to hear from people willing to share their ideas on how to push such accessibility efforts.

Other news

Android can now load PMTiles directly from APK assets, allowing apps to bundle offline tile archives in this format.
The semiliteral expression is now supported in Native, matching GL JS. It allows array-valued properties, such as text offsets, to contain elements calculated using expressions.

Releases

Platform	Latest Versions
Android	13.5.2 , 13.6.1 , 13.6.1 pre-release (with plugin API)
iOS	6.30.0 , 6.31.0

🌐 MapLibre GL JS

💪 We did a large sweep this month over the open issues and closed about 80 of them (~25%). We also swept through the PRs and revived some stale ones. Many thanks to John Carmack for driving this effort!

Additionally we have added support for the font-faces style spec property, officially closing one of the last major gaps between native and web.

We released 8 versions this month: 6.7, 6.8, 6.9, 6.9.1, 6.10, 6.11, 6.11.1 and 6.11.2. These versions are packed with new features, fixes and improvements. Our pace is increasing dramatically with the extensive use of AI, but we make sure to fully review and test all the code that ships in order to keep our quality high. Check out our AI contribution policy in the contributing guide.

Here are some highlights from these releases, although there are too many to list:

The font-faces style spec property is now supported, which allows using font files with MapLibre. This was one of the last gaps between native and web, and it is now closed.
Along with the above addition, we have improved out-of-the-box support for all kinds of complex script languages and made RTL an out-of-the-box feature that doesn’t require an external plugin.
The terrain feature is finally production-grade: for a long time terrain performance was lacking, especially on mobile devices, and there were a lot of bugs related to “jumps”. Recent versions have made it smooth and fast.
There were some sky-related bug fixes and improvements, so the sky looks a lot better — try it out!
A lot of small performance improvements to increase the Lighthouse ranking.

💙 As always, we would like to thank all the contributors this month, this wouldn’t have been possible without your help!

🦀 Martin

Martin 2.0 is now officially in beta! Test it against your setup and check out our new migration guide.

We released 3 versions this month: 1.16.0, 1.16.1 and the first beta of Martin 2.0 (2.0.0-beta.0). We merged more than 150 non-bot PRs, and Martin 2.0 is now in beta. Please try the beta against your setup and tell us what breaks. We have written a migration guide: 2.0 removes the options that v1.x and v0.x deprecated, changes some defaults and needs PostGIS 3.5 or newer. If Martin 1.16 starts without deprecation warnings for you, you’re probably fine (the only un-warned change is martin-cp -> martin cp).

Here are some highlights:

Tile grids other than Web Mercator: PostgreSQL, MBTiles and PMTiles sources can now be served on other grids, such as national or polar ones. Seven grids from the OGC registry are built in (for example NZTM2000Quad), and you can define your own in the config.
Server-side rendering is stable: It is no longer experimental. It has moved out of the default build into the -full Docker images and tarballs due to having some shared library version dependencies.
Faster startup: Martin accepts connections while its sources are still loading, and PostgreSQL discovery does less work per table. /health still only reports ready once everything has loaded.
Aliases for fonts, sprites and tile sources: give a font fallback stack, a sprite set or a set of tile sources one name, and a style can request it like a single source.
CQL2 filters on table sources: write filter: population > 100000 on a table instead of writing a SQL function.
A terminal dashboard shows sources, request rates, a live world map of tile requests and the log. In 2.0 it is on by default in an interactive terminal (--no-tui turns it off).
martin-cp is now the martin cp subcommand. It can skip now also skip tiles below an empty tile, which took a world copy from 243s down to 11s on our test database.
Performance work on the tile cache: on a warm cache, serving a tile’s content dropped from 107µs to 29µs.
Unstable (feature-gated) work continued on DuckDB/GeoParquet sources (s3://, hf:// and more, .duckdb files, hot reload) and on remote COG sources.

As always, we would like to thank all the contributors this month, this wouldn’t have been possible without your help!

MapLibre Tiles (MLT)

📦 Announcement: MLT v2 has evolved from a spec skeleton into a fully working format complete with its own high-performance Rust encoder/decoder, docs, and interactive inspector.

This month was about MLT v2. It went from a header and metadata skeleton to a working format with its own encoder, decoder, docs and inspector. Everything MLTv2 is still behind the unstable-v2 feature while there are still unresolved questions (see below).

We shipped 13 releases of mlt-core (0.12.7 -> 0.16.0), along with the mlt CLI, the FFI, WASM and Python bindings, and @maplibre/mlt 1.2.1 and 1.3.0.

Here are some highlights, although there are too many to list:

Every column kind now round-trips in v2. That covers strings, floats, nested properties and m-values. Nested properties use an ORC-style node tree, and a nested node’s structure is written once per row instead of once per entry. That saves 13.6% on a group of name* columns and 9.8% on a bag of all properties.
Strings. Dictionaries are front-coded, and a layer can share one dictionary across columns. Together that cuts the whole tile by 18.3% on OpenMapTiles and 21.5% on the tiles that one of our sponsors Amazon provided.
Floats. A float column can be stored as a dictionary or with ALP, which is chosen only when every value comes back bit for bit. ALP stores a frame of reference, races FastPFOR against varint for its offsets, and packs its two parameters into a single byte. This cuts decimal columns by 19.5% and makes the parameter search about 10x faster.
Smaller headers.
- The extent fits in a nibble.
- The column and m-value counts share one variant.
- Raw streams with a fixed element width no longer store their byte length.
- The spare nibble in the layer header now holds the geometry type when a layer has only one. About 60% of layers are like this and no longer write a types stream.
Geometry. Dictionary and tessellated layouts have been merged. A layer made only of tessellated polygons stores can store just its triangles, and triangle indices count from the layer’s first vertex instead of relatively to the start.
Presence and dictionary codes. Dictionary children share their parent’s presence bitfield, presence can be run-length encoded again (up to 4% smaller), and dictionary codes are bit-packed when that beats one varint per code.
Tile inspector. The new inspector is built on our WASM bindings to the high performance rust encoder/decoder. It shows a hex view of the tile next to a tree of its regions, draws the geometry, loads tiles from a URL, and has filters with live counts. Check it out -> https://maplibre.org/maplibre-tile-spec/inspector/
We have also rewritten most of our docs and it should be much more approachable. If something is unclear, that is a bug and we would love your questions.
We have also done a bunch of Hardening.
- Malformed FSST data, oversized dictionary child counts, vertex index overflow and float encodings that don’t fit are now rejected instead of panicking.
- Polygon rings with no area are skipped during tessellation.
- Tests moved to cargo-nextest, with a big push on coverage of the error paths in the codecs.
Cleanup. We removed the Pseudodecimal encoding, which was never implemented, the Java encoding server, the (currently sadly unmaintained) C++ encoder from CI.

MapLibre Tiles v2 Inspector

In terms of what we are still discussing (please join our slack channel 😉) before we can move for stabilization:

Do we want rANS entropy coding for vertex streams that are smaller, but also 15% slower to decode and more complex?
Does the proposed z coordinate system work for all use cases that are planned?
Do we want to remove the unused Morton encoding variants?

🎨 MapLibre Compose

Over the past couple of months, MapLibre Compose has shipped a shared implementation for Android, iOS, and desktop built on MapLibre Native FFI. These releases closed nearly all the previously open issues (about 80!), completed feature parity work for desktop and web, including map styling and proper compositing with Compose UI, added long-requested features including a map snapshotter and imperative styling APIs, plus support and demos for integrating maps with Android Auto and CarPlay.

StreetComplete, the OpenStreetMap surveying app, has also merged its migration from direct MapLibre Native Android integration to MapLibre Compose, sharing its map implementation across Android and iOS.

MapLibre Compose is now essentially feature-complete, except for Kotlin Wasm support which is in draft until the next Compose Multiplatform release. The remaining work before 1.0 is improving documentation, performance, finding and squashing bugs, and improving API ergonomics. User feedback is especially important at this stage.

✨ Community Spotlight

Version 5.0.0 of the MapLibre Navigation SDK has been released, bringing KMP compatibility and major improvements! Huge thanks to Fabian Keunecke for the great work! 🎉

Tel Aviv 2035

Tel Aviv 2035: A 3D map of Tel Aviv-Yafo built in just one hour with MapLibre GL JS at the Fable 5.1 Build Day on September 17, 2026, where it won the Breakthrough track!

Repo (MIT): github.com/benjddd/fable-build-day-tlv-2026 (tag build-day-2026-09-17-winner; see MAKING_OF.md)
Live App: tlvnext.com | Short Film: Watch here

About the Build: Built as a one-page web app using MapLibre GL JS fill-extrusion over municipality raster orthophotos (1997–2025).

Tel Aviv 2035: existing buildings coloured by year, with permitted and planned volumes in blue

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones. As an exception, this month we will have it one day earlier to accommodate maintainer’s availability.

Upcoming Calls

MapLibre Native: Oct 13, 2026 – 7:00–8:00 PM Berlin Time (UTC+2)
MapLibre GL JS: Oct 13, 2026 – 8:00–9:00 PM Berlin Time (UTC+2)

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Oct 28, 2026 – 9–10:00 AM UTC

All calls are open to everyone. Zoom links are shared in the MapLibre Slack. Not yet a member? Request an invite via the OpenStreetMap US Slack and join the #maplibre channel. We’d love to see you there!

Results of the 2026 MapLibre Governing Board Election

Thu, 10 Sep 2026 00:00:00 GMT

Results are in for the 2026 MapLibre Governing Board election, and we’re excited to share them alongside a warm welcome to our newest Voting Members. A big thanks to everyone who were part of the election process this year!

Board Results

Five members have been elected to serve on the 2026 MapLibre Governing Board:

Yuri Astrakhan (incumbent)
Devesh Kumar (new)
Sargun Vohra (new)
Stefan Karschti (incumbent)
Minh Nguyễn (new)

🎉 Congratulations to all the five elected members. We’re looking forward to another year of strong leadership from this group.

💐 We’d also like to recognize Zarichnyi Yaroslav and Malcolm Toon, who both ran for the board this year and remain active, valued members of the community.

🙏 And a heartfelt thanks to Frank Elsinga, Stephanie May, Haowen You, and Birk Skyum for their time on the outgoing board. The work they put in over the past year has left MapLibre stronger for it.

📊 Key Election Statistics

Total eligible voters (Voting Members): 172
Ballots cast: 103
Voter turnout: ~60%
Seats available: 5 (out of 7 candidates)
Election method: Conducted online using OpaVote, with ranked-choice voting (Meek STV).

👉 Checkout the detailed election results on GitHub.

🗳️ Growing our pool of Voting Members

Ahead of this year’s board election, we ran a voting members nomination round. Voting Members are the ones who elect the Governing Board and vote on any changes to the MapLibre Charter.

That process brought in 31 new Voting Members this August, and we’re glad to have them on board as MapLibre keeps growing. The complete list of voting members, now 172 members strong, is available in our GitHub documentation.

Thank you again to every candidate, Voting Member, and community member who made this year’s election possible.

MapLibre Newsletter August 2026

Wed, 02 Sep 2026 00:00:00 GMT

Welcome to the August 2026 edition of the MapLibre Newsletter!

From the rapid release cadence of MapLibre GL JS and exciting update about Globe in Native, to Martin’s new hillshade and contour postprocessing, development velocity is at an all-time high.

Before getting further into project updates, a special shout goes to Radar, for their unwavering partnership since 2023. Sustained backing, from organizations and individuals alike, keeps us moving forward. If you’d like to help sustain MapLibre’s ongoing work, learn more on our Sponsors page.

Thank you, Radar, for supporting us consistently since 2023 💙

🏛️ Board & Team Updates

2026 Elections: Voting member nominations and board elections ran throughout August. Stay tuned for a detailed blog post coming soon summarizing the election results!
Team Growth: Birk Skyum, who has long served on our board and made consistent contributions to our codebase, is now joining our team as a Graphics Engineer!

📱 MapLibre Native

New features and improvements in MapLibre Native this month include:

A PR with a promising globe implementation was opened. See the behemoth of a PR with no less than 30.000 lines of code. This is quite exciting, as globe mode is one of the most requested features of MapLibre Native. Stay tuned for pre-releases so you can help with quality control. Reviews are also welcome.

John Carmack’s globe implementation. It will probably take a while until it lands, because this is quite a big feature requiring careful review and testing. Map style based on OpenMapTiles and data from OpenStreetMap.

Another quite large (LLM assisted) PR implements the global-state expression that was implemented earlier in MapLibre GL JS. This functionality makes it possible to define ‘variables’ for a style that you can use in various expressions. See #4516 for the PR which was submitted by Taiyu Yoshizawa from our valued sponsor MIERUNE. Reviews welcome!
Stephan Schmid from Mercedes Benz made string expressions operate on Unicode, see #4344.
Vladyslav Odobesku from Intellias implemented a CustomVectorSource in #4377. This provides a more efficient way to load vector data when using MapLibre Android, since you can load it as binary data (in MVT format).
@munawiki implemented split and join style spec expressions in #4463.
Yaroslav Zarichnyi from Lyft implemented a customizable gradient for fill extrusions. Please give feedback on the related style spec change.
Bart Louwers is hacking on a C plugin API for MapLibre Native. There is also a template repository with some example plugins. The idea is that you will be able to fork this repository to easily create and release your own plugins. The current examples cover a rectangle layer, a layer that loads GLTF models and the core hillshade and heatmap layers implemented as a plugins(in the future, we might want to exclude lesser-used core layers and require people to load those as plugins to keep the core small, though we would need to ensure that plugins loaded this way do not introduce regressions). There is also a plugin for adding shadows to fill extrusions. Please share your ideas for plugins so we can use this for shaping the plugin API.
We moved the namespaces and include paths from mbgl to mln. Because we don’t consider the C++ API to be stable, we do not consider this a breaking change for the platforms. For in-flight work we have included some scripts in #4487 and #4511

🌐 MapLibre GL JS

Six (!) versions were released this month: 6.2.0, 6.3.0, 6.4.0, 6.4.1, 6.5.0, 6.6.0, with two new style spec properties among them.

📣 Increased release frequency is a consequence of the improved quality of the AI code generation and people actively opening PRs to solve problems that were a lot harder to solve due to steep learning curve. It’s worth mentioning that this causes delays in PR reviews due to higher volume of PRs. We hope to address this going forward, and we appreciate your patience as we work through the review queue.

fill-extrusion-rounded-corner-distance arrived in GL JS in v6.2.0, following last month’s Native-first landing, which allows you to draw rounded corners for buildings.
symbol-height-offset and symbol-height-anchor were added to allow raising icons and text above the map. This feature was discussed in the last two monthly meetings and after the spec matured, it is now available for your use cases, such as icons on top of building or drones in the sky.
There were also a few features related to improved icon animation by rendering on the GPU, as well as the ability to keep the perspective or flat warp in image sources.
Going forward we intend to close the last gap between native and web by supporting the font-faces style spec definition and improving complex scripts support. It’s ready for review and you can test it out via the #8237 PR.
There’s also a strong momentum for supporting some basic cases related to projection and custom CRS that started here in #8236 and is expected to continue next month.

🙏 Thanks to all the contributors this month! It’s great to see so many features and bug fixes arriving. Keep up the good work!

🦀 Martin

Martin, the MapLibre tile server, shipped two releases in August (see 1.14.0 and 1.15.0 in the changelog):

The major features were:

Hillshade postprocessing. Martin can now bake shaded relief from a source serving Mapzen normal tiles, so clients get hillshade instead of a normal map they have to shade themselves. Docs, PR
Contour postprocessing. convert_to_contour traces contour lines out of Terrarium elevation tiles and serves them as MVT, tagged with elevation and whether the line is a major one, with the interval configurable per zoom. Output is vector, so the client styles and labels the lines. Docs, PR

[!IMPORTANT] Two security advisories (our first) were fixed in 1.14.0. As always, we recomend to update. Out-of-gamut CIE colors in a static-overlay body could permanently kill render workers (GHSA-6774-6cqw-f586, affects only the opt-in rendering feature), and repeated sprite ids let a single unauthenticated request amplify the work required (GHSA-5x5g-6p4c-jqfh, medium).

Images of how hillshade/contour look:

Hillshade

Contour

🤖 Maplibre Agent Skills

MapLibre Agent Skills is a collection of agent skills, markdown files an AI coding assistant loads as context, that teach assistants to write correct MapLibre code. With help from a new contributor (@johncarmack1984), the project has matured to the point where we are ready for you all to really kick the tires. The project published v0.2.0 this month. The release:

adds maplibre-v6-migration, covering the breaking changes in MapLibre GL JS v6 most likely to trip up coding agents.
adds maplibre-source-wiring, split out of maplibre-tile-sources, for the cases where a source is configured but nothing draws.
adds a release watch that files an issue when an upstream MapLibre release removes, renames, or deprecates something a skill still mentions.

Nine skills now span cartography, tile sources, PMTiles, terrain rendering, fonts and glyphs, and Mapbox and v6 migration, plus a process skill for turning a research or coding session into a new skill.

Skills are backed by a committed baseline run of prompt injections showing the model failing without the skill. Install the set with npx skills add maplibre/maplibre-agent-skills, and if your assistant still gets MapLibre stuff wrong, file a failure report.

🪶 MapLibre Flutter

flutter-maplibre-gl has shipped v0.27.0!

After 0.26.0 tackled years of accumulated backlog, this release focuses on making the package easier to use, more consistent across platforms, and closer to the current MapLibre ecosystem.

The new documentation site: every guide comes with a live, interactive map. Documentation | Migration Guide | Full changelog | Package

Highlights:

Interactive documentation site: maplibre.org/flutter-maplibre-gl now provides practical guides across the API, with live examples you can explore directly in the browser.
Alignment with MapLibre Style Spec: the plugin’s style APIs are now generated from the current upstream spec instead of an outdated snapshot, thereby bringing new properties and expressions.
Platform parity: a growing part of the API now behaves consistently across Android, iOS, and Web, including features like cluster inspection, feature state, map padding, among many others.
Web upgrades: The web platform now uses MapLibre GL JS 6.4.1, adding support for globe, terrain, sky, and colour relief.
Faster maps: Engine pre-warming cuts startup times, and large GeoJSON updates run without blocking the UI.
Resilient Android apps: Maps now correctly recover and preserve camera position during activity recreation.

Together, these changes move flutter-maplibre-gl closer to its goal of providing a consistent MapLibre experience across Android, iOS, and Web, while making the package easier to learn and more pleasant to use.

📣 Monthly downloads have grown from around 20,000 in August 2025 to more than 80,000 today, roughly a 4× increase in one year.

🙏 Thanks to everyone who contributed to this release and helped make MapLibre Flutter more capable, consistent, and accessible!

✨ Community Spotlight

MapLibre GL JS Ecosystem Adoption

MapLibre GL JS has recently seen notable adoption across the wider mapping ecosystem. The following are four prominent FOSS projects I’ve recently worked with to enhance their support for MapLibre:

deck.gl, a geospatial visualization framework, now has a dedicated MapLibreOverlay in the deck.gl package. For MapLibre users, this new first-party solution replaces the reliance on MapboxOverlay and builds directly on MapLibre’s public APIs and types. As the Mapbox and MapLibre renderers diverge, this will help maintain a high level of compatibility. PR
Placemark.io, a geospatial data editor, has replaced Mapbox GL JS with MapLibre GL JS 6, removing its remaining Mapbox dependency and making the project fully open source. The migration also moves to OpenFreeMap and provider-neutral routing. Thanks to Birk for the migration! Write-up · PR
Apache Superset, a data exploration and visualization platform, has added MapLibre support across its geospatial charts, with new charts defaulting to MapLibre and open basemaps that require no API key. The change will be released in Superset 6.2.0, while Mapbox remains available for backwards compatibility. PR
Home Assistant, a home automation platform, has moved its default basemap from CARTO raster tiles to OpenStreetMap vector tiles rendered with MapLibre GL JS through maplibre-gl-leaflet, while continuing to use Leaflet for map interactions. PR

Expressive

Built by Zbigniew Matysek (@falseinput), Expressive is a language that compiles to MapLibre style JSON and is tailor-made for maintaining base map styles.

It lets you split styles across files, name colors and widths once, derive one value from another, and write expressions in a readable syntax.
Because every style JSON is already a valid Expressive file, existing styles can be rewritten piece by piece.
Checkout the source code or interactive demo, which runs the OpenFreeMap Bright style rebuilt in Expressive with 119 layers driven by 15 parameters, recompiling live in your browser.

👥 Conferences & Events

Last month was packed with conference attendance across State of the Map (SOTM) Paris and FOSS4G 2026! You can explore the full schedule of talks and sessions in our MapLibre SOTM & FOSS4G Gist.

Key talks and recordings from SOTM Paris include:

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Native: Sep 09, 2026 – 7:00–8:00 PM Berlin Time (UTC+2)
MapLibre GL JS: Sep 09, 2026 – 8:00–9:00 PM Berlin Time (UTC+2)

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Sep 30, 2026 – 9–10:00 AM UTC

GSoC'26: DuckDB Backend for Martin TileServer

Sat, 15 Aug 2026 00:00:00 GMT

Introduction and Motivation

Hi everyone, I have been working on DuckDB support for Martin as part of Google Summer of Code, under the mentorship of Frank Elsinga. Martin already serves vector tiles from PostGIS, from pre-generated archives such as PMTiles and MBTilles, can extract images from COG and convert geojson to vector tiles on the fly. This project adds a path for serving tiles directly from analytical datasets like GeoParquet directly via DuckDB.

The motivation for this is that many geospatial workflows already use DuckDB and GeoParquet for storage and analysis. Until now, putting that same data on a map generally required importing it into PostGIS, generating a separate tile archive, or maintaining a proxy layer. DuckDB’s spatial extension now provides ST_AsMVT and ST_AsMVTGeom, making it possible for Martin to generate vector tiles from those datasets directly. Track the progress on this feature here - #2264.

How DuckDB-backed sources fit into Martin.

Config Structure for DuckDB backed sources

The first major decision was to design an appropriate config structure to parse for building sources backed by DuckDB. This had two main paths: .duckdb files and GeoParquet analytic datasets. The following config structure was then designed incorporating already existing features Martin provides like auto discovery of spatially enabled tables etc.

duckdb:
  pool_size: 4
  auto_bounds: quick
  sources:
    - database: /data/tiles.duckdb
      auto_publish:
        tables:
          from_schemas: autodetect
          source_id_format: "{table}"
          id_columns: [id, gid]
          extent: 4096
          buffer: 64
          clip_geom: true

      tables:
        roads:
          schema: main
          table: roads
          geometry_column: geom
          srid: 4326
          minzoom: 0
          maxzoom: 14
          properties:
            id: int4
            name: varchar

    - geoparquet: /data/buildings.parquet
      layer_id: buildings
      geometry_column: geom
      srid: 4326
      minzoom: 0
      maxzoom: 14
      extent: 4096
      buffer: 64

martin-core: DuckDBSource and pool (#2831)

The next step was to add the runtime layer in martin-core to provide a way for Martin to hold DuckDB connections and execute tile SQL through its existing Source abstraction.

DuckDB has a different operating model from Postgres. It is an embedded analytical engine, so Martin opens a duckdb::Connection directly in its own process rather than connecting to a database server. That connection can query GeoParquet in place using read_parquet(...) and the data does not need to be imported first. The spatial extension is loaded on each connection to provide the MVT functions, while remote GeoParquet sources also require DuckDB’s httpfs extension.

The implementation introduces a single DuckDBSource for all DuckDB-backed layers. A database table and a GeoParquet file require different configuration, but they all ultimately run a query with z, x, and y parameters. DuckDBSqlInfo therefore stores the generated query, while the source-specific logic is largely confined to building its FROM clause. This kept the execution path shared and left room for database-backed sources to be added without another tile-source implementation.

Connections are reused through DuckDBPool. Database-file sources open read-only connections to the .duckdb file. GeoParquet sources instead create an in-memory DuckDB connection, load the required extensions, and read the external file when a query runs. The pool is limited by pool_size, so requests wait for an available connection.

This matters because DuckDB parallelizes a single query internally. A tile query can use several worker threads for Parquet scans, spatial filtering, and MVT encoding, with the limit controlled by Config::threads. Martin may also have multiple pooled connections, so the effective level of parallelism is approximately pool_size × threads. The default pool size is four.

Integrating this with Tokio required one additional boundary. duckdb-rs is synchronous, whereas Martin’s tile interface is asynchronous. Connection checkout must remain non-blocking, and executing ST_AsMVT must not occupy a Tokio worker thread. deadpool provides asynchronous checkout and the actual DuckDB call is moved to Tokio’s blocking pool:

Connection creation follows the same pattern because extension loading and session setup are blocking operations. The returned connections are health-checked to ensure they can be reused.

Bounds and SQL utilities (#2902)

The next piece was source metadata. Martin exposes TileJSON for every source, and TileJSON needs geographic bounds. A GeoParquet file does not provide an equivalent server-side catalogue, so the DuckDB backend needs to derive its bounds from the geometries it reads.

This PR added three bounds modes. skip leaves bounds out of TileJSON. calc computes an exact extent with DuckDB spatial functions and transforms the result to WGS84. quick, the default, first tries ST_Extent_Approx, which uses cached geometry bounding boxes where they are available. The quick path is time-limited: if it cannot produce a result in time, Martin starts without bounds rather than delaying startup. If the approximate function is unavailable or produces no result, it falls back to the exact calculation.

The exact query also handles point-like or otherwise degenerate extents. A zero-width or zero-height box is buffered before conversion, producing valid TileJSON bounds instead of an invalid envelope.

The PR also introduced the small SQL utility layer used by the following resolver work. Identifiers, string values, schema-qualified relations, and EPSG CRS values are escaped separately before being placed in generated SQL. This is necessary because relation names and file paths cannot be passed as normal query parameters in every position used by DuckDB’s spatial and read_parquet(...) functions. Keeping that logic in one place made the later SQL generation both safer and easier to read.

GeoParquet configuration and resolution (#2931)

With the runtime and metadata utilities in place, the next PR defined the GeoParquet source model and the resolver that turns a configured file into a DuckDBSource.

The resolver begins with DESCRIBE SELECT * FROM read_parquet(...). It identifies the geometry column, validates an optional feature ID column, and treats the remaining columns as MVT properties. A configured geometry column takes precedence; otherwise, Martin accepts a file with exactly one GEOMETRY column and rejects files with none or several ambiguous candidates.

The source CRS can be configured explicitly or discovered with ST_CRS. The resolver accepts EPSG:* values and OGC:CRS84, then records the result as an SRID. Before building the tile query, it applies ST_SetCRS to the geometry. This is important because GeoParquet processing pipelines can preserve the geometry while dropping the CRS metadata DuckDB needs for a correct transformation.

The generated query follows the normal MVT flow: create the requested tile envelope, transform source geometries into Web Mercator, filter features against the tile bounds, pass each geometry through ST_AsMVTGeom, and finally assemble the layer with ST_AsMVT. The layer ID, feature ID, extent, buffer, clipping behaviour, and zoom limits all come from the source configuration.

The resolver combines this query with the bounds calculation from the previous PR and builds TileJSON from the discovered schema and metadata. At that point it can return a complete DuckDBSource. The remaining work was to connect this resolver to Martin’s top-level lifecycle and verify the full HTTP path.

End-to-end local GeoParquet support (#3054)

This PR connected DuckDB configuration to Martin’s normal startup lifecycle. When unstable-duckdb is enabled, Martin resolves the duckdb: block alongside its other source types and adds each valid GeoParquet source to the catalog.

That completed the local GeoParquet path: configuration file to resolver, resolver to DuckDBSource, and DuckDBSource to the usual catalog, TileJSON, and /{source}/{z}/{x}/{y} endpoints. Invalid entries follow Martin’s warning policy, so one malformed GeoParquet source does not prevent valid siblings from starting.

The end-to-end tests start Martin with a temporary configuration, verify the catalog and generated TileJSON, request a real vector tile, and inspect the decoded MVT output. The fixture includes a polygon that crosses a tile edge, confirming that DuckDB clips it correctly while retaining features inside the tile.

The PR also introduced just test-duckdb and a feature-gated CI job. This keeps the expensive bundled DuckDB build out of unrelated test suites while ensuring the complete GeoParquet path is tested whenever DuckDB support changes.

What this enables

The immediate use case is serving a map directly from a GeoParquet dataset. Martin can expose a parquet analytical dataset directly as a standard vector-tile endpoint without a separate PostGIS import. MapLibre clients receive the usual catalog, TileJSON, and MVT responses.

This is particularly useful when DuckDB is already the analytical layer. The same files can support batch analysis and map rendering, avoiding a second spatial database that exists only to serve tiles.

The shared DuckDBSource design also provides a path beyond GeoParquet. The execution and pooling layer does not depend on read_parquet(...) and future sources can generate SQL against tables in a .duckdb file while using the same tile-serving code.

Remaining work

The current implementation is intentionally gated behind unstable-duckdb. Before it can become a stable Martin backend, the most important work is:

DuckDB database sources: implement structured configuration and resolution for tables and auto-publish. Those fields are parsed today but are not served.
Remote GeoParquet: the connection layer supports HTTP(S) through httpfs; it still needs dedicated end-to-end coverage.
Discovery and CLI support: add directory/glob discovery for Parquet files and a command-line configuration path comparable to Postgres.
Operational features: support query cancellation and URL query parameters where appropriate.
Hot reload: detect changes to local GeoParquet files and refresh their sources without restarting Martin, matching the reload support available for other file-backed sources.
Documentation and stabilization: document the configuration, resource trade-offs, and when to choose DuckDB over PostGIS or pre-generated archives; then evaluate removing the unstable- feature gate.

Conclusion

This work establishes the core path for serving vector tiles from local GeoParquet through DuckDB. For users whose geospatial data already lives in analytical files, this provides a simpler route from data to map: keep the dataset in GeoParquet, query it with DuckDB, and serve it through Martin!

MapLibre Newsletter July 2026

Sun, 02 Aug 2026 00:00:00 GMT

Welcome to the July 2026 edition of the MapLibre Newsletter!

It’s been a big month. MapLibre GL JS v6 just shipped, barely eight months after v5 landed in December 2025. Additionally, MapLibre Native landed its first-ever style spec property before GL JS, Martin pushed out three releases in a row, and Flutter got an experimental FFI engine that’s 10x faster on data-heavy maps.

Before we dive in, we begin with a note of gratitude to JawgMaps, for their continuous backing of MapLibre since 2023. Contributions like theirs, from organizations and individuals alike, are what keep our project running and our community thriving. If you’d like to support our ongoing work, visit the MapLibre Sponsors page for more details.

Big thanks to JawgMaps, for supporting us since 2023!

🏛️ Governing Board Update & 2026 Elections

Board Change: Frank Elsinga has stepped down from the Governing Board. Per the MapLibre Charter, his seat is filled by Stefan Karschti, who placed sixth in last year’s allocation. Thank you, Frank, for your service this term!

2026 Elections: Nominations are open for this year’s Governing Board election.

Date	Milestone
Aug 14, 2026	Deadline for Voting Member nominations and Board candidate registration
Aug 20, 2026	Deadline for approval of new Voting Members (via PR review)
Aug 31, 2026	Governing Board election poll closes (OpaVote)

📱 MapLibre Native

Rounded Fill Extrusion Corners: Support for rounded fill extrusion corners has been implemented by Alex Cristici in #4343. You can now use the fill-extrusion-rounded-corner-distance style spec property. Notably this is the very first time a new visual style spec property has landed in MapLibre Native before MapLibre GL JS since the fork! Special thanks to Steve Gifford for the original proposal.

Screenshot showing the new rounded corners for fill extrusions in action. OpenMapTiles based map style.

Crisper CJK Text Rendering: CJK characters that use local glyph rasterization are now rendered with double the resolution, matching MapLibre GL JS and significantly improving the legibility of these characters. This was implemented by Taku Fukada, an engineer at our valued sponsor MIERUNE.

Android feature-state support: The feature-state functionality is a way to read and set properties on individual features, which can be used for styling with a style expression. Android support was added in #4219 by Brandon Roeder. A PR from Markus Wendorf that adds a similar API to MapLibre iOS is still open.

Fresh PMTiles Documentation: Stephanie May contributed fresh new PMTiles documentation in #4278. Check out the new guides in both the MapLibre Android and MapLibre iOS docs.

🌐 MapLibre GL JS

📢 v6 Release

We published the final four pre-releases(6.0.0-19, 6.0.0-20, 6.0.0-21, and 6.0.0-22) of Version 6 alongside the official v6.0.0 release itself. This is a huge milestone for us! While it introduces breaking changes, it also paves the way for future improvements. For more details, check out our migration guide.

It has been over a year and a half since our last major update, and breaking changes were piling up. So we needed to carve out a dedicated breaking release, but don’t worry, we don’t plan on doing another one anytime soon (we know how painful migrations can be!).

We noticed this release created complication for projects pinned to latest. We strongly advise against auto-updating to latest versions in production for this exact reason. Always pinning to specific versions will keep your builds safe and predictable.

We had a stack of non-breaking features and bug fixes ready to go that we didn’t want to mix into the core 6.0.0 release. To keep things clean, we also shipped v6.1.0 this month.

🤝 A Quick Note for Contributors

While the momentum around AI tools makes drafting code faster than ever, we kindly ask contributors to focus on driving a single PR to completion before opening new ones. We take quality and maintainability very seriously. Aligning code to MapLibre standards, conducting thorough reviews, and making necessary adjustments takes time. Focusing on one high-quality pull request at a time helps us review faster and get your contributions to a “ready to merge” state smoothly.

🙏 Thanks to all the contributors this month:

🦀 Martin

Over the last two months, Martin shipped three major releases (v1.11.0, v1.12.0, and v1.13.0). Key highlights include:

Live Source Reloading: Hot-reloading has been completed across all source types to keep data fresh without server restarts. Local PMTiles and COG files reload on filesystem changes, while PostgreSQL and remote object stores poll on a configurable timer to update their schemas and sources.
Direct GeoJSON Tile Serving: Martin can now serve vector tiles directly from WGS84 .geojson/.json files on the fly. It constructs a Hilbert R-Tree index on startup, then queries, clips, and encodes MVTs per request. It also supports filesystem-event hot-reloading.
Upstream Tile Passthrough: Martin now supports acting as a proxy cache for upstream HTTP tile servers. It fetches tiles from configured templates or mirror servers, allowing developers to wrap external tiles in Martin’s caching pipeline and hide upstream credentials.
Static Map Overlays: A new endpoint renders static map images with styled vector overlays (fills, lines, circles) drawn on top. The camera can center on coordinates, a bounding box, or auto-fit to the overlays.
GSoC Spotlight: Google Summer of Code student Manbhav laid the groundwork for serving tiles directly from DuckDB and GeoParquet. This includes core integration logic and initial config-resolver wiring.

🙏 Thanks to all the contributors who made these releases possible:

🎨 MapLibre Compose

MapLibre Compose now features an experimental desktop implementation rewrite backed by maplibre-native-ffi on the desktop-ffi-rewrite branch. This has allowed us to:

bring Compose Desktop to near-parity with Compose Android and iOS in functionality.
supports proper compositing with Compose UI on desktop.

This new architecture is expected to resolve a large collection of longstanding open issues, including #570, #627, #595, #184, #568, #608

🪶 MapLibre Flutter

This month flutter-maplibre-gl grew an experimental new engine: a pure-Dart FFI backend for Android, on the exp/native-ffi-android branch. By driving the map directly through the MapLibre Native C API with dart:ffi, we can now achieve:

10x Faster Data Pipelines: Replacing large GeoJSON sources (e.g., 20k points) is ~10x faster, sustaining ~30 Hz live updates without UI thread jank.
Jank-Free Frame Delivery: A dedicated native thread handles frame rendering so background Dart tasks (like GC) never drop frames.
Gesture responsiveness, where platform views historically held an edge, reached full parity across pan, pinch, and rotate by moving to a vsync-aligned frame loop and display-thread rendering.

Screenshot of interaction performance benchmark: FFI backend vs. Platform Channels.

The public maplibre_gl API is unchanged: a single MapLibreGlNative.use() call before runApp opts an app in. This is an experimental spike (Android arm64 only). Threading lessons learned here are directly shaping maplibre-native-ffi’s executor design #433. Thanks to @sargunv for the C API collaboration!

👥 Conferences & Events

Keep an eye on our blog for an upcoming post covering MapLibre’s schedule and participation at upcoming geo conferences.

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Native: Aug 12, 2026 – 7:00–8:00 PM Berlin Time (UTC+2)
MapLibre GL JS: Aug 12, 2026 – 8:00–9:00 PM Berlin Time (UTC+2)

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Aug 26, 2026 – 9–10:00 AM UTC

MapLibre Newsletter June 2026

Sat, 04 Jul 2026 00:00:00 GMT

Welcome to the June 2026 edition of the MapLibre Newsletter!

We would like to extend our sincere thanks to Mierune, MapLibre’s inaugural sponsor, for their continuous backing since 2022.

As we keep building and evolving, contributions from organizations and individuals alike are what keep our project running smoothly and our community thriving. If you would like to support our ongoing work, please visit the MapLibre Sponsors page for more details.

A huge shoutout to Mierune, MapLibre’s very first sponsor!

📢 We are Hiring: Graphics Engineer

We are looking for a Graphics Engineer to join our team!

If you are passionate about open-source geospatial tools and low-level graphics programming, we would love to hear from you.

Check out the job description at maplibre.org/jobs/graphics-engineer.

📱 MapLibre Native

Thanks to the efforts of Adrian Cojocaru and Alex Cristici, the instancing based fill extrusion optimizations is now implemented for the Vulkan backend as well. If you are using MapLibre Android, this is yet another reason to switch to the Vulkan backend (the default since version 13.0.0).
Harel Mazor shared a blog post detailing his experiences adding Android Auto and Carplay support to his app using MapLibre Native. He also published a project to bring contours to MapLibre iOS and Android using a Rust-based HTTP interceptor.
Over on Slack, Vladyslav Odobesku created a discussion thread about adding a Kotlin based CustomVectorTileProvider that would be a more performant alternative to CustomGeometrySource for Android developers.
MapLibre Native FFI project now features browser support using the WebGPU backend. Dive into the Slack discussion thread and the relevant PR for more details.
Taku Fukada from our valued sponsor MIERUNE implemented double resolution rendering for CJK characters. This makes these characters much more legible on mobile screens. MapLibre GL JS has had this behavior for a while already and we’re thrilled to bring this crisp rendering to MapLibre Native.

Releases:

Platform	Latest Versions
Android	13.3.0 , 13.3.1
iOS	6.27.0

🌐 MapLibre GL JS

We have rolled out seven pre-releases for version 6: 6.0.0-12 through 6.0.0-18.

We are nearing the finish line for the version 6 breaking changes! You can track our final milestones on the tracking issue: #6427

We have just a few remaining Pull Requests that needs community’s input before they close:

PR #7800
PR #7839

🤝 We would like to thank all the people who have contributed to the project this month:

👥 Conferences & Events

Last month (June 11–13), our board members headed to Madison, Wisconsin for State of the Map US 2026 to connect with the community and share what we’ve been building. A huge thank you to the organizers and everyone who stopped by to chat with us!

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Native: Jul 08, 2026 – 7:00–8:00 PM Berlin Time (UTC+2)
MapLibre GL JS: Jul 08, 2026 – 8:00–9:00 PM Berlin Time (UTC+2)

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Jul 29, 2026 – 9–10:00 AM UTC

MapLibre Newsletter May 2026

Wed, 03 Jun 2026 00:00:00 GMT

Welcome to the May 2026 edition of the MapLibre Newsletter!

Our sincere thanks go out to Komoot for their ongoing support of MapLibre since 2023. Please refer to our Sponsors page for more details on how organizations and individuals can give back to the project. Your contribution will directly help us run the project successfully and keep the community thriving.

Read on for this month’s updates!

We are deeply grateful to Komoot for their steadfast support of the MapLibre community since 2023.

📱 MapLibre Native

Memory Optimization: Taking advantage of instancing, Alex Christi managed to significantly reduce the memory usage of fill extrusion layers (see PR). Right now, this is implemented for the Metal backend, with Vulkan following suit thanks to Adrian Cojocaru’s work (see PR). If you are a heavy user of fill extrusion layers, we would love to hear your experience.

Android Renderer: With Vulkan now being the default renderer in MapLibre Android 13.0.0, more people are trying out the Vulkan backend. MapLibre Android 13.2.0 introduced some Vulkan specific bugfixes.

HarmonyOS Ecosystem Expansion: This MapLibre Native PR adds support for a new platform, HarmonyOS, Huawei’s commercial OS competing with Android and iOS in China. It is related to OpenHarmony, an open source project also utilized by initiatives like Oniro.

Cross-Language Bindings: Separately, MapLibre Native FFI (the experimental C API wrapper for MapLibre Native), has made great progress since onboarding last month. It has officially landed Java, Rust, Zig, and Kotlin Native bindings, while filling out its support matrix across macOS, Windows, and Linux using Vulkan, Metal, and OpenGL.

Dave Brophy opened several PRs this month, including an implementation of contour lines based on Raster DEM data. Unfortunately, the PR was closed since we require contributions to have a human in the loop. In practice, this means a feature like this can only be contributed to the core library by someone with a strong graphics background and knowledge of MapLibre Native rendering internals.

Code Integrity & AI Policy

We want the core of MapLibre Native to be stable and maintainable for the long term. This means being judicious in accepting pull requests, especially those written using an LLM. At the same time, we understand that some of our users want to move quickly, and these days that often means using AI to write functionality.

Our Solution: We plan to create a plugin API for MapLibre Native. This will allow developers to extend the library without changing the core codebase. As an example, MapLibre GL JS has a popular contour plugin; in the future, MapLibre Native might have one as well.

🌐 MapLibre GL JS

A lot of performance improvements have been added in our latest pre-releases. Now that we have officially dropped support for WebGL 1, we are looking to modernize our WebGL stack further. Check out the #7640 tracking issue for more details and to follow along.

Help Us Test the MapLibre GL JS v6 pre-releases

We have already implemented most of the breaking changes for the upcoming release, and we hope to ship the new major version soon. To ensure a flawless launch, we are releasing a new version after nearly every PR merge.

Our request to you: Please test the latest pre-releases in your environments and let us know if we broke anything before the major version is released!

For those of you who build MapLibre GL JS locally and ship custom changes, we have great news! We have switched to using Rolldown, cutting our local build times down from minutes to seconds. This is a massive boost to the developer experience!

🤝 We would like to thank all the people who have contributed PRs this month:

Style Specification: Share Your Inputs

A discussion around line opacity and layer opacity in general is currently underway. We want to ensure our future spec design meets real-world developer needs.

Please head over to the tracking thread to share your inputs with us: Discussion #503

🦀 Martin

Nine martin releases shipped across April and May (1.5.0 through 1.10.1), with matching martin-core and mbtiles versions. April is folded in here because no changelog went out at the time.

Key highlights include:

On-the-fly MLT support: The biggest change is MLT (MapLibre Tiles) support. Martin now transcodes MVT to MLT (and back) on the fly, picking the format from the client’s Accept header. On our test fixture, MLT is about 39% smaller on the wire and about 12% faster to serve from cache due to that. Checkout the full guide if you want to dig in.

Server-side raster rendering: Now stable and on by default on Linux builds via MapLibre Native (styles: rendering: true). This closes a massive milestone #978 open since October 2023.

Live source reloading: MBTiles directories hot-reload as of April, COG and PMTiles followed in May, and PostgreSQL groundwork is in place for the PG reload work that comes next.

🤝 Thanks to the community around Martin:

📣 As we scope next steps for server-side raster rendering, we want you to tell us what you’d want from the API (overlays, query params, perf knobs).

☀️ GSoC Spotlight: DuckDB backend! A warm welcome to Manbhav Sugla (@manbhav234), our Google Summer of Code student, whose first PR: #2831 feat: duckdb-source implementation at martin-core, landed in draft and kicks off a brand-new DuckDB source for Martin, with reviews and suggestions welcome.

✨ Community Spotlight

OMT Router: Built by Abel, this fast, zero‑backend library builds routing graphs straight from OpenMapTiles vector tiles to compute optimal routes and isolines entirely in the browser. Dive into the source code or test it yourself on the live interactive demo.

QGIS2VectorTiles: Returning with a major upgrade since its last feature, QGIS2VectorTiles packs a QGIS project into a lightweight package complete with vector tiles, a matching MapLibre style, and a ready-to-use web viewer.

Recent updates to the project introduces native MBTiles export, imagery background layers, alpha channel color support, and a redesigned multithreaded export pipeline utilizing the GDAL CLI for faster tile generation. It also vastly expands style conversion (adding symbol-placement, text-variable-anchor, and interactive pop-ups) alongside a brand-new OpenLayers web viewer option.

👥 Conferences & Events

We plan to participate and contribute to sessions at State of the Map US — Madison, Wisconsin between 11-13 June 2026.

Thursday, June 11 (Workshops):

Stephanie will guide OSM editors through quick, easy ways to extract OSM data and display it on a map.
Yuri will host a hands-on session showing attendees how to spin up their own map service utilizing OSM data and Planetiler.

Be sure to sign up for the workshops and spread the word!

Friday, June 12 (Lightning Talk):

Yuri will deliver a rapid-fire lightning talk tracking the latest ecosystem updates across MapLibre and the new MLT (MapLibre Tiles) specification.

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Native: Jun 10, 2026 – 7:00–8:00 PM Berlin Time (UTC+2)
MapLibre GL JS: Jun 10, 2026 – 8:00–9:00 PM Berlin Time (UTC+2)

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Jun 24, 2026 – 9–10:00 AM UTC

Welcoming YellowMap as a Silver Sponsor!

Fri, 15 May 2026 00:00:00 GMT

We are thrilled to officially welcome YellowMap as a Silver sponsor of the MapLibre organization!

Why YellowMap Chose MapLibre: A Shift to Modern Vector Maps

For YellowMap, the decision to migrate to MapLibre was driven by a desire to modernise and add functionality. They recently transitioned from raster map configurations to vector tile approach allowing for smoother zooming and easier customisation. During this transition, YellowMap conducted exhaustive high-load and performance testing that confirmed MapLibre could meet their high standards.

Today, YellowMap’s infrastructure, powered by a Kubernetes cluster, serves nearly a million map views a day and handles global map tile updates every four weeks. MapLibre GL JS has helped them handle this massive scale effortlessly.

How YellowMap Meets Data Compliance Needs with MapLibre

At the core of YellowMap’s product offering is SmartMaps, built to address the strict data privacy demands of the European B2B market. While many modern mapping providers rely on external content delivery networks (CDNs) or track user behaviors via cookies, YellowMap takes a self-hosted approach:

100% GDPR Compliance: YellowMap hosts all mapping systems entirely on their own self-managed servers.
No Tracking: SmartMaps solution operates completely without cookies and does not transmit any user data (such as IP addresses or advertising IDs) to external providers or third-party CDNs.
Digital Sovereignty: SmartMaps’ independent architecture provides data security for privacy-critical B2B power users, including major financial institutions like Sparkasse, where end-users rely on secure interfaces to do things like look up local ATM branches.

Showcase of SmartMaps used in a store-locator application.

MapLibre’s open-source, vendor-agnostic nature goes hand-in-hand with YellowMap’s data privacy and digital sovereignty philosophy, allowing them to maintain complete ownership of their tech stack and uphold their digital sovereignty unique selling proposition (USP).

How YellowMap Utilizes MapLibre Today

YellowMap’s core mapping SDK, SmartMaps GL, functions as a specialized wrapper around MapLibre GL JS. Their current deployment relies heavily on several advanced MapLibre features:

Globe View: Providing an immersive, global perspective for large-scale data visualization.
Multi-Language Support: Enabling end users customers to switch map languages dynamically.
3D Buildings: Rendering buildings as 3D extrusions for detailed cityscapes and immersive urban visualizations.

The Road Ahead

YellowMap’s integration with MapLibre is only expanding. Driven by growing customer demand for digital sovereignty and data protection, they are currently preparing to integrate MapLibre Native into their environment, with internal technical documentation slated for completion in the coming days.

YellowMap is also interested in developments surrounding the entire backend tile generation stack, Martin tile server format integrations, and native support for simple SVG sources.

We are incredibly grateful for YellowMap’s support, which helps ensure that MapLibre remains open, and community-driven mapping framework for everyone. If you are interested in sponsoring MapLibre, please reach out to us at sponsor@maplibre.org. We would love to hear from you!

MapLibre Newsletter April 2026

Sun, 03 May 2026 00:00:00 GMT

Welcome to the April 2026 edition of the MapLibre Newsletter! This month, we have exciting updates across all our projects. Key milestones include overhauls for React Native and Flutter, the transition toward MapLibre GL JS v6, and foundational research into a native MLT 3D tile format.

📱 MapLibre Native

Alex Cristici improved the resilience of MapLibre Native when the system runs out of memory (see PR).

There now is a new experimental C API for MapLibre Native, which can serve as a foundation for new platforms. See the new repository as well as the onboarding discussion. This is the work of Sargun Vohra, who also used what he learned when creating MapLibre Compose for the new C API.

Releases:

Platform	Latest Versions
Android	13.1.0
iOS	6.25.1 , 6.26.0

🌐 MapLibre GL JS

Versions 5.22.0, 5.23.0, and 5.24.0 were released this month, introducing mostly performance improvements and bug fixes along with minor public API additions, and marking the final releases for version 5.

We have begun releasing version 6 pre-releases featuring the breaking changes planned for this major update. We will continue rolling these out over the next few weeks and expect to finish shortly.

The primary breaking changes for this version include:

Dropping WebGL1 support to resolve long-standing bugs and feature requests while improving performance and compatibility with modern libraries.
Transitioning from CommonJS to ESM, which will allow us to move faster, adopt modern tools, and upgrade our overall build system and infrastructure.

Once all breaking changes are in place, we will provide a migration guide to assist with the transition from version 5 to version 6. While most changes so far are fairly trivial, some may be tricky; we encourage you to try these pre-releases and help us build robust migration documentation for the community.

It has been over a year since our last major update, and we believe now is the right time to move on from legacy constraints we have carried for a while.

As always, we would like to thank all our contributors:

👏 Xavier Bourry, Frank Elsing, Jakub Pelc, itisyb, Yu Chun Tsao, neodescis, Matt Van Horn, Will Field, Ashwin Chandran, Seokcheol Jeong, Sam, and Kyℓe Hensel.

🧩 MapLibre Tile (MLT)

Markus Tremmel has shared initial design considerations and encoding strategies for MLT 3D, building on an original proposal by Anas. This project explores how a dedicated 3D tile format can be optimized for the MapLibre ecosystem while identifying key areas where it diverges from existing standards like 3D Tiles.

There is potential for direct MapLibre GL JS integration, which would pave the way for more robust 3D capabilities natively and the project is currently seeking feedback on both use cases and technical encoding.

You can explore the design document and provide feedback on the GitHub repository.

⚛️ MapLibre React Native

MapLibre React Native v11 is here, and it is the first release to exclusively support React Native’s new architecture. Alongside this foundational shift, the entire API has been overhauled to align with MapLibre GL JS, making it easier than ever to share knowledge and code between web and native map implementations.

One of the most exciting additions is style-spec compliant paint and layout props on the unified Layer component. This means layer definitions exported from the style spec can be spread directly onto a Layer component with no translation needed.

A full migration guide with before-and-after code snippets for every breaking change is available in the v11 migration docs. Grateful to everyone who contributed to this release and look forward to building on this clean foundation in the versions ahead!

🪶 MapLibre Flutter

flutter-maplibre-gl

flutter-maplibre-gl, the long-standing Flutter plugin, has shipped v0.26.0! This release focuses on closing years of accumulated backlog and bringing the package back to a healthy maintenance baseline.

Interactive examples of new features.

Highlights:

Offline regions, rebuilt end-to-end — the offline manager now supports pause/resume of downloads, per-tile progress reporting, cache eviction policies, and rate-limit safety on the tile server side.
WASM release mode on Flutter Web — long-standing build issues with WASM in release mode have been resolved, making Flutter Web a viable production target.
takeSnapshot() — a single, unified snapshot API now works consistently across Android, iOS, and Web.
Tap handling — onMapClick now reliably fires on every tap, including taps on rendered features.
Feature State on Web — setFeatureState, getFeatureState, and removeFeatureState are now available on the Web platform, closing a feature parity gap with the native platforms.
Camera interpolation — easeCamera now accepts interpolation curves, removing velocity jumps in GPS-following scenarios.
Synchronous GeoJSON drag — drag handling for GeoJSON features is now synchronous, eliminating stale positions during interactions.
A long tail of fixes — including Android split-screen behavior, an iOS onStyleLoaded race condition, and a brand new example app.

A screenshot of the new hover effect.

Full changelog: https://github.com/maplibre/flutter-maplibre-gl/blob/main/CHANGELOG.md

Package: https://pub.dev/packages/maplibre_gl

Special thanks to all the contributors and maintainers for shepherding the package through this work.

flutter-maplibre

Version 0.3.5 of the flutter-maplibre has been released, featuring several improvements to consistency and stability alongside general maintenance. The MapLibre SDKs and the dependencies on jni / jnigen have been updated.

As an ongoing task, work continues on static typed expressions that fit well into Dart. Ideas regarding the Dart syntax, can be discussed here.

✨ Community Spotlight

HDTP is an open data platform by Codeando México that features a notable GTFS Realtime (GTFS-RT) visualizer. This tool combines MapLibre with deck.gl to create an interactive map (checkout the cine mode) for exploring real-time transit data, efficiently displaying live vehicle positions.

👥 Conferences & Events

LinuxFest Northwest

On April 25, Stephanie May and Matt Wilden delivered a joint presentation at LinuxFest Northwest on the synergies between MapLibre and OpenStreetMap US. They discussed how the tooling and infrastructure across both ecosystems have matured enough for anyone to build an open-source map—including building custom tiles, styling layers, and scaling a CDN or dynamic tile server.

The enthusiastic crowd was eager to dive deeper into the world of open mapping. You can find the slides for their talk, titled “The Latest in Open Source Maps,” here, along with various demos showcasing how accessible working with open-source data and maps has become.

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Native: May 13, 2026 – 7:00–8:00 PM Berlin Time (UTC+2)
MapLibre GL JS: May 13, 2026 – 8:00–9:00 PM Berlin Time (UTC+2)

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

May 27, 2026 – 9–10:00 AM UTC

MapLibre Newsletter March 2026

Fri, 03 Apr 2026 00:00:00 GMT

Welcome to the March 2026 edition of the MapLibre Newsletter! This month marks a significant transition for our community. We have made the decision to sunset the current MapLibre Bounty Program as we shift towards a contributor recognition system.

Please stay tuned for more details in the coming months as we finalize how this new system will empower our community. In the meantime, we encourage everyone to read the FAQ included in our recent blog post for more context on this change.

This evolution is made possible by the continued and growing support from our partners.

🙏 We are particularly grateful to Notion for their recent financial contribution via Open Collective.

Contributions like these are vital as we look out for co-funding models for major features like Terrain3D and the maturation of the MapLibre Tile (MLT) project.

Now, let’s dive in for the latest updates!

📱 MapLibre Native

Releases

Platform	Latest Versions
Android	13.0.0 , 13.0.1 , 13.0.2
iOS	6.24.0 , 6.25.0
Node.js	6.4.0 , 6.4.1

Terrain3D: Call for Funding

Support for Terrain3D is one of the most upvoted features for MapLibre Native. While several, (mostly) vibe coded prototypes have been developed, delivering a production-grade implementation is something that requires a significant investment in graphics engineering and expertise.

A visualization of elevation data

We are pleased to announce significant progress! We have identified a company that is willing to commit substantial funding to this initiative. However, they are seeking an additional co-funding partner to bring this feature to life.

If your organization is interested in supporting this development, please reach out to us at team@maplibre.org. We are also open to connecting with individual developers who are interested in contributing to this effort.

To clarify, MapLibre (the organization) is not directly funding Terrain3D for MapLibre Native at this stage. Instead we are facilitating connections between interested parties (companies, developers). MapLibre will provide maintainer support through consensus building, quality control, CI/CD, communication and release management.

We have created a dedicated branch feature/terrain-3d for continued work on the initial prototype. You can follow the progress in this PR.

🌐 MapLibre GL JS

We had a great month with 5 new releases: v5.20.0, v5.20.1, v5.20.2, v5.21.0, v5.21.1.

✨ Some of the highlights of this month include:

We introduced updateable features to the geojson-vt library, which improved the GeoJSON update performance significantly. While this initially caused a few nasty bugs which were quickly resolved thanks to Ryan Scully, the results are worth it. The latest version is reportedly 7x faster compared to when we began GeoJSON optimizations a few months ago. Many thanks to everyone who contributed code, helped with the testing, and submitted bug reports!
Memory optimizations and removal of legacy code supporting outdated browsers, mainly lead by Johan.
Improved ETag handling added by Rivka Matan and Ryan Scully stops the map from re-downloading unchanged data, saving bandwidth and speeding up load times.
Resampling support is available now. This was added by Lars Maxfield. This option lets users turn off smoothing to see raw, pixel-accurate terrain data instead of a blended or blurry image
An example of how to use MapLibre GL JS with 3D tiles example was added by Hang.

Last month we mentioned starting pre-releases for Version 6. However due to the high volume of contributions to the current branch, we have decided to continue with Version 5 for now. We still aim to begin the Version 6 transition in the coming months.

🏆 The sheer volume of work contributed this month is amazing! A huge thanks to this month’s contributors: Claudio, Baixiaochun, Xavier Bourry, Johan, Kikuo Emoto, Kate Miháliková, Gareth Bowker, Danila Poyarkov, Ted Piotrowski, Hang, yano-h-wni, Rivka Matan, Ryan Scully, ItisYB, Lars Maxfield, JT, Stephen Andre and PierreC.

🧩 MapLibre Tile (MLT)

The MapLibre Tile (MLT) project has seen significant progress this month. The Rust implementation is rapidly maturing; we have introduced a comprehensive suite of synthetic tests to ensure stability across edge cases.

Beyond just stability, we have achieved full decoding and expanded partial encoding support, bringing us closer to a production-grade toolkit. This progress is a major step toward making MLT a viable, high-performance alternative to MVT, offering better compression and faster parsing for large-scale geospatial data.

Tim Sylvester also made many improvements to the Java CLI tool. The performance for parallel conversion from MVT has been improved by several orders of magnitude. This now makes it a suitable tool to adapt existing MVT creation pipelines. In addition, the data input of the Java encoder is being generalized. This prepares MLT for a future where the data model of MLT that goes beyond MVT parity, enabling support for m-values or encoding lists and nested key-value structures.

On the rust side (competition is good!), both the encoder and decoder have seen major refactorings by Yuri Astraken and Frank Elsinga that have increased this encoders performance and output quality signifcantly. It can now beat java in most cases, but this is because we have settings that explore more state-space which is slower. More engineering is neccesary to improve performance beyond what java offers. There are also experiments using diplomat to provide FFI access to the rust based tooling. More on this in the next update.

You can follow the development and check out the MLT Specification on GitHub.

🦀 Martin

This month, like the last month, has been focused on implementing a production-grade MLT encoder/decoder, so there has not been much movement regarding Martin.

We fixed a startup crash that occurred when ST_Extent returns a LineString instead of Polygon , and added ZSTD support thanks to @nuts-rice. We also further reworked our new documentation site and ironed out a few of the remaining inconsistencies.

✨ Community spotlight

We are tracking an exciting development in the rendering world: the Slug algorithm is now out-of-patent.

Most maps currently draw text using pictures of letters, which can look fuzzy when you zoom in close to the map view. The Slug algorithm replaces these pictures with mathematical blueprints, allowing labels to remain perfectly crisp at any angle or scale.

Now that this technology is public property, we are looking for community members to help us research how to bring these benefits to MapLibre. Join us in our GitHub discussion.

👥 Conferences & Events

FOSSGIS

MapLibre was well-represented at the FOSSGIS, a German open source geospatial and OpenStreetMap conference. It was a fantastic opportunity to connect with the community and share updates on our projects.

Oliver Wipfli(former MapLibre coordinator) shared how his project Mapterhorn is expanding from terrain tiles to create a new dataset with satellite coverage.
Kilian Finger discussed progess on getting MapLibre React Native ready for the new architecture.
Frank Elsinga and Bart Louwers gave a talk on the latest MapLibre developments, specifically introducing the community to MapLibre Tile (MLT).

If you want to view the MapLibre talks at the conference, checkout the recordings below (they are in German):

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Navigation: Apr 8, 2026 – 5:00–6:00 PM UTC
MapLibre Native: Apr 8, 2026 – 6:00–7:00 PM UTC
MapLibre GL JS: Apr 8, 2026 – 7:00–8:00 PM UTC

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Apr 29, 2026 – 10:00–11:00 AM UTC

We're Sun-setting the Bounty Program

Mon, 23 Mar 2026 00:00:00 GMT

TL;DR: MapLibre is sun-setting the bounty program as originally conceived because it isn’t a sustainable way to incentivize contributions at our current scale. The Board and maintainers are working hard to identify what comes next. We will honor any existing bounty commitments.

Since our founding, MapLibre has asked sponsors to contribute to a development fund intended to incentivize new feature development; primarily through bounties. After running this program for several years, we’ve concluded it no longer serves our community well.

Effective March 31, 2026, we will no longer be offering bounties for development work. We will instead pursue roadmap and feature development goals through pathways more typical for open source software.

We are working toward a contributor recognition system that rewards regular, high-value contributions that sustain and strengthen our community. If you have questions or ideas, please reach out.

Reason for the change

We are making this change because the system as it was designed fails on a structural level:

Overhead: The bureaucratic overhead is high for both MapLibre and our community.
Visibility: Many very helpful contributions happen outside this system and remain invisible to it, such as community work and ecosystem maintenance.
AI: We need to respond to the rising use of coding agents and AI assisted development; the Bounty System does not adequately incentivize the patterns we need from contributors.
Compensation: The payouts are not competitive enough to be a meaningful or reliable income source in most markets.
Adoption: We have not seen significant usage of this system for contributions.

The Governing Board’s mission is to sustain and grow this project by recognizing those who invest their time and money in it. A bounty-based model may have seemed like a good idea at first, but at our current scale it creates more problems than it solves.

Looking ahead

We would like to replace the bounty system with a contributor recognition system that rewards impact and community contribution. The Board and maintainers are actively working to define what this looks like, and we will share more details as they are finalized.

MapLibre exists because of its contributors across code, ecosystem integrations, and community work. That hasn’t changed. Our goal is a well-funded project that can pay the people who sustain it. That starts with sponsorship; if your company builds on MapLibre, please become a sponsor.

MapLibre remains a community-driven project. If you have feedback or ideas, we want to hear from you. This is an ongoing conversation, and we’re building the future together.

Frequently asked questions

Q: What is the history of the bounty program?

MapLibre introduced our bounty program in 2022 to give back to contributors, encourage new participation, and create a lightweight reward system. Developers could sign up, comment on bounty-labeled issues, complete the work, and submit an invoice through OpenCollective. The process was bureaucratic by design, and at the time, we had no budget or runway. We are more established today, and want to align with the common practices of other open source organizations to ensure the sustainability and stability of the project.

Q: Is this part of a broader organizational change?

No. MapLibre remains a lean organization with a Governing Board made entirely of volunteers and four part-time staff members.

Our financial reports are public. We are currently operating at a loss. See our sponsor page if you want to help.

Q: What if I have an in-flight bounty?

Contact your maintainer. We will honor existing commitments.

Q: I maintain a MapLibre integration for another platform or framework. When can MapLibre financially support me?

Ecosystem maintainers — the volunteers who keep integrations like Flutter, React Native, Qt, and others working — extend MapLibre’s reach into developer communities our core team cannot serve directly. That work matters enormously to us, and to the users and companies downstream who depend on it.

We can’t pay you directly yet, but it’s a goal we’re working toward. In the meantime, we support ecosystem maintainers in concrete ways: we’re exploring grant-based and commercial funding for larger efforts, we can help with hardware or testing resources if you’re blocked by a missing device or platform, and we can cover reasonable conference travel costs for presenting your work. Reach out to a board member to start the conversation.

MapLibre Newsletter February 2026

Tue, 03 Mar 2026 00:00:00 GMT

Welcome to the February 2026 edition of MapLibre Newsletter! It’s been an active month with exciting updates, from shifting rendering backends to launching a collection of agent skills to perform MapLibre related tasks.

A special thanks to MapTiler for their continued support. We updated our Sponsors page this month, to make clearer how organizations and individuals can give. If you have been thinking about contributing, there has never been a better time.

Our gratitude goes to MapTiler for their continued support to MapLibre.

With that note, let’s dive into the latest updates across the MapLibre ecosystem!

📱 MapLibre Native

Core library: Distance-Based Level-of-Detail (LOD)

Nathan Olson implemented a distance-based level-of-detail algorithm into the core library. However, platform APIs for this functionality still need to be added.

Experimental WebGPU Backends for Mobile

Birk Skyum implemented a WebGPU backend for Android and for iOS. At this point the motivation behind this is more or less “because we can”, but it might offer opportunities to share custom shaders between platforms in the future.

New Hillshading Algorithms Merged

Andrew Calcutt’s PR that implements additional hillshade algorithms has been merged! These algorithms are included in the current pre-release for Node.js, and the next releases for MapLibre iOS and MapLibre Android.

Android: Transitioning to Vulkan by Default

We released MapLibre Android 13.0.0 which now uses Vulkan as a default rendering backend. This means that the org.maplibre.gl:android-sdk package is now using Vulkan. You can use the org.maplibre.gl:android-sdk-opengl package if you prefer to stick to OpenGL ES for now.

🌐 MapLibre GL JS

New Releases: Versions 5.18 and 5.19

We’ve released versions 5.18 and 5.19 this month. A major highlight is the migration of our documentation to Zensical, the next-generation replacement of Material for MkDocs, which has served us very well until now. We also added anisotropicFilterPitch to support some interesting data analysis use cases.

We would like to thank all the contributors this month for these versions - truly inspiring work!

🙏 n4n5, Lars Maxfield, pcardinal, Simon, Birk Skyum, Harel Mazor, Ganesh Lokhande, Ryan, Frank Elsinga, Kai Gritun, Stanislaw Puda, Lucas Wojciechowski, Russell Porter

The Road to Version 6

The following PR, which will pave the way for our next major release is now ready to be merged:

👉 https://github.com/maplibre/maplibre-gl-js/pull/6992

We expect to release a first pre-release for version 6 in March. While we haven’t made a major (breaking) release in over a year now to keep things as maintainable as possible, it is now time to move forward with changes we’ve previously deferred.

The primary change in version 6 regarding developer experience will be the transition to ESM. As the industry moves toward ESM and our current build process is becoming increasingly complex, we are considering not releasing a CommonJS version. This transition will allow us to leverage newer technologies like Rolldown.

We would love to hear your thoughts on these expected breaking changes to ensure we don’t disrupt your workflow. Please join the discussion in the relevant tracking issue and share your feedback.

🪶 MapLibre Flutter

Versions 0.3.4 and 0.3.4+1 of maplibre have been released this month, bringing significant architectural improvements and expanded platform support.

iOS transition to FFI

A major milestone in this release is the complete transition of the iOS implementation to use FFI, removing all remaining usages of method channel serialization. This simplifies the integration between Flutter and the native SDK while providing minor performance gains.

Federated plugin architecture

As part of an ongoing committment to code quality, the plugin has been reorganized into a fully federated plugin architecture, separating each platform implementation into a dedicated packages. This restructuring improves long-term maintainability and allows each platform to evolve independently. These changes happened under the hood and require no migration from users.

Experimental desktop support

Experimental support for Windows and macOS has been introduced via a WebView–based implementation that uses MapLibre GL JS. This is a simple solution to bring performant vector map rendering to these desktop platforms while broader native support continues to mature.

MapLibre GL JS map rendering within a Flutter App on Windows.

Documentation and Future Roadmap

The documentation website has been migrated to Zensical alongside the broader MapLibre migration. Check it out and let us know what you think.

Looking ahead, work is progressing on typed style layer properties and expressions, a highly anticipated feature. We are currently targeting static typing for style expressions, paint/layout properties, and new style layer inspection capabilities for the upcoming v0.4.0 release.

🤖 Maplibre Agent Skills

In an effort to move with the times and inform the LLMs of all the great things you can build with MapLibre, we’ve launched maplibre-agent-skills, a library of structured knowledge files that help AI coding assistants (Claude Code, Cursor, GitHub Copilot) write better MapLibre applications.

Rather than putting up with bad or wrong MapLibre integrations, we’re directly informing the AI agents so they in turn share good information and the right recommendations on when it makes sense to use MapLibre, how to deal with tile sources and other renderer resources, and how to follow open-ecosystem patterns.

Skills available now:

maplibre-tile-sources — choosing hosted vs. self-hosted tiles, OpenFreeMap, PMTiles, glyphs, CORS
maplibre-pmtiles-patterns — serverless tile hosting on S3, R2, and static hosts
maplibre-mapbox-migration — migrating from Mapbox GL JS to MapLibre GL JS

Visit maplibre-agent-skills for more details on how to use or install these, or review the open issues for what’s next.

We’re looking for contributors. Skills are plain markdown files, easy to read, review. We welcome your expansions, corrections and questions. If you’ve tackled geocoding, routing, styling, framework integration (React, Vue, Angular, Flutter, Swift), or performance — your experience can make a big impact.

See contributing guidelines for how to write a skill, or open an issue to propose a new one we haven’t thought of yet.

🎨 Style Spec

The MapLibre Style Spec continues to evolve to support more complex styling needs:

split and join, which allow better string manipulation, are now part of the spec and are expected to be incorporated in MapLibre GL JS soon.
resampling was also added to support other layers besides raster.
symbol-elevation will probably land soon to allow better support for placing symbols in a 3D map, check it out here: https://github.com/maplibre/maplibre-style-spec/pull/1508

🦀 maplibre-rs

In February our focus has been on text rendering, with the following enhancements merged in:

SDF renderer plugin, adding support for text labels as shown on the picture below. Thanks to @maxammann for the PR.
Support for configurable text-field property for symbol layers, so it’s possible to e.g. set the language of the labels. Thanks to @birkskyum for the PR.
Render tests harness added to the project. Thanks to @birkskyum for the PR.

Demonstration of the new SDF-based text rendering in maplibre-rs.

🧩 MapLibre Tile (MLT)

There is a growing interest in the new format. Our current priorities are:

Mature decoders. In particular, we are rebuilding the test infrastructure to ensure high quality decoders in all the major languages.
Encoders in Rust and C++. Having mature encoders will allow integration into all kinds of tools such as databases and tiles servers.
Leverage the native strengths of the MLT directly. For example, in MapLibre GL JS we aim to move away from the current method of converting data into an MVT-style model.

📣 Call for Volunteers: MLT Logo

The MLT project is looking for a volunteer to design our official logo. This is a great opportunity to contribute to the project and leave a lasting mark on the MapLibre ecosystem. Please join the discussion to provide your inputs or share your submissions!

We’ve made great progress on the tooling side, including a Rust-based TUI and a dedicated QGIS plugin 🎉 Stay tuned for more updates!

MLT TUI: Direct feature inspection within the terminal.

MLT Data integration progress within the QGIS ecosystem.

⚙️ Martin

While it has been a relatively quiet month as we focus on MLT development, we’ve still shipped several key improvements to the tile server:

Web UI Fixes: The path-prefix now works correctly within the Web UI.

Smarter Routing: Common URL mistakes (e.g., using /source.mvt instead of /source) now return a 301 redirect instead of a 404, including periodic log hints to help fix configurations.

COG Stability: The experimental Cloud Optimized GeoTIFF (COG) backend was tightened significantly (thanks to David E Disch, PR #2510). To ensure stability, COGs must now be fully WebMercator-compatible (EPSG:3857), tiled, and consistently sized. Some previously ambiguous COGs may no longer load as we move toward a more predictable, production-ready implementation.

Manbhav Sugla also migrated our documentation to Zensical, which looks much more modern than what we had before.

✨ Community spotlight

Yossef from our community has build QGIS2VectorTiles which streamlines the process of packing a QGIS project into a styled vector tile package ready for MapLibre. It allows users to design maps within the familiar and flexible QGIS Desktop and export stunning MapLibre client-side web maps leveraging GDAL’s MVT driver.

The exported output package includes:

Vector tile source: XYZ directory
Styled QGIS layer file: A .qlr file
MapLibre style: A ready-tp-use .json stylesheet
MapLibre sprites (optional) :.png and .json files
A ready-to-use MapLibre viewer: A pre-configured .html file

This package is ideal for:

Client-side web map rendering via MapLibre, OpenLayers, and Leaflet
Lightweight WMS/WMTS vector tile serving via GeoServer and QGIS Server
Sharing complex, multi-source styled QGIS projects packaged as a single data source and layer file

A short demo is attached:

Exporting styled vector tiles directly from QGIS.

More information is available on the plugin homepage.

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Navigation: Mar 11, 2026 – 5:00–6:00 PM UTC
MapLibre Native: Mar 11, 2026 – 6:00–7:00 PM UTC
MapLibre GL JS: Mar 11, 2026 – 7:00–8:00 PM UTC

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Mar 25, 2026 – 9:00–10:00 AM UTC

🔗 View meeting times in your local timezone.

All calls are open to everyone. Zoom links are shared in the MapLibre Slack. Not yet a member? Request an invite via the OpenStreetMap US Slack. We’d love to see you there!

CalTopo joins the MapLibre Sponsorship program

Mon, 16 Feb 2026 00:00:00 GMT

We’re pleased to announce that CalTopo is now a Silver sponsor of the MapLibre project.

CalTopo has built one of the most trusted field mapping platforms in the US, relied on by search and rescue teams, wildland firefighters, and backcountry adventurers who need maps to work when it counts. We’re proud to welcome them as a MapLibre sponsor — and to support the open-source rendering infrastructure that powers their maps.

CalTopo is an app for collaborative map building and offline adventuring, and they rely heavily on MapLibre powering their 3D maps, making it possible for users to explore terrain in a more intuitive, visual way.

Below, the CalTopo team shares more about why they chose to support MapLibre and how it fits into their product roadmap.

What motivated CalTopo to support MapLibre?

MapLibre is a core part of how CalTopo works and we rely on it every day to deliver the mapping experience our users expect. Supporting MapLibre is about investing in an organization that we depend on and believe in. When the libraries continue to grow and improve, it helps us build better tools for our community and ensures the long-term stability of the mapping technology behind our apps.

How does MapLibre fit into your product and technical roadmap?

MapLibre plays a central role in how people experience CalTopo. In our mobile app, it’s the map engine that displays all of our layers, routes, and user data. On the web, MapLibre powers our 3D maps, making it possible for users to explore terrain in a more intuitive, visual way. As we continue to invest in performance and expand our 3D capabilities, MapLibre remains an important part of how we bring those ideas to life.

What do open-source mapping tools mean for your community?

Open-source mapping tools make it possible for us to stay focused on what matters most to our users. By building on reliable, community-driven libraries, we’re able to move faster, keep costs down, and put more effort into solving real planning and navigation challenges. That ultimately means a better product for our users and access to powerful tools without unnecessary barriers.

We’re thankful for the work and care that goes into the libraries and MapLibre organization. The time and effort contributed by the community have a direct impact on the tools our users rely on every day. We’re proud to support this work and excited to be part of an open mapping ecosystem that continues to grow and improve through collaboration.

We’re grateful to CalTopo for their support and for sharing their perspective. Sponsorships like this help strengthen the long-term sustainability of the MapLibre project. If you are interested in sponsoring MapLibre, we invite you to learn more about our sponsorship program.

MapLibre Newsletter January 2026

Tue, 03 Feb 2026 00:00:00 GMT

Welcome to the January 2026 edition of MapLibre Newsletter! This edition covers project updates across the MapLibre ecosystem, a round-up of events from the past month, and highlights from our growing global community.

MapLibre continues to move forward thanks to the support of its community. Since launching GitHub Sponsors, 87 sponsors have supported MapLibre over time, with 35 sponsors currently backing the project, alongside 40+ community backers on Open Collective contributing varied amounts.

Thank you to everyone who supports MapLibre with their time, feedback, code, and financial contributions 💙.

Our sincere thanks to the individuals and organizations who support MapLibre through GitHub Sponsors and Open Collective. Your contributions, big or small, help keep the project open, independent, and community-driven.

📱 MapLibre Native

We’ve published the test app for iOS on TestFlight!

If you have a spare iPhone lying around, please enroll and run the ‘long running test’ made by Adrian Cojocaru. Any crashes are automatically reported to our Sentry project and will be available for MapLibre developers to investigate¹. Testflight link: https://testflight.apple.com/join/h81pYA1M

Nathan Olson added camera roll support to MapLibre Native (#3011). This feature is now available on both MapLibre iOS and MapLibre Android.
Nathan also is working on a distance-based level-of-detail(LOD) implementation in #4057. This is the same algorithm that is used for MapLibre GL JS. If you (also) have an aviation related use case for MapLibre Native we would love to hear from you.
Releases this month:
- MapLibre iOS 6.23.0, 6.22.2

🌐 MapLibre GL JS

Versions 5.16 and 5.17 were released this month. We also integrated the geojson-vt version that was recently onboarded into the MapLibre organization, which should facilitate faster GeoJSON updates in the near future.

We are looking to improve GeoJSON serialization, including addressing limitations related to nested properties. We’d love to get community feedback on the following PR: https://github.com/maplibre/maplibre-gl-js/pull/6992

Once this PR is merged and GeoJSON serialization is improved, it will pave the way for releasing version 6 as this will be breaking. Version 6 will also include additional breaking changes that we’ve gathered over the past year, which are described in the following issue:

https://github.com/maplibre/maplibre-gl-js/issues/6427

Any feedback is very welcome.

We would like to thank this month’s contributors, every contribution helps make the library better for everyone who uses it. THANK YOU! 🙌

Lucas Wojciechowski, Les, melitele, Minh Nguyễn, Stanislaw Puda, Lars Maxfield, ToHold, Licheng Mao, Ryan, Stephanie May, yujian, Harel Mazor, Taku Fukada, David E Disch

🧩 MapLibre Tile

This month we officially announced MapLibre Tile!

Tim Sylvester is working on adding PMTiles support to the Java Encoder CLI (#798). The Java CLI tools can be downloaded from the releases page.

We have added coverage checking to the Java encoder/decoder. At the Codecov page you can see that Rust and Java have some catching up to do to reach the coverage number of the TypeScript decoder.

We have a monthly community call to discuss MLT developments, if you would like an invite, send a message to team@maplibre.org

Screen grab from the MapLibre demo site showcasing vector tiles.

⚙️ Martin

We’ve released Martin 1.3.0, bringing improvements to logging, font handling, routing, and tile formats - plus several performance and UX fixes.

Highlights include:

More flexible logging: Martin now uses tracing instead of log, enabling better instrumentation and configurable log output via RUST_LOG_FORMAT. Supported formats include compact (default), json, full, bare, and pretty.
Improved glyph support beyond U+FFFF: Fonts with characters outside the Basic Multilingual Plane (e.g. emoji, historic scripts, or private-use glyphs) are now handled correctly. We also removed FontSources.masks, reducing memory usage and startup time.

Since not everyone is likely aware of what U+FFFF means:
- U+0000 - U+FFFF is Basic Multilingual Plane, which covers characters for almost all modern languages
- U+10000 - U+3347F covers minor characters such as historic scripts and emojis
- U+E0000 - U+E01EF is for tags and variation selectors
- U+F0000 - U+10FFFF is for private use (i.e. can be assigned arbitrary custom characters without worrying about possible conflict with the future standards)

Native subpath support: A new route_prefix config option and --route-prefix CLI flag allow Martin to serve from a subpath without requiring reverse-proxy URL rewriting.
MLT decoding support: Martin now supports the MapLibre Tiles Specification (MLT), allowing MLT-based tiles to be served directly.
Human-readable time estimates in martin-cp progress output
PostgreSQL materialized view support and improved table metadata

Check out the full changelog on GitHub, and as always, thanks to Hiroaki Yutani, David E Disch, Amanda, Kunal, thomfuhrmann, Birk Skyum, Frank Elsinga and Yuri Astrakhan who contributed to this release 💙

👥 Conferences & Events

Last month, members of the MapLibre team were on the ground connecting with the community, sharing updates, and learning alongside fellow open-source contributors at the following events:

FOSS4G Asia in Nashik, India where Frank Elsinga held a workshop on Tile Serving with MapLibre.
State of the Map India in Nashik, India
FOSDEM in Brussels, Belgium where Frank Elsinga and Bart Louwers presented State of the MapLibre Tile Format.

MapLibre team members at recent community conferences, including FOSS4G Asia (Nashik, India), State of the Map India, and FOSDEM (Brussels).

It was great to meet community members in person, exchange ideas, and represent MapLibre across regions.

We’re looking forward to attending more events in the coming months. If you’d like to follow along or suggest events we should be part of, please let us know in this GitHub discussion.

🗓️ Monthly meetings

We continue our regular community calls on the second Wednesday of each month, with an additional session on the last Wednesday to better accommodate Asia/Oceania time zones.

Upcoming Calls

MapLibre Navigation: Feb 11, 2026 – 5:00–6:00 PM UTC
MapLibre Native: Feb 11, 2026 – 6:00–7:00 PM UTC
MapLibre GL JS: Feb 11, 2026 – 7:00–8:00 PM UTC

🌏 MapLibre Eastern Call

Held on the last Wednesday of the month at an Asia/Oceania-friendly hour:

Feb 25, 2026 – 9:00–10:00 AM UTC

🔗 View meeting times in your local timezone.

All calls are open to everyone. Zoom links are shared in the MapLibre Slack. Not yet a member? Request an invite via the OpenStreetMap US Slack. We’d love to see you there!

Note: crash reports may include some privacy-sensitive data such as IP addresses (see privacy policy). ↩

Announcing MapLibre Tile: a modern and efficient vector tile format

Fri, 23 Jan 2026 00:00:00 GMT

Today we are happy to announce MapLibre Tile (MLT), a new modern and efficient vector tile format.

What is MapLibre Tile?

MapLibre Tile (MLT) is a successor to Mapbox Vector Tile (MVT). It has been redesigned from the ground up to address the challenges of rapidly growing geospatial data volumes and complex next-generation geospatial source formats, as well as to leverage the capabilities of modern hardware and APIs.

MLT is specifically designed for modern and next-generation graphics APIs to enable high-performance processing and rendering of large (planet-scale) 2D and 2.5 basemaps. This current implementation offers feature parity with MVT¹ while delivering on the following:

Improved compression ratio: up to 6x on large tiles, based on a column-oriented layout with recursively applied (custom) lightweight encodings. This leads to reduced latency, storage, and egress costs and, in particular, improved cache utilization.
Better decoding performance: fast, lightweight encodings that can be used in combination with SIMD/vectorization instructions.

In addition, MLT was designed to support the following use cases in the future:

Improved support for 3D coordinates, i.e. elevation.
Improved processing performance, based on storage and in-memory formats that are specifically designed for modern graphics APIs, allowing for efficient processing on both CPU and GPU. The formats are designed to be loaded into GPU buffers with little or no additional processing.
Support for linear referencing and m-values to efficiently support the upcoming next-generation source formats such as Overture Maps (GeoParquet).
Support complex types, including nested properties, lists and maps.

As with any MapLibre project, the future of MLT is decided by the needs of the community. There are a lot of exciting ideas for other future extensions and we welcome contributions to the project.

For a more in-depth exploration of MLT have a look at the following slides, watch this talk or read this publication by MLT inventor Markus Tremmel.

When can I use it?

For the adventurous, the answer is: today. Both MapLibre GL JS and MapLibre Native now support MLT sources. You can use the new encoding property on sources in your style JSON with a value of mlt for MLT vector tile sources.

To try out MLT, you have the following options:

The easiest way to try out MLT is to use the MLT-based demotiles style.
You can also try out the encoding server that converts existing (MVT-based) styles and vector tile sources to MLT on the fly. This is mostly a tool for development.
To create tiles for production, you could use Planetiler, as the upcoming version will support generating MLTs.

Refer to this page for a complete and up-to-date list of integrations and implementations. If you are an integrator working on supporting MLT, feel free to add your own project there.

We would love to hear your experience with using MLT! Join the #maplibre-tile-format channel on our Slack or create an Issue or Discussion on the tile spec repo.

Acknowledgements

MapLibre Tile came to be thanks to a multi-year collaboration between academia, open source and enterprise. Thank you to everyone who was involved! We are very proud that our community can innovate like this.

Special thanks go to Markus Tremmel for inventing the format, Yuri Astrakhan for spearheading the project, Tim Sylvester for the C++ implementation, Harel Mazor, Benedikt Vogl and Niklas Greindl for working on the JavaScript implementation.

Also thanks to Microsoft and AWS for financing work on MLT.

One exception: unlike MVT, MLT does not support layers where a value in a column changes type from feature to feature. ↩

MapLibre

MapLibre Newsletter September 2026

MapLibre Native

Cross-platform Plugin System

Ongoing Terrain3D work

OpenHarmony Platform

Call for MapLibre Accessibility Features

Other news

Releases

🌐 MapLibre GL JS

🦀 Martin

MapLibre Tiles (MLT)

🎨 MapLibre Compose

✨ Community Spotlight

MapLibre Navigation SDK 5.0.0

Tel Aviv 2035

🗓️ Monthly meetings

Results of the 2026 MapLibre Governing Board Election

Board Results

📊 Key Election Statistics

🗳️ Growing our pool of Voting Members

MapLibre Newsletter August 2026

🏛️ Board & Team Updates

📱 MapLibre Native

🌐 MapLibre GL JS

🦀 Martin

🤖 Maplibre Agent Skills

🪶 MapLibre Flutter

✨ Community Spotlight

MapLibre GL JS Ecosystem Adoption

Expressive

👥 Conferences & Events

🗓️ Monthly meetings

GSoC'26: DuckDB Backend for Martin TileServer

Introduction and Motivation

Config Structure for DuckDB backed sources

martin-core: DuckDBSource and pool (#2831)

Bounds and SQL utilities (#2902)

GeoParquet configuration and resolution (#2931)

End-to-end local GeoParquet support (#3054)

What this enables

Remaining work

Conclusion

MapLibre Newsletter July 2026

🏛️ Governing Board Update & 2026 Elections

📱 MapLibre Native

🌐 MapLibre GL JS

📢 v6 Release

🤝 A Quick Note for Contributors

🦀 Martin

🎨 MapLibre Compose

🪶 MapLibre Flutter

👥 Conferences & Events

🗓️ Monthly meetings

MapLibre Newsletter June 2026

📢 We are Hiring: Graphics Engineer

📱 MapLibre Native

🌐 MapLibre GL JS

👥 Conferences & Events

🗓️ Monthly meetings

MapLibre Newsletter May 2026

📱 MapLibre Native

Code Integrity & AI Policy

🌐 MapLibre GL JS

Help Us Test the MapLibre GL JS v6 pre-releases

Style Specification: Share Your Inputs

🦀 Martin

✨ Community Spotlight

👥 Conferences & Events

🗓️ Monthly meetings

Welcoming YellowMap as a Silver Sponsor!

Why YellowMap Chose MapLibre: A Shift to Modern Vector Maps

How YellowMap Meets Data Compliance Needs with MapLibre

How YellowMap Utilizes MapLibre Today

The Road Ahead

MapLibre Newsletter April 2026

📱 MapLibre Native

🌐 MapLibre GL JS

🧩 MapLibre Tile (MLT)

⚛️ MapLibre React Native