Make child tiles from parent rather than re-processing #158
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes the behaviour of the
cut_coords
parameter totilequeue.process.process_coord
so that anycut_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?