Skip to contents

The ONE zone table each spatial unit publishes

Source: R/app_bundle.R
app_zone_tbl.Rd

A release may carry more than one zone.tbl for a single fld. v2 has two for subregion_key — ply_subregions_2025 (AK, AKL48, L48, USA) and ply_subregions_2026 (AK, GA, PA, USA), two keys in common — and because app_zone_taxon() dropped zone_tbl, (zone_fld, zone_value, key) came out duplicated 13,077 times: the same taxon in the same subregion with two different area_km2. The app would have listed every taxon twice.

Usage

app_zone_tbl(con, manifest = NULL, geom_keys = list(), zone_sets = NULL)

Arguments

con

a DBI connection to a release database

manifest

the release's published manifest (atlas_manifest(), or the manifest.json beside the database); its zones[] rows name the table per field. A manifest rebuilt by manifest_build() is not acceptable here — it has already collapsed the rows this needs — and one whose zones lack zone_set_key is refused.

geom_keys

named list zone_type -> keys present in the published geometry, checked against the manifest's choice

zone_sets

the zone-set registry (data/zone_sets.csv), cross-check only

Value

a data frame fld, tbl, why, n_tables, one row per field

The manifest decides

The release's own manifest.json names the table. Its zones[] rows carry fld and tbl, and v2's says subregion_key -> ply_subregions_2025 (zone_set_key: subregion_2025-06). That is the first and normally the only evidence, and it is already an input of app_bundle_build().

Everything else is a check, not a second opinion:

  • geom_keys — the keys in the published geometry — must AGREE with the manifest. A disagreement means the notebook was handed the wrong GeoPackage, which is a defect to stop on, not a tie to break.

  • zone_sets — the registry's source basename — is a cross-check, recorded in why, never a chooser.

There is no fallback guess. A field with two tables and no manifest row is an error: "most recent date_created" looked reasonable and picked ply_subregions_2026 for v2, whose keys match no published geometry — two defensible answers depending on who called, which is the ambiguity this rule exists to remove.

The winner is recorded in boot$units[].zone_tbl so the notebook's geometry check can assert its GeoPackage holds the same keys.