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

The tag highway=busway was approved years ago. The OSM Carto maintainers refuse to support it, despite several pull requests (1, 2). For good or bad, OSM Carto is the OpenStreetMap map (sic). OSM Carto is not a private rendering to satisfy the maintainer’s ideas of tagging. Therefore, the maintainer‘s reservations about the community-approved highway=busway tag should not hold back the map.

I request the OSM foundation overrides the maintainers in accepting a pull request to render highway=busway. If this is not the correct venue to contact the OSM foundation on this matter, let me know which one is.

13 Likes

The OSMF doesn’t have the power to override the maintainers of a project. OpenStreetMap Carto gets no money or other support from the foundation.

As a maintainer, the one of the issues is a lack of maintainer time and energy. There are a few causes, but at least in my case, working on OpenStreetMap Carto stopped being interesting and fun and became a necessary duty some time ago. This is for a few reasons including what I view as a tech stack past it’s best-by date, user requests in conflict with the unclear goals of the style, and slow internal processes.

8 Likes

You may be underestimating how much time you need to properly test and review such pull request.

Not sure whether anyone tested latest version of either with full fun of layering, bridge/tunnel styling, unpaved styling, crossings with various road types etc.

For discussion on PR: noone responded to Render highway=busway as highway=service + access=no by nighto · Pull Request #4714 · gravitystorm/openstreetmap-carto · GitHub in #4714 one

For #4456 it appears that Render highway=busway by jdhoek · Pull Request #4456 · gravitystorm/openstreetmap-carto · GitHub is not resolved

I would strongly suggest to handle this before making suggestions like this one. I would do either of them if I would strongly care about highway=busway rendering.

Also, note that this would be need to addressed by someone also in case when you suggestion would be followed. The same goes for doing testing mentioned above.

that would be really extreme precedence, and OSMF has no power to do this (and no technical measures), and in my opinion it would be a poor idea for multiple reasons

If you would care solely about highway=busway rendering then it would require creating a fork of OSM Carto and maintaining it (or using completely abandoned style), and using it on OSMF tile servers instead of OSM Carto.

And I strongly feel that it would not be a good idea for many reasons. For start, it would basically kill OSM Carto entirely. And I doubt whether you would find people to run it in the first place.

See Contact - OpenStreetMap Foundation

Though I expect that you would get very similar reply.

(this entire comment is not OSMF board statement, just my personal views on that)

11 Likes

Not sure whether anyone tested latest version of either with full fun of layering, bridge/tunnel styling, unpaved styling, crossings with various road types etc.

right now, not only the bridges and tunnels are missing or buggy but all of the busway is missing, including all of its tunnels and bridges, which is not hypothetical but real, so this argument doesn’t seem very strong.

3 Likes

I suspect the solution to this problem is to make it not that, partially because:

To be clear for those who are not aware, the problem is here - it’s simply not possible to be “the main feedback mechanism” and “an exemplar stylesheet for rendering OSM data”. There are some things that it makes absolutely no sense to render on a general map, so there needs to be something else that can provide feedback on those.

In the specific case of highway=busway I added support for that to a fork of OSM Carto a couple of years ago. The technical change didn’t take long; the research into how the tag was used took longer (but still not very long). This was despite me not thinking that the tag was a good idea.

It’s entirely reasonable for the maintainers of a particular style to not render a certain tag because they believe it doesn’t meet their goals for inclusion. After that, it’s an OSMF + OSMF Working Group decision to decide which style(s) get featured on osm.org, and (most importantly) get the benefits of OSMF’s CDN.

Looking forward (and somewhat offtopic from this specific request) it’s surely likely to be some sort of vector tile style(s) that become “the next face of OSM”. These typically split “what tags we care about” (like this schema) from “what it looks like” (see for example here)**. I’m not yet sure how the “tags that we care about” can be trivially expanded to include the next highway=busway without causing problems for the users of that schema.

** my fork of OSM Carto has done that since around 2014; so do many other styles.

13 Likes

In software development adding buggy unfinished or untested features to patch hole of missing feature is considered as a big mistake and bad idea.

In open source development additional effect is that typically single time contributor will be not spending extra time to fix bugs once pull request with feature they wanted is merged.

2 Likes

What I hear here is:

  • OSM Carto is maintained by volunteers, it’s time consuming and not very attractive to contribute to anymore.
  • Some elements are not prioritized on OSM Carto to be included.
  • OSM Carto is central to OSM since it’s the default layer.
  • People have been asking for a more modern (vector-based) layer for a long time.

This feels like an opportunity for OSMF to take a decision on the level of control they want over the main OSM layer.

  • Is this an opportunity to fund (or hire) OSM Carto development?
  • Is this an opportunity to fund a OSM Carto fork to add/change some behaviors to be more aligned with what most OSM users need?
  • Is this an opportunity to fund/hire someone to develop a new vector-based layer that includes most elements people would expect from a modern map?
