Repository navigation
Interactive Explorer: Facet counts wrong when filtering by multiple facet values #304
Description
The Interactive Explorer appears to work as expected when one filters by 1 facet value. The facet counts update appropriately.
However, when one applies multiple facet values as filters (for example when one filters by "Material: Anthropogenic material" and "Specimen Type: Artifact" then the facet values are wrong.
Activity
ekansa commentedon Jun 19, 2026
Here's the URL to the problem I'm observing: https://isamples.org/explorer.html?material=https%3A%2F%2Fw3id.org%2Fisample%2Fvocabulary%2Fmaterial%2F1.0%2Fanyanthropogenicmaterial&object_type=https%3A%2F%2Fw3id.org%2Fisample%2Fvocabulary%2Fmaterialsampleobjecttype%2F1.0%2Fartifact#v=1&lat=33.1062&lng=21.5915&alt=13413424
rdhyee commentedon Jun 19, 2026
Thanks Eric — confirmed, and you've pinpointed it exactly. Here's what's going on in plain English.
You're right that it works for one filter but breaks for several. When you pick a single facet value, the counts are served from a precomputed lookup table that already knows "if this one thing is selected, here's what every other facet's count should be." That table only covers the one-filter case. The moment you select a second value (your Material: Anthropogenic material + Specimen Type: Artifact example), that shortcut no longer applies.
What happens then: at the zoomed-out / world view, instead of recalculating the combined counts, the other facets quietly fall back to their full, unfiltered totals. So the numbers you see aren't "wrong math" — they're the global counts showing through where cross-filtered counts should be. That's why it looks broken.
Two things worth knowing:
Why it's like this: computing combined counts across the whole dataset at world view used to require scanning a ~39M-row table, which stalls the in-browser database — so that path was deliberately left showing the baseline rather than hanging.
The fix: we recently shipped a compact "bitmask" index (#299) precisely so this kind of multi-filter calculation can be done in one fast pass instead of the slow 39M-row scan. The plan is to use it to compute the combined counts at world view too, so the numbers stay correct no matter how many facets you select. Related: #230, #276.
Will follow up here when the fix lands.
ekansa commentedon Jun 19, 2026
Do the fix.
Also, if a user selects a combination of filters that does not have pre-computed counts, then make sure the user interface does NOT show inaccurate numbers.
isamplesorg#304/isamplesorg#305 Phase 2: multi-filter facet counts at…
isamplesorg#304/isamplesorg#305 Phase 2: address Codex review (honest…
isamplesorg#304/isamplesorg#305 Phase 2: fix masks-catch recoupling +…
isamplesorg#304/isamplesorg#305 Phase 2: correct coverage-handshake c…
isamplesorg#304/isamplesorg#305 Phase 2: make the facetIndexReady cov…
isamplesorg#304/isamplesorg#305 Phase 3: extend mask-index counts to …
isamplesorg#304/isamplesorg#305 Phase 3: fix global-search honesty fa…
docs: plan of record for #305 facet-count coherence
#306/#305: complete per-pid facet index (sample_facet_index)
Merge pull request #308 from rdhyee/feat/304-multifilter-counts
Merge pull request #309 from rdhyee/feat/304-viewport-search-counts
#340: never show baseline facet counts under an active search
coherence: stop four more surfaces asserting numbers they don't have
isamplesorg#343 round 5: snapshot banners on the remaining current-fa…
invariant round 2: guarantee a successor on throw; make the verifier …