Repository navigation
穴の結合で、近くにある穴の面積を失わないようにし、速くする - #32
Merged
Merged
Conversation
…r edge The union keeps a sub-edge when the union's interior is on exactly one side, sampled at a fixed 1e-5 degree (about 1 m) off its mid-point. Where another hole runs closer than that, the sample lands inside it: the edge looks interior on both sides, is dropped, and the traced ring cuts across a hole. Rounded to 1e-5 degree, Boston's street parcels have many holes one unit apart; their holes lost up to 21% of their area and whole blocks were filled. The offset is now at most half the distance from the mid-point to the nearest other sub-edge, which after splitting cannot be crossed. Same change as js-sdk-core's PolygonUnion.ts and android-sdk-core's PolygonHoleUnion.kt. Resources/polygon-hole-union-fixture.txt (the same file as in js-sdk-core and android-sdk-core) holds holes that touch at a point, share an edge or part of one, chain, overlap, run one unit apart, or touch the outline, at 1e-5 and 1e-6 degree, and two Boston street parcels; the expected areas are shapely's.
Splitting tested every edge against every other, and the clearance added for the side samples scanned every sub-edge again: both quadratic in the hole edges. Boston's 104 street parcels with two or more holes (89,589 hole edges) took 2.1 s in node; on the Android tablet (debuggable) the ten that need a union took 5.2 s before the polygons reached the map. Edges are now filed in a uniform grid over their bounding boxes, and splitting and the clearance ask only the edges near a box. The box is padded by the farthest intersectionPoints can reach past a segment (its collinear test, 2e-6 degree), so the same edges meet and every output ring is the same as before, coordinate for coordinate: checked on the 26 fixture cases and the 104 Boston parcels, as rounded and as bundled. Coverage skips a ring whose latitudes do not straddle the sample point, which pointInRing would count as outside anyway. Boston, 104 parcels: node 2.1 s -> 0.26 s, JVM 1.09 s -> 0.14 s.
This was referenced Nov 9, 2026
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.
なぜ
ポリゴンの穴が近くにあると、
unionHoleRingsが穴の面積を失い、穴のはずの所が塗られていました。ボストンの道路区画（穴が 100 個ほどある 1 つのポリゴン）では、穴の面積を最大 21% 失い、街区がまるごと灰色に塗られていました。結合後の輪郭を決めるとき、各辺の両側の点が穴の外か内かを調べています。その点を、辺から常に 1e-5°（約 1 m）横に取っていました。1 m より近くに別の穴の辺があると、点がその穴の中に入ります。すると必要な辺が捨てられ、作り直した輪郭が穴を横切っていました。穴どうしが接していること自体は原因ではなく、接していると結合が動くので表に出ていただけです。
develop では穴が 2 つ以上あるポリゴンはすべて結合を通るので、穴が離れているデータでも起きます。ボストンの同梱データでは 53 ポリゴンで、最大 20.8% の面積を失っていました。
何を変えたか
検証
polygon-hole-union-fixture.txt、26 ケース）を読みます。正解の面積は shapely の union から取りました。結合の時間（ボストンの穴が 2 つ以上ある区画 104 件、MapLibre）：
確認できていないもの
Polygonsの effect が 2 回走るため、結合も 2 回走ります。前からあるもので、2 回目は約 50 ms です。feat/polygon-tilingにも同じ不具合があります。develop を取り込めば直ります。