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 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 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 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?
Tippecanoe takes geojson and splits it up into tiles, we are talking about doing that with OSM data here. Typically you will want to apply some normalisation of the input data, then you need instantiate the geometry of the OSM objects, then split things up according to the vector tile schema in use and then write the tiles.
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.
Well nobody claimed things are going to get simpler.
It is difficult to beat raster tiles in that respect. vector tiles split up responsibility for what you get visually over multiple moving pieces with different provenance and operators.
Partially because they're completely different stacks -- the client side is WebGL + Javascript, and the server side is whatever they've been doing for 15 years.
They're probably missing a raqm/freebidi or something in the stack on the client side.
Ah, so the input into the client-side isn't OSM-like data (i.e. OSM XML or some high-level transform of that), but rather something closer to a vector graphics format like SVG?
It's a mapbox mvt, which is protobuf. It contains the OSM data (obviously), but it's a specific format that's in wide use (mapbox-gl, maplibre, and many other open source versions). There are similar versions in pmtiles, which is basically the same thing in a http range friendly big single file which can be hosted on S3-like storage and used directly.
The difficulty is that the stack for rendering vector tiles in the browser is different than the legacy vector->png generation that's been done for ages.
Not really. You need to build geometries from raw OSM data (aka the stuff that you edit) then transform those geometries into MVT format adding appropriate attributes from the original data. In general you actually will want to normalize the data and throw out anything that is not included in the vector tile schema you are using. The net result is quite far from raw OSM data in any case.
PS: I maintain a project that stores actual OSM data in MBTiles format for offline editing, and yes proper editing apps have to do the above on the fly and it is the main reason they are not lightning fast.
> 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…
I often use Google Maps to search for PoIs and opening hours since their data is so good, but often once I know where the place is I'll switch over to Apple Maps to navigate (partially because it just feels like Google's doing a lot more creepy tracking).
But yeah, add a third "hell yes" to hating not being able to see street names. I wonder if some of it is cultural differences - the maps apps seem really insistent that I can always see things like highway numbers and route numbers, which we have, but apart from major motorways (e.g. "M2") we don't really use any of those at all and refer to streets by their actual name. I wonder if it's more common to refer to numbered routes more in the US, and the apps are geared that way because of it?
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.
Also not to mention while navigating Google Maps stupidly hides all the business names en route. I want to see every single business along my route, damnit, so that I know where I could possibly go to eat or stop for a rest along the way.
The Google Assistant is also the most useless piece of crap ever. "OK Google show me all the businesses on the map" doesn't work, and neither does "OK Google zoom in" for that matter. Most useless UX ever.
That's something that REALLY irked me when visiting a new city this past weekend.
We were trying to find somewhere to eat... And a labeled map of the city blocks around us would have been perfect. We didn't really care what kind of food we had, we aren't picky folks... We just wanted to know the options to see what sounded good at the time.
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.
That method just doesn't work in Manhattan, where due to buildings, you're lucky if your GPS is working, much less the compass to tell you which direction to face.
The vast majority of Google Maps users are capable of using A-GPS data, they are not reliant on a clear GPS satellite signal alone. And Google’s A-GPS data for Manhattan is extremely detailed. Again, this makes sense for a one-size-fits-all product like Google Maps.
That's not good enough, AGPS doesn't work near skyscrapers. The issue isn't that the signal isn't "clear", it's that it reflects off the buildings and the GPS receiver will get a clear but wrong signal.
To correct this you need something like QZSS or accurate models of the buildings to compensate for it.
Yeah, it doesn't work for this. I've tried it in the last few months and talked to people working on location about it out of curiosity. Not in NYC specifically but in other cities.
Even short buildings have issues here - if you walk down a wide street in Tokyo, which are pretty common and often surrounded by 3-4 story buildings, with the map open and look at it closely, you will often show up on the other side of the street. (Which surprised me, because it's literally why QZSS exists.)
Afaik, the issues with WiFi are that if you're traveling at any speed there isn't much time to do scans, and the position of the WiFi networks themselves isn't clear enough because of multipath (reflections), because it is crowdsourced from other devices that don't have real ground truth locations, and because the other devices gathering info are at different heights above ground or are indoors.
The main advantage of A-GPS with WiFi is that it starts up faster and that it mostly works indoors or when you can't see any satellites.
The correction which Apple and Google are taking is anonymous UWB location in a mesh network via Time of Flight (ToF), Angle of Arrival (AoA) and Device-to-Device communication.
That is how locations are transmitted for Find My Phone/Device, and how relative close-by positioning works for AirTags and similar, but it's not used to determine absolute locations as far as I know. It would certainly be cool if it did that though.
3GPP Release 16 started the UWB location and position scope while Release 17 finalized the 5GC capability. Perhaps more work is being done there, I haven't been tracking it closely lately.
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.
Google doesn't really optimize to show you ads. They're a monopoly and the voting shares are owned by Larry/Sergey; they have no intrinsic motivation to care about anything. If you want to be optimization-brained (don't, it's bad for you) they optimize for metrics that individual people make up and use to get promoted.
They monetize the map other ways, like with the expensive API fees, but I wonder if they really care about it. Whenever I look at it for a few seconds I see something obviously sloppy, like misspelled POI names or people adding fake businesses at their apartment.
Google Maps is a navigation aid that's also used to sell ads.
People don't open the app to look at the ads. They open it to navigate, and if it can't be used for that purpose they won't open it at all. It is infuriating to me when a Wendy's ad is given more visual importance in color and size on the app than the actual place I want to find. But it doesn't seem to bother a lot of other people. Somewhere further in the direction of more advertisements is a point where a significant number of normal people will stop using Maps as a navigation tool, and somewhere further still is a point where more advertisements will become less profitable and will be rejected by even the developers. But we're nowhere near that point yet.
Until then, I'll keep using a combination of Garmin Explore, OsmAnd, and Maps depending on how much I care about topo data, traffic status, reviews, search results, and ads. I'm setting up an Owntracks so I can replace the Timeline data that they're removing customer access to, and contributing to OpenStreetMap, but still using Maps.
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.
Where can we learn more about the label positioning/enabling algorithms? I'm wondering at what stages of the vector-tile rendering pipeline various actions happen e.g. selecting for a particular language, binding into the tile (single object?), avoiding crowding line geometry, avoiding crowding of other labels, font selection, rasterization, ...
> the algorithm tries to optimize the positions of text labels
Not only that, deciding whether to show a label at all can depend on its size and shape, and if a label deemed important becomes larger that can lead to the decision to not show some map details (in an ideal world)
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.
https://marble.kde.org/ has had their own implementation of a streaming vectorOSM layer for nine years and I was eagerly waiting for something akin to materialize in other OSM map applications for quite a while.. Downloading hundreds of megs of map data in big whole-country chunks always was a space issue in android OSM apps. Very glad a standard is finally being established and looking forward to it getting picked up and polished.. Great work! : )
I went looking for the Marble app on Android and it's not in the Play store or on f-droid. The link to the Play store from the website is a 404. Did they abandon it?
Both apps mainly use downloaded/"offline" preprocessed map data in their own formats.
MVT format vector tiles are not remotely suitable for navigation or search (not ruling out that something could be hobbled together, but it would be a bit of a stretch).
There can be no one ultimate map app because use cases differ. For example, OSMAnd has many power-user features that are very useful for people who also contribute to OSM, but would only clutter the interface of an app for normies.
I'm interested in applying transforms to vector tile coordinates at render time. What libraries do you recommend for that? I have zero experience with map rendering but I understand coordinate transformation well. I'd like to render a log azimuthal earth. I know I'll need to pull tiles at different scales and stitch them together, just not sure which library to use to make that easy.
One thing I appreciate about the default raster-based maps is how snappy they are. Zooming in and out on OSM is much faster than on Google/Apple/Yandex/Bing maps. Of course, vector-based maps mean I can finally use OSM for countries that use Ethiopic/Arabic/Hebrew/Georgian/Armenian/Hanzi/Indic writing systems.
Does anyone know if vector tiles could carry adequate data to facilitate reverse geocoding (address lookup)? E.g. the polygon of a building containing its street address in its metadata. I’m surprised I haven’t seen that before, as reverse geocoding services can get expensive, though I wonder if it’s because I’ve misunderstood how vector tiles actually work.
Possibly, but why would you want to do this client side? This seems like the type of operation that makes much more sense in "OSM space", not vector graphics space.
Sure you could .... but to find something you would need to have the tile in question so you would need to calculate the tile to retrieve, and then find the object at the location (which is roughly equivalent to rendering the tile).
Doesn't seem to make sense when you can just run a nominatim or photon instance locally. Not to mention that currently you would typically have to add additional address data to the mix to get the quality of commercial geocoding services which makes the doing it via tiles even less attractive.
If this means I can get fatter/thicker/larger text labels on my maps, I'm all for it. As it stands, it feels like tiles have precomputed text embedded, which is never at a size I can handle.
I saw some morecantile/mercantile in the article, so I will plug a side project of mine “utiles” for anyone needing tile util(e)s: https://github.com/jessekrubin/utiles
One of the downsides of MVTs and the typical max zoom level of 14 is that that they do require more local resources than simply rendering a 256x256 bitmap.
For OSM the question is naturally would a complete migration (aka turning off raster tile support) exclude any noticeable number of people from contributing.
But right now that decision is still a long way off, the vector tile service hasn't even been integrated in osm.org yet.
Is there a tool to capture vector tiles to raster files? Some tools like Apple's MapKit don't support vector tiles yet, and it could be interesting to use one single map base and be able to just generate the raster, instead of having a specific raster server
Apple’s MapKit most definitely supports vector tiles, because you are given a CGContext to draw with. You just have to implement the MVT spec (it’s small)
It’s not a lot of work, like at all. And unlike mapbox/libre you’re are still within UIKit so you can leverage all the existing UI tooling on top of your vector layers.
It much more performant, ergonomic, and requires no external dependencies.
Sidenote: the most infuriating thing about google maps widgets has been the removal of the scale by default. All them transportation apps with their embedded map views have been of annoyingly limited use for multimodal navigation.. without a scale it just leaves me guessing whether a distance can be considered walkable .. Then I was flabbergasted when leaflet copied this crucial design decision.. yet my efforts to convince the leaflet team to reconsider reverting the default (because defaults are rarely changed downstream) utterly failed: https://github.com/Leaflet/Leaflet/issues/8902 .. awefully reminds me of the design trend for thin scrollbars and tiny touch targets being enforced in GUIs all over, mostly without an easy option even to configure it.. WONTFIX in KDE f.e. https://bugs.kde.org/show_bug.cgi?id=416003 come on..
Hopefully with AI, we'll soon enter an era of liquid software where everything can be dynamically changed at will. Oh the future, behold xD
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.
is there already a live version of this? Because for me, there doesn't seem to be an option for activating vector tiles on https://www.openstreetmap.org/
I think what he implies is that he's hosting it locally on that, in which case the high specs are a weird flex because the demo map runs like absolute molasses for me.
Maybe it's high load or the guy doesn't have much upload speed, but it showcases that overzooming low level tiles renders really bad square lines when the high detail layers refuse to download.
One clear advantage of the new SVG format is, apparently, that Arabic script is now, finally!, rendered the way it was always intended—left-to-right with unconnected letters /s
I wish they were SVG, that would make rendering them less of a headache.
There is still no good library which takes in a MVT tile and spits out the appropriate PNG or JPEG for rendering in via a tile base mapping engine. There is still no good cross platform mapping engine that can render vector tiles in a way that is easy to consume. There are certainly engines on specific platforms, but unless we use something like Leaflet or OpenLayers it is hard to make it work with native APIs on, say Windows, MacOs, Linux, iOS or Android without needing to adding a whole browser engine on top of your app.
Yup. I work a lot with MVTs and one of the headaches is, after you have your nice shiny state-of-the-art maps, turning them back into PNG raster tiles for all the various clients that can't natively render vector tiles.
This link is shrinking though! There's slowly growing support. Leaflet and OpenLayers are fundamentally limited by being canvas-based, so there's only so much they can do.
QGIS has one of the fastest, cleanest MVT renderers I've seen, but I don't know how easy that would be to extract out.
PostGIS is the best platform for generating vector tiles, but it's extremely clunky. On the projects I'm working on (eg https://vectorcharts.com/) I do extensive processing in PostGIS, but then encode to vector tiles in bespoke C++ code.
There are plenty non-web vector map renderers, but they generally provide a full GUI widget, not a simple "extent -> png" function. I don't think creating that would be too much work, though: Just set one of those libraries to render to a texture.
If I would like to print vector-tile based maps to pdfs for handout's or something, is there any CPU renderer, server- or client-side that could output SVGs instead of rasterizing on GPU to bitmap at some point?
I havent yet come across any renderer that would do this even partially, even before opening the whole can of worms that is text rendering.
Closest thing I'm aware of might be ArcGIS Maps for Adobe Creative Cloud but would need something that's more like a library and preferably FOSS.
Recent versions of QGIS support vector tiles in the MVT format (like these ones). So with a suitable style you should be able to create a layout using vector tiles and print.
Assuming you meet the relevant attribution/license requirements for the various bits you choose of course. I don't think any usage policy has been published for these tiles yet.
Unfortunately there are some translation issues with styles for MVT sources so you might need to do a bit of fixing if you don't want to go the route of a paid plan with MapTiler (third party provider) who have a plugin.
QGIS can do this. It's a large dependency and loads Mapbox/Maplibre styles by converting them to internal ones, so it might look a little different than the standard Maplibre renderer, but you get the benefit of easily editing those styles.
So while showcasing the brand-new vector tiles, they accidentally also showcased a pretty significant bug? Should have picked some city with non-latin script that's written left-to-right... er, maybe Athens?
The author of the blog post chose an area that doesn't render well. The various issues are being flagged in the relevant repositories as they are found.
Mapbox Vector Tiles are not SVG, its is similar to geoJSON but encoded in protobuf. The renderer is going to typically be WebGL based in the browser written in javascript.
Yeah, I’m curious if that problem is baked into the SVG, or if the renderer has a “don’t screw up Arabic” option that’s disabled by default. You’d think nobody would design software that way, but Photoshop has that option, and it really is turned off by default!
They are just Unicode strings in the vector tiles (which are their own format, nothing to do with SVG). It's this particular demo that is missing basic Arabic support.
string_value: "شارع المدينة القديمة"
I can't read Arabic, but I know if I see "ل ا" then it's broken — "ال" is correct: https://isthisarabic.com/
I can't believe they still haven't added a 2x pixel density version of the default map style. It's $CURRENTYEAR and we all have high pixel density phones. No one uses 1080p displays anymore. The default blurry version makes any page using OSM feel amateur.
We don't offer 2x raster tiles because we simply don't have the resources to do it while keeping the tiles minutely updated and open access. We serve around 60k req/sec on a tiny donation backed budget.
The raster tiles are primarily for our OSM mappers to see their map changes rendered quickly to improve the feedback loop.
Raster tiles hosted at tile.openstreetmap.org are not intended for widespread production use, they’re principally for mapper feedback. If you have a business need for something that doesn’t look “amateur” you should arguably be using a third party OSM-based service or hosting your own tiles.
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 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).
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 article wasn't authored by anybody actually involved with the service or setting it up, just in case that wasn't clear.
Paul has written a blog post or two on the subject https://www.openstreetmap.org/user/pnorman/diary
Ah this is great and super interesting. Thank you!
I built a fork of OpenrailwayMap (original at https://www.openrailwaymap.org, vector styles at https://openrailwaymap.fly.dev).
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 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 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.
Lack of data in OSM is a very different issue from what is being discussed here.
Obviously. I just brought it up to explain why I use both OSM and Google Maps.
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.
The new stack has some unique feature like the vector tiles being minutely updated directly from OSM mapping changes.
There are still issues to fix as it is still only a technical preview.
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?
Yes and No.
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 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.
Way too much latency I am sure.
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.
I think we need both of those.
These are tile-based maps — vector tiles, rather than raster tiles.
Any caching you do on raster tiles also works here.
Oh okey, So I confused them with PMTiles..
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).
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.
> 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
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?
Different use case.
Tippecanoe takes geojson and splits it up into tiles, we are talking about doing that with OSM data here. Typically you will want to apply some normalisation of the input data, then you need instantiate the geometry of the OSM objects, then split things up according to the vector tile schema in use and then write the tiles.
Yes, vector tiles are much easier to self host.
You have for example https://protomaps.com/ or https://openmaptiles.org/ or https://versatiles.org/ (random order).
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.
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
OP asked "Does this reduce the operating costs of hosting OSM-based maps".
openstreetmap.org has a very complex setup for real-time updates, but in general, hosting OSM-based maps is much cheaper with vector tiles.
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.
Indeed, but that is probably not going to help end users of apps.
Well nobody claimed things are going to get simpler.
It is difficult to beat raster tiles in that respect. vector tiles split up responsibility for what you get visually over multiple moving pieces with different provenance and operators.
> It is difficult to beat raster tiles in that respect.
Intuitively, why can't the local vector rasterizer do whatever the server-side tile rasterizer does, especially if both are fully custom?
Partially because they're completely different stacks -- the client side is WebGL + Javascript, and the server side is whatever they've been doing for 15 years.
They're probably missing a raqm/freebidi or something in the stack on the client side.
Ah, so the input into the client-side isn't OSM-like data (i.e. OSM XML or some high-level transform of that), but rather something closer to a vector graphics format like SVG?
That makes sense then, thank you!
It's a mapbox mvt, which is protobuf. It contains the OSM data (obviously), but it's a specific format that's in wide use (mapbox-gl, maplibre, and many other open source versions). There are similar versions in pmtiles, which is basically the same thing in a http range friendly big single file which can be hosted on S3-like storage and used directly.
The difficulty is that the stack for rendering vector tiles in the browser is different than the legacy vector->png generation that's been done for ages.
> It contains the OSM data (obviously) ...
Not really. You need to build geometries from raw OSM data (aka the stuff that you edit) then transform those geometries into MVT format adding appropriate attributes from the original data. In general you actually will want to normalize the data and throw out anything that is not included in the vector tile schema you are using. The net result is quite far from raw OSM data in any case.
PS: I maintain a project that stores actual OSM data in MBTiles format for offline editing, and yes proper editing apps have to do the above on the fly and it is the main reason they are not lightning fast.
It can, it's just that they typically don't, because they use an off the shelf data schema for the tiles and a library to handle the rendering.
Having the data in tiles also complicates some things (where the renderer needs to consider merged tiles to get a similar result).
For Arabic specifically, different users want text to render differently, so you'd want to do it on the client if you can.
(Some countries use Roman numerals and some use Arabic numerals for numbers. And by Arabic numerals I don't mean 1-9.)
All Arabic-speaking countries use Arabic numerals. Some use Western Arabic numerals (123) and some use Eastern Arabic numerals (١٢٣).
Roman numerals are I, V, X, etc.
See perhaps:
* https://en.wikipedia.org/wiki/Arabic_numerals_(disambiguatio...
* https://en.wikipedia.org/wiki/Hindu–Arabic_numeral_system#Gl...
* https://en.wikipedia.org/wiki/List_of_numeral_systems
it looks like the selected font doesn't support arabic text, producing the disconnected characters.
It's likely an issue with displaying Arabic text in WebGL, since that needs to handle all of the possible options for each letter in the text-shaping.
I'm not sure how the QGIS vector tile renderer works, but for the github demo page it would be easy to add the RTL text plugin to MapLibre to correctly handle the RTL text: https://maplibre.org/maplibre-gl-js/docs/examples/mapbox-gl-...
Also see: OpenFreeMap — free OpenStreetMap vector tile hosting
https://openfreemap.org/
OpenFreeMap is not providing:
- 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#...
Wow, this looks incredibly polished!
Is this based on the same vector tech stack at all, or is it a completely parallel development?
No, it's a totally different stack. Have a look at GitHub as well, it tells in detail how it's done.
> 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.
The starting case is anyway automatic positioning of the labels.
Even on the raster tiles that have been in use for years.
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…
I often use Google Maps to search for PoIs and opening hours since their data is so good, but often once I know where the place is I'll switch over to Apple Maps to navigate (partially because it just feels like Google's doing a lot more creepy tracking).
But yeah, add a third "hell yes" to hating not being able to see street names. I wonder if some of it is cultural differences - the maps apps seem really insistent that I can always see things like highway numbers and route numbers, which we have, but apart from major motorways (e.g. "M2") we don't really use any of those at all and refer to streets by their actual name. I wonder if it's more common to refer to numbered routes more in the US, and the apps are geared that way because of it?
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.
Also not to mention while navigating Google Maps stupidly hides all the business names en route. I want to see every single business along my route, damnit, so that I know where I could possibly go to eat or stop for a rest along the way.
The Google Assistant is also the most useless piece of crap ever. "OK Google show me all the businesses on the map" doesn't work, and neither does "OK Google zoom in" for that matter. Most useless UX ever.
That's something that REALLY irked me when visiting a new city this past weekend.
We were trying to find somewhere to eat... And a labeled map of the city blocks around us would have been perfect. We didn't really care what kind of food we had, we aren't picky folks... We just wanted to know the options to see what sounded good at the time.
But nope, can't see that either.
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.
That method just doesn't work in Manhattan, where due to buildings, you're lucky if your GPS is working, much less the compass to tell you which direction to face.
The vast majority of Google Maps users are capable of using A-GPS data, they are not reliant on a clear GPS satellite signal alone. And Google’s A-GPS data for Manhattan is extremely detailed. Again, this makes sense for a one-size-fits-all product like Google Maps.
That's not good enough, AGPS doesn't work near skyscrapers. The issue isn't that the signal isn't "clear", it's that it reflects off the buildings and the GPS receiver will get a clear but wrong signal.
To correct this you need something like QZSS or accurate models of the buildings to compensate for it.
The term "A-GPS" in common practice includes also wifi and, as I mentioned, Google's data for this is very detailed in Manhattan, too.
Yeah, it doesn't work for this. I've tried it in the last few months and talked to people working on location about it out of curiosity. Not in NYC specifically but in other cities.
Even short buildings have issues here - if you walk down a wide street in Tokyo, which are pretty common and often surrounded by 3-4 story buildings, with the map open and look at it closely, you will often show up on the other side of the street. (Which surprised me, because it's literally why QZSS exists.)
Afaik, the issues with WiFi are that if you're traveling at any speed there isn't much time to do scans, and the position of the WiFi networks themselves isn't clear enough because of multipath (reflections), because it is crowdsourced from other devices that don't have real ground truth locations, and because the other devices gathering info are at different heights above ground or are indoors.
The main advantage of A-GPS with WiFi is that it starts up faster and that it mostly works indoors or when you can't see any satellites.
The correction which Apple and Google are taking is anonymous UWB location in a mesh network via Time of Flight (ToF), Angle of Arrival (AoA) and Device-to-Device communication.
That is how locations are transmitted for Find My Phone/Device, and how relative close-by positioning works for AirTags and similar, but it's not used to determine absolute locations as far as I know. It would certainly be cool if it did that though.
You might be thinking of https://en.wikipedia.org/wiki/Differential_GPS.
3GPP Release 16 started the UWB location and position scope while Release 17 finalized the 5GC capability. Perhaps more work is being done there, I haven't been tracking it closely lately.
https://www.3gpp.org/technologies/location-and-positioning
Huh, is that for mesh UWB networks? I would've assumed it was for mmWave cell stations, which I've never once seen in real life.
Not sure if thats true. I see some people using the blue line, but some dont and instead look for street names, etc.
I also dont think that this is the reason that the street names are often hidden.
> Just show the name of every street damnit
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.
Or when you zoom in and the names remain tiny and illegible.
> Just show the name of every street damnit.
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.
Google doesn't really optimize to show you ads. They're a monopoly and the voting shares are owned by Larry/Sergey; they have no intrinsic motivation to care about anything. If you want to be optimization-brained (don't, it's bad for you) they optimize for metrics that individual people make up and use to get promoted.
They monetize the map other ways, like with the expensive API fees, but I wonder if they really care about it. Whenever I look at it for a few seconds I see something obviously sloppy, like misspelled POI names or people adding fake businesses at their apartment.
Google Maps is a navigation aid that's also used to sell ads.
People don't open the app to look at the ads. They open it to navigate, and if it can't be used for that purpose they won't open it at all. It is infuriating to me when a Wendy's ad is given more visual importance in color and size on the app than the actual place I want to find. But it doesn't seem to bother a lot of other people. Somewhere further in the direction of more advertisements is a point where a significant number of normal people will stop using Maps as a navigation tool, and somewhere further still is a point where more advertisements will become less profitable and will be rejected by even the developers. But we're nowhere near that point yet.
Until then, I'll keep using a combination of Garmin Explore, OsmAnd, and Maps depending on how much I care about topo data, traffic status, reviews, search results, and ads. I'm setting up an Owntracks so I can replace the Timeline data that they're removing customer access to, and contributing to OpenStreetMap, but still using Maps.
Why would you expect the layout algorithm to be significantly different?
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.
Where can we learn more about the label positioning/enabling algorithms? I'm wondering at what stages of the vector-tile rendering pipeline various actions happen e.g. selecting for a particular language, binding into the tile (single object?), avoiding crowding line geometry, avoiding crowding of other labels, font selection, rasterization, ...
> the algorithm tries to optimize the positions of text labels
Not only that, deciding whether to show a label at all can depend on its size and shape, and if a label deemed important becomes larger that can lead to the decision to not show some map details (in an ideal world)
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.
https://marble.kde.org/ has had their own implementation of a streaming vectorOSM layer for nine years and I was eagerly waiting for something akin to materialize in other OSM map applications for quite a while.. Downloading hundreds of megs of map data in big whole-country chunks always was a space issue in android OSM apps. Very glad a standard is finally being established and looking forward to it getting picked up and polished.. Great work! : )
I went looking for the Marble app on Android and it's not in the Play store or on f-droid. The link to the Play store from the website is a 404. Did they abandon it?
(Low effort comment) I wonder if this means OSMAnd and OrganicMaps will now finally team up to deliver the ultimate FOSS Map app
Both apps mainly use downloaded/"offline" preprocessed map data in their own formats.
MVT format vector tiles are not remotely suitable for navigation or search (not ruling out that something could be hobbled together, but it would be a bit of a stretch).
There can be no one ultimate map app because use cases differ. For example, OSMAnd has many power-user features that are very useful for people who also contribute to OSM, but would only clutter the interface of an app for normies.
At the very least I hope it means they can share map tiles between them so I don't have to use gigabytes of space on the same map
No it doesn't.
How so?
The fantastic offline routing and metrics of OSMAnd placed into a lightweight and snappy OrganicMaps interface would be a huge win for me.
There is Organic Maps already.
And it works really well. The smooth zoom in is amazing.
I'm interested in applying transforms to vector tile coordinates at render time. What libraries do you recommend for that? I have zero experience with map rendering but I understand coordinate transformation well. I'd like to render a log azimuthal earth. I know I'll need to pull tiles at different scales and stitch them together, just not sure which library to use to make that easy.
`open('7006.mvt.json', 'w').write(...)` (from section `Analysis-Ready Data`) should either be
import pathlib
pathlib.Path('7006.mvt.json').write_text(...)
or the historical alternative
with open(...) as f:
Does anyone know how to download the OSM placemarks (museum, fort, bus stop, etc) for use in another GIS program like AlpineQuest or even the desktop?
One thing I appreciate about the default raster-based maps is how snappy they are. Zooming in and out on OSM is much faster than on Google/Apple/Yandex/Bing maps. Of course, vector-based maps mean I can finally use OSM for countries that use Ethiopic/Arabic/Hebrew/Georgian/Armenian/Hanzi/Indic writing systems.
Does anyone know if vector tiles could carry adequate data to facilitate reverse geocoding (address lookup)? E.g. the polygon of a building containing its street address in its metadata. I’m surprised I haven’t seen that before, as reverse geocoding services can get expensive, though I wonder if it’s because I’ve misunderstood how vector tiles actually work.
Possibly, but why would you want to do this client side? This seems like the type of operation that makes much more sense in "OSM space", not vector graphics space.
Sure you could .... but to find something you would need to have the tile in question so you would need to calculate the tile to retrieve, and then find the object at the location (which is roughly equivalent to rendering the tile).
Doesn't seem to make sense when you can just run a nominatim or photon instance locally. Not to mention that currently you would typically have to add additional address data to the mix to get the quality of commercial geocoding services which makes the doing it via tiles even less attractive.
Yes, they could. You can attach whatever metadata you want to a vector tile feature.
If this means I can get fatter/thicker/larger text labels on my maps, I'm all for it. As it stands, it feels like tiles have precomputed text embedded, which is never at a size I can handle.
Old eyes are inflexible.
I saw some morecantile/mercantile in the article, so I will plug a side project of mine “utiles” for anyone needing tile util(e)s: https://github.com/jessekrubin/utiles
Was fun to write and I learned loads!
This will be great for custom maps.
I am on QGIS 3.30 and many of the street labels at 1:31860 scale show up in red and are not aligned correctly.
Exciting update! How does the new vector tile system handle performance on low-end devices with large datasets?
... it doesn't?
One of the downsides of MVTs and the typical max zoom level of 14 is that that they do require more local resources than simply rendering a 256x256 bitmap.
For OSM the question is naturally would a complete migration (aka turning off raster tile support) exclude any noticeable number of people from contributing.
But right now that decision is still a long way off, the vector tile service hasn't even been integrated in osm.org yet.
Is there a tool to capture vector tiles to raster files? Some tools like Apple's MapKit don't support vector tiles yet, and it could be interesting to use one single map base and be able to just generate the raster, instead of having a specific raster server
Something like https://github.com/maptiler/tileserver-gl can serve raster tiles from a vector tile dataset
Apple’s MapKit most definitely supports vector tiles, because you are given a CGContext to draw with. You just have to implement the MVT spec (it’s small)
The idea is to use "MapKit" for maps, not to override it and draw everything yourself... The fact that it's possible doesn't mean it's a good idea.
It is however possible to use Maplibre, Mapbox or some other libraries which I think do support vector tiles.
It’s not a lot of work, like at all. And unlike mapbox/libre you’re are still within UIKit so you can leverage all the existing UI tooling on top of your vector layers.
It much more performant, ergonomic, and requires no external dependencies.
I am absolutely amazed that Apple don't support this yet. I had thought mapping was a competitive advantage for them...
Sidenote: the most infuriating thing about google maps widgets has been the removal of the scale by default. All them transportation apps with their embedded map views have been of annoyingly limited use for multimodal navigation.. without a scale it just leaves me guessing whether a distance can be considered walkable .. Then I was flabbergasted when leaflet copied this crucial design decision.. yet my efforts to convince the leaflet team to reconsider reverting the default (because defaults are rarely changed downstream) utterly failed: https://github.com/Leaflet/Leaflet/issues/8902 .. awefully reminds me of the design trend for thin scrollbars and tiny touch targets being enforced in GUIs all over, mostly without an easy option even to configure it.. WONTFIX in KDE f.e. https://bugs.kde.org/show_bug.cgi?id=416003 come on.. Hopefully with AI, we'll soon enter an era of liquid software where everything can be dynamically changed at will. Oh the future, behold xD
How soon before mobile apps can start using these?
> Imagery should appear much sharper and switching the language of the labels should become possible.
So, every eg. city-shape-vector (well.. polygon) will cary the metadata/text of the name of that city in every defined language?
Large cities already contain the name in many languages. See Paris for example: https://www.openstreetmap.org/relation/71525
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".
If there's a Wikidata QID associated with it then one can also use that to look up names in other languages
The tiles aren't necessarily a 1:1 translation of the data.
The official tiles will probably be close though.
Sure, but that's contained in the database, and then the tiles are generated that only contain one text (usually) in a png form).
Now all the metadata from the table will have to be put into SVG tile files.
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.
No but you could fetch tiles with only the text you need to patch the tiles you already have.
is there already a live version of this? Because for me, there doesn't seem to be an option for activating vector tiles on https://www.openstreetmap.org/
See https://community.openstreetmap.org/t/vector-tiles-on-osmf-h...
thank you very much; on the link provided, I found this demo: https://pnorman.github.io/tilekiln-shortbread-demo
https://github.com/pnorman/tilekiln-shortbread-demo
Sorry, I just added a link to a live demo in the post: https://pnorman.github.io/tilekiln-shortbread-demo/
What was that interlude about the computer's specs lol, I thought it was going somewhere but it didn't.
I think what he implies is that he's hosting it locally on that, in which case the high specs are a weird flex because the demo map runs like absolute molasses for me.
Maybe it's high load or the guy doesn't have much upload speed, but it showcases that overzooming low level tiles renders really bad square lines when the high detail layers refuse to download.
One clear advantage of the new SVG format is, apparently, that Arabic script is now, finally!, rendered the way it was always intended—left-to-right with unconnected letters /s
I wish they were SVG, that would make rendering them less of a headache.
There is still no good library which takes in a MVT tile and spits out the appropriate PNG or JPEG for rendering in via a tile base mapping engine. There is still no good cross platform mapping engine that can render vector tiles in a way that is easy to consume. There are certainly engines on specific platforms, but unless we use something like Leaflet or OpenLayers it is hard to make it work with native APIs on, say Windows, MacOs, Linux, iOS or Android without needing to adding a whole browser engine on top of your app.
Yup. I work a lot with MVTs and one of the headaches is, after you have your nice shiny state-of-the-art maps, turning them back into PNG raster tiles for all the various clients that can't natively render vector tiles.
This link is shrinking though! There's slowly growing support. Leaflet and OpenLayers are fundamentally limited by being canvas-based, so there's only so much they can do.
QGIS has one of the fastest, cleanest MVT renderers I've seen, but I don't know how easy that would be to extract out.
PostGIS is the best platform for generating vector tiles, but it's extremely clunky. On the projects I'm working on (eg https://vectorcharts.com/) I do extensive processing in PostGIS, but then encode to vector tiles in bespoke C++ code.
There are plenty non-web vector map renderers, but they generally provide a full GUI widget, not a simple "extent -> png" function. I don't think creating that would be too much work, though: Just set one of those libraries to render to a texture.
Maplibre Native even seems to have a headless "render to PNG" backend: https://github.com/maplibre/maplibre-native/tree/main/platfo...
If I would like to print vector-tile based maps to pdfs for handout's or something, is there any CPU renderer, server- or client-side that could output SVGs instead of rasterizing on GPU to bitmap at some point?
I havent yet come across any renderer that would do this even partially, even before opening the whole can of worms that is text rendering.
Closest thing I'm aware of might be ArcGIS Maps for Adobe Creative Cloud but would need something that's more like a library and preferably FOSS.
Recent versions of QGIS support vector tiles in the MVT format (like these ones). So with a suitable style you should be able to create a layout using vector tiles and print.
Assuming you meet the relevant attribution/license requirements for the various bits you choose of course. I don't think any usage policy has been published for these tiles yet.
Unfortunately there are some translation issues with styles for MVT sources so you might need to do a bit of fixing if you don't want to go the route of a paid plan with MapTiler (third party provider) who have a plugin.
There's also a list of "print map" generators of varying types here: https://wiki.openstreetmap.org/wiki/OSM_on_Paper
QGIS can do this. It's a large dependency and loads Mapbox/Maplibre styles by converting them to internal ones, so it might look a little different than the standard Maplibre renderer, but you get the benefit of easily editing those styles.
So while showcasing the brand-new vector tiles, they accidentally also showcased a pretty significant bug? Should have picked some city with non-latin script that's written left-to-right... er, maybe Athens?
They released them for testing purposes, originally on a test server and now a soft launch on OSMF hardware. https://community.openstreetmap.org/t/vector-tiles-on-osmf-h...
The author of the blog post chose an area that doesn't render well. The various issues are being flagged in the relevant repositories as they are found.
Mapbox Vector Tiles are not SVG, its is similar to geoJSON but encoded in protobuf. The renderer is going to typically be WebGL based in the browser written in javascript.
https://wiki.openstreetmap.org/wiki/Vector_tiles
https://maplibre.org/maplibre-gl-js/docs/
Yeah, I’m curious if that problem is baked into the SVG, or if the renderer has a “don’t screw up Arabic” option that’s disabled by default. You’d think nobody would design software that way, but Photoshop has that option, and it really is turned off by default!
They are just Unicode strings in the vector tiles (which are their own format, nothing to do with SVG). It's this particular demo that is missing basic Arabic support.
I can't read Arabic, but I know if I see "ل ا" then it's broken — "ال" is correct: https://isthisarabic.com/Someone's already made an issue: https://github.com/pnorman/osmf-shortbread-todo/issues/9
Found via what seems to be the announcement of this demo/preview service: https://community.openstreetmap.org/t/vector-tiles-on-osmf-h...
[flagged]
[flagged]
I can't believe they still haven't added a 2x pixel density version of the default map style. It's $CURRENTYEAR and we all have high pixel density phones. No one uses 1080p displays anymore. The default blurry version makes any page using OSM feel amateur.
We don't offer 2x raster tiles because we simply don't have the resources to do it while keeping the tiles minutely updated and open access. We serve around 60k req/sec on a tiny donation backed budget.
The raster tiles are primarily for our OSM mappers to see their map changes rendered quickly to improve the feedback loop.
Raster tiles hosted at tile.openstreetmap.org are not intended for widespread production use, they’re principally for mapper feedback. If you have a business need for something that doesn’t look “amateur” you should arguably be using a third party OSM-based service or hosting your own tiles.
Funnily enough I have 3x 1080p monitors in front of me. Maybe I am "no one". :)
> No one uses 1080p displays anymore.
I live in a bubble, the post.
[flagged]