Conversation
find_nearby_places called WithTag(key, value) once per value, producing
AND-matched filters like [amenity=restaurant][amenity=cafe][amenity=bar]...
A single element can never hold all those values at once, so every
multi-value category (restaurant, cafe, healthcare, finance, transport, ...)
returned an empty {"places":[]} result regardless of location.
Pass all values in one WithTag(key, values...) call so the builder emits
the intended OR-regex [amenity~"restaurant|cafe|..."], matching the usage
example documented in pkg/core/overpass.go.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c2e16f2842
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for _, value := range values { | ||
| queryBuilder.WithTag(key, value) | ||
| } | ||
| queryBuilder.WithTag(key, values...) |
There was a problem hiding this comment.
OR categories across tag keys as well
When the requested category maps to more than one OSM key, this still appends every key to the same global tag set, and OverpassBuilder.buildElementFilter concatenates those filters into one selector (pkg/core/overpass.go:218-220). For example category:"cafe" now emits filters like [amenity~"cafe|ice_cream"][shop~"coffee|tea"], requiring an element to have both tags, while mapCategoryToOSMTags defines those keys as alternatives (pkg/tools/places.go:258-262); the same applies to park, pharmacy, transport, and unknown multi-word categories, so those searches remain empty or severely underreported unless an object happens to carry all tag families.
Useful? React with 👍 / 👎.
Problem
find_nearby_placesreturns{"places":[]}for any category that maps to multiple OSM tag values — which includes most of the common ones (restaurant,cafe,healthcare,finance,transport, ...). It reproduces everywhere, including dense city centers, so the tool effectively can't find restaurants at all.Root cause
The handler builds the Overpass query by calling
WithTag(key, value)once per value:Each
WithTagappends a separate tag filter, andbuildElementFilterconcatenates them, so they are AND-ed:No single element can have
amenityequal to six values at once, so the result set is always empty.Fix
Pass all values for a key in one variadic
WithTag(key, values...)call. The builder's existing multi-value path then emits the intended OR-regex — and this matches the usage example already documented inpkg/core/overpass.go(WithTag("amenity", "restaurant", "cafe")):Verification (manual, against live Overpass via the MCP server)
find_nearby_places{category:"restaurant"}:Single-value categories (e.g.
pharmacy) were unaffected before and after.