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

[ZeLonewolf (Brian M Sperlongano)]

While I share the sense of frustration in this thread with the contributor experience when interacting with osm-carto, I also agree that the OSMF and its working groups have neither the mandate nor the ability to change the way osm-carto is run.

I also agree that a missing feature on the map is a rather low priority for the foundation, when compared to things like making sure we have enough money to keep the servers and core services running and paying our small staff (basically just @Firefishy) that makes it happen.

Allan is not being dismissive when he writes:

@apm-wa

There is a concept called “doocracy” that has run OSM for almost two decades now,

He is expressing the reality that this project which looks reasonably well composed from the outside is really just a collection of individual services, built by a bunch of different folks, that have been duct taped together and more or less basically work.

So ask yourself – if you had the power of the OSMF board, and you cared about this specific issue (the standard tile layer being responsive to community expectations) – what would you do about it?

Would you raise funds to hire a paid developer to create and maintain a replacement to the standard tile layer?

Would you write a sternly-worded letter of protest to the current osm-carto maintainers?

Would you pick another existing tile layer to be the standard tile layer? Perhaps the cycle map? The humanitarian map?

I am hearing a lot of complaints here but not anything that the OSMF/OWG is actually able to do. @imagico correctly identifies the project’s utter lack of alternative options:

@imagico

What is getting lost – and that is the key point – is that the ultimate problem is not OSM-Carto, it is the lack of anything other than OSM-Carto (source).

So I think unless you’re willing to be part of that change to create an alternative, and I’ve outlined one way to do it above, all you are doing is complaining to people that aren’t able to fix the problem. Maintaining a style is a ton of work, and if you aren’t willing to do it, you don’t really have a leg to stand on when complaining that the people that have chosen to do the work of maintaining a style aren’t doing a good job.

It amazes me that there are apparently so many people that don’t like how osm-carto is run but nobody willing to say “hey, let’s get a group of folks together and see if we can fork an alternative.” It is further mind-boggling to me that there is so little initiative to create a fork of a project that’s essentially 99% done but just missing just some allegedly small set of minor additions. We are not talking about building Rome in a day, we’re talking about basically adding a few bells and whistles to an existing product.

This would be very different conversation if we could say “The OSMF/OWG should switch the standard tile layer to $PROJECT instead.” That’s actionable. But only if $PROJECT exists.

[StC]

@ZeLonewolf

So ask yourself – if you had the power of the OSMF board, and you cared about this specific issue (the standard tile layer being responsive to community expectations) – what would you do about it?

Rethink/debate what the purpose of www.openstreetmap.org is, create a competitive framework for renderings to appear on the front page?

My perception about this debate is not that people are frustrated with the board not intervening in a given rendering. It is that a very particular rendering that was granted a particular role by the board has issues, and there appears to be no mechanism to deal with this.

Sorry if I’m beside the point, still new here.

[Tjuro (Mart)]

I would like to say that I’m saddened by this whole situation. Of course, when highway=busway was first introduced it was expected that it would not render. But now that a couple of years later there is no rendering is unfortunate.

I think that this is not because of unwillingness to render, more so a lack of clear consensus on what highway=busway should be used for. For example, use on all bus only roads or only on BRT systems. Etc.

And lack of good rendering options. I feel like both PRs don’t render busways in a good way. Mainly being way less prominent than I would expect. And not reflecting real world properties of busways, for example having a solid centreline, being made from concrete.

And while I prefer any rendering over no rendering, once a style has been chosen it becomes harder to change and there is less reason to change.

What also does not help is that the collaboration and interactions on OSM carto are very low. I used to follow all issues and pull requests. But now I feel like the vibe is very negative and most issues are caused by the dated tech stack and left unsolved.

While OSMF should not intervene with OSM carto they could provide better facilitation for new general-purpose styles to be introduced. For example, by having a page on openstreetmap.org that links to many map styles and where people can like styles to rank them higher on that page.

[Richard (Richard Fairhurst)]

Ok. Plenty of people have eloquently set out their stall here or elsewhere, which (a) explains why we are where we are, and (b) suggests nothing is going to change with osm-carto any time soon. Absent a fork, for which there’s no indication of any great enthusiasm, osm-carto will keep doing what it’s doing.

So I can see two ways to move forward the cause of rendering on osm.org.

1. openstreetmap-website #4042 is merged with additional support for the Americana style. OSMF additionally considers running an OpenMapTiles-schema instance on its own hardware. Hey presto, we have two vector tile styles on osm.org (the OpenMapTiles-originated one and Americana) and a clear direction of travel. It’s not ideal because both are based on the same OpenMapTiles schema, which is moderately restrictive (though it does at least include busways ), but it’s a move forwards and opens us up for more good stuff in the future.

