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.

19 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

5 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

1 Like
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)

10

Thanks for posting this @Nighto - It does indeed appear chicken and egg and I have reverted from bus way back to service road for this case. The simplest approach would be to have a standard service road dotted as no access so really no change there then so that busways can be added and there is groundswell for the PRs can gain traction.

11

I would be interested in whether openstreetmap-carto would opt into the Software dispute resolution panel - OpenStreetMap Wiki.

Edited to add: I appreciate that this is a big suggestion, so here’s my rationale.

As I understand it, the dispute is basically:

  • carto maintainers do not wish to add rendering of highway=busway until most of usages of highway=service for busways are migrated to the new tags
  • community does not wish to migrate existing usages of highway=service for busways to highway=busway until the new tag is rendered
  • this is a chicken and egg situation to which I don’t see a possible resolution other than one side being overruled
5 Likes
12

I think the second half of the sentence might not even be necessary:

I’m somewhat surprise nobody has written an OSM-Carto Controversial Decisions wiki page yet to match iD Controversial Decisions. Edit: It does already exist and the link now redirects.

1 Like
13

I don’t think this is accurate. The split tagging usage is an issue, but a design concept for highway=busway was recently discussed, without opposition to the basic idea of rendering this tagging. Unfortunately the discussion (like many others) petered out. And this wasn’t even a PR (which some brave and determined soul needs to volunteer).

Realistically Carto is always going to be a tough nut to crack, not least because any solution also needs to simultaneously address the old highway=bus_guideway rendering.

1 Like
14

imagico’s comments in March are not what I would consider without opposition to the basic idea: they write “There is nothing any of the maintainers here has against displaying bus exclusive roads if there is clear agreement among mappers on how to map those.” but their criteria for clear agreement, per this comment, is retagging: “pointers to changes in mapping practice if and when they happen.”

Perfect is the enemy of good. We don’t need to simultaneously address anything. Render busway the exact same way as highway=service+access=no. Then things will start being retagged where appropriate. Then you can fix any imperfections. And you’re anyway having imperfections now, with floating traffic lights because retagged busways aren’t being rendered…

6 Likes
15

This was done in my PR (contributed three years ago).

This is done in the other PR.

Just use highway=busway and accept that our project’s frontpage has a broken renderer. A fair number of contributors have put in plenty of time and effort to solve this — OSMF knows this is an issue too, but effectively declines to get involved — but it’s not going to happen until one of the few remaining maintainers of Carto decide they want it, or Carto gets replaced.

So don’t waste your time. You’ll only get scolded even if you mean well and come with a convincing set of arguments. Point people to OsmAnd and OrganicMaps; those are the better showcases for OpenStreetMap, and on openstreetmap.org Tracestrack Topo does render them.

Don’t tag for the renderer.

17 Likes
16

Paul Norman is developing a vector tile-based system to replace Mapnik based rendering, which will make OSM-Carto obsolete as well.

4 Likes
17

I agree, and this was part of my logic for suggesting the Software Dispute Resolution Panel.

As I understand it, the SDRP came about because people were pretty unhappy with iD’s project decisions coupled with its prominence as the default editor on osm.org. Because it’s one thing if Jarek’s Obscure Editor suggests bad tagging, and another thing if the web app at OpenStreetMap.org/edit does.

We can and should point people to other apps and layers, but it is also the case that OpenStreetMap.org, and carto and iD as the default choices on that, are many people’s introduction to OSM and colour their views.

Otherwise it’s a bit strange to be saying “use apps that have OpenStreetMap data but not OpenStreetMap.org because that doesn’t represent OpenStreetMap well”.

I would prefer not to feel compelled to append &layers=P every time I create a link to osm.org.

2 Likes
18

If you suggest that on Carto’s Github repo, I’ll get my :popcorn: ready.

4 Likes
19

Save me some, please!

20

By the way, imagico has a point that busway is not used consistently (I put the comment on github):

From the wiki, the following:

  • Bus-only service roads
  • Bus-only motorway links
  • Physically-separated bus bypass lanes
    seemto be quite widely tagged as highway=busway.

Frankly I do not understand the rationale for these not being included in the definition. I am not sure if people expected highway=busway to be rendered differently from other roads - I think it would make sense to render them as any other roads inaccessible to cars and render BRT more on relations (because those should have the same visibility as for example metro lines when zoomed out, but based on the primary tag alone, one cannot do that).

21

<sarcasm>

Sounds like an excellent reason to not render anything (despite the fact that every use is at the very least a road exclusively for buses) until that is all sorted out.

I really hope Carto stops rendering building=* soon as well until all ambiguity is sorted there. It is massively abused. I mean, what do people even mean by ‘building’?

</sarcasm>

12 Likes