Skip to content

Versioned Coordinate Atlas

Coordinate register — instantiates Neighborhood-Preserving Substrate Mapping

Keeps every released version of the map's coordinate system side by side with its provenance, so any point's address can be traced, compared, and translated across versions.

A map that lives changes — recomputed, re-tiled, extended — and every change silently invalidates the coordinates other systems have already stored. Versioned Coordinate Atlas is the register that prevents that. It keeps every released version of the map's coordinate system side by side, each stamped with its provenance (how it was built, from what, when), organised across scales, and indexed so that any point's address can be traced to a version, compared across versions, and translated between them. Its defining idea is that coordinates are treated as versioned, citable artifacts rather than a live, mutable surface: the atlas is both the memory and the authority that keeps "where is X?" answerable across time.

Example

Genome positions are given as coordinates on a reference build, and the "same" gene sits at different numeric positions on GRCh37 and its successor GRCh38. A versioned coordinate atlas is exactly how the field keeps this straight: each build is a released map version with provenance — assembly method, date, contributing data — stored alongside the others, with liftover chains that translate a coordinate on one build to its counterpart on another.[1] A lab holding a decade of variant calls on GRCh37 can, through the atlas, locate those same variants on GRCh38 without redoing the science, and can cite exactly which build a result was expressed in. Without the atlas, a coordinate is a bare number whose meaning drifts; with it, every position stays traceable and translatable.

How it works

  • Freeze and publish each map version as an immutable release.
  • Attach provenance to every version — inputs, method, parameters, date, author.
  • Store across scales — aggregated zoom levels kept mutually registered to the detailed map.
  • Maintain translation chains between versions so a coordinate can be lifted from one to another.
  • Index the whole as a bank so the right version, and the right context-specific map, can be retrieved on demand.

It remembers and translates; it does not compute the alignment transform itself, nor decide when a new version is warranted.

Tuning parameters

  • Version granularity — release on every change (full traceability, heavy) or at milestones only (lean history, coarser lineage).
  • Provenance depth — a bare version tag, or full lineage that lets a version be reproduced and audited.
  • Scale-hierarchy levels — how many aggregated zoom levels to store and keep registered to the base map.
  • Translation coverage — liftover chains between every version pair (costly, direct) or only between adjacent versions (cheap, multi-hop).
  • Retention / deprecation — how long old versions stay first-class before archival; retire too aggressively and old references break.

When it helps, and when it misleads

Its strength is making coordinates durable and citable: old work stays locatable, results stay reproducible, and downstream systems can pin to a fixed version instead of chasing a moving surface.

Its failure mode is that an atlas is only as trustworthy as its translation chains — a lossy or approximate liftover silently corrupts coordinates that look cleanly translated, and provenance recorded but never verified quietly rots. The classic misuse is treating a translated coordinate as exact when the liftover between versions was approximate, in regions that do not map cleanly at all. The discipline is to mark untranslatable or ambiguous regions explicitly rather than force a translation, and to verify provenance rather than trust the stamp.

How it implements the components

  • map_version_and_provenance_trace — its core: every version stored immutably with the full lineage of how it was built.
  • multi_scale_map_hierarchy — versions are held across registered zoom/aggregation levels, so a coordinate resolves at any scale.
  • context_specific_map_bank — the indexed collection from which the right version, or the right context's map, is retrieved.

It does not compute the transform between two versions — that is Map Registration and Alignment — and it does not decide when a new version is warranted (Adaptive Remeshing and Reallocation).

Notes

The atlas stores versions and serves translations, but the translations themselves are computed elsewhere: Map Registration and Alignment derives the transform between two versions, and the atlas records and re-serves it. The two are partners — the atlas is the memory, registration is the bridge — and conflating them tends to produce an atlas that stores transforms nobody validated.

References

[1] Liftover is the standard operation for translating genomic coordinates between reference builds (for example GRCh37 to GRCh38). It is reliable only where the builds correspond; regions that were rearranged between builds have no clean mapping, which is why a good atlas marks them unmappable instead of guessing. ↩