Skip to content

expose the zagg-pyramid/2 fixed ladder as a multiscale / datatree view #36

Description

@espg

🤖 from Claude (filed at espg's direction, 2026-08-05; companion to the /2 heads-up on issue #1)

Motivation

Once zagg-pyramid/2 lands (englacial/zagg#389; design record englacial/zagg#381), every /2 store is inherently multiresolution: a guaranteed ladder at every HEALPix order from 0 through the base (two numbers — parent_order and d — determine the whole above-shard geometry), recorded fully expanded in block-level pyramid.overviews. Today the reader surface is per-level opens; the store's actual identity wants a resolution-aware view.

Scope

  • open_hive (or a sibling entry point) returns a multiscale view: a datatree with one dataset per order, or a resolution= selector — decode the expanded manifest list verbatim, never derive.
  • Surface the per-entry provenance as level metadata once the staged sweep lands it (fold regime, source_children, merges-from-raw — pyramid v2: staged dense sweep on the partition machinery englacial/zagg#384), so users can filter levels by generation.
  • Honor the upgraded accuracy doctrine in the API docs: exact-class fields are exactly correct at every order (true downsampling pyramid); approximate-class fields are analysis-grade at their recorded generation — not display-only.
  • Zoom-out ergonomics: the ladder roots at order 0 for every store (≤ 12 root artifacts world-view), which is the natural default level for a first render (relevant to the issue Percentile-surface materialization: dense (quantile, cells) views for the gridlook feeder #21 gridlook feeder).

Notes

Refs issue #1 (plan), #21 (percentile-surface feeder), #31 (all-time surface — unaffected in posture, stays in the family dict).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions