Busways not rendered on main openstreetmap-carto for years, PRs are ready but not accepted

General talk
, , , ,
1

Hi there. Before the introduction of highway=busway tag, bus corridors and BRTs were mapped with the good old combination of highway=service + access=no + bus=yes, which is currently rendered as expected on openstreetmap-carto.

Since the introduction of highway=busway, it is tried that openstreetmap-carto support this new relevant tagging. There’s an issue open two years ago. On the issue comments, the lead devs state that, on their opinion (my interpretation), there might be a bit of an chicken-and-egg problem, as some mappers refuse to change to the new scheme because the rendering is broken, and therefore (again, my interpretation) osm-carto developers doesn’t seem to want to add that feature to the main OSM rendering.

Now one might think that, of course, the openstreetmap-carto is a voluntary-based project and therefore people must not expect it to be fixed asap, but several solutions / PRs have been proposed, with different renderings, and have been refused (not explicitly, but with (again, my interpretation) nitpicking review until discussion stales) over this two years course.

This leads to a very broken map, and IMHO a quite ridiculous situation with floating traffic signals rendered on top of unrendered ways (example in Eindhoven, The Netherlands).

Then I decided to take my turn on trying to fix this mess and proposed a PR that renders highway=busways exactly like the old tagging did (which, although “deprecated”, is still valid and still used worldwide) thinking that this would make it being accepted quickly, but apparently I was wrong. The lead devs don’t think that this matter is relevant enough, and the PR is still unaccepted for two months.

While mappers from some european cities (for instance, Eindhoven, NL) choose to tag their bus corridors under the new scheme and thus having it hidden from the map, others, specially from “peripheral” cities but where bus corridors form a much more relevant mode of transportation (Rio de Janeiro, BR and Jakarta, ID, among others) refuse to change to this new tagging in order to have a non-broken map on the main OSM rendering (which is the one that tends to be used by more users).

So in a nutshell this post is a call to attention to this issue because I am tired of just waiting for the past two years. I even learned how to contribute with the openstreetmap-carto / writing CartoCSS etc. just to see if I could help to have it fixed, but apparently my good will on contributing was not enough. While we have a database where anyone can edit (following a set of rules, and being subject to be reverted or banned if that’s the case) the main rendering on the project website is tightly controlled by a small group of people who are not necessarily considering the importance of certain features because it might not be present in the city where they live. Of course the OpenStreetMap project is much bigger than a rendering, but we are talking about the main rendering, the one that is presented to most users, the newbie ones, the visitors etc. And again, this is not about rendering a random amenity POI, but rather a important highway=* feature, while all other highways classes are rendered virtually on every render out there, including the main one.

Phew, out of my chest. Your opinions are very much welcome.

17 Likes
2

Various OSM Carto contributors and maintainers are inactive or barely active for various reasons and sadly I do not have some nice solutions for that could be readily applied.

Sadly it is not so bad - because that would be relatively easy to fix.

1 Like
4

We have been using highway=busway in the Netherlands for a long time now. highway=busway is already supported in all other software we use. I encourage all local communities to do the same. If Carto maintainers do not care about Carto rendering being broken, then neither should you.

6 Likes
5

The reluctance of the Carto volunteers in this case clearly leads to a broken map. Busways are very present in the environment, but show up as blank spots on the map. I’d see it as a bug, but the Carto volunteers don’t. They also seem to deny that busways have been approved almost 2 years ago and seem to prefer the old-style tagging.

If they don’t want busways on their own map, that’s fine. But even though it’s a third-party layer it shows up as “Standard” on osm.org, which makes many mappers think that this map style follows OSM standards.

Would it be possible to fork OSM Carto and render approved features like busways on osm.org? This way the standard map style could get rid of an extra layer of people that can veto approved features on osm.org. And the Carto volunteers can still choose whatever they want on their map.

1 Like
6

Yes (compare with here).

It “just” needs someone to host it.

4 Likes
7

A quick update: there has been a new layer released on openstreetmap.org called “Tracestack Topo”, and this one includes busways rendering. It is now my default layer. I wonder if at some point it will take “Standard” (i.e. Carto) position and be the default layer for osm webite visitors.

[]s

2 Likes
8

A bit off topic…
Sadly, type=boundary boundary=forest relations for my countries state forestry boundaries not rendered on the new “Tracestack Topo” layer

9

That’s not entirely surprising, for a couple of reasons. One is that there is not much use of that tag yet. Another is that if a style does decide to process them, what does it process them as? When I looked at usage, there was often some other landuse also used. I ended up with this, but that works only because that map style already has a concept of “different tree-covered areas within a larger forestry area” which most other OSM-based maps don’t handle.

(and apologies for continuing the off-topic - happy to continue the discussion elsewhere)