I'm a bit conflicted with vector tiles. I haven't found a good combination of style and tile generator (schema) that provides the same level of detail as the original raster tiles provide.
The article has screenshots that very much demonstrate this difference. The first screenshot has, for example, a lot of POIs (statues, shops, theaters, viewpoints), highways that are different when they are bridges, different colors for grass vs parks, different line widths for different highways, sports fields, building and neighbourhood names, arrows denoting one-way streets, building parts, stairs, trees, and a lot more.
The second screenshot has none of that, aside from a single trolly station and a single street name (which is also rendered incorrectly).
I've tried a lot of vector styles (all openmaptiles styles, the base protomaps styles, all mapbox styles) and generators (protomaps, openmaptiles, mapbox). None of them come close to the amount of detail as the raster OSM tiles while still being as readable.
I've never found anyone as bothered with this as I am. Vector styles are cool as they zoom and pan very smoothly, and their style is fairly easily editable. But, for any map where you actually want to see map data instead of using it as a base map for your own data, vector maps fall short.
Maybe it is just because of computational limits. I can imagine that displaying the same amount of detail as the OSM raster tiles would require too many resources: both on the client side and for tile generation.
It would be nice if OpenStreetMap would try to mimic their raster style closer, instead of providing just another low contrast, low detail base map. I hope this release of open vector tiles will facilitate more detailed vector maps!
You are basically right. But your framing might be slightly off. The primary advantage in vector tiles for whoever is providing the map is not the small benefits of greater sharpness or flexibility in styling. It's the vast decrease in compute required. Maintaining the infrastructure to generate up to date raster tiles is a pretty serious undertaking.
I've tried a few times over the years to replicate it using vector tiles. It's pretty challenging to load enough detail into the tiles without hitting the size limits, and the default Mapbox tiles don't containing anything like enough information.
There are workarounds with vector tiles that raster tiles don't have though, like the ability to turn on/off different layers, while still retaining legibility (because labels can still be aware of what is underneath them).
Some of what is going on is that the software to generate continuously updated vector tiles has been the focus, rather than fleshing out a style that uses those tiles.
That's great and wasn't clear at all from the article. The engineering challenge behind that is very much worth a post on its own. Must've been no small feat!
The style was built to match the look of the original raster tiles closely, although I added many more interactivity features in the vector variant.
Is is interesting from a style/tile design perspective that the performance tradeoffs choices become very different how and where the tiles are rendered. This is obvious, but it has effects on what is possible on the server / clients visually as well.
I agree with you wholeheartedly. I use a mix of OpenSteetMap and Google Maps to get around. I would love to use exclusively OSM, but it simply doesn't have as many places catalogued.
I can't describe how much more usable OSM maps are because of how many POIs they show. You get a very real sense of the physical place just by looking at the map. A park looks distinctly like a park. A hospital looks distinctly like a hospital.
Google Maps looks a lot better from the perspective of a graphic designer, sure. But I usually have to resort to cross-referencing the shape of streets/intersection to get my bearings. With GM everywhere looks like everywhere else.
I completely mirror your thoughts. I have spent a fair while trying to bend vector maps into being as good as openstreetmap.org's default style (which in my opinion is just Pure Bliss) and have not managed to find anything workable enough, where you can't notice the loss of detail within 2 minutes of playing with it.
Which is a real pity. I'm optimistic that someone will solve it eventually.
I agree with you, but I go one step further: I am disappointed by OSM raster tiles and especially Google's digital tiles because even they show barely enough information, if you compare them to old style printed street directories. I think they also have a tendency to avoid crowding by omitting important things in busy spaces and showing useless things in empty spaces, whereas the correct thing to do is to show the important things in the busy spaces precisely to indicate that they're busy spaces. And I think there are better things that can be done than just showing trivia if you consider the local area (e.g. a private tennis court might be better off not shown in especially if there's not a great density of mapped objects, but perhaps it's relevant at a resort).
But that's a lot of work, and whereas it's easy to add extra trivia to OSM it's much harder to add extra detail to tiles.
As Doctor_Fegg has pointed out further down, the OSMF provided raster tile service on openstreetmap.org is primarily intended to provide fast feedback to contributors and not for general purpose use, in particular not as a competitor to google.
The whole point of OSM is that you can take the data and build / design your own things. Yes it would be nice if there were multiple viable google alternatives based on OSM and other open data, but that is likely just a pipe dream, the economics don't really work.
I've been successful with using https://maputnik.github.io/editor in the past for disabling lots of features, so I imagine it could do the opposite and enable all the layers and features you want to see on a vector map.
I've tried that, but the openmaptiles spec and protomaps spec just don't provide enough details to be able to display a detailed map like the OSM raster tiles.
That's not to say that maputnik isn't great; it is! It's an awesome frontend to the complex style files.
It's been fascinating to watch the open source community build out vector map tile capabilities. I was doing some web GIS work back in roughly 2018, and Google/Apple's streaming vector maps performed like magic and something we would have loved to use if we could afford it. Shortly thereafter the core tech was available in open source, and then there were even free hosted solutions. Now our leaflet maps have great vector layers for free. Thanks open source!
I'm a little surprised it's taken this long for OSM to get there, the basic technical pieces were available over a decade ago. I don't mean to complain about the free map service, it's excellent, and I recognize they focus more on the editing and data ownership. Serving is hard and expensive.
Mostly I wonder how much MapBox's dominance for a few years disrupted other efforts.
Does this reduce the operating costs of hosting OSM-based maps, since presumably they require less CPU spent on rendering and vectors consume less storage/bandwidth?
No because the official OSM tile layer is heavily subsidized by Fastly (€720k last I checked) and rendering by AWS (€40k)
Yes because technically it would use fewer resources thus easier on AWS+Fastly and also easier to self-host
In last risk assessment I read closely(1) OSM noted "If we lost [Fastly] sponsorship, we would likely cut off all third-party access to the standard tile layer and run a small number of Varnish servers."
As I understand it, primary drivers for vectors was not cost more improving internationalization, generally enabling client-side rendering decisions, and driving a modern toolchain that would net multiple follow-on benefits
I'm a bit behind, there is more recent info available at (2)
I wonder if it would be feasible to distribute tile data in a DHT. There is a single source of truth that could seed the DHT and users would share the load of serving the data. It'd have to be opt-in on individual nav devices for privacy and battery reasons, but anyone running their own OSM proxy would have an incentive participate.
Yet you forget that tiles based maps are plays very nicely even with simplest HTTP caching (even multiple layers of them). Compared to vector stuff that needs caches that are range requests aware, or some magic block storage.
I somehow prefer to stick to tile based maps because caching, easy rendering and I also care about sat images, with cannot be vectorized.
No, because you've been able to self host (or have somebody host them for you) vector tiles for a long time with very little effort, and yes that will somewhat offload processing to clients, and, more importantly allow many styling decisions to be made by the client (but not all).
The actual -new- thing is that the work Paul has done for the OSMF allows on the fly (aka in minutes) updates of the vector tiles. This is important for OSM contributors as a feedback mechanism and the main reason the OSMF operates the current raster tile service.
What is currently a bit out in the open is which usage restrictions will apply to to using the vector tile service as, just as with the raster tile service, the intent is not to compete with or replace third party services and a vector tile service could potentially do that.
this is the first I've seen of these alternative tools compared to using Tippecanoe(https://github.com/felt/tippecanoe). Are they considered to be higher performance?
openfreemap.org creator here. Yes, with vector tiles you are basically hosting static files, the server has nothing to do, except HTTPS encryption. Even gzipping is already done in the tiles.
For vector tiles osm.org this is not the case. They should be generated on the fly from the database to show mappers the current state of the map with minimal delay. Yes, the resulting results can be cached like static files, but much more work is done on the server.
The other issue is that the arabic font is not rendering correctly in the vector version. It's rendering left to right (instead of right to left) with characters broken up instead of linked.
The whole point of vector tiles is that the rendering is local and controlled by a style configuration (except for the tile schema) that can be changed. So the brokenness you are seeing is either in the style or the library that is rendering the contents locally.
> Imagery should appear much sharper and switching the language of the labels should become possible.
I expect that to work sub-optimally. Label dimensions are far from guaranteed to stay the same if you change language, and label dimensions interact with map layout, even influencing what to show.
If your labels grow larger, they may end up covering too much of the map or even overlapping. If they grow smaller, users may wonder why a city that was omitted before because of space constraints doesn’t show in the empty space created.
I hate it when city and street names disappear on Google Maps as you zoom in and out. Sometimes a street or business name only appears at one particular zoom level and not higher or lower. Just show the name of every street damnit. I don't care about crowding. Standing at an intersection staring at an unlabelled map is a useless map.
I also hate it! I dont know why they do it, sometimes i zoom in all the way and there is still no street name. Its just silly, who is making these design decisions?
The problem is, i keep using maps because google has the best POI system/database around, and it will take other apps long yo beat it, even apples POIs cant hold up…
Yes. Google Maps is getting to be just as useless as their search engine. These are just some of the ways in which it fails me nowadays:
* Open the app. Instead of getting a map you get, "What's happening nearby" or somesuch. And how to close this changes with every release. I have NEVER in life life EVEN ONCE opened a mapping program because I was simply bored and wanted some other place to go.
* Search for "$name_of_place_or_business in $specific_city". Instead, it gives you all the locations with a similar name near your current location until you massage the query in some way. (It doesn't do this all the time but more than enough to be annoying.)
* Search for the name of a road or intersection in a city. It will instead give you a list of businesses with similar names, or in some cases, having nothing to do with the name you searched for.
* Search for the name of a particular business. Get results for their competitors instead. (Feels illegal.)
* The traffic overlay changed months back so that only interstate traffic is visible at normal zoom levels. Now you have to zoom in WAY too far for the feature to be actually useful on all other roads. Someone is asleep at the wheel at Google. (Pun intended.)
On a couple recent trips I ran into this when trying to figure out what river I was near / crossing. Multiple times I basically said "lemme get a better tool for this" and flipped to OsmAnd. Google Maps just basically/barely showed there was a channel of water and didn't show the name.
Younger generations are much less likely to navigate by comparing a map to the street names at an intersection. Instead, people navigate by searching for a particular destination and then following the line that the router generates.
When Google Maps is a one-size-fits-all product, you can't blame them for choosing an approach like this. Fortunately, the OSM ecosystem lets you choose (or develop for yourself) whatever approach you prefer.
I don't know about every street. But if you zoom in all of the way then yes, every street more than slightly in the viewport should be labeled. I have the same problems with all sorts of things like lakes where you need to find the magic zoom level and map position that reveals the name.
Some things are understandably harder, I don't necessarily need the Country, Province and City in every view of the map. But streets and lakes tend to not have much stuff inside of them so it seems obvious that when zoomed far in they should appear.
And zoom the label font size with the map size. I'm an old guy and cannot read the text on the map. Try to zoom in... the map zooms but the text stays the same size. Maddening.
I don't recall offhand whether it's Apple or Google maps that do this. Maybe both.
But why? Google Maps is not a navigation aid. Its purpose is not to help you know the name of the street you are in. It's a tool for paying customers to steer you towards their shops. If all you need to do is follow a path towards a certain shop, they don't need to show you the names of the streets.
It's not that the layout algorithm is different, it's that the algorithm tries to optimize the positions of text labels to get an aesthetically pleasing spacing, while preventing them from overlapping each other.
If you keep the label positions the same, but translate the text, then the layout will have been computed with the wrong bounding boxes, and you will tend to get wrong spacing and unintended overlaps.
This is a very welcome new development! I look forward to even better looking maps.
I'm just a bit puzzled by the "my workstation" section :-). There doesn't seem to be any relation to the rest of the article, not even high system requirements to do the things discussed after that.
The usefulness of being able to switch the language depends on the availability of translations of course. It might give editors an incentive to add more translations for place names.
Just to nip this in the bud, OpenStreetMap in general doesn't contain "translations" it contains the exonyms that are commonly in use for geographic objects. Most of the time things only have a name in the local language so there will be no value for other languages in the OSM data. Transliterations are a bit of a grey area in this context, but are definitely more useful than actual translations which tend to be garbage.
Further point: the data available in the vector tiles is defined by the vector tile schema and by far doesn't contain "everything".
The tile schema being used for the current testing (shortbread) doesn't support many languages, but they I think those working on this want to support them once the bugs are worked out.
For an example of how this might look see e.g. https://americanamap.org which uses OSM data, but doesn't aim to be near live like the tiles this thread is about.
Readit News
The article has screenshots that very much demonstrate this difference. The first screenshot has, for example, a lot of POIs (statues, shops, theaters, viewpoints), highways that are different when they are bridges, different colors for grass vs parks, different line widths for different highways, sports fields, building and neighbourhood names, arrows denoting one-way streets, building parts, stairs, trees, and a lot more.
The second screenshot has none of that, aside from a single trolly station and a single street name (which is also rendered incorrectly).
I've tried a lot of vector styles (all openmaptiles styles, the base protomaps styles, all mapbox styles) and generators (protomaps, openmaptiles, mapbox). None of them come close to the amount of detail as the raster OSM tiles while still being as readable.
I've never found anyone as bothered with this as I am. Vector styles are cool as they zoom and pan very smoothly, and their style is fairly easily editable. But, for any map where you actually want to see map data instead of using it as a base map for your own data, vector maps fall short.
Maybe it is just because of computational limits. I can imagine that displaying the same amount of detail as the OSM raster tiles would require too many resources: both on the client side and for tile generation.
It would be nice if OpenStreetMap would try to mimic their raster style closer, instead of providing just another low contrast, low detail base map. I hope this release of open vector tiles will facilitate more detailed vector maps!
I once spent a lot of time developing this very detailed style for planning cycle tours: https://stevebennett.me/2015/01/14/cycletour-org-a-better-ma...
I've tried a few times over the years to replicate it using vector tiles. It's pretty challenging to load enough detail into the tiles without hitting the size limits, and the default Mapbox tiles don't containing anything like enough information.
There are workarounds with vector tiles that raster tiles don't have though, like the ability to turn on/off different layers, while still retaining legibility (because labels can still be aware of what is underneath them).
The style was built to match the look of the original raster tiles closely, although I added many more interactivity features in the vector variant.
Is is interesting from a style/tile design perspective that the performance tradeoffs choices become very different how and where the tiles are rendered. This is obvious, but it has effects on what is possible on the server / clients visually as well.
I can't describe how much more usable OSM maps are because of how many POIs they show. You get a very real sense of the physical place just by looking at the map. A park looks distinctly like a park. A hospital looks distinctly like a hospital.
Google Maps looks a lot better from the perspective of a graphic designer, sure. But I usually have to resort to cross-referencing the shape of streets/intersection to get my bearings. With GM everywhere looks like everywhere else.
Deleted Comment
Which is a real pity. I'm optimistic that someone will solve it eventually.
But that's a lot of work, and whereas it's easy to add extra trivia to OSM it's much harder to add extra detail to tiles.
The whole point of OSM is that you can take the data and build / design your own things. Yes it would be nice if there were multiple viable google alternatives based on OSM and other open data, but that is likely just a pipe dream, the economics don't really work.
That's not to say that maputnik isn't great; it is! It's an awesome frontend to the complex style files.
Mostly I wonder how much MapBox's dominance for a few years disrupted other efforts.
There are still issues to fix as it is still only a technical preview.
No because the official OSM tile layer is heavily subsidized by Fastly (€720k last I checked) and rendering by AWS (€40k)
Yes because technically it would use fewer resources thus easier on AWS+Fastly and also easier to self-host
In last risk assessment I read closely(1) OSM noted "If we lost [Fastly] sponsorship, we would likely cut off all third-party access to the standard tile layer and run a small number of Varnish servers."
As I understand it, primary drivers for vectors was not cost more improving internationalization, generally enabling client-side rendering decisions, and driving a modern toolchain that would net multiple follow-on benefits
I'm a bit behind, there is more recent info available at (2)
1.https://operations.osmfoundation.org/2024/01/25/owg_budget.o... 2. https://osmfoundation.org/wiki/Finances
I somehow prefer to stick to tile based maps because caching, easy rendering and I also care about sat images, with cannot be vectorized.
I think we need both of those.
Static or infrequently updated vector tiles can be generated from OSM data by a number of tools, but those most popular right now are https://github.com/systemed/tilemaker and https://github.com/onthegomap/planetiler
The actual -new- thing is that the work Paul has done for the OSMF allows on the fly (aka in minutes) updates of the vector tiles. This is important for OSM contributors as a feedback mechanism and the main reason the OSMF operates the current raster tile service.
What is currently a bit out in the open is which usage restrictions will apply to to using the vector tile service as, just as with the raster tile service, the intent is not to compete with or replace third party services and a vector tile service could potentially do that.
this is the first I've seen of these alternative tools compared to using Tippecanoe(https://github.com/felt/tippecanoe). Are they considered to be higher performance?
You have for example https://protomaps.com/ or https://openmaptiles.org/ or https://versatiles.org/ (random order).
You can learn more about this in the blog of the developer who develops this tile server: https://www.openstreetmap.org/user/pnorman/diary/403600
p.s. current link to the demo page: https://pnorman.github.io/tilekiln-shortbread-demo
Deleted Comment
https://openfreemap.org/
- search or geocoding
- route calculation, navigation or directions
- static image generation
- raster tile hosting
- satellite image hosting
- elevation lookup
- custom tile or dataset hosting
https://github.com/hyperknot/openfreemap?tab=readme-ov-file#...
Is this based on the same vector tech stack at all, or is it a completely parallel development?
I expect that to work sub-optimally. Label dimensions are far from guaranteed to stay the same if you change language, and label dimensions interact with map layout, even influencing what to show.
If your labels grow larger, they may end up covering too much of the map or even overlapping. If they grow smaller, users may wonder why a city that was omitted before because of space constraints doesn’t show in the empty space created.
The problem is, i keep using maps because google has the best POI system/database around, and it will take other apps long yo beat it, even apples POIs cant hold up…
* Open the app. Instead of getting a map you get, "What's happening nearby" or somesuch. And how to close this changes with every release. I have NEVER in life life EVEN ONCE opened a mapping program because I was simply bored and wanted some other place to go.
* Search for "$name_of_place_or_business in $specific_city". Instead, it gives you all the locations with a similar name near your current location until you massage the query in some way. (It doesn't do this all the time but more than enough to be annoying.)
* Search for the name of a road or intersection in a city. It will instead give you a list of businesses with similar names, or in some cases, having nothing to do with the name you searched for.
* Search for the name of a particular business. Get results for their competitors instead. (Feels illegal.)
* The traffic overlay changed months back so that only interstate traffic is visible at normal zoom levels. Now you have to zoom in WAY too far for the feature to be actually useful on all other roads. Someone is asleep at the wheel at Google. (Pun intended.)
When Google Maps is a one-size-fits-all product, you can't blame them for choosing an approach like this. Fortunately, the OSM ecosystem lets you choose (or develop for yourself) whatever approach you prefer.
I don't know about every street. But if you zoom in all of the way then yes, every street more than slightly in the viewport should be labeled. I have the same problems with all sorts of things like lakes where you need to find the magic zoom level and map position that reveals the name.
Some things are understandably harder, I don't necessarily need the Country, Province and City in every view of the map. But streets and lakes tend to not have much stuff inside of them so it seems obvious that when zoomed far in they should appear.
I don't recall offhand whether it's Apple or Google maps that do this. Maybe both.
But why? Google Maps is not a navigation aid. Its purpose is not to help you know the name of the street you are in. It's a tool for paying customers to steer you towards their shops. If all you need to do is follow a path towards a certain shop, they don't need to show you the names of the streets.
Even on the raster tiles that have been in use for years.
If you keep the label positions the same, but translate the text, then the layout will have been computed with the wrong bounding boxes, and you will tend to get wrong spacing and unintended overlaps.
I'm just a bit puzzled by the "my workstation" section :-). There doesn't seem to be any relation to the rest of the article, not even high system requirements to do the things discussed after that.
So, every eg. city-shape-vector (well.. polygon) will cary the metadata/text of the name of that city in every defined language?
The usefulness of being able to switch the language depends on the availability of translations of course. It might give editors an incentive to add more translations for place names.
Further point: the data available in the vector tiles is defined by the vector tile schema and by far doesn't contain "everything".
Now all the metadata from the table will have to be put into SVG tile files.
The official tiles will probably be close though.
For an example of how this might look see e.g. https://americanamap.org which uses OSM data, but doesn't aim to be near live like the tiles this thread is about.