Introspects the release rather than being told about it, so a manifest cannot drift from the data it describes. Everything that differs between releases — which model id is public, which tables exist, which metrics are cell-level, which spatial units were scored — is read, not assumed.
Usage
manifest_build(
con,
ver,
status = "released",
grid_id = grid_for_ver(ver),
base = atlas_base_url(),
metrics = NULL,
capabilities = list(),
zone_tiles = list(),
zone_sets = NULL,
extra = list()
)Arguments
- con
open DuckDB connection to that release's database
- ver
version label
- status
released,prereleaseorretired- grid_id
defaults to
grid_for_ver()- base
atlas base URL from
atlas_base_url()- metrics
optional data frame of published metric COGs to merge in (
metric_key,subregion_key,cog,rescale_min,rescale_max); until score COGs are published thescore_cogscapability stays FALSE- capabilities
named logicals overriding the derived ones. Needed whenever a surface is NOT a table in
con: v8'scell_model, for instance, is published as a Parquet directory beside the database, so deriving fromconalone would advertisecell_species_list = FALSEand switch off a panel that works. Overrides must be justified by checking the RELEASE, not by optimism.- zone_tiles
named list of
zone_set_key-> PMTiles URL, attached to the zones table so an app resolves outlines by VINTAGE instead of a hardcoded unversioned filename on the file host- zone_sets
the zone-set registry (
data/zone_sets.csv), used to resolvezone_set_keyfor a release whose ownzonetable predates that column. Only v8 stampszone_set_keyinto the database; v1–v7 record a spatial unit astbl/fldonly, so without the registry every historical manifest comes out with nozone_set_keyand therefore nopmtiles— the app then cannot draw a single zone outline on any version but the newest.- extra
named list merged into the manifest (e.g.
zone_sets)