Agree! Outsiders sadly wouldn't have experienced this first-hand. The thing is, PR acceptance criteria aren't even firm. If imagico after a long back-and-forth decides he doesn't like it, then too bad for the prospective contributor.

A similar situation holds with openstreetmap-website. Sadly currently barely anyone uses Rails...

Honestly even reading his prior blog post and this together, his own outline of his position made me feel there was more to it. Like the way I read it, they had a process of open contribution, and then they closed it down, partly at the author's suggestion, and then those contributors who felt the process was too onerous because of pushback against perceived euro-centrism of their contributions went and made their own projects.... which were more succesful for Europe and North America.

Sounds like open source working correctly. If someone doesn’t agree they can always fork the project and aim for their own direction.

Absolutely possible; that's not the problem here.

The deeper problem is that Carto gets a free ride on the website as the incumbent house style. You can fork it, but doesn't make it the default style shown on openstreetmap.org. You could fork it, get popular community support, and still get nowhere except for wasting a lot of effort, because displacing Carto takes a lot of political manoeuvring as well as server resources for hosting the default style (which are not insignificant).

If it was a matter of just forking it, and have the openstreetmap.org website maintainer pick it up if it proved more popular than that would be that, but given the fact that the one other Carto maintainer who seems semi-active is also a member of the OpenStreetMap operations working group (i.e., server resources), spending any effort on a fork with the goal to displace Carto seems pointless at this point in time. I prefer to spend my resources on just making the map better.

Some people justly pick up their crayons and go make a nice thing elsewhere (like the Americana style), or contribute to the styles used by popular apps. For now part of the community just gave up on Carto and is waiting to see how developments for the new vector style will pan out.

And as always, forking might solve a specific issue, but creates so many new ones that it isn't such a clearcut and obvious or even sensible solution.

I wouldn't compare osm-website and osm-carto at all. The commit logs are very different.

openstreetmap-website: https://github.com/openstreetmap/openstreetmap-website/commi... . Numerous commits most days.

openstreetmap-carto: https://github.com/gravitystorm/openstreetmap-carto/commits . So far in 2024; one small regression fixed, one niche bit of tagging added to an existing style, some largely pointless code style tidying. That's it.

Sure, you're right - I haven't checked osm-carto in a while. Nonetheless, the barrier to contributing to osm-website is too high and the maintainers also not welcoming. TomH is infamous for his comments that brush off even OSMF board members. The openstreetmap-website is due for improvements, but the same thing applies - maintainers are very finicky and even worse, one of them is abrasive as hell.

Elsewhere in the comments it was pointed out about hostility to experimentation, the same applies to openstreetmap-website. There are many things that could be tried on the front-end, but in the eyes of TomH you need to be perfect at the first shot, based on his understanding of the situation.

Somebody pointed out that openstreetmap-website contributions pace curiously picked up after the NorthCrab's blogs detailing his unofficial and unsolicited Python rewrite, OpenStreetMap NG. Honestly even if he's somewhat cringe at times, he's still more adaptive than TomH and co. E.g. people pointed out that Mongo is fauxpen source so he duly rewrote the DB part in Postgres.

If you're willing to entertain more leisurely mappers like me (i.e. those unaware of what happens in the community), care to steelman their reasons for the blockade?

My reading of the situation is that, in general, they want the community to reach consensus on a globally consistent data model and visual language, ultimately for the purpose of serving all of humanity, fairly. Given the unique position of influence held by this renderer, ad hoc iteration on it without holistic planning risks inadvertently establishing harmful precedent that might take years to correct, or worse, to notice at all if only underrepresented users are impacted.

For the specific case of busways, this holistic planning simply has yet to occur.

That sounds a bit far-fetched to be honest. Right now by not rendering them you're impacting everyone, not just some underrepresented users :)

Oh boy, global consensus? That's a big ask.

Why not allow branches of divergence? You'll maintain a higher and increasing level of free help from a bigger base of contributors that way.

> global consensus?

No, that’s not what I wrote. It’s local consensus on a system that is fit for global use, which means being cautious about what concepts receive special treatment from the renderer.

> not allow branches of divergence

I’m not sure where you got this idea. It’s explicitly licensed under CC0 and GitHub shows 800 forks. This freedom to diverge is one of the arguments in support of being conservative about changes to the common default.

