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

[ZeLonewolf (Brian M Sperlongano)]

@JeroenHoek

You know that this is not a viable suggestion without backup from either the OSMF or the website maintainers (and that is expressing it politely). Forking Carto is easy (just one button to click), actually getting the technical support needed to get a rendering pipeline set up and have it hosted on OpenStreetMap.org? That is understandably beyond what most single contributors here can do.

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.