Some editing software uses this to hint what type of layer something is. It's not documented, but per https://gist.github.com/springmeyer/bbf49c89180485f477b9 from mapbox/tilejson-spec#14 it's a geometry key which is set to polygon, line, point, or unknown.

Instead of defaulting to 0 and 14, the min and max zoom should come from the configuration being generated

I want to rewrite how tilekiln stores tiles. Although loose tiles on-disk can work for planet-sized datasets, it's a pain, particularly when it comes to deleting them. Because local tile creation needs to remain a first-class option, this can't be solved by pushing tiles to an object store.

A few options to consolidate multiple tiles are

1. PMTiles

PMtiles would be my preferred format to store and distribute tiles in, but it's not clear to me that it supports the operations needed for just updating one tile, like what happens in an incremental update. My reading of the format is that it would also be more difficult to parallelize the work then write back to a single PMtiles file, as stuff like deduplication would require tracking across all workers.

2. MBTiles

MBTiles is sqlite-based, so in theory supports updates. In practice, sqlite, and thus mbtiles, does not work well when handling high-concurrency writing of updates, or handling reading and writing of updates at the same time. MBTiles support is the best of all options, with lots of people having written tools for them.

3. Tapalcatl

Tapalcatl 2 would still use multiple files, but reduce the number of files by a couple of orders of magnitude. Within an individual ZIP archive the tile writing work couldn't be done in parallel, but in practice this isn't an issue because there are enough ZIP archives to split work across them.

ZIP archives have some functionality for updating in place, which would require one worker updating files on disk to handle all the tiles in that archive, which is practical. Or, the entire archive could be regenerated, because if an individual tile in an archive has changed, odds are good others at the same zoom have changed, and it's guaranteed some at lower zooms will have changed.

The biggest issue is that it isn't open source yet.

If every query is going to need ST_AsMVTGeom(way, {{bbox}}, {{extent}}) AS way then it should be a j2 function.

MVT is what the spec says to use, not PBF

After cleaning out everything I think I saw an error where multiple processes tried to create the directory and failed

Tilekiln generates each layer independently and concatenates them in Python. This works well for development because SQL errors are clearer, and it's easier to profile to get per-layer performance information.

Doing all the layers in one complex SQL statement should be faster, with fewer round-trips to the server.

The general form of the current SQL is

WITH mvtgeom AS (SELECT contents...)
SELECT ST_AsMVT(mvtgeom.*)
FROM mvtgeom

This will need some adjustment to be more like

SELECT ST_AsMVT(mvtgeom.*)
FROM (SELECT contents...) AS mvtgeom

This will then allow

SELECT string_agg(t)
FROM (
SELECT ST_AsMVT(mvtgeom.*) t
FROM (SELECT contents1...) AS mvtgeom
UNION ALL
SELECT ST_AsMVT(mvtgeom.*) t
FROM (SELECT contents2...) AS mvtgeom
) AS tiles

How should tilekiln respond to a failure in one of the jobs? It could

1. exit as soon as possible,
2. skip the rest of the tiles in that chunk, or
3. render everything else and exit with a return value of 1.

Are there any command-line flags that should be added to change its behavior?

@rory, what's your expectation from tirex/renderd?

https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

Right now it's an optional part of the config. Should it be required? Are there use cases for a config without any layers?

For small tiles I'm finding that an increasing percentage of time is being spent in tilekiln instead of in postgres generating tiles

The config file calls for a two-number array for center, but the tilejson spec calls for three, including the zoom.

Currently the SQL is generated by wrapping the user-supplied SQL and processing the wrapped jinja2 string as a j2 template.

https://github.com/pnorman/tilekiln/blob/6c32f13a544dc828fd84f32dcf91bf9195fe653d/tilekiln/definition.py#L45-L54

This lets the wrapped SQL refer to variables like {{extent}} but comes with the downside that the wrapping SQL has to be jinja safe. This does not work in a few cases

• a layer name could be a j2 variable
• testing the SQL generation functions is difficult

This needs to be rewritten to have the inner SQL processed as a j2 template then wrapped in SQL with python's format function.

Needed are

• extent
• geom_name
• buffer
• clip_geom

Each object in the vector_layers array should have a min and max zoom property.