Skip to content

Venue coordinates + radius search on Find Eligible candidates (2dsphere; coords sourced from UI via Places) #989

Description

@JoshuaVSherman

Hi Opus I am confused on the ordering here, is this issue currently blocked by upstream dependencies or is it ready to be worked by Sonnet (or Flash High), we need to discuss and also cleanup the description some because it is confusing.

Design SETTLED with Josh 2026-07-19 (Fable) — no longer a spike. Radius search for Find Eligible: "venues within N miles of a point", not just exact-city matching.

Design

  • Coordinates are sourced from the UI only — JaMmusic#1244's Google Places autocomplete on the venue address field returns exact coordinates when Josh picks an address; they are saved with the venue. No server-side geocoding, no Google calls from wjb, and NO backfill of existing records (Josh's standing rule). Venues gain coordinates as Josh creates/edits them through the form.
  • Hard rule (unchanged): never store an approximated or city-centroid coordinate. A venue either has the exact pin Places returned for its street address, or it has no coordinates.
  • Schema: GeoJSON Point field (e.g. location: { type: "Point", coordinates: [lng, lat] }) + 2dsphere index. Optional — most records won't have it initially.
  • Query: the Find Eligible candidates endpoint accepts optional lat, lng, radiusMiles params. When present, add a geo filter ($nearSphere/$geoWithin) ON TOP of all existing eligibility rules (outreachEligible, valid email, cooldowns, gigInterval — nothing replaced). Venues without coordinates never match a radius query.
  • Center point comes from the UI too: the Find Eligible screen gets a Near: [Places search box] within [N] mi control (JaMmusic issue, filed separately). Josh can type ANY city/address — chosen deliberately over a venue-cities dropdown so he can prospect territory with zero existing venues (decision discussed in detail 2026-07-19; do not re-litigate).

Order

  1. JaMmusic#1244 (Places autocomplete + capture coordinates) — prerequisite; also carries the GCP enablement steps (Places API + key permission, commands in that issue, billable).
  2. This issue — schema field + 2dsphere index + radius params on the candidates endpoint. Can build in parallel with #1244 (the field just stays empty until the UI writes it), but is pointless to ship first.
  3. JaMmusic Find Eligible "Near" control — blocked on this issue + #1244.

Non-goals

  • No backfill/migration of coordinates for existing venues.
  • No server-side geocoding, ever, in wjb.
  • No changes to eligibility rules themselves.
  • Tour-building / clustering around a booking: later, on top of this.

Acceptance

With one venue re-saved through the form (so it has a pin): a candidates query with lat/lng/radiusMiles covering it returns it; the same query centered 100 miles away does not; venues without coordinates are unaffected in non-radius queries and absent from radius ones.

🤖 Design by Claude Code — Fable 5

Metadata

Metadata

Assignees

No one assigned

    Labels

    JoshManual step only Josh can do — no agent can perform itOpus

    Type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions