read_plan: select mortie linestring vs shapely by grid type (HEALPix -> mortie)

[espg]

Follow-up to #43 / PR #49. plan_read (src/zagg/read_plan.py) does the within-granule segment->AOI crossing check with shapely.LineString (euclidean, confirmed fine at 20 m ATL03 spacing). It currently uses shapely unconditionally, with no grid-type awareness.

Open question from the PR thread: make the within-granule check grid-aware — when the output grid is HEALPix/mortie, use mortie linestring coverage instead of shapely.

Decide whether the two concerns stay separate (mortie for shard dispatch upstream, shapely within-granule) or whether plan_read should branch on grid type and call into mortie for the HEALPix case.

[espg]

Thoughts?

[espg]

🤖 from Claude

Design analysis — mortie linestring vs shapely in plan_read:

Currently src/zagg/read_plan.py uses shapely LineString (Euclidean) unconditionally for the within-granule segment-to-AOI crossing check. The question is whether HEALPix grids should branch to mortie's linestring coverage.

Three approaches with tradeoffs:

(A) Keep shapely for all grids — no change
At 20 m ATL03 photon spacing, Euclidean projection error within a single granule pass is small (~10 m per 100 km, well inside any usable HEALPix cell). The within-granule check is a coarse segment-crossing filter, not a precision geometry operation. Zero code change.
Downside: conceptual inconsistency — HEALPix shard dispatch uses mortie's S2 geometry, but the within-granule filter uses Euclidean. Not a correctness issue at practical photon densities.

(B) Branch on grid type (HEALPix → mortie linestring, rectilinear → shapely)
Calls mortie's linestring coverage API for HEALPix grids, giving geometric consistency end-to-end.
Downside: adds a branch, makes plan_read grid-aware (it's currently grid-agnostic). Also depends on mortie v1 interface stability (#57) — the morton_index redesign may change the linestring API surface.

(C) Defer until mortie v1 (#57) ships
The mortie interface for morton_index is still in flux; binding plan_read to the current API only to rewrite it again for v1 is wasteful. Natural sequencing: #57 ships → review mortie v1 linestring API → decide then.

Recommendation: Option (A) now, revisit after #57 resolves. The Euclidean error at ATL03 spacing is negligible for a crossing filter, and the mortie v1 API change is a real risk. The consistency argument is valid but lower priority than avoiding premature binding to a moving interface.

---

Generated by Claude Code

[espg]

🤖 from Claude

Acknowledged on the minor update. Per the analysis above and to track the deferred work cleanly, opened #60 to revisit plan_read's linestring choice after mortie v1 (#57) ships and the v1 linestring API surface is stable. That follow-up captures the three concrete checks for revisit (mortie v1 signature, the right branch seam in plan_read vs _planned_read_group, and whether the S2 path measurably changes shard membership at ATL03 cell scales vs the current Euclidean path).

This issue's decision stands as Option (A) — keep shapely LineString for all grids in plan_read for now; no code change. Leaving waiting since the decision is final and the follow-up is tracked at #60.

---

Generated by Claude Code

[espg]

... does #96 fix and close this for us?

[espg]

🤖 from Claude

Largely yes — for the path that matters (HEALPix production), #96 is exactly the grid-aware branch this issue contemplated.

What #53 asked: should plan_read's within-granule segment→AOI crossing check branch to mortie for HEALPix instead of using shapely LineString unconditionally (option B in the analysis above).

What #96 does: processing._planned_read_group now computes coarse_mask = grid.shards_of(grid.assign(seg_lat, seg_lon)) == shard_key and passes it into plan_read, replacing the per-segment shapely/bbox match with the same mortie test the photon path already uses (read.py:401). So on the HEALPix production path the segment→shard selection is now mortie/S2-exact, not Euclidean shapely — option B, landed.

One nuance — shapely isn't fully gone from plan_read: #96 keeps the bbox/LineString path as a grid-free fallback (used when no coarse_mask/grid is supplied — i.e. the offline plan_read unit tests). So #96 doesn't delete shapely from read_plan.py; it makes the production HEALPix path mortie-based and leaves shapely only as the grid-less fallback. That residual ("should the fallback path itself become grid-aware") is the bit already tracked in #60.

Recommendation: once #96 merges, the core of #53 is satisfied. Cleanest is to have #96 carry Closes #53 (I'll add a Refs #53 note to its body now) and close this on merge, with #60 carrying the leftover fallback question. Holding the actual close/relabel for your call — marking waiting here in the meantime.

---

Generated by Claude Code