Fix bad interaction between dynamic dropping and limiting by truncation #260
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.
The safety checks added in #257 had another negative interaction of their own: when there were enough features in a tile that they hit the feature limit before they had all been deserialized, but there was also an abrupt feature limit set with
--limit-tile-feature-count
, it would still try to find features to drop dynamically, getting into a loop looking for them. Now when the abrupt limit is applied, it will stop looking for the graceful limit.The new test demonstrates the problem by making a tile that has more features than the drop-as-needed feature count limit, which in turn is greater than the drop-abruptly feature limit. With recent versions of tippecanoe it would get stuck in a loop.