Preamble: this came out of a Claude-assisted brainstorming session while looking at related census-tooling issues across griddy and bayesiansurpriser. Filing it as a discussion starter rather than a hard ask — happy to drop or rescope any of it.
When using tongfen for longitudinal work (e.g. dynamics analysis across multiple census vintages, or comparing model-based scores like Bayesian surprise across years), I keep wanting to ask the output two questions that aren't easy to answer today:
- Which source regions does this target inherit from, and at what weight?
- How comparable is this target across vintages — is it intact, a split, a merge, or substantially redrawn?
Tongfen already has the building blocks: TongfenID/TongfenUID keys, TongfenMethod, check_tongfen_areas's max_log_ratio, and tongfen_tag_largest_overlap. This proposal is about surfacing the underlying provenance more directly so users can audit and filter without re-deriving it.
Proposed additions (all backward-compatible):
estimate_tongfen_correspondence() gains a weight column (area- or pop-based, configurable) on the long-format correspondence so the contribution of each source to each target is explicit.- Derive a
change_class ∈ {intact, split, merge, redrawn, novel} column from the correspondence (cheap given TongfenID).
tongfen_aggregate() output retains the correspondence used via attr(out, \"tongfen_correspondence\") — no breaking change to the columns of the returned object.- A small
tongfen_comparability_score() helper combining max_log_ratio, weight entropy, and method into a per-target 0–1 score downstream code can threshold against.
- Optional
plot_tongfen_provenance() — map of change-class by target, useful for sanity-checking a longitudinal study area.
Related: #2 covers error propagation through downstream analysis when tongfen_estimate is used; this issue is complementary, focused on transparency rather than statistical error modelling. Happy to draft a PR if any of this is welcome — could split it into two (the weight + change_class work, and the score/plot helpers).
Preamble: this came out of a Claude-assisted brainstorming session while looking at related census-tooling issues across griddy and bayesiansurpriser. Filing it as a discussion starter rather than a hard ask — happy to drop or rescope any of it.
When using tongfen for longitudinal work (e.g. dynamics analysis across multiple census vintages, or comparing model-based scores like Bayesian surprise across years), I keep wanting to ask the output two questions that aren't easy to answer today:
Tongfen already has the building blocks:
TongfenID/TongfenUIDkeys,TongfenMethod,check_tongfen_areas'smax_log_ratio, andtongfen_tag_largest_overlap. This proposal is about surfacing the underlying provenance more directly so users can audit and filter without re-deriving it.Proposed additions (all backward-compatible):
estimate_tongfen_correspondence()gains aweightcolumn (area- or pop-based, configurable) on the long-format correspondence so the contribution of each source to each target is explicit.change_class ∈ {intact, split, merge, redrawn, novel}column from the correspondence (cheap givenTongfenID).tongfen_aggregate()output retains the correspondence used viaattr(out, \"tongfen_correspondence\")— no breaking change to the columns of the returned object.tongfen_comparability_score()helper combiningmax_log_ratio, weight entropy, and method into a per-target 0–1 score downstream code can threshold against.plot_tongfen_provenance()— map of change-class by target, useful for sanity-checking a longitudinal study area.Related: #2 covers error propagation through downstream analysis when
tongfen_estimateis used; this issue is complementary, focused on transparency rather than statistical error modelling. Happy to draft a PR if any of this is welcome — could split it into two (theweight+change_classwork, and the score/plot helpers).