Interactive Explorer: Facet counts wrong when filtering by multiple facet values

[ekansa]

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.

[ekansa]

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]

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:

• The map itself is still correct. The dots/samples shown are properly filtered by all your selections — it's specifically the facet count numbers that mislead in this case.
• Zooming in fixes the counts. Once you're not at the world view, the counts are recalculated live and do reflect all active filters. So this is specifically a zoomed-out-view problem.

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]

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.