OSM Carto maintainers refusing to render approved `highway=busway`

The funny is, commercial co’s like Komoot use the OSM data (and I know because they specifically pointed me here to correct a few ways on their map), then if you want the access to the hiking map render you have to pay them 59.99 Euro annually plus buy maps ‘per (Italian) region’. The ‘for free’ data is a little too free. Maybe these data consumers could be approached for a little sponsoring.


As much as I appreciate the idea, this should be raised in the OSMF forum page / mailing list and seems out of scope for this topic.


I think you are underestimating just how ripe the situation for a sufficiently motivated community organizer to provide a viable alternative to osm-carto that the OSMF could designate as a replacement. You are also overestimating what is required. You don’t need to set up a rendering pipeline, you just need to have a viable alternative software implementation and team of maintainers that the OSMF/OWG could choose to switch the standard tile layer to.

Richard has absolutely hit the nail on the head - osm-carto is no longer a cooperative community project where decisions are made through consensus but rather one under the control of a single decision-maker. The fact that the single decision-maker thinks the reverse is true is a shocking contrast to the diverse list of major project contributors that seem to agree with Richard (based on his comment’s reactions list).

In the last year or so we’ve seen two osm-carto maintainers quit outright. Another maintainer in this thread, who we all owe a debt of gratitude for his work on the project, is practically single-handedly keeping the project afloat technically despite lamenting that he no longer finds joy in the role. The repository owner rarely interacts with the project anymore. The switch to the flex back-end, which saw a talk at State of the Map US this summer, is effectively dead due to lack of maintainer support. This blocks technical advances such as support for route relations and thus highway shields.

I agree that osm-carto is built on a technology stack that is effectively obsolete in 2023, and anyone starting a new map project should probably work off a vector stack. Now that it’s possible to run a planet-scale vector tile server for pennies, it would be imprudent for a community project to choose a raster stack without a strong technical reason.

I’m not terribly interested in organizing a team to manage a global style, since I’ve been focusing my efforts on enabling the amazing team we have working on the Americana style. Open-source American-flavored cartography is way behind other global and regional styles and it’s important to my national mapping community that we have an outlet for expressing distinctly American concepts on the map. However, I recognize that there are people that care deeply about the map that appears by default on OpenStreetMap’s web presence and I’d like to point out that they have a path to make things better.

osm-carto has one distinct advantage that makes it ripe to fork and continue advancing as the face of OpenStreetMap: it’s basically complete. So if you, or a sufficiently motivated group, were to come together with the goal and vision of having a standard tile layer that represents the whole community rather than the whims of a single maintainer, here’s your recipe:

  1. You make a fork of osm-carto, and preferably stick it in an organization space so it’s not under one maintainer’s personal github space. (This was a mistake I made in starting Americana; we are just now working to migrate to an organization space).
  2. You build a team and clearly define the values and purpose of your osm-carto alternative in order to address the social and organizational problems that have so clearly plagued the original project.
  3. At first, you keep the fork “tight” and to the extent possible merge in upstream changes. This way you’re only having to manage the differences between the core project and community expectations. So at first it’s something like “osm-carto plus busways and shrubbery” or whatever set of features people think are hung up.
  4. You petition the foundation to use your software as the standard tile layer. In other words, you don’t need to set up a new build pipeline, you just position your flavor to be shovel-ready as the style for use in the pipeline that already exists. It’s likely a one-line change in the existing scripts that deploy osm-carto to osm.org.

The “tight fork” approach I’ve outlined avoids having to build a style from scratch and also doesn’t require you to set up your own rendering pipeline. It’s an social and organizational problem, not a technical one.


First off, credit where it’s due: I appreciate @imagico’s prompt response to my concerns about his fork. In case anyone is wondering, he isn’t participating here because of a disagreement about how the forum is run, which is his prerogative; everyone has the right to choose which communities they participate in. That said, having seen a fair number of OSM Carto enhancement requests end in a stalemate, I share this sense of cognitive dissonance:

A true open-source project is indeed a community. Fostering and sustaining a community requires people skills like empathy, humility, and pragmatism, coupled with a shared vision. All the technical and artistic excellence in the world cannot salvage a community that lacks these qualities.

Sometimes it’s as simple as expressing concerns using the “Comment” option, instead of the “Request changes” option that acts as a senatorial hold on the proposal, in order to give other maintainers the space to disagree. Other times, maintainers hold a well-justified view that contradicts the prevailing outsider view, and it’s up to the maintainers to proactively promote their viewpoint before the wider community, speaking with one voice.