21 Likes

From my naive perspective: maintaining the iD editor is funded, so it seems a little odd that maintenance of Carto isn’t. Both are the “main” elements used to interact with OSM data on osm.org.

That being said, I don’t think it would actually “solve” this particular issue. A paid maintainer may still decline to render a tag and some in the community may disagree with that. Unless there was some mechanism included with a paid maintainer to overturn the maintainer’s initial decision and “force” them to render it?

This would have my vote. (Whether that’s a vectorised version of Carto, or something else entirely.)

But what are these elements and who decides they should be rendered? Though my understanding is that a vectorised map is more flexible and users could select/deselect elements to draw?

3 Likes

I guess that depends on the main audience for each site.

Maybe there are an element-set that is by default on for osm.org site, that the community can agree on, and other sites can change that set depending on their needs.

Related discussions/issues/PRs:

(and links included in those)

2 Likes

Not to sound trollish, but isn’t it? At least, it doesn’t seem to belong to OSMF, as it is not located under https://github.com/openstreetmap/? Unless I’m wrong, it is a separate project, that OSMF happens to make use of. Thus owners / maintainers of that project are the ones who decide what they will (or won’t) do.

If OSMF is unhappy about those decisions, they can fork the style (license allows it, yes?) or they can change default style to something else completely.

But for that there likely would need to be consensus about what OSM users want, and that seems hard, as it tends to vary between extremes (some wanting GoogleMaps lookalike, some wanting US printed-map style, some wanting EU style, some wanting basemap with majority of features NOT being rendered so it can be used as basemap, and some insisting that OSM is not a map but a geo database and thus only map shown on osm.org should be debug-map with every single tag represented graphically for easier debug; or even that any map should be completely removed from osm.org website to drive the point home and thus save the time on conflicting wishes of users), even before the allocation of resources.

Alternatively, if one wants to convince (Carto, or any other) maintainers to do something, it is usually best accomplished in a way you would use to try to convince complete stranger to do you a favor. That is: not by threatening, demanding, complaining, arguing or trying to force your view, but instead listening to their feedback and expending extra time and effort to read the whole thing and trying to accommodate and implement what they ask for.
Not willing to expend that effort and/or “bend to their will”? It’s fine and quite reasonable course of action, but then one really shouldn’t feel entitled to get something back from those volunteers.

OSMF might as well demand that Ruby programming language must support some new feature, as it would make the osm.org website built on Ruby on Rails easier for them. :smile_cat: It’s not how FOSS works.
Did you actually read that comment near the bottom of that PR you linked? It’s not very often that I agree with @imagico but this seems to be correct interpretation to me:

As we have said many times in other contexts: The proposal process on the wiki is a means to allow mappers to evaluate their tagging ideas in discussion with a somewhat wider audience and possibly identify and address issues that they have not seen. It is not in any way authoritative to anyone - neither mappers nor data users. It can help increase the chance of a new tagging idea to be successful, it is not a guarantee for that. And it has no bearing on our decision if and how to render certain tags. We base that primarily on how tags are actually used.

Or to rephrase: Proposal process is not about vote outcume. It is about discussion to be able to work out the kinks and potential problems, as well as modifying the idea you had so the tag that one proposes is more usable to wider audience, and find holes in the plans - before the tag starts getting used (when dealing with the issue would be much more involved and problematic). Voting is there just to give people a feeling of closure, not because it accomplishes anything by itself.

(and that that particular proposal seems to have had several issues that went unaddressed, and that its vote barely passed. Never a good sign for wide adaptation)

12 Likes

Certainly the process should be followed more holistically going forward, but process is still only a means to an end. Mappers shouldn’t be forced to choose: get yelled at for degrading the usability of what for now is the most influential mapper-oriented renderer? Or get yelled at for bucking what the wiki says is a settled tagging convention?

Anyways, where does this leave us now? The tag is plainly being used in high-profile situations. If the highway=busway tag really is so flawed as claimed, where is the push to repeal its approval and bring some clarity to the matter?

9 Likes

As others have said, the OSMF can’t override the maintains, like you ask.

Have you considered the OSM standard approach, of just doing it yourself? Fork the project. Make a new global map style. Render toilets. Make a new map project? Maybe you can win mind share from OSM carto and replace them?

3 Likes

My latest update on that PR is from May this year. I have resolved all major issues; what remains is vague hand-waving pointing to huge unsolvable meta-issues which Carto will never resolve and which act as convenient items to point to when a feature is not wanted. There is not much more I can do as an individual contributor. There is also the issue that while the feedback received from the community on that PR is overwhelmingly positive, the feedback from the maintainers does not inspire confidence that any amendments I make on the pull request will lead to it getting merged; I can contribute my time for OpenStreetMap in more effective ways.

In software development, leaving a huge bug wide open instead of at least partially addressing it with available solutions provided or acceptable workarounds is considered unprofessional and inconsiderate to the stakeholders.

