Add retina support

[ponychicken]

No description provided.

[tmcw]

This could use a bit more description.

As far as the maps, I think it's a pretty long-term task; retina maps are not easy to do nor host.

As far as graphics, there aren't many retina/non-retina assets right now - when we start working on a sprite, I think it makes sense to do a high-DPI version, but there's no sprite as of yet.

Also, a high-DPI OSM logo would make sense, I suppose, but I don't think it makes sense right now - the logo should go in the sprite anyway.

[ponychicken]

Adding support to OpenLayers shouldn't be too hard. Hosting costs are a different thing of course.

On Friday, 21 September 2012 at 16:36, Tom MacWright wrote:

This could use a bit more description.
As far as the maps, I think it's a pretty long-term task; retina maps are not easy to do nor host.
As far as graphics, there aren't many retina/non-retina assets right now - when we start working on a sprite, I think it makes sense to do a high-DPI version, but there's no sprite as of yet.
Also, a high-DPI OSM logo would make sense, I suppose, but I don't think it makes sense right now - the logo should go in the sprite anyway.

—
Reply to this email directly or view it on GitHub (#104 (comment)).

[tomhughes]

Note that the SVG for the logo is in the repository, so it's easy to render a version at higher dpi.

[tmcw]

Adding support to OpenLayers shouldn't be too hard. Hosting costs are a different thing of course.

No, it should and it will. This would necessitate serving 4x as many tiles (and thus as much bandwidth), redesigning the OSM style to work with a different scale factor (which would likely result in a duplicate set of icons, for which we only have bitmaps).

[tomhughes]

Changes to OpenLayers are, of course, out of scope for this issue tracker.

I would also repeat my normal caution about OpenStreeMap being primarily about producing data rather than about displaying a pretty picture to casual visitors, so it's unclear whether the significant extra costs of providing higher DPI tiles would be worthwhile within the context of our core mission. Ultimately that's a decision for the project as a whole though, and for OSMF as the people that would have to find the resources.

[mackerski]

In the year that has passed, a lot more hi-dpi devices exist including many laptops. Key site assets (like the logo, as mentioned) would be cheap to convert and host and would improve the browsing experience for users of relevant devices. The map tiles remain a problem, though. Also: don't most modern browsers support direct presentation of SVG (which would work for site assets anyway)?

[tomhughes]

You know where the repository is - if you want retina versions of anything then nobody's stopping you. Talking about it endlessly will however achieve nothing.

[jeisenbe]

Now in the 2020s the majority of screens are moving to 2x resolution. I believe all new smartphones and most desktop and laptop screens are at the higher resolution.

Most of the issues with the map styles have been resolved, see e.g. gravitystorm/openstreetmap-carto#2038 and

Is the additional cost of hosting retina tiles still a prohibitive issue?

Are there other issues that would need to be resolved?

[tomhughes]

We're not going to be hosting a second set of bitmap tiles - the solution is vector tiles so if you want retina tiles then help out with that.

[jeisenbe]

At some point would it make sense to switch to only retina tiles for the raster style? Do we have data about the percentage of openstreetmap.org visitors who are currently using devices with high DPI screens? If at some point the percentage has reached >90% perhaps it would make sense to only serve high DPI tiles.

My understanding is that the vector tiles would be an additional option rather than a replacement.

[tomhughes]

No once we have a vector tile solution raster tiles will be dropped in an instant - we might still serve them but they will be rendered on demand so we can render at whatever resolution the client requires.

[mwoehlke-kitware]

So... late to the conversation, but I was also just being bothered by this. TBH, though, I'd be ecstatic if OSM would just serve tiles at twice the resolution; no additional hosting costs required. The tiles look great when I zoom out one step and the higher-resolution tiles are being shown at actual 1:1 resolution, before the lower resolution tiles load and replace them. True, this wouldn't work for everyone because the text would be too small in some cases, but in some instances it would be an instant and inexpensive improvement.

[robertpiosik]

@tomhughes I'd like to point out that information density on vector maps is very poor compared to server-rendered raster counterparts.

[Redsandro]

Yes, OpenStreetMap's Mapnik should be configured to use high resolution tiles by default. I'm not sure why after ten years this is still not enabled.

Ah I just learned it is to save on resources. If you transfer all graphics on the internet in half resolution, you can send four times as much graphics for the same bandwidth. 🤔

Apple Maps:

Google Maps:

MapQuest:

Here WeGo:

OpenStreetMaps.org:

This is not manipulated. These are screenshots from my UHD screen.

[gravitystorm]

I'm going to close this issue for various reasons:

• This site supports high-dpi map tiles, and has done for many years. You can see this on the "Cycle Map" and "Transport" layers, for example.
• The lack of support for high-dpi tiles from other providers will be solved by engaging with those providers directly, not by discussing it here. If you want the OSMF to serve high-dpi tiles, then that's a problem they need to solve (and let me be clear - everyone involved with both operating the servers and developing the stylesheets knows all about this, so please don't pester them - help them, yes, but please don't just pester).
• When a specific provider has high-dpi tiles available, please open a request for us to enable them for that layer. Until then, there's nothing that we can do within this repo.
• There are some low-dpi images used in various places around the site (for example, the banner image on the copyright page). I'm keen to see those updated to have high-dpi variants, although it's not a current priority for the team. If you want to work on these assets (see the app/assets/images directory) please feel free to discuss these in separate issues.

I'm happy to clarify any of the above points.

[Redsandro]

My first interaction on the entire repo and I get the issue closed. 😅

Apologies. In hindsight, upon learning the amount of parties involved, I can understand how these comments can be frustrating.

On the other hand, to the observer it is as simple as (1) go to OSM, (2) observe low-DPI tiles by default, (3) find this open issue through Google, (4) see no passionate effort redirecting the attention to where it should be headed, and (5) misinterpret that as relevant people being unaware. Perhaps the knowledge deficit between developers and observers causes the disconnect.

I'm happy to clarify any of the above points.

@gravitystorm could you clarify point number two in relation to the default OSM map behavior described above, so the next person who is brought to this closed issue (and I) can understand the problem better?

Along the lines of: This website uses provider X for the default tiles, and they cannot provide High-DPI tiles because of reason Y, which is discussed in issue Z, where they need help with V?

[mwoehlke-kitware]

The lack of support for high-dpi tiles from other providers will be solved by engaging with those providers directly

I'm happy to clarify any of the above points.

Okay. Please clarify; who are we supposed to "engage with" w.r.t. the standard layer? What non-OSM provider is responsible for that?

[tomhughes]

The operations group are responsible for the technical infrastructure behind the standard layer, so https://github.com/openstreetmap/operations/issues would be the place. That said their position with regard to the standard layer has already been made clear in this ticket as I am both a developer here and a member of the operations team.

I'm not totally sure but it might well be that changes would be needed to the style as well, which would be a matter for https://github.com/gravitystorm/openstreetmap-carto/issues but as we don't have the resources to host a second set of bitmap tiles spending time fixing and style issues is probably pointless.

As we've said repeatedly if people want to help then sorting out a vector tiles solution is the way to go but many people have started down that route in the past...

[gravitystorm]

My first interaction on the entire repo and I get the issue closed. sweat_smile

No worries! It wasn't your comment in particular - when I looked back at the previous comments I realised it was worth stepping in.

Along the lines of: This website uses provider X for the default tiles, and they cannot provide High-DPI tiles because of reason Y, which is discussed in issue Z, where they need help with V?

This website uses tiles provided by the OpenStreetMap Foundation (specifically, a service run by the OSMF Operations Working Group) to provide tiles for the default layer (the "Standard" layer). They cannot provide High-DPI tiles because their current infrastructure does not easily support doing so. Specifically, the mod_tile-based infrastructure works on a query-then-render-then-store-then-serve basis (note store, not cache, which is a subtle but important difference), which has big implications for disk space used on the tile servers, in addition to the overheads of fully rendering everything twice.

They need help in developing alternative infrastructure, which will likely involve either rendering on-the-fly from vector tiles (i.e. still delivering rasters, but only storing the underlying vector tiles, which saves storing lots of rasters) or perhaps client-side rendering directly from vector tiles. The decisions involved in choosing the solution are complex, since they have implications for cost, cartography, server infrastructure (e.g. changing the needs between powerful database servers, adding lightweight rendering servers, using object stores for vector storage, etc), software choices and further software development, and then the operational overhead of doing so at scale, which can rule out options that are otherwise used in smaller scale setups.

The old adage of "if it was easy, it would have been done already" clearly applies.

In the time I was writing this @tomhughes has also replied, so I hope between these two comments you get enough of the background!

[Redsandro]

I appreciate you taking the time to explain this in such detail. If I understand correctly, this project is for the website UX/accounts, and it depends on the Mapnik project for editing, the OSMF project for providing the tiles, and the LeafletJS project for drawing the OSMF tiles on screen. High-DPI tiles cannot be provided at the source because it is a complex and resource-hungry process.

At the risk of forgetting something important, can I propose this website adds a "Standard 2x" layer that people can choose, a special mode for high-DPI fans who prefer a crisp map over larger street names? It is not ideal with the small names, but neither is a low-DPI map on a high-DPI screen.

The layer can be constructed with the existing tiles at half their size by using the tileSize and zoomOffset options like so:

tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
    tileSize: 128,
    zoomOffset: 1
})

Standard:

Standard 2x:

It's very pleasant to look at on a high-DPI screen, especially when you care more about the lay than the name of the land.

I'm getting ahead of myself a little here, but you can also choose to add it as a toggle, so it can optionally apply to other layers who's map tile sources were painstakingly set up in the "low-DPI era" as well.

[Redsandro]

Fiddle (The drawbacks are free, but you'll only see the benefits on a high DPI screen.)

[robertpiosik]

From my point of view, allowing users to turn to a mode of unreadable labels is bad. Really bad. What's the point of such a map then?

If you want to have unreadable map with sharp edges on your end you could tap cmd - / ctrl - couple of times and achieve the same effect you're proposing.

It is so unfortunate that offering a short living map tiles is such a resource hungry task...