2. OSMF (via a Board instruction or via EWG) funds core vector tile development. This is either two or three contracts: one to someone to build schema-agnostic tile infrastructure, another to develop the requisite JS for osm.org, possibly a third to work on the cartography (though this could be rolled into the first). This requires a whole bunch more thought and planning than (1) so place your bets as to whether it’ll happen.

I’d like to see 2, but in reality 1 is more likely. Some hybrid (or a commitment to do/fund more in the future) is of course possible.

[Minh_Nguyen (Minh Nguyễn)]

@Richard

1. openstreetmap-website #4042 is merged with additional support for the Americana style. OSMF additionally considers running an OpenMapTiles-schema instance on its own hardware. Hey presto, we have two vector tile styles on osm.org (the OpenMapTiles-originated one and Americana) and a clear direction of travel. It’s not ideal because both are based on the same OpenMapTiles schema, which is moderately restrictive (though it does at least include busways ), but it’s a move forwards and opens us up for more good stuff in the future.

One of the awkward things about this pull request is that it proposes to have the original OSM Carto coexist with a derivative style that superficially resembles OSM Carto. Ignoring that issue, I suspect many mappers would perceive the style as a temporary step backwards even with the inclusion of busways. Both the style and OpenMapTiles would require quite a bit of work to achieve feature parity with the original style. Is the OpenMapTiles project prepared to undertake that effort? (Another OSM Carto derivative, Apache Baremaps, has some room for improvement as well.)

The more modern vector tile stack potentially addresses some of the underlying technical debt in the original codebase, but it doesn’t by itself address the difficulty of evolving the design to accommodate an inevitable progression of new ideas from the OSM community. Even OSM Americana, young as it is, has been in need of a talented designer to set the project on a sound path. But the “OpenMapTiles style” is more complicated. It inherits many design decisions that assume the capabilities and limitations of Mapnik and CartoCSS rather than those of MapLibre. Would an OSM Carto lookalike style be open to departing from the OSM Carto look and feel to continue improving? This is the difference between using OSM Carto as a steppingstone and merely simulating OSM Carto as a demonstration piece.

Completing option (1) certainly would ease the pressure that OSM Carto is facing, which would not be a bad thing. But it raises more questions than answers in my opinion.

[Friendly_Ghost (Casper)]

@Minh_Nguyen

Would an OSM Carto lookalike style be open to departing from the OSM Carto look and feel to continue improving?

That depends on who’s operating it. The maintainers of Carto appear to take a conservative approach to the style, choosing stability over innovation. That’s their choice to make of course, but it frustrates the mappers who wish to see innovation in community tagging choices being reflected on the map.

Americana is a good example of a map style with a focus on innovation that could satisfy the desire for quick feedback to people to visualise their mapping activities. However, the goal of Americana to be an American style, rather than a global style, makes it not an ideal choice for the default style on osm.org. In that sense Carto still satisfies community needs better.

[Minh_Nguyen (Minh Nguyễn)]

@Friendly_Ghost

@Minh_Nguyen

Would an OSM Carto lookalike style be open to departing from the OSM Carto look and feel to continue improving?

That depends on who’s operating it. The maintainers of Carto appear to take a conservative approach to the style, choosing stability over innovation. That’s their choice to make of course, but it frustrates the mappers who wish to see innovation in community tagging choices being reflected on the map.

This particular derivative was authored by MapTiler, with one subsequent contribution by an unaffiliated developer that was intended to improve consistency with the original OSM Carto. Neither MapTiler nor the other OpenMapTiles maintainers have said much about their long-term plans for this style’s active development, just that it’s intended to be a reference implementation of an OpenMapTiles-based style. This is not to cast aspersions on anyone, but since there isn’t much of a public track record yet, it’s very tempting to project hopes and desires upon the project that also don’t come with enough material support.

[Wynndale]

There is another option of forking OSM-Carto and asking for the fork to be used on the website.

[Richard (Richard Fairhurst)]

The more modern vector tile stack potentially addresses some of the underlying technical debt in the original codebase, but it doesn’t by itself address the difficulty of evolving the design to accommodate an inevitable progression of new ideas from the OSM community.

It does, kind of. The burden of forking vector tile cartography for display on osm.org is much, much smaller than forking raster tile cartography. To fork raster tile cartography for use on osm.org, you need to not only master a complex rendering toolchain for your own testing purposes, but also stand up resilient infrastructure to generate and update tiles for the whole planet. I certainly couldn’t do the latter and I suspect not many people can.

To fork vector tile cartography, you need to click buttons to change some colours in Maputnik and export the JSON. The end.

I am, as ever, simplifying greatly! The vector tile option is hidebound by whatever’s contained in the schema. (Which, to be fair, is quite a lot in the case of OMT.) And there is the opportunity to do so much more: in particular, to allow people to host their own styles on osm.org by uploading the JSON - or maybe even an on-site instance of Maputnik. That eliminates the need for a style to be approved by OWG before people can see it. That is why I would really like to see “option 2” where the OSMF funds development to this aim, rather than “option 1”.