Perfect is the enemy of good.

That would be a valid reason to stop doing anything really innovative or experimental and going into maintenance mode. This is fine and completely understood. Leaving highway=busway completely unrendered though, is a huge bug which should be addressed, and which fits within the stated goals of Carto, even in maintenance mode.

But from what I’m seeing on those two pull requests (on of which is mine) and the issue itself, highway=busway is not getting rendered because some maintainers do not want that tag in OpenStreetMap, at all. I am not saying that this is your motivation Paul, but that is the effective vibe I am getting.

  • You could decide to render highway=busway exactly the same as highway=service and it would be an improvement.
  • You could decide to render highway=busway as a simple thin black line like golf=hole, and it would be an improvement.
  • You could decide to accept my pull request for highway=busway and while there might be minor visual bugs, it would be an improvement:

(The teal ways are highway=busway.)

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.

30 Likes

It’s not “some maintainers”. Let’s be honest. It’s one particular maintainer.

I am restraining myself here to stay within the Etiquette Guidelines, but I believe it would be clearly better for osm-carto in particular, and OSM in general, if that maintainer were to step down from osm-carto and focus his considerable talents and energies elsewhere. Speaking from experience, one of the most valuable skills in OSM is knowing when to stop and let others take a turn. :slight_smile:

27 Likes

By saying that is not motivation, you are saying I have given the vibe that I do not want highway=busway in OSM with what I’ve said on those issues. This is not correct, and I see no reasonable basis for that conclusion, as I have not made statements on either PR.

Aside from the fact that I haven’t made any statements, if I didn’t want highway=busway in OSM, I wouldn’t have included support for it in the flex backend work. That I did is a pretty clear statement that I do want it.

I have a limited amount of time, energy, and motivation to spend on style work, and of that, only some goes to OpenStreetMap Carto. I have been focused on technical details that have cross-over with other projects, not new features. Based on this topic, that motivation is decreasing.

4 Likes

I don’t think you have personally given that vibe, and I don’t wish you to take the above as personal criticism. I am addressing you in this thread as a maintainer of Carto who responded here, and who is one of the last remaining maintainers actively contributing to the codebase (for which you do have my gratitude, in addition to your work on the OWG).

But from an individual contributor’s standpoint it isn’t clear whether maintainers pushing back on a tag are doing so purely by expressing their personal reservations (regardless of what is said), or that this also makes the contribution effectively untouchable by other maintainers. In practice, as soon as a contribution seems to have gotten controversial, it gets indefinitely postponed.

Whether this is caused by a lack of resources, or by a lack of willingness is inconsequential really, as the end result (broadly used tags which fit in the general purpose map paradigm getting ignored) is the same.

6 Likes

… is actually pretty easy.

That is more difficult.It used to be pretty easy before the “https nannies” (both at the browser developer side and within OSM) decided that we should not be allowed to substitute our own URLs for ones a website wanted us to see.

It’s still somewhat possible - for my own use I replace “Humanitarian” map tiles with my own via manual hosts file entries**. I need to click through a browser warning when the certificate changes, but that’s it.

That’s not really “hosted on osm.org” though - it differs in a couple of major ways:

  • it’s not easily available to everyone else without some local PC jiggerypokery.
  • it doesn’t benefit from OSM’s CDN.

It’s the second of these that really differentiates OSM Carto from “some other map style on the internet”.

** “49.12.240.42 tile-a.openstreetmap.fr” etc.

2 Likes

ish… ? Yes hosting a tileserver is harder than not hosting a tileserver. But you don’t need a global tile CDN straight away. OSM.org has many map styles which don’t have that.

Yes it’s harder than if osm-carto accepted your own. But it’s not out of the range of a compentant unix sysadmin.

Be the change you want to see in the world! :blush:

3 Likes

I don’t talk in the forum often, but as a long-time mapper, this entire discussion is making me really sad.

I truly believe that the current state of osm-carto is holding OpenStreetMap back. By “current state” here I specifically mean the combination of two things: (1) that for whatever reason, the osm-carto project does not evolve along with the project, and (2) that osm-carto is the default style shown on osm.org and hence, de facto, the OSM style. Individually I don’t think these two facts are problems. The combination is what hurts. I don’t have anything against the osm-carto maintainers for doing whatever they want with their map style; it’s their map style after all and they should do with it whatever they please. However, as long as they are the default style on osm.org, it does matter.

Whatever the reason, my city has had broken busway rendering for I think over two years now, and we’re still nowhere closer to solving it. This and other issues (area=highway? shrubbery rendering, anyone?) are really impacting my mapping motivation. Why is it so hard to accept change? In the olden days, OSM used to be really agile; things were thrown at the wall to see what stuck. Some of these ideas were terrible, but at least we had fun. Now for every inconsequential change we get bogged down in deep discussions and it’s taking so much energy away from what matters: having fun actually mapping.

Maybe we should bring Osmarender back. /s

31 Likes