So what are you suggesting, that we choose a style at random each time a user visits?
We (that is to say operations) would probably need to consult the style operators and re-evaluate them because part of the process of approving a style is assessing whether it can handle the load and part of that calculation is that styles other than the default will get much lower loads.
it is an instructive way to demonstrate the plurality of the data, we are not aiming at end users anyway, or has this changed?
The layer selector could open automatically
and once you select a layer you will not have the mess until you log out or clear the browser cache
As usual with these type of discussions, it’s likely that this quickly turns into a never-ending exchange of people’s preferences and suggested implementations/solutions.
Usually it’s way easier to agree on the problem @Wynndale wants to solve: what’s the real problem/issue, who is affecting and why it’s important. Once the problem is clear for everyone, then a more productive and easier conversation with potential solutions is likely to happen.
Yeah, there are a few diaries and maling list messages here and there, that’s why my suggestion was to try to list here all the challenges in an organized and clear way (maybe as part of the original message for readability?), since not everyone might be fully aware of all the implications of having a single by default one.
With that clear, I think it’s going to be easier to suggest potential solutions with their pros and cons, so everyone will be able to understand how this issue is affecting others than themselves.
IMHO, OP already provided a pretty good summary, which at least should get the conversation started:
What is a problem though is the idea that any one style can be “standard” when they always have to make compromises between conflicting needs.
One of the OSM carto maintainers has written a rather deep dive analysis of the current situation recently, covering history, and current status, as well as the challenges and conflicting needs this standard style faces: OpenStreetMap-Carto – an update on the project | Imagico.de (apologies, no TL;DR version available).
openstreetmap-carto is the face of OSM. Over the years, it has managed to occupy an uncanny valley. Everyone – mappers and casual end users alike – perceives the map as something primarily intended for their use case. Any omissions seem like glaring oversights rather than careful compromises. I haven’t fully digested Christoph’s blog post, but it is helpful for understanding how he thinks about the space osm-carto occupies in the ecosystem. If the post had been published some years earlier, maybe it would’ve helped to set more realistic expectations.
We like to tell laypeople that OSM is a map database, but often that flies over their heads and they don’t share our enthusiasm about contributing to one. If we simply take away the Standard layer, they may no longer mistake OSM for a map product, but they’re no closer to understanding what makes OSM such a powerful concept at first impression. If we replace the Standard layer with a browser ballot of sorts, then someone who doesn’t understand the common thread among these choices will perceive the site as basically a map gallery, which is even further from what we’re about.
I don’t think we’ll have a very satisfying solution until we get to the point where osm.org renders vector tiles on the client side. In the vector tile world, the client-server architecture is optimized for more visual variety. If someone wants a niche POI type labeled on the map that no one else wants, we can genuinely suggest a fork instead of handwaving about one like today. As long as that fork is compatible with a common tileset, server load is a nonissue. There could even be some dynamic, personalized options. It’s no panacea, but it takes some of the pressure off the designers in charge to balance all the competing interests perfectly. At least the complaints will be distributed between the client-side style maintainers and the server-side tileset maintainers.
By itself, migrating to vector tiles doesn’t fundamentally change a layperson’s impression of the project’s purpose. But a completely different-looking style could have that effect. Vector style designers already rely on an inspector or “X-ray” mode for understanding and manipulating the data within vector tiles. Similarly, OSM has long had an interactive Map Data mode, hidden away where most users wouldn’t find it. Just as well: the overlay hammers the OSM API and bogs down your browser. Most people would probably prefer to blindly click around using the Overpass-powered feature querying tool instead.
Vector tiles would let us rethink the Map Data mode. It could perform just as well as a “human-readable” map and offer much of the same information immediately on hover. It would be functional at low zoom levels (thanks to filtering), and giving it an industrial chic aesthetic would require relatively little effort. We could make it the default style or put it just one click away, similar to the satellite toggle on most map sites. This too could be the face of OSM, one that unabashedly celebrates the intricacy of our data while serving as an efficient debugging tool.
If you’re looking for a straightfoward drop-in replacement for osm-carto, I’ve got nothing. But concrete efforts are being made toward vector tile infrastructure, so that’s what I’d invest my patience in.
If something is an “important feedback mechanism” then it needs to show what people have added - and often what they’ve added simply wouldn’t be appropriate to show on a general purpose map. Attempting to render everything would result in a stylistic mess, but not doing so results in people wondering why what they’ve added doesn’t appear.
Back in the dim and distant past, OSM had two map styles - a “standard” style which looked nice, and is essentially the parent of the current OSM Carto style, and Osmarender which showed (almost) everything but looked … less nice.
A return to having two non-specialised map styles would allow OSM Carto to be whatever its maintainers want it to be, but would still give everyday OSMers the feedback that they don’t get from OSM Carto now.
I’m not convinced that a vector tiles-based solution is the answer to a “show everything” map, (at least not without an awful lot of feature consolidation, via something similar to the lua translations that cartocss styles can use - some vector approaches support this sort of thing, some don’t), but I’m happy to be proved wrong.
I also don’t believe that OSM Carto itself has “run out of road” in terms of the technical capabilities of the software it’s based on - there’s more there that hasn’t been done, including at least use of lua to do more than just calculate z-order, and osm2pgsql’s flex output. There may be reasons to not making use of those based around the way the style is deployed at osm.org, but not doing so means that some of the SQL at https://github.com/gravitystorm/openstreetmap-carto/blob/master/project.mml is way more convoluted than it needs to be, and some features simply aren’t implemented - for example the bus guideway bridge at https://www.openstreetmap.org/way/92924790 doesn’t look like a bridge, but the same feature in a style that takes advantage of lua to simplify the rendering style itself here does.
If my interpretation of imagico’s reasoning is accurate, I’d say he is mainly concerned about Mapnik as a renderer. osm2pgsql has been very actively maintained in the past years (some of which has also been sponsored by OSMF), so I’d definitely rule this one out.
quoting from imagico’s blog post:
we already outgrew the possibilities of the technical framework we were using back in 2016. This is challenging because most of the components of the framework OSM-Carto uses are not actively maintained any more and there is no open source rendering system on the horizon that could replace it.
This got me thinking that part the problem really seems to be that database re-imports are considered too difficult, time consuming and costly by the OSM carto maintainers. Fast iterations and a “fail early and often” approach to style development isn’t feasible this way. That’s somewhat unfortunate, really.
I have a limited understanding of the technicalities behind the basemap, but I wonder if eventually OSM can show a base map and then allow people to enable additional layers on top that don’t need to recreate the base map but only add the POIs and items relevant to that layer.
For example, if I’m interested in cycling and accessibility, I would just enable those 2 additional layers. The basemap developers won’t be affected by additional layers, and layer-development should be just focused on those additional items.
Probably this layered approach will require something that OSM doesn’t have yet. How are other non-OSM maps solving this same problem?
The osm.org website actually supports at least one overlay tile layer already - the “Public GPS Traces” one. An example tile is this one. The background is transparent, so you can see the tiles underneath.
Overlays work fine when you’re just displaying some coloured feature over an existing map, but if there’s text in the overlay nothing will prevent it from clashing with existing text or other features on the underlying map, so theyre not a good general solution to (say) overlaying a layer showing additional points of interest or allowing a user to choose different language text (for that, client-side controlled vector tile rendering is the way to go). If you want an example of a map with a few overlays have a look here - the LA PRoW and GPS layers have no issues, but the boundaries layer does have text on it, and you’ll be able to find places where that text does clash with other text on the main map.
That does make sense - but frankly Mapnik is pretty much “good enough” to do what most people want it to do. I’m not up to date with current OSM Carto issues but I don’t remember “we can’t do that because Mapnik” being an issue in the majority of cases.
Actually (depending on what “it” means in your comment) no. It certainly doesn’t address the original point that @Wynndale was making (about OSM not really having one standard style). It doesn’t address the “provide an important feedback mechanism” argument that I was making. It doesn’t necessarily address any issues with lack of maintenance of Mapnik, just replaces it with something else (not necessarily better).
It would provide a whole bunch of other benefits (potentially including better localisation, removal of zoom restrictions, etc.) but let’s not pretend that moving to a different map display technology is some sort of magic pixie dust that will solve all problems, including the numerous ones alluded to by the comments on this OSM Carto issue.