show the whatevermap as default until the user chooses a style.
show the whatevermap as default until the user chooses a style.
I was actually looking for serious suggestions…
it is a serious suggestion, (provided we could find a few tile providers that are ok with the usage, or maybe could be compensated at fair rates)
Even if we could, what kind of image does it present if every visitor is presented with a mess of incompatible tiles?
It hardly makes us look like a serious organisation does it…
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
My 2 cents.
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.
I believe everyone here should be quite familiar with the implications and challenges of having a single “by default” map style. If you want to learn more, I’d highly recommend to read this blog post, and in particular the comments & links mentioned in there: Cristoffs's Diary | Openstreetmap-Carto – Democracy Or anarchy? | OpenStreetMap
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).
For convenience, this post was crossposted here on talk.
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.
There are some good points above, but I think one of the biggest problems is that the goals set out in https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md actually contradict one another.
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.
I don’t think there are any technical reasons which would inhibit a deployment of a osm2pgsql flex based rendering style. Again, there are issues on another level according to Use flex backend by pnorman · Pull Request #4431 · gravitystorm/openstreetmap-carto · GitHub, which seems to be about limited adaptability.
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.
Yes what it requires is vector tiles, which requires people to stop talking endlessly for years and years and years and actually develop a vector style to replace the current style.
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.
I was replying to @nukeador’s comment, which makes clear that “it” refers to the idea of multiple layers, which is much easier with vector tiles and client side rendering where you can customise what is rendered for each viewer.
I can’t find a way to edit my original post (or add tags) so I’d better say that Cristoffs’s diary and the Imagico blog (especially the triangle) as linked above are key reading. While there is the alternative approach of trying to solve problems by governance as was done with iD, it doesn’t raise the profile of alternatives, which is less serious for iD as other editors are well enough known. A building block for something like this could be infrastructural support like tile servers or vector tiles.