string_value: "شارع المدينة القديمة"
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...
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.
Maplibre Native even seems to have a headless "render to PNG" backend: https://github.com/maplibre/maplibre-native/tree/main/platfo...
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.
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
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.
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.
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.
The official tiles will probably be close though.
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.
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.
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.
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.
You have for example https://protomaps.com/ or https://openmaptiles.org/ or https://versatiles.org/ (random order).
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.
Any caching you do on raster tiles also works here.
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
openstreetmap.org has a very complex setup for real-time updates, but in general, hosting OSM-based maps is much cheaper with vector tiles.
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?
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.
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 this based on the same vector tech stack at all, or is it a completely parallel development?
- 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#...
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).
It is however possible to use Maplibre, Mapbox or some other libraries which I think do support vector tiles.
It much more performant, ergonomic, and requires no external dependencies.
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.
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.
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.
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.
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.
To correct this you need something like QZSS or accurate models of the buildings to compensate for it.
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.
You might be thinking of https://en.wikipedia.org/wiki/Differential_GPS.
I also dont think that this is the reason that the street names are often hidden.
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.
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.
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.
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…
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?
* 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.)
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.
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)
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.
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.
Intuitively, why can't the local vector rasterizer do whatever the server-side tile rasterizer does, especially if both are fully custom?
They're probably missing a raqm/freebidi or something in the stack on the client side.
That makes sense then, thank you!
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.
Having the data in tiles also complicates some things (where the renderer needs to consider merged tiles to get a similar result).
(Some countries use Roman numerals and some use Arabic numerals for numbers. And by Arabic numerals I don't mean 1-9.)
Roman numerals are I, V, X, etc.
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.
The raster tiles are primarily for our OSM mappers to see their map changes rendered quickly to improve the feedback loop.
I live in a bubble, the post.
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!
That's not to say that maputnik isn't great; it is! It's an awesome frontend to the complex style files.
Paul has written a blog post or two on the subject https://www.openstreetmap.org/user/pnorman/diary
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 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).
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.
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.
Which is a real pity. I'm optimistic that someone will solve it eventually.
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.
Was fun to write and I learned loads!
Old eyes are inflexible.
import pathlib
pathlib.Path('7006.mvt.json').write_text(...)
or the historical alternative
with open(...) as f:
f.write(...)