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).
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)
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.
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.
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.
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 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.
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.
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.
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)
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.
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].
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.
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]
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.
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.
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.
The site mentions "additional functionality" vs. Mapbox Native. Is that additional functionality listed somewhere? (Apologies if it is and I missed it)
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.
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.
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...
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.
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.
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.
