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.
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.
I at least would find it interesting to see the two compared by someone other than me ;).
https://github.com/protomaps/protomaps.js
TBH, the blocker is not demand for vector rendering but the technical difficulty and performance constraints of doing rasterization in the browser.
Do you think it's still too early to switch to vector map data for all clients then? Maybe render raster tiles on demand on the server to those clients that can't handle it?
There are a couple great public raster services like osm.org's default style and http://maps.stamen.com. These are 100% free to use, so they get used everywhere, but incur significant expense to the organizations running (paying) for them.
There aren't equivalent solutions in vector-land yet... I wrote a bit about this previously: https://protomaps.com/blog/free-tier-maps
Their stack is open sorce, described there: https://github.com/Qwant/qwantmaps#tile-server
[1]: https://github.com/SpatialServer/Leaflet.MapboxVectorTile
So lets optimize the browsers SVG rendering?
Things that are mandatory for map display, like:
- Label priority and positioning
- Display of internationalized, RTL, and Bidi text
- Geometry rasterization and styling
Are outside the scope of Leaflet's core design and can be implemented by plugins, one of which I have linked in a sibling comment.
I maintain a heavily used map of the US, and I found that storing data/serving in vector format seems to be the most efficient (on AWS s3 / DO spaces), and converting to raster in the browser or with a service call / lambda really opens the doors to a lot more use cases. I suspect parent can talk more about this than I can.
So raster tiles load much faster and OpenStreetMap retina tiles help against pixelation.
And you can - though not advisable for large areas - render raster tiles at much higher zoom levels, e.g. SomeOneElse renders his raster style up to level 28 for the UK.
I still think that the more proper solution would be to instead cap out the vector tiles on the other end, not going lower than say level 5.
I also don't intend to argue against a vector tile stack - both vector and raster have their use cases and pro's and con's. Vector tiles bring much more flexibility but less support in some use cases, raster normally loads/displays much faster (if served pre-rendered) and has universal support on the client side.
Unfortunately I'm not really aware of any FOSS dataset for that yet, but that may change in the coming decades if the price of mass to orbit goes down.
https://osmand.net/docs/user/map/vector-maps/
https://osmand.net/docs/technical/osmand-file-formats/osmand...
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
Is it, because sth. like a full street network layer would degrade performance too quickly?
[0]: https://github.com/onthegomap/planetiler [1]: https://github.com/maptiler/tileserver-gl
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.
If you need to support old underpowered devices you can serve raster tiles to them. I don't know how to automatically detect which type to send to a device, one way would be to just time how long it takes to render a frame of vector data and switch to raster maps if the device is too slow, or at least present the user with the option.
[0] https://www.mapbox.com/maps/streets (Press "Preview Style")
Google Maps (in Firefox) seem to be slow when loading data in, but decent when panning around. Though it does appear that they're using raster based tiles (I can quite literally see pixels when I zoom in, before the new tile loads and replaces the one for the previous zoom level).
Google Maps (Android app) seem to be really smooth when panning around, but also similarly slow when loading data in. Zooming is a bit sluggish, but not as bad as vector tiles when viewed through the browser.
I also remember using the HERE maps application a long time ago on an even slower device, somehow those performed way better than Google Maps application though.
My suspicions: a browser might have greater overhead, maybe not everything plays nicely with Firefox or my hardware. The slow data loading seems to be caused by the CPU/GPU instead of the network connection, because if new tiles are loaded in while I'm panning around, the movement also lags.
> If you need to support old underpowered devices you can serve raster tiles to them. I don't know how to automatically detect which type to send to a device, one way would be to just time how long it takes to render a frame of vector data and switch to raster maps if the device is too slow, or at least present the user with the option.
This is a good idea, provided that the people serving the maps would be interested in supporting both formats.
My daily driver is a Samsung Galaxy S4 (2014) with LineageOS and Firefox (Fennec F-Droid, no google services).
Your link works pretty well, it took a few seconds to load the map, but zooming and panning is quite smooth, it seems.
Edit: panning is much less smooth on openstreetmap. It's faster to bring in new features when zooming, but you have to endure blurry text and less details for half a second or so. Also, you can't rotate the view. IIRC google maps renders text locally to solve that.
This is exactly why I recorded a video and put one in that blog post - because sometimes people that are running even the same software will have vastly different experiences. At the end of the day "But it works/doesn't work on my machine." is just the reality that we need to deal with - which will vary for someone with a weaker or more powerful device, certain browser, certain drivers and so on.
> Panning is much less smooth on openstreetmap.
I'd say that from the best to worst for me it'd go a bit like this: Google Maps (application) > OpenStreetMap (web) > Google Maps (web) > MapLibre GL JS (web)
> It's faster to bring in new features when zooming, but you have to endure blurry text and less details for half a second or so.
Same here!
> Also, you can't rotate the view.
I can't rotate the view in Google Maps (web) either, only in the native app.
For me, the web maps also seem to use raster tiles, whereas the application seems to use vector data, added more info in another comment: https://news.ycombinator.com/item?id=33712150
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
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.
When writing this I found out that MapTiler[1] is maintaining MapLibre GL JS[2], a fork of a Mapbox project to do just that. It would be interesting to see the difference between self hosting raster and vector maps and compare pros and cons. You can even render raster tiles from vector tiles on the server if the client needs it[3].
[0] https://openmaptiles.org/docs/style/mapbox-gl-style-spec/
[1] https://www.maptiler.com/open-source/
[2] https://github.com/MapLibre/maplibre-gl-js
[3] https://openmaptiles.org/docs/host/tileserver-gl/