Link
click to show
click to show
Yes, definitely some ongoing stuff. I don’t know the best place to connect with the devs, but it’s *probably* either the OSM community forum (e.g. this post; there may be a newer one now though: https://community.openstreetmap.org/t/vector-tiles-on-osmf-hardware/121501) or on IRC.
AmiriaAre there any technical reason why OSM (website, the one lives at OpenStreetMap.org) uses raster methods for drawing map other than newly emerged vector ones?
I personally think vector-based generations for planet-scaled websites and apps would be a lot more resource friendly.
they hog a ton more RAM and CPU for me
not sure about the reactions to that one. It's simply that a webpage with some <img> tiles on it is basically no RAM at all, whereas locally rendering data vectors seems to take hundreds of megabytes and be heavy on the CPU as well so you sit there waiting for it to render while the fans spin up
(and then it also shows a lot less detail, but that must just be the current beta implementations)
First, the way that the OSMF servers work is very different form typical. Most vector tile hosters generate a tileset for their area of interest and reuse that for weeks or months. So they spend a bunch of CPU once to get a clear deliverable that they serve up quickly. This is very resource efficient *for the host* because they don’t need a bunch of CPUs or GPUs to scale up with user demand. And even if you render tiles more or less on demand with a cache invalidation policy like the OSMF does, vector might end up being less load on your servers (for reasons I’ll get to in a second).
“Render” is a bit different in both cases of course too. Vector tiles “render” on the server side to the mathematical description, which is sent over to the client. Then the client transforms to pixels. For raster tiles, the server has to do the work, which means a MUCH larger server farm, but the work is re-used for all clients.
MOST devices produced today which view maps have specialized GPUs which can render a vector tile very very fast. An iPhone made in 2016 is way more efficient than a more recent desktop with some cheap intel integrated graphics card. Android devices are somewhere in the middle. So I’d actually say this is *more* efficient if most of your user base is mobile and not on the cheapest tier of Android phones.
Another factor is styling. If you want localized name display, or if your users are not all on very old displays or low end Android, then each variable (language, styling choices like which layers to show, line styling, dark variants, @2x or @3x HiDPI, etc.) multiplies the number of times you would need to render a raster tile. And this isa really clear case of where you could run something like live-ish tiles for editors OSMF-style, with fewer resources. OSM tiles look like absolute garbage with grainy text on my screen because it wouldn’t be economical to render multiple DPI variants.
Soooooooo it’s nuanced and depends quite a bit on what your priorities
I That’s basically what MVT is though (and soon MLT). It’s just an efficient binary format. Renderers like MapLibre GL JS use hardware acceleration where available, which means most phones are quite performant. Desktops and laptops it kinda depends on whether you have a discrete graphics card. On my laptop for example there is basically no energy impact. On my desktop, I can hear fans go up… but that’s also true of many websites with crappy JS too, so… 🖕L I I guess I’d have to see something resembling a fair comparison. I’m not sure I’ve ever seen an SVG with as much detail as a typical map tile. > Maybe that it needs to be parsed in JS instead of in native code I would be pretty surprised if the parsing dominates any slowness you’re seeing. JS actually gets fairly fast with JIT (what every web browser does). The majority of the work is in rendering graphics, and those are all passed off to native APIs. WebGL is just passing off to hardware. The fact that I don’t see any slowness suggest that it’s a question of GPU, not CPU. A typical map tile render does a lot more than a typical SVG so it’s hard to make an apples-to-apples comparison. Map tiles need to support a range of zoom levels, need label placement rules in case of collisions, etc… I don’t think SVG can even do this. Vector maps also (typically, but not always; I think OpenLayers is an exception) have a different text rendering path. Map labels are usually given “halos” to make them more readable, and may have different scales or other transforms. This is a different (GPU as well) path but it’s also super efficient on most hardware (after you load the textures, it all happens on-GPU). Doing this in regular font rendering stacks is clunky and significantly less efficient than the SDF technique they borrowed from the game industry. I’m quite sure these aren’t the cause of any preformance differences you’ve seen, but I bring them up to show why SVG is typically not a suitable format for electronic maps.
But middle ground approaches generally are possible. For example in OpenLayers you can mix raster and vector layers (of multiple types; even GeoJSON and I think SVG).
Or on the server side you could “thin” out the tiles by stripping all the info the user doesn’t need. Like different languages based on the accept-language header or something.
But that’s more interesting to tile hosts than OSM editors I think.
AmiriaAre there any technical reason why OSM (website, the one lives at OpenStreetMap.org) uses raster methods for drawing map other than newly emerged vector ones?
I personally think vector-based generations for planet-scaled websites and apps would be a lot more resource friendly.
What do you mean, there are at least two vector tiles on openstreetmap.org website?
Click on the layers icon and choose Shortbread or MapTiler OMT.
Or did you mean why is the default for new users who never visited the website before and changed the layer still raster Carto?
I'd say inertia for that one (and it still renders nicer and with more details IMHO).
M I'm not sure I follow - most if not all OSM editors I know do not use tiles at all, but use "vector" XML format provided via OSM API 0.6 for on specified bbox? (and for bacground layer, they usually use some aerial raster - which is not vector for obvious reason) (and I did not understand the OP to be talking about editors, but base www.openstreetmap.org "display only" website anyway?)I That depends on the type of editor. EveryDoor, a POI editor, for example does not. It uses the raster tiles. My point for this though was simply that OSM mappers often want to see their edits reflected on the map in a somewhat timely manner, and the requirements for a style used by people who edit the map is much different from MOST users of maps. OSM Carto is a great style for mappers with its information density. It’s a terrible style to show to most end users consuming OSM data. Sorry for my confusing use of “editor” 😅 I was using it to refer to both human map editors as well as software tools.
I think the Shortbread schema is extremely light on details right now. OMT has more, but note that those tiles will typically be quite a bit behind the OSM database (like days, not minutes or hours). I *think* the goal is to get Shortbread to a point where it’d be useful for editors and IIRC it also has a similar render on demand + cache + invalidate approach as the raster tiles.