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.
There is another option of forking OSM-Carto and asking for the fork to be used on the website.
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”.
4 Likes
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.
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.
1 Like
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.
1 Like
Bringing more functionality to osm.org sounds like a great way to reduce fragmentation of the OSM ecosystem.
3 Likes
New vector tiles served at openstreetmap.org front page don’t necessarily need to be free for all.
1 Like
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.
I absolutely agree with that, and also with:
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:
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:
11 Likes
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…
4 Likes
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?
1 Like
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):
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
2 Likes
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\