feat(search): spatial coverage facet + exclude world from lower-level filters#1038
Merged
Conversation
Mirror the organizations facet in get_facets() so /search/ returns a
spatial_coverages bucket list ({key,count,name,fallback}); the website
search filter seeds its choices from this aggregation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Selecting a specific area (e.g. br) OR'd in spatial_coverage_exact:"world",
so filtering by Brazil returned Brazil-only datasets plus every global
("world") dataset (294 -> 673). Global datasets are indexed as ["world"]
only (get_spatial_coverage), so the facet counts were already exclusive;
this aligns the filter results with them. Ancestor rollup is preserved
(a state still matches its country); only world is dropped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Tick the box to add this pull request to the merge queue (same as
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two changes to the
/searchendpoint that back the website's spatial-coverage filter (basedosdados/website#1594).spatial_coveragesto the aggregations.get_facets()never emitted a spatial-coverage bucket list, so the website filter had nothing to seed from. Mirrors the existingorganizationsfacet: request thespatial_coveragefacet and translate slugs viaArea(name_{locale}). Output shape matches the other facets:[{key, count, name, fallback}]. The index field,?spatial_coverage=<slug>filtering, per-result output, and/facet_values/already existed onstaging.worldfrom lower-level spatial filters. Selecting a specific area OR'd inspatial_coverage_exact:"world", so filtering by Brazil returned Brazil-only datasets plus every global dataset (e.g. 294 → 673). Global datasets are indexed as["world"]only (get_spatial_coverage), so the facet counts were already mutually exclusive; this aligns the filter results with them. Ancestor rollup is preserved (a state still matches its country); onlyworldis dropped.Test plan
Verified against a local stack (Elasticsearch + fixtures,
rebuild_index):/searchaggregations now includespatial_coverages(world,br,us, …) with correct localized names and counts.?spatial_coverage=br→ 294 (was 673);?spatial_coverage=world→ 379;?spatial_coverage=us→ 175 (no world leak);?spatial_coverage=br_sp→ 306 (São Paulo 12 + country rollup 294, no world).Not included here
The
worldArea rename to "International"/"Internacional" is a data change (updates theArearow'sname/name_{locale}; the slug staysworldbecause it's hardcoded in the filter logic and used at index time). It resolves at query time, so no reindex is needed — apply it directly on the target DB (or as a data migration) rather than via this code PR.🤖 Generated with Claude Code