But both options would get things moving again, and that’s what we need. Building an osm.org where it’s possible for people to experiment with cartography, even if not all the functionality is there from day 1, is going to be the best way to find those “talented designers”.

[SimonPoole]

One of the many elephants in the room is that this (providing custom style support) will kill off similar commercial services in the OSM ecosystem. Perhaps it is time to kill them off, but it is something to be considered.

Another one is the specificity of the request. It isn’t the first time and won’t be the last time that a groups fav tag isn’t rendered by default on the default map and that that leads to “outrage”. Custom styling won’t fix that, it will make things easier for those that actually want to fix their particular itch themselves, but that isn’t the group that is facing unsurmountable challenges even today.

As these things go, I don’t expect the default style on the default map to have vastly different cartographic challenges than OSM carto has with the wealth of things that could be rendered, so I have no expectation of this problem ever being laid to rest.

Simon

* I would note that the tag was “approved” in 2021 and started gaining traction in 2022, not the implied decades. And BTW the creator of OSM Americana was a vocal supported of the tag and it would be more than slightly weird if Americana -didn’t- support it, so that is not an argument either way.

[Spiekerooger]

Before you are thinking about “going vector”, the problem is rather not the style but minutely updates for vector tiles. I think @pnorman is doing a lot of research and work into this.

Now the minutely updates at the current raster setup are not perfect as well in serving mappers feedback as a) not all edits result in a re-rendering and b) the CDN does not reflect the updated state immediately. Those two problems would probably persist if a toolchain is established for minutely updates of vector tiles but even getting there would require a lot of work.

[Richard (Richard Fairhurst)]

@Spiekerooger

Before you are thinking about “going vector”, the problem is rather not the style but minutely updates for vector tiles.

It’s not “before”, it’s “after”!

We possibly need a bit of a reset on expectations. A vector tile solution on osm.org is not going to be complete from day 1. It will probably not have the same update frequency that osm-carto has. It will not show every single feature that osm-carto shows. It will not have much of the intricate SQL that osm-carto uses to mangle OSM data towards its own cartographic viewpoint.

That’s fine. osm-carto has chosen to tackle particular challenges. A vector tile solution will prioritise different ones, both relating to deployment and cartography. Neither is right or wrong. Minutely updates are a nice thing but only really necessary for the default style, and we don’t need to replace osm-carto as the default yet: a twice-a-day update like @ZeLonewolf has achieved will be fine to begin with.

I’m not sure when the phrase “the perfect is the enemy of the good” was first used in OSM, probably 2006 or so, but it’s surely become a cliche by now.

[Friendly_Ghost (Casper)]

@SimonPoole

One of the many elephants in the room is that this (providing custom style support) will kill off similar commercial services in the OSM ecosystem. Perhaps it is time to kill them off, but it is something to be considered.

Bringing more functionality to osm.org sounds like a great way to reduce fragmentation of the OSM ecosystem.

[yvecai]

@SimonPoole

One of the many elephants in the room is that this (providing custom style support) will kill off similar commercial services in the OSM ecosystem. Perhaps it is time to kill them off, but it is something to be considered.

New vector tiles served at openstreetmap.org front page don’t necessarily need to be free for all.

[SomeoneElse (Andy Townsend)]

@Richard

To fork vector tile cartography, you need to click buttons to change some colours in Maputnik and export the JSON. The end.

That hasn’t been my experience. With the notable exception of Mapbox, documentation in the vector tile arena seems to be on a par with this.

@Richard

Building an osm.org where it’s possible for people to experiment with cartography, even if not all the functionality is there from day 1

I absolutely agree with that, and also with:

@Richard

The vector tile option is hidebound by whatever’s contained in the schema.

In the case of OpenMapTiles, I suspect that we’d pretty soon get forum threads along the lines of “OpenMapTiles schema maintainers refusing to include approved $tag”, but deploying something (even if just OMT-based like your option 1) would make these questions no longer hypothetical:

@Richard

We possibly need a bit of a reset on expectations. A vector tile solution on osm.org is not going to be complete from day 1. It will probably not have the same update frequency that osm-carto has. It will not show every single feature that osm-carto shows.

Agreed - I strongly suspect that any existing vector tile style would fall short of many people’s requirements of “what an OSM style should show”, but we can only start to have the conversation about how to make it less bad at that when there’s something to iterate from.

Just to throw in some examples, here are some renderings of the same area:

Vanilla OpenMapTiles (via TileMaker):

OSM Americana:

OSM Carto:

A different carto-based style (mine) designed to show significantly more than OSM Carto:

[Spiekerooger]

@SomeoneElse

