Re-coarsen the Arkhangelsk core: RU-ARK is a single ~305k km² polygon — splitting it needs geometry clipping (a turf-op), not a pure re-partition #43

New Issue

2026-10-14T21:35:30+02:00

kamilkrzywda commented

2026-10-14 21:35:30 +02:00

Follow-up to #41 (shipped in v0.26.0) and #31 (shipped in v0.25.0).

#31 split the 78-part RU-ARK mega-region into the mainland + two island groups; #41 then re-partitioned the mainland's 28-part Arctic-coast band (centroid lat ≥ 68) into Pechora (RU-PEO) and Yamal (RU-YAM). Both were pure re-groupings of the existing polygon parts — no new geometry, byte-identical union, so a turf-free stage sufficed.

The remaining 5-part lat < 68 core (the mainland proper) stays RU-ARK under its stable key arkhangel-sk-lhbk, but it is a single ~305,229 km² polygon — by far the largest single region in the dataset (Pechora is ~37.7k km², Yamal ~51.7k km², for scale). Splitting it into smaller regions like those requires geometry clipping: the 5 parts are large contiguous landmasses whose sub-areas must be cut along a border line, producing new boundary geometry. That is a turf-op (or an equivalent turf-free clip), so the split-arkhangel.mjs / split-arkhangel-band.mjs approach does not directly apply.

Acceptance criteria

Split the RU-ARK core into a few smaller regions (target area comparable to the band regions, ~30–55k km²) by clipping the parts along land borders (e.g. a Voronoi clip on the part centroids, or explicit border polylines).
Ownership-safe: one successor keeps the existing key arkhangel-sk-lhbk (precedent from #31/#41: the largest part retains the original key so existing Nation.territory lists and SQLite ownership are untouched); the other successors get fresh region keys.
New idempotent .mjs pipeline stage (turf is allowed in scripts/), wired between the existing stages and build:region-keys; a no-op once the new features exist.
Regenerate public/region-keys.json + public/region-adjacency.json (deterministic/idempotent), update the 4 dataset/manifest tests + server/regions.test.ts (reconcile the RUS expansion count), bump the version, changelog entry, AGENTS.md note, and a wipe deploy (new keys).

Open questions

How many successor regions, and what are their names/keys?
Does the anchor successor keep arkhangel-sk-lhbk (recommended, per precedent), or should the anchor be a brand-new key and arkhangel-sk-lhbk retired? (Retiring the key would break existing ownership and require a data migration, so keeping it is strongly preferred.)

Follow-up to #41 (shipped in v0.26.0) and #31 (shipped in v0.25.0). #31 split the 78-part `RU-ARK` mega-region into the mainland + two island groups; #41 then re-partitioned the mainland's 28-part Arctic-coast band (centroid lat ≥ 68) into Pechora (`RU-PEO`) and Yamal (`RU-YAM`). Both were **pure re-groupings** of the existing polygon parts — no new geometry, byte-identical union, so a turf-free stage sufficed. The remaining **5-part lat < 68 core** (the mainland proper) stays `RU-ARK` under its stable key `arkhangel-sk-lhbk`, but it is a **single ~305,229 km² polygon** — by far the largest single region in the dataset (Pechora is ~37.7k km², Yamal ~51.7k km², for scale). Splitting it into smaller regions like those requires **geometry clipping**: the 5 parts are large contiguous landmasses whose sub-areas must be cut along a border line, producing new boundary geometry. That is a turf-op (or an equivalent turf-free clip), so the `split-arkhangel.mjs` / `split-arkhangel-band.mjs` approach does not directly apply. **Acceptance criteria** - Split the `RU-ARK` core into a few smaller regions (target area comparable to the band regions, ~30–55k km²) by clipping the parts along land borders (e.g. a Voronoi clip on the part centroids, or explicit border polylines). - **Ownership-safe**: one successor keeps the existing key `arkhangel-sk-lhbk` (precedent from #31/#41: the largest part retains the original key so existing `Nation.territory` lists and SQLite ownership are untouched); the other successors get fresh region keys. - New **idempotent** `.mjs` pipeline stage (turf is allowed in `scripts/`), wired between the existing stages and `build:region-keys`; a no-op once the new features exist. - Regenerate `public/region-keys.json` + `public/region-adjacency.json` (deterministic/idempotent), update the 4 dataset/manifest tests + `server/regions.test.ts` (reconcile the RUS expansion count), bump the version, changelog entry, AGENTS.md note, and a **wipe deploy** (new keys). **Open questions** - How many successor regions, and what are their names/keys? - Does the anchor successor keep `arkhangel-sk-lhbk` (recommended, per precedent), or should the anchor be a brand-new key and `arkhangel-sk-lhbk` retired? (Retiring the key would break existing ownership and require a data migration, so keeping it is strongly preferred.)

kamilkrzywda closed this issue

2026-10-14 22:28:56 +02:00

kamilkrzywda commented

2026-10-14 22:28:56 +02:00

Won't fix / by design — kept Arkhangelsk as a single region (current v0.26.0). We evaluated a 4×5 grid split (→17 synthetic regions), a denser 6×6 grid (→22), a seeded Voronoi, and adding a real raion source (GADM/GeoBoundaries/OSM); none are worth it versus how the map reads today, and Natural Earth has no global admin-2 layer to cut along. Reopen this if that decision changes.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: OpenCode/History#43

Re-coarsen the Arkhangelsk core: RU-ARK is a single ~305k km² polygon — splitting it needs geometry clipping (a turf-op), not a pure re-partition #43

Re-coarsen the Arkhangelsk core: `RU-ARK` is a single ~305k km² polygon — splitting it needs geometry clipping (a turf-op), not a pure re-partition #43