There are kind of branches already (other layers have different styles [1]), but this debate is over the default layer style, which appears on first page load of openstreetmap.org

[1]: Transport Map Layer https://www.openstreetmap.org/#map=15/42.3594/-71.1051&layer...

> risks inadvertently establishing harmful precedent

What sort of harmful precedents might be established?

Modeling the world in a way that alienates or fails to serve people in specific places or cultures, creating undue technical burden on data consumers, causing pains that discourage mappers from contributing, dividing the already precariously small community, wasting volunteer time on later schema migrations

> causing pains that discourage mappers from contributing

Like not rendering (bus dedicated) roads despite them being tagged as (bus dedicated) roads using a tag approved by the community three and a half years ago. The openstreetmap.org website currently shows gaps all over the world wherever bus dedicated roads exist. This certainly discourages for mappers.

Compare:

Carto (default):

https://www.openstreetmap.org/#map=18/52.32853/5.04991&layer...

Tracestrack Topo:

https://www.openstreetmap.org/#map=18/52.32853/5.04991&layer...

What are the odds, this random example points to only a couple km away from my home.

I had never seen OSM for the area, the detail around Maxis is astounding. And the busway is quite relevant to understand traffic around the area.

"What are the odds, this random example points to only a couple km away from my home."

Probably a rhetorical question, but the odds for you individually were probably low, but the odds that the random example (where random here still means close to major cities) was close to some HN reader were probably quite high ..

Don’t wait for me to do it; you can steelman too: It’s plausible that the consequences of an actively wrong implementation would be more costly than this delay.

Instead of just throwing costs at each other, you could acknowledge the other party’s and then argue that yours are greater. (I personally would agree with you about this.)

I see the same roads in both, one of them has a dashed pattern on top. What is the problem?

In the first one what you’re seeing is just the absence of grass.

As an OSM contributor, the biggest pain for me is working hard to add data to the map only for it to not show up at all or look ugly.

Bus routes? I've read the wiki pages in order to map them. I don't even ride the bus, I just wanted to add the data in. Why put in all that effort when the map won't even show it though?

> Why put in all that effort when the map won't even show it though?

Just select a different layer, the "Transport Map" renders bus routes: https://www.openstreetmap.org/#layers=T

This is a problem with all maps. You cannot show everything, so you reduce it to something you want the map to show. While things like waste baskets, hydrants, dog excrement bag dispensers, etc. Can reasonably show up on deep zoom levels because they're just small icons, I think bus routes can clash with plenty of things that many people would also consider important.

Remember Falsehoods Programmers Believe About Names [1]. The amount of trouble people from across the world have had with tech, because some SWE in Silicon Valley decided that the way their names work is how everyone's names in the world work.

[1] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

I'm very aware of those issues. My full name has four words, it does not fit into first/last name fields. I have to deal with that problem constantly. I'm reminded of it every single time I pay for something with a credit card due to their idiotic first/last name fields. Some of them even have length limits.

This is a non-issue with Open Street Map. Tags are freeform. You can input literally anything into the database. You can have simple tags or ridiculously detailed and nested schemas, and values can be literally any text. You can and should seek community consensus so that a controlled vocabulary can be created and documented, effectively turning it into an API. It's not actually required though. If you have geospatial information and you add it to the map, the map is made richer and more useful than it was before. The map didn't have that data at all and now it does. Doesn't actually matter if the format hasn't been agreed upon yet, it can always be edited later so that it fits into a more regular format. I did a lot of tagging and schema improvements in my city.

Software that consumes the Open Street Map dataset obviously won't render the data it doesn't understand. They should be made to understand more stuff. Software can always be updated to make the most of data. The data has to actually be there to be usable though. The software won't matter at all if the data is missing or if it's garbage.

I've read (and engaged with) everything in that issue, but I still don't understand the vague 'well the tag is just too loosely defined' argument.

I mean, sure, there is some ambiguity around the exact limit of this tag, i.e., is it only meant for ways dedicated to rapid transit bus routes, or is it for ways dedicated to any bus performing a public transport role? That is a valid question (of the kind which tends to get answered in the OSM project with the passage of time and observing the actual usage of the tag), but, and at the end of the day, ways tagged with highway=busway are undeniably:

