Repository navigation
Fix scaleGeometry dropping polygons whose ring collapses - #933
Open
geoneutrino wants to merge 1 commit into
Open
geoneutrino wants to merge 1 commit into
geoneutrino wants to merge 1 commit into
Conversation
This was referenced Oct 28, 2026
Open
scaleRing() discards a point that repeats its predecessor only once two points are already on the output ring, so a duplicated FIRST vertex slips through. That shifts every later vertex one place along, the ring's closing vertex then matches the duplicate at j==4, and resize() truncates the whole ring to two points. scaleGeometry() drops any polygon whose outer ring has fewer than 4 points, so the feature vanishes from the tile entirely - at any size, not just for sub-pixel slivers. A clipped quadrilateral spanning ~1700 x 1600 tile units disappeared from 2 of the 4 z14 tiles covering the Rhine at 48.2098/7.6475, rendering as dry land inside the river while z13 and every lower zoom were correct. Do not fix this inside scaleRing(): its backtracking window is positional, so skipping the duplicate there shifts the whole ring and changes where later matches truncate it, silently rewriting rings that work today. That was tried first and it cost Kaptai Lake 80 of its 448 outer points, drawing a chord straight across the lake. Instead retry a ring that collapsed below 4 points without the backtracking, and only then. Rings that already survive are untouched. Verified on a Bangladesh extract with --threads 1, since tilemaker's output varies slightly between multi-threaded runs: no feature loses geometry or disappears, 1195 features are restored, and the 411 features whose geometry changes do so only by gaining area, where a restored piece is unioned into a combined feature.
geoneutrino
force-pushed
the
pr/scale-ring-duplicate-vertex-collapse
branch
from
October 30, 2026 14:40
0006c68 to
63e209d
Compare
Contributor
Author
|
Rebased onto current master. #939 does not touch scaleRing/scaleGeometry, and the bug still reproduces on master: on a 2 km OSM extract around 48.2098/7.6475 the Rhine water polygon is missing from 2 of the 4 z14 tiles, so the river renders as land there. With this PR it is present in all 4. Verified on my test extracts against master: 0 features lost, 1111 restored, and the 57 features whose geometry changes all only gain area. In each of those, every existing ring is preserved bit-for-bit and only the restored part is added. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
(small fix to not loose some small features like e.g. a small part of the river rhine in Germany. Verified agains my test data and visually approved on a planet run on all known/complex geometrie areas i know/had issues in the past)
done with help and data verification of AI
scaleRing() discards a point that repeats its predecessor only once two points are already on the output ring, so a duplicated FIRST vertex slips through. That shifts every later vertex one place along, the ring's closing vertex then matches the duplicate at j==4, and resize() truncates the whole ring to two points. scaleGeometry() drops any polygon whose outer ring has fewer than 4 points, so the feature vanishes from the tile entirely - at any size, not just for sub-pixel slivers. A clipped quadrilateral spanning ~1700 x 1600 tile units disappeared from 2 of the 4 z14 tiles covering the Rhine at 48.2098/7.6475, rendering as dry land inside the river while z13 and every lower zoom were correct.
Do not fix this inside scaleRing(): its backtracking window is positional, so skipping the duplicate there shifts the whole ring and changes where later matches truncate it, silently rewriting rings that work today. That was tried first and it cost Kaptai Lake 80 of its 448 outer points, drawing a chord straight across the lake.
Instead retry a ring that collapsed below 4 points without the backtracking, and only then. Rings that already survive are untouched.
Verified on my local test data extract with --threads 1, since tilemaker's output varies slightly between multi-threaded runs: no feature loses geometry or disappears, E.g. in Bangladesh (complex river deltas, Kaptai Lake ...) 1195 features are restored, and the 411 features whose geometry changes do so only by gaining area, where a restored piece is unioned into a combined feature.