Spool.select reads a bare range as SI while Patch.select reads it in the coordinate's units

[d-chambers]

Patch.select reads a bare numeric range in the coordinate's own units, while Spool.select reads it as canonical SI. For a coordinate already in SI these agree, which is why it has gone unnoticed. For any other unit they do not, and the same call returns opposite answers.

patch = ...  # x coordinate in degrees, e.g. from Patch.enrich against an EPSG:4979 inventory
spool = dc.spool(directory_of_that_patch).update()

patch.select(x=(-117.0, -116.9))   # keeps all 300 channels
spool.select(x=(-117.0, -116.9))   # 0 rows

spool.get_contents()[["x_min", "x_max"]]
# -2.0420352248333655 -- the value in radians, for a patch whose x is -117.0

get_contents() therefore reports an envelope no patch it yields actually contains, and a geographic selection silently returns nothing.

The mechanism is _CanonicalRange.for_patch_coord (dascore/utils/misc.py), which treats a bare number as a canonical SI magnitude, together with _base_unit_info in dascore/io/index/ingest.py, which stores coordinate envelopes converted with to_base_units(). Passing an explicit quantity works correctly on both paths (x=(-117.0 * dc.get_quantity("degree"), ...)), so the machinery is sound; the default reading of a bare number is what diverges.

This is not specific to degrees. A distance coordinate in feet has the same problem: patch.select(distance=(0, 100)) means 100 feet and spool.select(distance=(0, 100)) means 100 metres. Degrees just make it easy to hit, because a geographic coordinate is never in its SI base.

It predates the inventory work, but that work is what makes it reachable by default: Patch.enrich stamps geometry axes with the CRS's units, and the default CRS is EPSG:4979, so x and y come out in degrees while z is in metres. The same query is then right on one axis of a coordinate triple and wrong on the other two.

Deciding which reading is correct is the substance here. Patch.select's — a bare number means the coordinate's own units — seems the more defensible, since it is what the patch itself shows you, but changing Spool.select changes indexed-query semantics for every non-SI coordinate and deserves its own change rather than riding along with something else.

[d-chambers]

Decision on the reading: Spool.select should match Patch.select — a bare numeric range means the coordinate's own units — with a strict rule for the one case where that has no single meaning.

• When every stored definition of the coordinate in the spool carries the same unit (unitless definitions aside), a bare bound is read in that unit. This makes the spool behave exactly like a patch in the overwhelmingly common homogeneous case.
• When the spool holds the coordinate under more than one distinct unit (m and ft, deg and rad), a bare bound raises with a message telling the caller to pass a unit-qualified quantity. A bare number selects different physical intervals per file in that situation, so refusing to guess is better than a quiet split decision. This can soften to a warning later if it proves annoying.
• Quantities keep working as today on both paths.

Performance was checked before settling this: it does not fan out into per-unit queries. The distinct units already sit in the in-memory coord metadata, the bounds convert to SI in Python, and the converted thresholds become OR branches inside the existing coord_defs semi-join — same indexed scan, a few extra comparisons per candidate row. The load side gets simpler, not harder: the residual for a bare range becomes the bare tuple handed to Patch.select, which already reads it natively, so much of the user-facing _CanonicalRange plumbing can go.

None of the index code is released, so there is no compatibility cost. This lands as its own PR after #855 merges, along with showing units in get_contents() so the stored envelopes are self-explaining.

[d-chambers]

Amendment after discussion: mixed-unit archives do not raise after all. A bare numeric range simply means each coordinate definition's native units, exactly as it does on a patch — in a mixed archive that selects per-file intervals, and that is accepted behavior, same as it would be selecting patch by patch.

That choice makes the implementation simpler than either earlier sketch: store the envelopes in the coordinate's original units and put the original unit string in coord_defs.units, instead of converting to base SI at ingest. A bare query is then a single predicate straight against the native envelopes — no branching anywhere — and a quantity query converts itself once per distinct stored unit into the OR branches described above. It also fixes an existing mislabel: CoordDefRow.units is documented as the original unit string but currently holds the base unit, so a degrees coordinate reads rad in the index and get_contents() shows radians for a patch whose values are degrees.

The requirement to carry forward into the PR: it must be unmistakable that the units column and the envelope values are the ORIGINAL units as ingested, never a converted form — column naming, schema comments, and get_contents() output should all say so.

One accepted consequence, same class as the bare-query case: ordering a mixed-unit archive by such a coordinate orders by native magnitudes, which interleaves units. Unit-homogeneous archives, the normal case, are unaffected.

[d-chambers]

Correction to the framing above, checked against the last release rather than against dev.

The SI reading never shipped. On master the index describes only time, so a coordinate range on any other dimension was never evaluated by the index at all — it fell through to the patch at load, which reads it in the coordinate's own units. Verified there:

coord: 0.0 -> 981.0 ft
Patch.select bare (20,60):        22.97 -> 59.06
in-memory Spool.select bare:      22.97 -> 59.06
directory Spool.select bare:      22.97 -> 59.06
master chunk(distance=100):       10 chunks, first 0.0 -> 95.1 ft

So bare ranges have always meant native units, and get_contents() on master shows no distance columns at all — there was no radians-for-degrees display to hit. The canonical-SI storage came in with the unreleased index rewrite, which generalized indexing to every coordinate and converted their envelopes with to_base_units(). Both the divergence and the mislabeled units column are therefore regressions confined to the unreleased window, not long-standing behavior as this issue originally said.

That does not change the fix — envelopes stored in original units beside the original unit string, quantity queries converting per stored unit — but it does change what it is: PR #872 restores the released meaning rather than choosing a new one, so nothing here is a semantic change for anyone upgrading. The changelog has been rewritten accordingly, and the entry from #855 describing a chunk fix for the same unreleased regression was dropped, since its net effect for users is zero and its closing clause ("the same conversion Spool.select already performed") is no longer true.

[d-chambers]

Fixed on dev by #872.