Agreed - I strongly suspect that any existing vector tile style would fall short of many people’s requirements of “what an OSM style should show”, but we can only start to have the conversation about how to make it less bad at that when there’s something to iterate from.

Just to throw in some examples, …

But you missed the openmaptiles osm-carto vector style, e.g.

Still a lot missing but not that much as the vanilla style you mentioned and also having a small rendering glitch in those forests but not as bad as a base to start with…

[SimonPoole]

@SomeoneElse

In the case of OpenMapTiles, I suspect that we’d pretty soon get forum threads along the lines of “OpenMapTiles schema maintainers refusing to include approved $tag”,

This needs to be underlined: currently there is no reason the OSM-carto maintainers or any of the raster tile based maps can’t change things as they please (OK the people that have forked the specific style will groan but that’s it). Proposing a change to the underlying schema (of the two that essentially are in use in OSM space) will have further reaching consequences that will likely make it much harder for non-backwards compatible changes.

[Minh_Nguyen (Minh Nguyễn)]

(Someone could probably reach out to that rather complete fork of OSM software, OpenHistoricalMap, to see how they’ve implemented minutely updates of vector tiles.)

[Minh_Nguyen (Minh Nguyễn)]

@SimonPoole

I would note that the tag was “approved” in 2021 and started gaining traction in 2022, not the implied decades. And BTW the creator of OSM Americana was a vocal supported of the tag and it would be more than slightly weird if Americana -didn’t- support it, so that is not an argument either way.

The record will show that @ZeLonewolf wasn’t the one who pushed for OSM Americana to include busways. He didn’t need to; the rest of us were also sensitive to omissions that look like bugs. But it wasn’t inevitable; we also grappled with some of the same challenges that OSM Carto has, like the color to apply to these ways and the zoom levels at which to show them. The main difference is a willingness to ship something that isn’t a platonic ideal, with the understanding that it isn’t very difficult to revisit these decisions later.

[ZeLonewolf (Brian M Sperlongano)]

@SomeoneElse

In the case of OpenMapTiles, I suspect that we’d pretty soon get forum threads along the lines of “OpenMapTiles schema maintainers refusing to include approved $tag”

If the scenario is “OSMF hosts a stock OpenMapTiles instance for multiple style developers to use”, then yes that’s true, and it’s a good reason why we should approach the idea of an OSMF-hosted general-purpose vector tile server with at least some caution.

However, I think what maybe you’re implying is that is vector style developer doesn’t have, or can’t have, control over the schema of the underlying tiles. I don’t think that’s a fair characterization.

I think one of the benefits of developing a vector style that differs from raster stack development is that you can mature your project in a piecemeal way. We started building Americana using MapTiler Cloud, which had a free tier and each developer had to create an account to generate an access key for local development. This was great because we could get started right away and not have to worry about running a server - just code up some HTML and JSON, point it to the MapTiler tiles and off we go.

Then one day, as development and the style started getting more popular, we started to hit the limits of the free tier. So it was either pay for the next tier or run our own tile server. We also figured out that the MapTiler tiles didn’t update very often, but if we controlled the server, we could update it whenever we wanted to. So now we run our own tile server, with a few customizations that planetiler offers over the base OpenMapTiles.

The OSM Americana team has talked at length internally about what happens when we want to render something that isn’t in OpenMapTiles, and there’s an expectation that at some point we would need to or want to serve tiles that diverge from OMT. In fact, we are already doing this in minor ways since we render our own tiles. Specifically, we added additional languages to the tiles and suppress zoom 13 building merges.

Requests for new features fall into three buckets: 1) things we can render today with OpenMapTiles, 2) things we can render if OpenMapTiles accepts our PR, and 3) things we want to render that OpenMapTiles won’t accept. Fortuntely for us, OpenMapTiles has been very receptive to our PRs and we’ve been mostly able to send changes upstream and add rendering for each OpenMapTiles release.

However, there’s a few things we’d like to do that fall into the third bucket. For example, we’d like to render hiking routes and experiment more with wikidata integration. And so at some point we have to make the next step forward to not just running our own tile server using stock settings to actually defining the tile schema. TileMaker has had this functionality for awhile in lua, but it’s much slower to generate a planet than planetiler. That’s why last year I started working on efforts to generate a configurable planetiler schema. We expect the core OpenMapTiles schema to eventually transition from SQL and python code into a YAML config file, but the work to complete that is still a ways off. Once this is done, “modifying OpenMapTiles” becomes simply modifying a config file. If we really wanted to, we could extend planetiler today in arbitrary ways by writing a Java plugin.

So this is a long-winded way of saying that standard schemas are good for launching new vector tile projects without having to own the whole stack, but eventually a mature project will want to roll their own stack for functionality and performance reasons. And there are ways to do this now, and these are just the technologies that I’m personally familiar with.