Like probably every other open-source maintainer participating in this thread, I’ve struggled to hone these important skills and put them into practice over the years. The hardest – and best – piece of advice I ever received was that I needed to let go a bit and let others make mistakes and learn from them. A maintainer influences the product not only through direct contributions but also by setting the right environment, laying out a path for others to contribute code of high quality, either spontaneously or with some handholding. This requires sacrificing time, energy, and pride. That’s a lot to ask for in a person, but fortunately there are good role models in the OSM community to look up to.

You know, it’s funny how a feature request like that can really take off. OSM Americana owes its existence in large part to the difficulty of overcoming skepticism about a feature that, on its face, seemed like it would look ugly and only benefit one part of the world. We could have forked OSM Carto, but instead we took a more experimental approach with an unabashedly regional artistic vision.

That vision is hilariously incomplete, but it has brought together a community of varied interests and backgrounds to cook a mean stone soup while having some fun. What we initially thought of as a regional need turned out to have global relevance. The expressions of appreciation from mappers and map users around the world has been very gratifying and validating for this very small, very nascent project. Maybe this is a little bit of the joy that OSM Carto contributors miss.


So, given this perpetuated situation since at least when I started mapping actively in 2020, noting large swats of landscape not showing though mapped and wiki supported, what is a good and readily available selection for JOSM? Preferably one that has a high tile refresh rate as now when I set Carto standard to see what has not been mapped often get a blank when the day before area parts of what’s viewed was mapped ending up with double mappings at times (my fault not refetching the data).

If there’s a link that I can add per that “new default entries can be added in the wiki” which I read as “add to wiki and it will show up here too.” Little doubt if there were they’ve already been, but who knows.


That basically means choosing between a “mapper feedback” style and a “nice-looking general style”. OSM Carto tries to do both and doesn’t succeed; whichever purpose this new style chooses still leaves the other lacking.


Is www.openstreetmap.org a mirror for contributors or a showcase for the benefit of the rest of the world?


I noticed that a ‘busway’ I tagged recently completely failed to render in the default OSM view (that’s Carto, right?)

The only reason chose the tag was because it seemed by far the most appropriate one on offer in the drop-down menus in the default OSM browser editor (that’s ID, right?)

Regardless of all the issues stated above (I confess I scrolled through most without reading), it’s stoopid to offer default tags which don’t render by default :sweat_smile:
Either support the tag, or don’t offer it for people to use.
If this situation happened for lots of tags, it would badly damage the usefulness of the map.


Of the 6 map styles at OpenStreetMAp.org, it does render in Cyclosm and the Humanitarian style. It also renders in this style (disclaimer - mine) that I use as a general-purpose replacement for OSM Carto.

Actually, at least 9 different map styles explicitly handle that tag, and that doesn’t include those projects that haven’t advertised what tags they use.


That’s all very well, but (whilst I don’t have access to any kinda of analytics data for OSM websites),
would bet £5 that over 95% of users only ever look at the default OSM map style.

When people go to a website that don’t expect it to be broken by default and only work if you click on extra options.


Actually, I’d have thought that the “most popular rendering of OSM data” these days is one of Apple, Bing, Mapbox, Meta/Facebook/Instagram or Snap.


There are different kinds of mapper feedback. Sometimes mappers want the instant gratification of knowing they successfully added something to the database. A rough-around-the-edges style like Osmarender or a raw debugging style like the OpenMapTiles inspector can easily satisfy this need with negligible consideration given to design. Other times, the mapper wants to know that their mapping is making it all the way to a realistic, consumer-facing map. This is where the craft of visual design matters most, but also where there should be the widest range of options to choose from.

Sometimes the mapper just needs to know they haven’t horribly broken the map, and either will do. The other day, someone broke one of the Great Lakes. (It happens all the time.) If OSM Carto would’ve rerendered at low zoom levels in a timely fashion, the mapper could’ve more quickly seen their mistake. Fortunately, another astute mapper found and fixed the error within a couple hours, but not before it made it into fast-updating data consumers like OSM Americana and Wikimedia Maps:

Thanks to a new shoestring rendering server, OSM Americana fixed itself later that day, but artifacts remained on Wikimedia Maps for several days (even after clearing the local cache):

Americana is happy to serve as an end-to-end test for OSM data, but as any software developer knows, this kind of testing is a last resort. Something that makes it to this stage has a larger blast radius: OSM has long been the butt of jokes among Wikipedia’s editors and readers because we occasionally pull the drain plug on one of the Great Lakes.

Americana’s maintainers do consider mapper feedback to be a goal, but at a higher level than quality control. Would rendering a particular tag support the community’s stated desire to see some feature or attribute depicted on a transportation map? If the tagging scheme or tile schema doesn’t facilitate a treatment that’s reasonably consistent with our artistic direction, we collaborate with the local mapping community on a solution, or at least we document what we see as actionable requirements, so that someone else can come up with a solution upstream. If we consider something out of scope for the project, at least we’ve tried to make it easier to someone to stand up their own viable fork.

