importer: overlay carve as a declared staging kind — base table, overlay table, class map, priority (Poland #106 needs it) #118

New issue

Open

opened 2026-08-13 19:53:14 +00:00 by art · 0 comments

art commented

2026-08-13 19:53:14 +00:00

Owner

From the #116 review (finding 9, second item). docs/workstream-a.md currently nominates the #14 sankmark carve SQL as "the pattern to copy" for Poland's #106 (BDOT10k KU* airport areas over PTKM transport surfaces — the same overlay-over-coverage shape).

The concern: that pattern is per-cell union + class priority + clip + carve + class CASE + part_key, hand-written in YAML SQL. Copying it to plmap.yaml re-implements all of it — including the coverage-validity subtleties that #116's review just forced into the Sweden version (ST_CoverageClean seams, bound ST_MakeValid, piece-derived part_key) — and any future fix must then be made in N places.

The importer already owns coverage semantics (generalization_strategy: cover, partition_by, absorb_boundary). Proposal: an overlay carve as a declared staging kind — base table, overlay table, class map, priority — implemented once in the importer, so #106 (and any future overlay fold) is config, not copy-pasted SQL. Design questions to settle when implementing: class priority, per-cell vs nationwide processing, whether ST_CoverageClean is applied by the importer, and how part_key/absorption interact with the carved output.

From the #116 review (finding 9, second item). `docs/workstream-a.md` currently nominates the #14 sankmark carve SQL as "the pattern to copy" for Poland's #106 (BDOT10k KU* airport areas over PTKM transport surfaces — the same overlay-over-coverage shape). The concern: that pattern is per-cell union + class priority + clip + carve + class CASE + part_key, hand-written in YAML SQL. Copying it to `plmap.yaml` re-implements all of it — including the coverage-validity subtleties that #116's review just forced into the Sweden version (ST_CoverageClean seams, bound ST_MakeValid, piece-derived part_key) — and any future fix must then be made in N places. The importer already owns coverage semantics (`generalization_strategy: cover`, `partition_by`, `absorb_boundary`). Proposal: an overlay carve as a declared staging kind — base table, overlay table, class map, priority — implemented once in the importer, so #106 (and any future overlay fold) is config, not copy-pasted SQL. Design questions to settle when implementing: class priority, per-cell vs nationwide processing, whether ST_CoverageClean is applied by the importer, and how part_key/absorption interact with the carved output.

art referenced this issue

2026-08-13 19:53:20 +00:00

Poland: BDOT10k KU* — airport areas (KUKO02 lotnisko lub lądowisko) + airport_points #106

art referenced this issue from a commit

2026-08-15 01:58:20 +00:00

#14 review: the sankmark carve is a cell-clipped coverage — ST_CoverageInvalidEdges 1 415 → 0 on partition 23105

art referenced this issue

2026-08-15 01:58:44 +00:00

Closes #14 #116