Commute-Aware Search with Isochrone Heatmaps & Lifestyle Filters

Description

Help buyers discover homes that work for their life, not just their budget. Add a Commute-Aware Search that lets users set one or more destinations (work, school, partner’s work, etc.), preferred travel mode (drive, transit, bike, walk), and max commute time windows (e.g., 8–9am). Show isochrone heatmaps on the map, filter listings within those travel-time areas, and rank results by composite lifestyle score (commute + essentials like grocery/parks/gyms + school proximity).

This fits EstateWise’s agentic/AI stack by letting the chatbot factor commute constraints and local amenities directly into its recommendations and visualizations.

---

Motivation / Value

• Buyers routinely discard otherwise “perfect” listings due to commute pain.
• Visualizing where they can live within X minutes saves time and boosts trust.
• Differentiates EstateWise with explainable scoring: “This home ranks #1 because 21-min commute, 0.6 mi to a grocery, A-rated elementary zone.”

---

Scope (In)

• Commute Profiles (multiple per user): destinations, modes, windows, thresholds.
• Isochrone generation: draw travel-time polygons and cache results.
• Listing filter + re-rank: only show homes inside isochrones; add lifestyle signals.
• Map UI: toggleable heatmaps, pins for destinations, legend and score badges.
• Chat integration: “Find homes within 25 min of UNC campus by bus and near a park.”

Out of scope (initially)

• Street-level incident/parking data.
• Real-time traffic predictions beyond a chosen provider’s capabilities.

---

Acceptance Criteria

1. Commute Profiles
   • Users can create, name, and save multiple profiles (e.g., “Weekday Work”, “Kid’s School”).
   • Each profile supports 1–3 destinations, mode per destination, time window(s), and max minutes.
2. Isochrone Heatmaps
   • Map shows accurate travel-time polygons per profile with a clear legend.
   • Toggling the profile updates the map and listing results within 2–5s on cached queries.
3. Filtered Results
   • Search results restrict to listings inside the active isochrone(s).
   • If multiple destinations are set, obey AND (intersect) or OR (union) mode as selected.
4. Ranking
   • Results display a composite score (0–100) based on commute time, amenity distance, and school zone signal; hover/expand reveals the breakdown.
5. Chat Experience
   • The AI accepts commute constraints in natural language and returns filtered, scored homes with a short rationale per home.
6. Persistence & Privacy
   • Commute Profiles stored in MongoDB per user; PII handled securely (see Security below).
7. Performance
   • Subsequent identical isochrone requests are served from Redis cache.
   • P95 isochrone + search end-to-end under 4s on cached hits, under 8–10s on cold calls.
8. Tests & Docs
   • Jest unit tests & integration tests for API/ranking; Playwright E2E for map + filtering.
   • Swagger updated; user help tooltip explains commute modes, union/intersect, and scoring.

---

API & Data Model (proposed)

Endpoints

• POST /api/commute-profiles — create profile
• GET /api/commute-profiles — list profiles
• PUT /api/commute-profiles/:id — update
• DELETE /api/commute-profiles/:id — remove
• POST /api/commute/isochrone — returns polygon GeoJSON for { destinations[], mode, window, minutes }
• GET /api/search — accepts commuteProfileId, combine=intersect|union, and returns filtered + ranked listings

MongoDB (Mongoose)

• CommuteProfile:
  • userId, name
  • destinations[]: { label, lat, lng, mode: 'drive'|'transit'|'bike'|'walk', window: '08:00-09:00' }
  • maxMinutes (per destination or global)
  • combine default 'intersect'

Redis

• isochrone:{hash} → cached GeoJSON + TTL

---

Ranking (initial weights, configurable)

• Commute score (60%): scaled by minutes vs. threshold.
• Amenities (25%): inverse distance to nearest grocery, park, gym (basic Points-of-Interest set).
• Schools (15%): zone rating signal (coarse: A/B/C or distance to zoned school).

Formula: score = 0.60*C + 0.25*A + 0.15*S → 0–100 with caps and floors; include per-factor tooltips.

---

Security & Privacy

• Store only destination coordinates + user label; do not store full postal addresses unless user opts in.
• Encrypt destination labels at rest if sensitive; ensure TLS in transit.
• Expose only aggregate commute metadata to the UI; never reveal other users’ profiles.
• Rate-limit isochrone endpoint; validate lat/lng & modes; sanitize inputs.

---

Tasks

• Backend
  • CommuteProfile model + CRUD endpoints
  • Isochrone service + provider abstraction (e.g., Mapbox/ORS/Google) with Redis caching
  • Listing filter by polygon (point-in-polygon or server-side geospatial query)
  • Ranking service with tunable weights and amenity lookups (seed a minimal POI set)
  • Swagger docs, request validation (zod/joi), auth guards
• Frontend
  • Profile editor (add destinations, pick mode, set time window/minutes, union/intersect)
  • Map overlay for isochrones + destination pins (legend, toggles)
  • Results panel: score badges with breakdown tooltip; empty-state guidance
  • Chat command patterns for commute (“within 25 min of UNC by bus”)
• AI Integration
  • Prompt hooks so the agent can read active commuteProfileId and call search tool
  • Response explainer: 1–2 lines describing why each listing ranked highly
• Quality
  • Jest unit & integration tests (isochrone caching, polygon filter, ranking math)
  • Playwright E2E: create profile → draw heatmap → filter → rank → chat confirm
  • Analytics: track feature adoption and latency, log cache hit ratio

---

Risks & Mitigations

• Isochrone latency / rate limits: cache aggressively; batch requests; exponential backoff; per-user quotas.
• Amenity data coverage: start with a small curated POI file; make the layer pluggable for future sources.
• Ranking subjectivity: keep weights configurable; expose rationale; allow tweak via admin.

---

Estimated Effort

~2–3 sprints (MVP heatmap + filter + ranking), plus 0.5 sprint for polish & analytics.