Minutely updated vector tiles demo

In the current OSMF tile servers database updates are done by osm2pgsql which passes a list of tiles that may have changed to renderd which updates the metadata for a block of tiles. When a tile which has metadata indicating it is out of date is requested the server attempts to re-render it on demand. Tirex is not used, but it is basically a drop-in replacement for renderd. mod_tile is used as a frontend for all of this and includes some logic to bypass renderd in some cases.

With the setup I have database updates are done by osm2pgsql, which passes a list of tiles to tilekiln which generates them at that time. When running in production tiles are never generated on-demand.

The former system means that if there is no load on the service the server is not very busy, but it scales poorly at higher load. It is also operationally difficult as any issue with the entire rendering chain can cause immediate issues for users.

The latter system has essentially the same load regardless of number of users, as fetching a pre-generated tile is very cheap. It is also operationally simpler because an issue with generating tiles will prevent updates, not serving users.

This looks normal to me. There is no simplification - it’s moving an unsimplified geometry to an integer coordinate space. I don’t know what tile you were looking at or how much it was overzoomed by, but it looked to be about a z5 tile overzoomed by about 5-6 zooms. I’m not worried about this, because it’s not a real use-case and any tile based system will look bad when overzoomed that much.

This is what a z5 raster tile looks like overzoomed by only 4 zooms
image

Vector tiles hold up better here because the edges remain crisp, but eventually the impact of the integer quantization become obvious.

Thanks for spotting this. I have it noted as a TODO in the source code. It wasn’t present in osm2pgsql-themepark’s table definitions so didn’t get added this in the rest.

Do you happen to have a list of tiles requested? It would be useful for testing purposes. Note that tilekiln is not yet compressing with content-encoding, so the bytes unpacked is the better value to compare. This is a known issue, but I want to solve this correctly to eliminate compressing and decompressing multiple times between the generation, storage, tilekiln, and the CDN.

Issues with the schema itself (as opposed to my implementation) can be raised on the shortbread github. We should be able to fix schema bugs fairly easily, but schema changes will need to happen in 1.1 or 2.0. It’s still good to get a list of feature requests in early so we can start considering them.

This lives in spirit because some code is shared between the shortbread implementation and the spirit implementation.

This can be raised with Versatiles

Tilekiln issues can be raised on github but any errors (e.g. 503 errors) are more likely to be something needing restarting on my setup. There are potentially issues that could be raised against osm2pgsql or osm2pgsql-themepark but those would arise out of issues against other components.


The tiles are from shortbread 1.0 so you can see the tags used there.

Yes, versatiles released a new style and previously some assets on their servers were moved.

You can. Label points for water polygons are in the water_polygons_labels layer. Adding them to the water_polygons layer would not help as it is not possible to label what is represented as a polygon in a vector tile because of how tile boundaries are handled. Without a link I can’t verify if the label is there or not.

6 Likes