Americana is not the only data consumer that operates at this level. StreetComplete is another great example of a project that deeply cares about its relationship with the OSM community, and there are plenty more at the local level.

Feedback means little unless it’s part of a feedback loop in which users and mappers also have some influence over the state of affairs. Many of us were drawn to OpenStreetMap because we felt that proprietary mapping platforms were unresponsive to our feedback and even less responsive to our ideas that didn’t fit inside their feedback forms. It’s wonderful that OSM Carto can more or less provide mapper feedback at the level of raw data (new road opened!), but this thread exposes the perception that this feedback loop has become dysfunctional at the editorial level.


Well this may be not wrong.
And if there were a bunch of tags which are on the ID autocomplete choices, and which don’t render in them, I’d strongly argue that ought to be fixed too :smile:

So are you suggesting that:

  • iD doesn’t offer tag presets for things that don’t appear in all or most popular maps


  • those popular maps should render everything in iD’s presets?

The second of those is problematical because many popular maps are thematic (transport, cycling, roads for cars, etc.) and it really doesn’t make sense to show things that don’t fit that theme - a road map only shows enough non-road detail so that the user has a bit of context; to show more would clutter the map and make it less good as a road map.

The first of those is equally problematic because it means that the wealth of detail that differentiates OSM from other maps simply couldn’t be entered with iD, and the thematic maps that use that dtaa would be much poorer as a result.


Yes I take your general point.
(Although I don’t think it has much practical bearing on the ‘busway’ tag in Carto, tbh) -
Maybe in general, the iD editor could offer some kind of indication of tag support? There’s an ‘info’ button with a line or two of helpful into for the majority of tags, maybe something could be made to display there?

This could promote tagging for the renderer though. In essence, an unintended side effect might be that mappers use “incorrect” tags simply because they are supported by a particular renderer (in this case Carto) whereas the “correct” tags are not.

Edit: it’s also worth noting that the info button shows the wiki link to the tag. Normally on that page there’ll be useful documentation, the status of the tag, as well as the number of times the tag has been used. Which is perhaps more important than whether some renderer has chosen to show it on their map.

1 Like

Perhaps - although that information for some styles is only a few clicks away. From iD the link in the info takes you to the wiki. There’s a link there to taginfo, and projects lists the projects that support it and advertise the fact.

Unfortunately “OSM Carto” isn’t one of the projects that lists the tags used in that way. See issues here (closed in 2017) and here (closed as completed because “too hard” in 2022), so your point about “how do we know what tags OSM Carto uses” is very much still valid.

1 Like

I think to be honest,
in general, most editors will have an understanding that there are various different renderers, with various different mapping intentions and emphases, and so not every tag is rendered on every map - and as you point out, more info about that is readily found on the OSM wiki for those who are interested.

We should not let that distract us from this particular specific gripe about Carto and busways :smile:
Like most renderers, Carto ‘shows all the roads’ so it just looks weird when busways are mysteriously left out. It was a reasonable request to ask for this to be fixed.


Speaking as an ex-Board member here. The Board has consistently taken the policy position that the Foundation should seek to ensure an open-source pathway for entering and doing QC on data for the geospatial database (supporting iD, for example, as well as Nominatim and Potlatch) but should leave map rendering to the doocracy and commercial ecosystem. That is why appealing to the OSMF Board of Directors for funding to generate an actual map – a downstream visual rendering of the data – is likely to fall on deaf ears.


Discussions of the OpenStreetMap Foundation’s role have often turned to discussing what is core. To build its strategy on firm ground, the Board has sought to improve that definition and offers the following:

The core is the mapping process.

That is a new way to define core, functionally rather than technically.

So, we now have two complementary definitions:

  • Technical core: rock bottom, without which OpenStreetMap disappears. Mostly the database and its API.
  • Functional Core: The Mapping Process.

Part of the OpenStreetMap Foundation’s mission is to ensure that there is at least one fully Free and Open Source Software path to complete the OpenStreetMap mapping process. Decisions about what software to support will follow directly from this.


If the board wishes to reconfirm this standpoint every time someone brings this up (or if former board members like @amapanda_ᚐᚋᚐᚅᚇᚐ and you wish to defensively point out that everyone can just fix it themselves), and conclude that leaving gaps and bugs on the default layer shown on openstreetmap.org is totally acceptable, than that is their prerogative.

It won’t stop people asking why this cannot be fixed, and it won’t make the issue magically go away. It also won’t stop issues like this from harming the project; something I would hope does fall within the scope of what the OSMF is willing to deal with, or at least quantify as a risk.

Something is broken here, and it is not just the lack of highway=busway rendering. Regardless of whether it is a process, governance, or some other factor, it highlights an issue that cannot be reasonable expected to be fixed by any one contributor.