Maplibre: community-driven Mapbox GL fork(maplibre.org)
maplibre.org
Maplibre: community-driven Mapbox GL fork
https://maplibre.org/
86 comments
I'm one of the folks behind the fork (and part of the initial steering committee). Happy to answer any questions!
I've struggled to understand the relationship between Mapbox, Mapbox Studio, Mapbox GL, OpenStreetMap, and other libraries like OpenLayers or Leaflet.
Could you please explain (in brief) the mapping "ecosystem" as it were, and where Maplibre fits into the picture?
Could you please explain (in brief) the mapping "ecosystem" as it were, and where Maplibre fits into the picture?
Good question! There's a lot of Map<thing>s and it's very unclear how they all fit together without prior experience.
OpenStreetMap (OSM) is a community-driven, fully open and usable data library. It has usable data for almost the entire world for everything from cities, roads, houses, parks, country borders, and work. It's a database of everything you need to make map. They also have a website that renders that map, but it's not commercially usable.
Mapbox is one of the first companies to take OSM's dataset and commercialize it. Along the way they created a lot of the wildly used mapping libraries, including renders, data formats, and styling tools.
Mapbox Studio is one of Mapbox's proprietary tools for working with maps in their ecosystem.
Mapbox GL is a suite of renderers, originally entirely open source, developed by Mapbox with the community to render map data (from many different sources).
MapLibre GL is a community-driven fork of the Mapbox GL suite, after Mapbox closed the licenses to require payment if you use the latest versions.
OpenLayers and Leaflet are both alternative, open source renderers with various levels of capabilities. Interestingly, the creator of Leaflet now works for Mapbox (if my facts are correct and current).
OpenStreetMap (OSM) is a community-driven, fully open and usable data library. It has usable data for almost the entire world for everything from cities, roads, houses, parks, country borders, and work. It's a database of everything you need to make map. They also have a website that renders that map, but it's not commercially usable.
Mapbox is one of the first companies to take OSM's dataset and commercialize it. Along the way they created a lot of the wildly used mapping libraries, including renders, data formats, and styling tools.
Mapbox Studio is one of Mapbox's proprietary tools for working with maps in their ecosystem.
Mapbox GL is a suite of renderers, originally entirely open source, developed by Mapbox with the community to render map data (from many different sources).
MapLibre GL is a community-driven fork of the Mapbox GL suite, after Mapbox closed the licenses to require payment if you use the latest versions.
OpenLayers and Leaflet are both alternative, open source renderers with various levels of capabilities. Interestingly, the creator of Leaflet now works for Mapbox (if my facts are correct and current).
Yeah, the bit about the developer of Leaflet is accurate. One thing I'd expand on: the first iteration of web mapping was all built on raster maps, where the map was rendered in advance, server-side, and a simple client downloaded tiles to the client to build a slippy map. Leaflet was an open source library that did that task well.
The commercial players have mostly abandoned this approach, though, in favor of technologies that render on the client. They're more performant (tiles are smaller), and necessary if you want, say, to be able to rotate your map and still have all the labels be upright and not collide, or show/hide individual geographic features dynamically in response to user input, or apply perspective/tilt as you would for a heads-up display in a car, etc.
Mapbox GL was Mapbox building that (as already exists for Google Maps, Apple Maps, etc.). At a very high level, it and Leaflet serve a similar purpose, but are technically very different from one another.
(full disclosure: former Mapbox employee, still a shareholder)
The commercial players have mostly abandoned this approach, though, in favor of technologies that render on the client. They're more performant (tiles are smaller), and necessary if you want, say, to be able to rotate your map and still have all the labels be upright and not collide, or show/hide individual geographic features dynamically in response to user input, or apply perspective/tilt as you would for a heads-up display in a car, etc.
Mapbox GL was Mapbox building that (as already exists for Google Maps, Apple Maps, etc.). At a very high level, it and Leaflet serve a similar purpose, but are technically very different from one another.
(full disclosure: former Mapbox employee, still a shareholder)
Isn't it the case that pre-rendered tiles are more performant for the mobile user? Continously rendering the tiles on a smartphone is draining more battery? I would guess?
It's true that raster tiles are easier to draw, but CPU/GPU is rarely the limit for performance even on (modern) mobile devices, network access then disk access then memory usage is. And using the network is one of the largest sources of power use. Vector tiles are smaller downloads, therefore they are more performant.
Wall time CPU profiling is just not that useful anymore and yet it's the only thing most people ever think about for some reason.
Wall time CPU profiling is just not that useful anymore and yet it's the only thing most people ever think about for some reason.
Along with dynamic rendering mentioned in other comments, vector data is sparse, so bandwidth is basically zero past a certain (surprisingly low) zoom. Raster tiles are a dense data structure, so you need to bake tiles to the maximum allowed zoom and clients need to download them. High zoom tiles also have higher entropy so you end up with a huge volume of images with low cache hit rates. It’s expensive for the provider and slow for bandwidth constrained mobile users.
Yeah, pre-rendered tiles are typically more performant on any device. It’s basically downloading and displaying a png. In my experience, download times were not the bottleneck for vector tiles, but rather all the on-device rendering. This is especially true when you consider that most of the time, the tiles are already cached on your device.
I believe the reason most companies moved to vector had more to do with the other stuff gp mentioned: ability to rotate, dynamically show/hide features, etc.
I believe the reason most companies moved to vector had more to do with the other stuff gp mentioned: ability to rotate, dynamically show/hide features, etc.
If you never change what you display, that might well end up being true, but if changing display state (you want to highlight or shade or hide a feature, for example) that would likely require downloading whole new tiles for raster but could be a pretty trivial mutation of the current local state that doesn't require a full re-render from scratch. You probably also don't need to download as much on zoom; there are tiles for different zoom levels with vector tiles because tiles get really large when zoomed way out otherwise, mostly full of features or detail you can't see or wouldn't show, but you might not need as many, and can overzoom a given tile and have it still look nice with relatively few artifacts. All of which is to say: it depends.
To some degree its possible to combine bitmap tiles and client side lightweight vector overlay. If you want to work with ortofoto (basically satellite/airplane captured imagery) then you basically have to do it that way.
Definitely true. In my experience it's less to do with battery and more that the client-side rendering process is so intense. Particularly because of the single-threaded nature of JS: a GL-based map on a web page makes the whole thing drag on a low-specced phone.
These days Chrome and Firefox have the OffscreenCanvas API that would let you do all that rendering in a different thread, but last I looked MapBox GL didn't support it. Not sure if that's changed with libre.
These days Chrome and Firefox have the OffscreenCanvas API that would let you do all that rendering in a different thread, but last I looked MapBox GL didn't support it. Not sure if that's changed with libre.
[deleted]
Yes, for sure. Good expansion points.
Leaflet started because openlayers was very clunky. But since the major rewrite of openlayers v3 it's become a great choice and the author of leaflet has stated here on hackernews hat it's probably what you should use these days
Sorry, but I never stated such a thing. OpenLayers is great when you want all possible features/formats ever created baked in, and excels for certain use cases such as GIS academia, but Leaflet is still the library of choice for most raster-based maps — intentionally simple, lightweight, very easy to use, carefully designed, extremely stable, extensible and working beautifully.
I must agree. The simplicity and versatility of Leaflet makes it a mapping library par excellence.
I feel like I half-remember something I saw here on HN a couple of years ago, about some mapping related startup going out of business, and open sourcing some interesting tidbits. Do you (or anyone else) happen to remember that, or know what I'm talking about?
Sorry for being so vague, that's just all I remember of the whole deal. I probably bookmarked the link, but I'll probably never find it again now.
Edit: it may have been MapZen that I was thinking about.
https://www.mapzen.com/blog/shutdown/
Sorry for being so vague, that's just all I remember of the whole deal. I probably bookmarked the link, but I'll probably never find it again now.
Edit: it may have been MapZen that I was thinking about.
https://www.mapzen.com/blog/shutdown/
Mapzen is probably the one you're thinking of. A lot of their projects got rolled into various foundations (e.g., Linux Foundation).
Got it. Thanks a lot for the clear explanation!!
Great explanation, thanks!
Rough overview:
Leaflet: fairly simple open source mapping library. Canvas-based. The original Mapbox (called MapboxJS) is based on this.
Openlayers: open source mapping library that’s more capable (e.g many different protections) but also more complex. Can render to Canvas or SVG.
Openstreetmap: public and free source of mapping data. Mapbox uses this as a default data source.
MapboxGL: completely new implementation of a mapping library written in WebGL (should perform better). MapboxGL changed its license recently, prompting the creation of the libremap fork.
Leaflet: fairly simple open source mapping library. Canvas-based. The original Mapbox (called MapboxJS) is based on this.
Openlayers: open source mapping library that’s more capable (e.g many different protections) but also more complex. Can render to Canvas or SVG.
Openstreetmap: public and free source of mapping data. Mapbox uses this as a default data source.
MapboxGL: completely new implementation of a mapping library written in WebGL (should perform better). MapboxGL changed its license recently, prompting the creation of the libremap fork.
A big difference moving from OpenLayers and Leaflet to MapLibre GL is that you can use vector tiles and style them in the browser as opposed to rendering PNG files on the server. Converting OpenStreetMap to vector tiles is implemented by OpenMapTiles and they also have some open map styles.
no, openlayers supports vector tiles out-of-the-box and leaflet with a plugin
True, OpenLayers and Leaflet have some support for vector tiles. However, you cannot rely on it because the performance is not there to render a normal map. Alternatively, you can use maplibre-gl-leaflet to integrate the two but it's experimental with some significant caveats.
You can use vector tiles with openlayers but they draw it on the canvas and not via web GL i.e. it is slower.
Leaflet - developed to work with PNG image map tiles
Mapbox GL/Maplibre - works with vector tiles which are similar in format to an SVG
I believe this plugin[1] is a hybrid approach which allows Leaflet to load vector tiles on a plain 2D map with no map tilt or rotation
[1] https://github.com/mapbox/mapbox-gl-leaflet
Mapbox GL/Maplibre - works with vector tiles which are similar in format to an SVG
I believe this plugin[1] is a hybrid approach which allows Leaflet to load vector tiles on a plain 2D map with no map tilt or rotation
[1] https://github.com/mapbox/mapbox-gl-leaflet
I noticed that Mapbox Studio has a way of creating & exporting styles (kinda like stylesheets but for maps). Do you know if those styles can be imported into a libre renderer like Maplibre, or if a similar tool/ecosystem exists for creating & sharing open-source map styles? Like if I wanted all roads to be rainbow-colored and rivers to be green.
In Mapbox Studio, the features all seem to be semantically tagged (e.g. this is a road of type X, a POI of type Y) and it makes styling a cinch. I know OSM has its own set of tags for features. Are these compatible (not sure if Mapbox Studio is using OSM data underneath)? Is there an established standard for this type of thing?
(ps TY again for answering my other question so thoroughly)
In Mapbox Studio, the features all seem to be semantically tagged (e.g. this is a road of type X, a POI of type Y) and it makes styling a cinch. I know OSM has its own set of tags for features. Are these compatible (not sure if Mapbox Studio is using OSM data underneath)? Is there an established standard for this type of thing?
(ps TY again for answering my other question so thoroughly)
https://maputnik.github.io is similar to Mapbox Studio, but isn't going to give you all you mentioned.
All vector tile sources use tags in various ways, so Maputnik (and the resulting styles) do as well. There isn't a standard tagging schema (and all MVT sources tend to differ slightly), but OSM's tagging is often influential on the resulting schema.
All vector tile sources use tags in various ways, so Maputnik (and the resulting styles) do as well. There isn't a standard tagging schema (and all MVT sources tend to differ slightly), but OSM's tagging is often influential on the resulting schema.
That's exactly what I was hoping for. Thank you again!
The exported styles are compatible (if you don't use newer features like terrain & fog) because Maplibre is nearly identical to GL JS v1.13, there were no rendering changes since the fork.
Im curious as to integration with DeckGL which seems to be the emerging standard for 3d maps and also for interactivity. Do you know if maplibre will work the same with it as mapboxgl does?
Yes. deck.gl has two ways of interfacing with Mapbox GL, either where deck.gl is a layer on top of Mapbox GL (with a separate WebGL context) or by sharing the same WebGL context. Sharing the same WebGL context allows e.g. Mapbox's 3D buildings to "pop" above deck.gl or to put Mapbox's labels above deck.gl layers. Those docs are here [0].
Either way, the recommended way of connecting deck.gl with Mapbox is through React Map GL. Those docs describe how to use Maplibre GL here [1] and here [2].
[0]: https://deck.gl/docs/get-started/using-with-map#using-deckgl...
[1]: https://visgl.github.io/react-map-gl/docs/get-started/mapbox...
[2]: https://visgl.github.io/react-map-gl/docs/get-started/get-st...
Either way, the recommended way of connecting deck.gl with Mapbox is through React Map GL. Those docs describe how to use Maplibre GL here [1] and here [2].
[0]: https://deck.gl/docs/get-started/using-with-map#using-deckgl...
[1]: https://visgl.github.io/react-map-gl/docs/get-started/mapbox...
[2]: https://visgl.github.io/react-map-gl/docs/get-started/get-st...
> Either way, the recommended way of connecting deck.gl with Mapbox is through React Map GL.
I should note this is only the recommended way when you're using React
I should note this is only the recommended way when you're using React
I'm not sure as to specifics (as I haven't tried this), but if DeckGL worked with 1.x Mapbox GL JS, it should just work with MapLibre, with a few potential minor adjustments (e.g., nomenclature). Can't promise it though.
I can verify this: I upgraded my Deck.gl project from MapBox to MapLibre recently, and it was a simple matter of renaming some imports.
This works absolutely seamlessly.
I'm using Vue instead of the React integration and that's also working without any issues.
This works absolutely seamlessly.
I'm using Vue instead of the React integration and that's also working without any issues.
What would it take to display a map in a style as close as possible to the one used on openstreetmap.org ?
A few things:
- A data source for vector tiles; there's a lot of options: https://stadiamaps.com (my company), https://maptiler.com/ & https://jawg.io (other core contributing companies), among others.
- A style that matches. I'm not aware of an open source style that closely mirrors OSM's style using MapLibre GL Styles (also forked from Mapbox). OSM Bright is pretty close: https://github.com/mapbox/osm-bright / https://github.com/openmaptiles/osm-bright-gl-style.
- A data source for vector tiles; there's a lot of options: https://stadiamaps.com (my company), https://maptiler.com/ & https://jawg.io (other core contributing companies), among others.
- A style that matches. I'm not aware of an open source style that closely mirrors OSM's style using MapLibre GL Styles (also forked from Mapbox). OSM Bright is pretty close: https://github.com/mapbox/osm-bright / https://github.com/openmaptiles/osm-bright-gl-style.
The OSM style is here: https://github.com/gravitystorm/openstreetmap-carto
There is an issue about converting it to vector: https://github.com/gravitystorm/openstreetmap-carto/issues/3...
Doesn't seem like there's any current vector versions of that style, but you could make one yourself using Maputnik or similar; you'd probably want to start with OpenMapTiles and maybe even one of the pre-existing styles for OMT like OSM bright.
There is an issue about converting it to vector: https://github.com/gravitystorm/openstreetmap-carto/issues/3...
Doesn't seem like there's any current vector versions of that style, but you could make one yourself using Maputnik or similar; you'd probably want to start with OpenMapTiles and maybe even one of the pre-existing styles for OMT like OSM bright.
It would take someone designing the same style in the vector format. This [0] is the closest I've seen to a vector port of the default OSM style. Demo [1]
[0]: https://github.com/baremaps/openstreetmap-vecto
[1]: https://www.baremaps.com/assets/demo.html
[0]: https://github.com/baremaps/openstreetmap-vecto
[1]: https://www.baremaps.com/assets/demo.html
In the Github issue linked by z77dj3kl I found a link to this vector port by ESRI : http://esri.maps.arcgis.com/apps/View/index.html?appid=d6b18...
Closed source but very impressive
Maybe not the best place for this, but hey it's a question.
When adding clusters vs points to a map, filtering points is really simple, but I haven't found a simple way to filter clusters outside of filtering a data source and reapplying it to the clusters.
If there a better way of doing this?
When adding clusters vs points to a map, filtering points is really simple, but I haven't found a simple way to filter clusters outside of filtering a data source and reapplying it to the clusters.
If there a better way of doing this?
It's not perfect, but you can put counts of points in each cluster (maybe you have count = 5, A_count = 2, B_count = 3 which means that this particular cluster has 5 points total, 2 of which are A and 3 of which there are B). Then you can filter based on these attributes.
The obvious downside of this is that the cluster positions aren't accurate because they're based on points that are supposed to be hidden, but it's fast and doesn't require recalculating.
The obvious downside of this is that the cluster positions aren't accurate because they're based on points that are supposed to be hidden, but it's fast and doesn't require recalculating.
Does it support rendering of rasters? What about support on Desktop platforms?
MapLibre GL Native supports server-side raster rendering via tileserver-gl or a custom server implementation (my company does this).
Desktop support should be possible with some extra work with Native, but I'm not certain, for instance, if the QT bindings are fully working yet.
Desktop support should be possible with some extra work with Native, but I'm not certain, for instance, if the QT bindings are fully working yet.
My understanding is that mapbox-gl-native dropped node binding support prior to the fork; the code is still there but the build system can’t build it. I’m hoping to help maplibre bring it back up to a working state.
Yes, you can render raster layers (tile sources).
https://docs.mapbox.com/mapbox-gl-js/example/map-tiles/
https://docs.mapbox.com/mapbox-gl-js/example/map-tiles/
And here's the forked version of that example: https://maplibre.org/maplibre-gl-js-docs/example/map-tiles/
The site mentions "additional functionality" vs. Mapbox Native. Is that additional functionality listed somewhere? (Apologies if it is and I missed it)
Metal support (coming soon) and MBTiles support (released AFAIK) are two things I know of, but I defer to the Releases page for specifics beyond that: https://github.com/maplibre/maplibre-gl-native/releases.
Thanks!
What is the additional functionality? I couldn't find any document comparing MapLibre GL to MapBox GL JS 1.x.
We are using MapTiler along with MapBox GL JS. It seems that MapLibre GL JS is our next logical upgrade step. For one it's great that you have a Leaflet plugin under your github org.
We are using MapTiler along with MapBox GL JS. It seems that MapLibre GL JS is our next logical upgrade step. For one it's great that you have a Leaflet plugin under your github org.
This is going to be a good test of my rule that any project with "libre" in the name -- except, as my astute colleague pointed out, libreadline -- is doomed to failure.
Libreoffice is the main project now when they left openoffice.
Libreoffice + syncthing was my recent attempt at replacing Google Drive/Docs.
The latest mac version of Libreoffice is nearly unusably laggy even on brand new fast hardware with lots of ram, and it looks like garbage to boot.
The latest mac version of Libreoffice is nearly unusably laggy even on brand new fast hardware with lots of ram, and it looks like garbage to boot.
Using LibreOffice is like being constantly insulted and abused by its authors. I think it is the outstanding example of "libre == junk".
Umm. What?
Insulted? Abused? What are you talking about?
Insulted? Abused? What are you talking about?
Calibre seems to be doing fine.
I don’t see any support for alternate projections. For my raster-based dataset (satellite data) of polar regions I don’t see any benefit over my current openlayers approach. Looks great for vector-based 4326/3857 projected data, though! Please let me know if I’ve overlooked projection support?
This is definitely something I'd love to see. We have a lot of data in EPSG:27700 and having to reproject everything to 3857 to display to users is A) wrong and B) seriously messy and intensive for the backend servers, especially with raster tiles...
Forgive me if obvious—where are you pulling the underlying data from? Is the data itself OS licensed?
Where the SDK pulls its data from is not hardcoded.
The SDK is just a library, used to render vector map tiles, usually in the MVT-format: https://docs.mapbox.com/vector-tiles/specification/
Most maps rendered with such an SDK are based on OpenStreetMap data.
The SDK is just a library, used to render vector map tiles, usually in the MVT-format: https://docs.mapbox.com/vector-tiles/specification/
Most maps rendered with such an SDK are based on OpenStreetMap data.
As others stated, this demo dataset is pretty simple. I believe it's only using Natural Earth data (https://www.naturalearthdata.com/). The primary focus is on the rendering library.
OpenStreetMap in the form of OpenMapTiles: https://openmaptiles.org/
Doesn't need to be OMT though. That's just the de facto free & open source tile generator from OSM data.
OpenStreetMaps probably.
Mapbox uses data from OSM among others when they create their tiles. https://docs.mapbox.com/help/getting-started/mapbox-data/#co...
Mapbox uses data from OSM among others when they create their tiles. https://docs.mapbox.com/help/getting-started/mapbox-data/#co...
OpenStreetMap* (no s at the end).
Sorry :p It’s ironic because I had a friend once—well we shared kitchen and bathroom in the student housing, flatmates of sorts—that used to refer to Google Maps as “Google Map” and I never corrected her because I just found that adorable for whatever reason. Lol.
Good thing it's all digital. Unfolding one big Google Map would take a looooooong time...
Open-source mapping libraries for developers using JavaScript, Android, iOS and more...
[deleted]
Same acceleration bug with Firefox under Linux that makes me hates Mapbox GL with passion ... Makes quite a lot of website unbearably unusable ...
Would you please provide a way for the user to deactivate that terrible idea ? Thanks.
Would you please provide a way for the user to deactivate that terrible idea ? Thanks.
Can you please report this on our issue queue? From a cursory search, it doesn't look like anyone complained about scroll zoom on Firefox under Linux before. We'd be happy to fix this after hearing more details. https://github.com/mapbox/mapbox-gl-js/issues
I have nothing concrete to report, I slide 2cm, it works, settle down, slide 2 more and it goes nuts or not. Impredictable UX. But it's cool and flashy.
I just avoid sites using mapbox-gl as much as I can...
Or, you could help us fix the issue so that all Mapbox maps work great for you? Could you record a screencap of this issue and submit a GitHub ticket? We honestly have never seen anything like this ever reported.
care to elobrate a bit?
The smoothness on the demo (at least on my machine) is very nice. Good work :)
If it is true that Apple will soon drop OpenGL and only support Metal:
Will the SDK also work on iOS and Mac then, i.e. has Metal support?
Will the SDK also work on iOS and Mac then, i.e. has Metal support?
There is active development on a Metal-supporting version, yes!
https://github.com/maplibre/maplibre-gl-native/tree/metal-su... is the branch and https://github.com/maplibre/maplibre-gl-native/issues?q=is%3... are associated issues.
https://github.com/maplibre/maplibre-gl-native/tree/metal-su... is the branch and https://github.com/maplibre/maplibre-gl-native/issues?q=is%3... are associated issues.
Yes, we have a beta build of the SDK with Metal support (https://github.com/maplibre/maplibre-gl-native/tree/metal-su..., https://github.com/maplibre/maplibre-gl-native/releases/tag/...). There are some minor issues we are addressing in the new release. Contributors and brave souls willing to try out the build are more than welcome :).
This needs really solid Metal support or it won't be adopted on mobile.
(Copied from another thread)
There is active development on a Metal-supporting version.
https://github.com/maplibre/maplibre-gl-native/tree/metal-su... is the branch and https://github.com/maplibre/maplibre-gl-native/issues?q=is%3... are associated issues.
There is active development on a Metal-supporting version.
https://github.com/maplibre/maplibre-gl-native/tree/metal-su... is the branch and https://github.com/maplibre/maplibre-gl-native/issues?q=is%3... are associated issues.
Last I checked there's no WebMetal.
Does there need to be?
https://github.com/maplibre/maplibre-gl-native
https://github.com/maplibre/maplibre-gl-native
[deleted]