How come these map projects still use raster tiles? Are there no open source map projects that render the OSM data to vector data, and renders that vector data on the clients GPU? Maybe raster tiles are better at something I'm missing, but vector maps are easier to style[0], localize, they're sharper, easier to rotate and zoom smoothly. Maybe it's harder than I think to render it on all sorts of clients including mobile?
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].
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]
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.
Seems like MapTiler is maintaining an open source full stack vector alternative, and OpenLayers[0] looks good as well, so maybe it's time for legacy libraries to add vector support, or for users to switch libraries? There's even bindings from Maplibre GL to Leaflet [1].
I at least would find it interesting to see the two compared by someone other than me ;).
I'm surprised I don't see more implementations caching and serving vector tiles. I know some (most?) large mapping companies do this.
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.
vector tiles are years-old now.. there are a dozen decent implementations.. why would Leaflet not support vector tiles ? is there some commercial agreement behind closed doors regarding crippled Leaflet now?
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).
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.
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.
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.
> 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.
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.
That's strange, it works flawlessly on my 2018 phone, although that has a Snapdragon 845 which was considered the fastest SoC available for Android phones at the time. How is the Google Maps, OsmAnd, or Mapbox experience on your phone? They also use vector map data.
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.
Firefox seems to have very inconsistent behaviour on Mapbox/Maplibre sites. I deal with a lot of bug reports with no pattern to them except Firefox is slow but on the same device, Chrome is perfect...
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.
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.
But with vector tiles you (normally) start overzooming at level 15, resulting in either much less detail or really large file sizes for a zoom 14 vector tile that would have to carry all the data to be used in overzooming.
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.
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
OsmAnd uses offline vector tiles as standard, they support multiple different styles including custom ones. It performs fine on my phone, and it shows off many of the benefits with vector data. It's easy to choose which kind of point of interest you want displayed, hike and bike routes can be colored in, I think it uses much less storage space on the phone. You can add raster maps to OsmAnd if you want to though.
Vector map of the whole Earth in PMTiles format is only ~65GB[1] and doesn't need any server or database - it's just a static file which you can host wherever you want.
bdon (author of PMTiles) already commented on this thread. I recommend taking a look at https://protomaps.com/docs - compared to this, raster tile servers sound like ancient technology.
Google maps with its massive places data set is just too good. It’s expensive but I find it is always consistently up to date and mostly reliable. Have found some bugs with the places api which I reported, such as it not working for some queries which are off by 0.001 lat/lng
Of course Google is going to be more up to date and complete for POIs when these POIs need customers to survive and customers use Google search to find info. Google uses its monopoly in the search market to also become dominant in the geo data market. There's no competing with a hundred million shop owners contributing and updating their own data.
Hiking trails and other more niche things, though. Compare the data quality there :)
I work in e-commerce, and some of my clients have physical stores. Those clients want their site to have a store locator and a map to show the closest physical stores to customers. Over the years, I've looked into doing it with a self-hosted OSM solution, but never got too far, as it wasn't clear on what had to be done or run. Everyone seems to be OK with using a Google Maps product in the end (live or static map).
I'll favorite this submission so I'll have something to reference if anyone balks at Google Maps ripping them off, and has a spare server around.
> Everyone seems to be OK with using a Google Maps product in the end (live or static map).
Everyone is also okay with driving combustion vehicles for the time being, even while realizing that it might not be the cleanest option. Supporting Google similarly feels dirty when necessary, but yes it's the norm.
For some things like traffic info, there also just isn't much of an alternative that works in most of the world with one simple thing to implement. There are things where OSM or TomTom or so just can't compete because it requires tracking half a billion people's locations in real time. Or showing up with your opening hours on Google's search monopoly by existing as a POI on TomTom or OSM will also just never happen, whereas existing as a POI on Google Maps is enough (using dominance in one market to influence another market). I know "everyone" is fine with using these products, but that's not why nerds get enthusiastic about seeing OSM in different places :)
> Even on this smaller extract, these services already use a large portion of my 1TB SSD (667 GB total). Assuming the usage scales proportionally, I would need around 3.7TB of storage for the entire planet. Not to mention the RAM requirements also scaling.
Serving large data sets at acceptable latency typically requires some proportional amount of RAM to keep frequently accessed files and indexes in memory (especially if you're serving off of HDDs).
It depends on the service, but we frequently find geo services are RAM limited up to a certain point (at which point there's enough cached to make it CPU limited).
Valhalla in particular in an in-memory router, so it's holding the whole transportation graph in memory. Not sure about the tiling and geocoding pieces. Most organizations with a "need to serve the world" requirement presumably don't balk at buying all-the-RAMs. Amazingly, the max-RAM-in-machine number has grown faster than the data-in-the-world number, and just being memory bound is a perfectly reasonable design decision, given the performance and complexity wins.
Osrm is in memory as well. We were serveing most of Europe and Asia from a box with 128 Gb RAM. It can use a mmaped file but it's too slow, even on a NVME drive. If you route anything more than 300 kms it will take a few seconds and then timeout.
Unfortunately, I am not aware of any open source project that covers the one feature that I still use Google Maps for. Reviews. Does anyone know of any?
I am wondering now if that's something that could be federated well.
https://mangrove.reviews/ exists but has almost no users.
As far as I know, there's currently only the main instance, but the software is open source and they provide regular database dumps.
Sometimes even scalability may be vastly inferior. I've implemented geocoding/geodecoding on OSM data, which for our use was 10-50x faster and our usage would chew through first tier plan in about an hour. Instead, our single server is about as expensive as that first tier.
hey........ i have a wildly awesome idea about improving OSM. can anyone build this and help the community? i would help by giving my time....
here is the idea.
a ride sharing app uses OSM for routing and such. fine. The driver follows the map but some times there are new turns or changes to road that are not in the map, or there are some improvements.
my idea. the ride sharing app has the historical "ACTUAL" rides that have already taken place.
we build a tool that takes point A&B from the route given and plots its own normal route. the actual trip and "Expected" trip are overlaid and if there are deviations, the software (after some adjustments for errors) this can give us a high level idea of the general map to actual route. this can also tell mappers which routes to fix and stuff...
there is one tool that does manually but i would be like for large number of routes that would be matched 1:1.
Grab (https://www.grab.com/my/), Amazon Logistics, Apple (afaik) and some other mobile apps already do this. Full-time staff are correcting OpenStreetMap with one-way restrictions, speed limits, road width. Strava allows OpenStreetMap mappers to see where people walked/cycled to identify missing paths. Facebook is tracing new roads based on machine-learning satellite imagery (https://wiki.openstreetmap.org/wiki/RapiD).
Readit News
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/
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?
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 ;).
[0] https://openlayers.org/
[1] https://github.com/maplibre/maplibre-gl-leaflet
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.
https://maplibre.org
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.
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.
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")
[0]: https://github.com/onthegomap/planetiler [1]: https://github.com/maptiler/tileserver-gl
[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
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.
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.
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
Deleted Comment
https://osmand.net/docs/user/map/vector-maps/
https://osmand.net/docs/technical/osmand-file-formats/osmand...
https://osmand.net/docs/user/map/raster-maps/
https://anygis.ru/Web/Html/Osmand_en
bdon (author of PMTiles) already commented on this thread. I recommend taking a look at https://protomaps.com/docs - compared to this, raster tile servers sound like ancient technology.
[1]: https://app.protomaps.com/store/planet-z14
Hiking trails and other more niche things, though. Compare the data quality there :)
I'll favorite this submission so I'll have something to reference if anyone balks at Google Maps ripping them off, and has a spare server around.
Everyone is also okay with driving combustion vehicles for the time being, even while realizing that it might not be the cleanest option. Supporting Google similarly feels dirty when necessary, but yes it's the norm.
For some things like traffic info, there also just isn't much of an alternative that works in most of the world with one simple thing to implement. There are things where OSM or TomTom or so just can't compete because it requires tracking half a billion people's locations in real time. Or showing up with your opening hours on Google's search monopoly by existing as a POI on TomTom or OSM will also just never happen, whereas existing as a POI on Google Maps is enough (using dominance in one market to influence another market). I know "everyone" is fine with using these products, but that's not why nerds get enthusiastic about seeing OSM in different places :)
Why? 20TB consumer storage is a thing. https://www.amazon.com/Western-Digital-20TB-Internal-Drive/d... ($420, heh)
What in the implementation makes the RAM usage explode?
It depends on the service, but we frequently find geo services are RAM limited up to a certain point (at which point there's enough cached to make it CPU limited).
I am wondering now if that's something that could be federated well.
note that this proprietary map data may be completely beating OSM or being vastly inferior, depending on your use case
here is the idea.
a ride sharing app uses OSM for routing and such. fine. The driver follows the map but some times there are new turns or changes to road that are not in the map, or there are some improvements.
my idea. the ride sharing app has the historical "ACTUAL" rides that have already taken place.
we build a tool that takes point A&B from the route given and plots its own normal route. the actual trip and "Expected" trip are overlaid and if there are deviations, the software (after some adjustments for errors) this can give us a high level idea of the general map to actual route. this can also tell mappers which routes to fix and stuff...
there is one tool that does manually but i would be like for large number of routes that would be matched 1:1.
https://wiki.openstreetmap.org/wiki/Organised_Editing/Activi...