Make child tiles from parent rather than re-processing

[zerebubuth]

This changes the behaviour of the cut_coords parameter to tilequeue.process.process_coord so that any cut_coords ("children") are created by clipping the post-processed features of the main ("parent") tile rather than re-processing the children from the original, un-processed features.

This is likely to be faster, but probably only marginally as we currently only use cut_coords for tiles at zooms over 16, which generally have negligible post-processing time.

However, it does change the behaviour; re-processing the children tiles meant that post-processing filters would be run with the zoom of the child tile, whereas with this change it will just contain a subset of the data in the parent tile, which was post-processed at the zoom of the parent tile. This probably isn't an issue for zooms over 16, as we don't have any zoom-dependent processing there which would be different from zoom 16. This new behaviour is the desired behaviour for making 512px / 256px tiles, for which we want the content to be the same.

@rmarianski, @iandees could you take a look, please?

[nvkelso]

Related to https://github.com/mapzen/tile-tasks/issues/196.

[nvkelso]

Can you add a linked PR for changing the default max zoom config to 15 (versus current zoom 16), please?

[zerebubuth]

@nvkelso I don't think the code is ready for that yet. I'm trying to make as many small, independent changes as possible, so that it's friendlier to reviewers than a large PR or interdependent set of PRs. Changing the max zoom is likely to be one of the final changes.

[nvkelso]

So this code expands the meta-tile to 2x2 at the existing zoom (display only), so the meta-tile spacing is 2x2, and every meta-tile then has a 512px tile and four 256px tiles packed inside it?

[zerebubuth]

So this code expands the meta-tile to 2x2 at the existing zoom (display only), so the meta-tile spacing is 2x2, and every meta-tile then has a 512px tile and four 256px tiles packed inside it?

Unfortunately, there's still a long way to go until that's all working!

The only change here is to the behaviour when specifying cut_coords - which are currently only specified for z17+ tiles when rendering the z16 tile "parent". Previously, the post-process functions were run at the child tile's zoom, but now the child tile will be made from the parent, so will contain content post-processed at the parent's zoom.

I don't think this makes any difference to how we're currently using the code, as everything that's in the tile at z16 is in z17+ tiles too - it's what allows overzooming them in Tangram without problems.