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.