I’ve put up a demo page showing my work on minutely updated vector tiles. This demo is using my work for the tiles and the Versatiles Colorful stylesheet. There are some technical details on my diary but I wanted to expose the work to a wider audience.
These tiles are updated minutely but may lag a few minutes behind due to various levels of caching. This won’t be an issue later on as it’s just cache settings that need changing, not the backend.
I’m interested in feedback. The part that I’m working on is just the generation of tiles so if you know the issue is with the style you’re better off opening an issue there. The advantage of vector tiles is that if you don’t like the style, you can use your own.
If someone has already put together a docker-compose based setup that only requires specifying a small BBOX of interest, which automatically updates the data and generates tiles within it, I would be happy to focus on testing, multilingual support, and possibly even operating a small test server similar to this. So, if anyone has a setup like this already configured, could you please share it?
Is there a straightforward way to tell which changeset triggered the latest update of a particular tile, or its timestamp? Is this something one can query in Prometheus as well? That could be useful for when, say, someone drains one of the Great Lakes by accident, since the changeset bbox could technically be elsewhere.
Thanks. If you could give a link to the url for the demo it would help to find the location and zoom you’re seeing the problems on. This problem is a bit trickier. Any map layer starts to exhibit problems if you zoom in enough, and if you have a very finely noded curved way it will always experience jumps like this if you zoom in enough because there is coordinate rounding. It looks like this is happening on z19, which is equivalent in scale to z20 on a typical raster map. I’ll look at what scale we’re targeting and increasing the extent.
There shouldn’t have been - everything was working fine when I checked it. Fastly is set to a 5 minute TTL and Varnish to 5m, so the most there should be is about 15 minutes.
There’s a few possibilities
an exceptionally big change came in and that took longer because many tiles needed generating
the tile wasn’t indicated as having changes by osm2pgsql, because the algorithm is known to not be perfect, and then a later change came in that touched that tile
My usual issue with vector tiles is geometry simplification being too aggressive, but since that doesn’t seem to be the case here, that’s something going right
There’s no true simplification going on here at all. There is a resolution reduction and de-duplicating step (ST_AsMVT) but that is adjusted by the resolution used and should hold up well till the scale of z19 raster tiles.
If you try zooming in quickly on a slow connection you will see very simplified lines but this is better than rasters where you see a blur.
I also find many tile sets oversimplify. I understand why because it’s an easy way to reduce tile size but it is frequently overdone. This is best seen at a zoom like 13.99 where the tiles are 1024 pixels wide.
I do expect to need to introduce some simplification but because I’m aiming at mappers it adjusts the priority of reproducing the original geometries compared to performance and tile size.
I call that quite ambitious; I guess the interests of mappers – though less in numbers – in the minutes presented vary much more than the interests of consumers. I might be wrong though.
I’m not aiming to meet the needs of every mapping-related use case that mappers have. No one service can do that. But minutely updates are really only of use to mappers so the biggest single feature is for them.
There seems to be some issue with rendering railways, service roads et cetera (which I assume is because of those tags not being covered in the style yet). Here’s an instance of that in Sealdah, India.
