9a955f8f20
rega measured ~3.6 MB of boundary GeoJSON costing 5-6 s of MapLibre worker parsing before the first territory draws, on every partner page. These copies are for interactive maps; the full files stay for posters, print and build-time point-in-polygon. world-adm0-web.geojson 1,866 KB -> 383 KB (gzip 596 -> 134) 162 features, 572/572 parts gb-IND-ADM1-full-web.geojson 1,796 KB -> 227 KB (gzip 451 -> 69) 36 features, 452/452 parts gb-IND-ADM1-web.geojson 1,628 KB -> 178 KB (gzip 412 -> 55) 34 features, 40/40 parts, listId kept (gb-CHN-ADM1 is 56 KB already: no copy) library/scripts/boundaries/build-web-boundaries.mjs writes them with mapshaper (pinned 0.6.121, via npx; not a repo dependency): -explode, then topology- preserving Visvalingam with keep-shapes, then -dissolve with every other property copied. The explode makes each island its own shape, so keep-shapes protects every one: without it, the world drops from 572 to 240 parts. The run FAILS on a changed feature count, a lost key, a changed property or a dropped part. Negative-tested (without -explode: 297/572 parts -> FAIL), and a second run writes identical bytes. Measured (_qa-cycle/03-deployment-cycle/REPORT-WEB-BOUNDARIES.md): median area error 0.57% (world), 0.04% (India). Of 14,486 real people-group points, 95.9% stay in the same country in the world file and 99.9% in the India file; the misses are archipelago coasts. No runtime code does point-in-polygon on these files, so this is visual only. Not wired: consumers still fetch the full files, and generate-tree does not stage the -web copies yet. Both are in the report's switch table. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.