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

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.

4 Likes

(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.)

3 Likes

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.

7 Likes

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.

9 Likes

I agree with JeroenHoek’s opinion, it’s frustrating even just reading issues of other proposal in osm-carto‘s repository that are constantly being rejected, and the general feeling of the whole project is that it’s resistant to change, whereas at the same time other osm-related projects (e.g., iD/Rapid) rarely have such poor and non-motivating feedback when faced with a specific problem, and osm-carto really doesn’t inspire confidence that “my efforts can be merged”.

Maybe the maintainers should try to maintain the project in a more agile way (of course, this is only a personal opinion, and does not mean that I force the maintainers to do so).

It’s unlikely that we’ll ever find a map rendering style that satisfies everyone (even the exact usage of labels is unlikely to be unified and consistent upon worldwide, or else how did driveway2 come about?) I’d like to know which of the current more dynamic forks might replace osm-carto as osmf default render style in the future (even if it might its visual presentation change quickly or have minor bugs).


Edit: Maybe someone who wants to build a fork can come forward and form a new team? Is this possible?

Ich persönlich halte es zwar für “eigenartig”, dass man nur übereinander spricht (schreibt) statt miteinander, aber damit alle auf dem gleichen Kenntnisstand sind (gefunden via Wochennotiz):

english:
Personally, I think it is “strange” that people only talk (write) about each other instead of with each other, but so that everyone is on the same level of knowledge (found via weekly note):

https://imagico.de/blog/en/a-note-on-osm-carto/

1 Like

It absolutely is possible; it just needs one or more people to step forward and Actually Do It. The technical bit (fork and modify the style) is easy. Lots of people have done that.

“Deciding what this new style is for” is somewhat harder, but also doable. The best way to learn what the problems actually are is to do it.

Once that’s done and the style has some sort of track record in doing what it set out to do better than OSM Carto, the next stage is the political bit, as outlined above.

Bluntly, the reason that we are where we are is because no-one had the appetite to do all of the above. If you want to be the person that proves me wrong, be my guest! Lots of people will be willing to help answer technical and even political questions, but what they’re not willing to do is own the project.

10 Likes

I am quite new to this whole discussion and also possibly quite naive. I can not figure out who you mean, even though I read the whole github issue and all of this thread. could you please point it out to me? I just read a lot of forum / wiki / github and I am really touched by the amount of effort of all these talented people working towards Free Open Source Software and the high values of community / commons. It is saddening me deeply to see these efforts kind of fruitless because something fundamental is not working. I just feel dumb because I can not figure out who or what is obstructing change.

A quick update: there has been a new layer released on osm.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

Pleasing to they eye with the elevation gradients for a particular audience such as those into mapping landscape, but then did ‘the fell test’. Blank. /o\

I’m guessing that means “I looked to see if natural=fell is rendered by this map style, and it was not”.

Taginfo projects suggests a few options that do.

Indulge my wholesale ignorance, but how would I add a fell rendering map into JOSM. Got as far as this screen from which I added the OpenTopoMap which I like much because it gives the elevation gradients helping to decide the incline of roads but more importantly what direction waterways flow on sloped terrain.

Edit: Did find the imagery preferences page here but as it says there, the instructions on ‘how to’ are wanting.

This might be better as a new thread?

2 Likes

Not sure if this is sarcasm, as you might have indicated at the end, but just in case:

As far as I can tell, Tracestrack’s style is currently a closed-source style, which makes it an unlikely candidate for a default layer. There’s some discussion about it here:

A different, open-source OSM Carto derivative has been proposed as a featured layer, though it’s still hosted by a third party:

4 Likes

Tracestrack - Information says:

The source code of Tracestrack Carto style is not open. We plan to make it open source in certain moment in future.

1 Like

For those who missed it, it’s now on github.

2 Likes

If the same, todays newsletter 697 links to a new version announcement of Carto 5.8.0 imagico's Diary | OpenStreetMap Carto version v5.8.0 released | OpenStreetMap
Maybe this addresses something, anything to cheer one or few up. Sadly golf=hole no longer renders, used it 18 times on a course, have to retag as pin. Some railway stuff and flowerbeds now render \o/, mapped a few. Now we need fell in same variation or same as heath.:sunglasses:

(not related to busways but) that statement isn’t true. Please read the link that you used yourself for details of what is actually happening. There are plenty of things to discuss where perhaps OSM Carto could perhaps be doing a better job than to accuse a style change of doing something that it has not done.

Read on “…used it 18 times on a course, have to retag as pin”… the pins of the golf=hole lines went, so now 18xpin is on the end node ;0)

The post which you quote is a good example of why I am much less motivated to deal with any feedback from users who are mappers.

1 Like