a) roads;

b) used by buses;

c) unless otherwise indicated, not accessible to general traffic.

Absolutely refusing to render even a simple line after three and a half years (despite two PRs provided) is hard to explain as anything but antagonistic gatekeeping behaviour.

The arguments in that discussion don't really make sense either. Such lanes exist outside Latin America too. Like the "busbaan" in Almere, Netherlands. Edit: And in Diemen, as pointed out above.

But generally this "process-first" attitude makes me step back as a contributor immediately. I prefer doing something the wrong way and fixing it later instead of not doing it at all.

The same thing totally antagonizes me against Wikipedia editors so I never participate there either.

These lanes also exist in Germany.

Definitely agree. This type of gatekeeping is toxic and ultimately makes us all worse off.

I work full time in web mapping. IMHO the ugly OSM style and its lack of innovation held back adoption of OSM severely for years.

Do you mean the early-2010s era style? Sure that one was quite ugly.

The current style on https://www.openstreetmap.org/ basically looks the same as I remember it in ~2010, and is quite ugly compared to Apple Maps and even new google maps.

Or even something like OrganicMaps which runs on OSM data

No, it does not look the same as in 2010. Your memory is failing you.

That's very subjective, I find the Google style barely usable compared to OSM carto. No experience with Apple.

How did this stop you from deploying your own tile server with your own style?

First, my remark is about the impact on the adoption of OpenStreetMap in general, not my personal usage of it.

And second - it did not stop me from doing that, but it was extremely difficult, and took months of effort. I built a tool to set up a server with all the components required to download the data, load it into PostGIS, style it with Tilemill and generate and serve tiles: https://github.com/stevage/saltymill

So I find your comment quite disingenuous.

Wow. This sort of obstructionism is what convinces people Open Source is not worth the time and effort. Really disappointing. As someone else said in that issue, "perfect is the enemy of good". Thousands of KMs of road are currently not VISIBLE on the map due to stonewalling.

The material difference between this and someone intentionally sabotaging things is in practice, zero.

It's crazy destructive

Is he?

> Since the matter of consensus based decision making has been put into the foreground i like to emphasize again that in contrast to many other matters in this style there is no lack of maintainer consensus on this issue. And even if there was disagreement on a concrete decision - i have stated many times now that from my side that would not stand in the way of merging a change implementing this and none of the other maintainers has indicated that this is a matter of fundamental importance for them either.

Effectively. There are two PRs (one a stand-in minimal solution, another a fully worked out one) which solve this problem; neither has gotten merged or even seriously considered. If you dig around a little the gatekeeping patterns become obvious, and you'll also note a number of other maintainers giving up and resigning. But don't do that; it just makes for depressing reading.

Besides, regardless of what he says there, there isn't even a single thin line on Carto rendered maps to indicate the presence of significant infrastructure where this tag is used. That inaction speaks clearer than his words.

I'm not sure if you read his recent comment (from March) where he explains the reason for blocking the PR.

The reason so far is that there is no consensus on whether highway=busway should replace the additional tags one can add to indicate that a highway street is limited for buses only.

  > However, so far we are pretty far away from highway=busway replacing highway=\* + access=no + bus=yes as the consensus tagging for any and all bus only roads world wide. Hence my suggestion in #4226 (comment) still applies - solving #214, and in context of that think about rendering highway=busway in a way that reflects a distinct meaning (which would likely be in analogy to highway=pedestrian). A possible design approach to this is shown in https://imagico.de/blog/en/rethinking-road-access-restrictions-rendering/

So, no, it's not stagnated because the author wants it. A previous commit from one of the maintainers (jeisenbe) said the issue was closed because no consensus was obtained from the tag proposal, dated 2020:

  > I’m closing this for now because there is still no established way to tag these features. Once either service=busway or highway=busway (or some other tag) becomes established as the clear consensus of most mappers, we can reopen this issue.

https://github.com/gravitystorm/openstreetmap-carto/issues/4...

Ask anyone from the community and this is quite a good reason to block the addition of new features to the map style, especially if they aren't widely used and not standard.

I don’t really want to get into the weeds on this one again but as someone from the community I completely disagree with this characterisation. osm-carto is comatose and largely for reasons like this.