Just to set the record straight: MapTiler is *not* the maintainer of MapLibre. MapTiler is *one of* many participating companies in the MapLibre organization, which has a board and a charter [1].

Amazon has donated $300,000 to MapLibre, Facebook - $80,000, TomTom - $10,000, and lots more companies have donated. Most of the code maintenance is done by various volunteers and companies, e.g. Amazon has hired a whole team of engineers to work on MapLibre native, etc.

P.S. I came up with the name MapLibre, called people to unite around this effort, and am on the board of the MapLibre organization. [2]

[1]: https://maplibre.org/charter/ [2]: https://twitter.com/nyuriks/status/1336493514646052864

You’re absolutely right and here’s an open source self-hosted project for MBTiles: https://github.com/akhenakh/kvtiles

More info from the author here: https://blog.nobugware.com/post/2019/self_hosted_world_maps/

The vector tiles are much smaller in filesize than pixel data and the rendering technology is much better. Almost all the styling is done on the client side so the server is basically just querying a spatial database.

A few reasons:

1) Some of the most popular map library frontends like Leaflet support only raster tile layers out of the box.

2) Quality vector generalization (feature-dropping) is much more difficult than raster generalization.

3) A large fraction of use cases just need a "good enough" basemap without those extra features.

Small note of clarification about MapLibre. It's a vendor-neutral, community-led project supported by a lot of different industry participants (including AWS & Meta).

https://maplibre.org

> MapLibre GL JS[2]

Here's a nice example of the maps in action (though the other links also have showcases): https://openmaptiles.org/docs/website/maplibre-gl-js/

The transitions seem really smooth and the user experience is pleasant... until I open them on an Android device that came out just 2 years ago (one of those rugged models), in Firefox.

I'm sure that the slowness has something to do with rendering vector data, because all of the sudden those maps become unusable - slow zooming, slow loading (possibly the data is fetched reasonably quickly, just slow to display), slow scrolling. In a word, laggy. When looking at an area of my choice, using the vector maps (even after letting them load fully) I get probably less than 10 frames per second so panning feels choppy.

On the other hand, the raster maps are basically what you'd get when panning across an image - the latter experience remains reasonably smooth. There, the only disadvantage is the typical swapping out of raster tiles as you zoom in or out, but that's a small nuisance at best, apart from the visual difference in quality.

Have a look at OpenStreetMap, which the first link uses for its data: https://www.openstreetmap.org

As it currently stands, if we all used only vector data, I feel like a lot of people on lower spec devices would be left out. I wonder whether any serious tests have been made on the battery usage or performance of both types, but even tests this simple show that there are certain problems with the current implementations of vector maps.

I actually did a blog post about this just now, with a video example of the two types of maps running side by side: https://blog.kronis.dev/everything%20is%20broken/vector-maps...

Note: this isn't meant to be a super accurate comparison, but rather a quick look into some of the immediately apparent practical differences in what the user experience is like.

I would also like to throw in planetiler[0] and tileserver-gl[1] which I am happily running to serve vector tiles for some regions in Germany.

[0]: https://github.com/onthegomap/planetiler [1]: https://github.com/maptiler/tileserver-gl

In addition to the links others have given I'd note that serving dynamically generated Mapbox Vector Tiles (MVT) can be done very easily from a very standard postgis server these days [0]. For me this is the no brainer way to go. Your main problem is likely to be converting from OSM's labyrinthine data structure to something easier to serve.

[0] For the explanation and minmal version see https://www.youtube.com/watch?v=t8eVmNwqh7M source code here https://github.com/pramsey/minimal-mvt. For a full fledged package see https://github.com/maplibre/martin or https://github.com/CrunchyData/pg_tileserv

The zoom is especially bad with raster OSM right now since they only support zoom up to level 19, which results in a lot of pixelation if you want to go closer than seeing an entire street.

My experience with it is that vector tiles can become very CPU-heavy on the client, specially when moving into 3D space like with MapLibre's terrain layers.

It's less computationally expensive to just fetch a pre-rendered tile and drape it onto the map, which keeps rotating, panning an tilting very performant.

It doesn't look that nice, so there's the tradeoff. It can also be easier to just cache tiles on the end device and resort to them instead of constantly reassemble the vector layers.

Raster tiles are smaller in terms of amount data sent over the wire and work better for users with less powerful computers/ mobile

Really if you aren't interacting with the data on the client I would stick with good old rasters - it's harder to get set up with them but they perform way better