# Sidewalk Gap Mapper: Walkability Barrier Reporter ## The Problem Pedestrian infrastructure in many neighborhoods is dangerously incomplete—sidewalks that abruptly end at property lines, curb cuts that don't exist where crosswalks do, and crumbling segments that become impassable for anyone using mobility aids. Residents currently have no systematic way to document these hazards, leaving city planners without data and community members without safe route alternatives. Meanwhile, ADA compliance complaints require specific evidence that doesn't exist because no one's been collecting it. ## Who Uses It **Daily Route Planners**: Wheelchair users, parents with strollers, and elderly residents who need to know *before* they leave home whether their path is actually passable, not just theoretically sidewalked on Google Maps. **Neighborhood Advocates**: Block captains, disability rights advocates, and safe-routes-to-school organizers who need documented evidence of infrastructure failures to present at city council meetings and include in grant applications. **City Officials & Planners**: Public works staff and elected officials who want constituent-sourced data on where infrastructure money would make the biggest impact, without commissioning expensive surveys. **Local Business Owners**: Shop owners who want customers to be able to safely walk to their doors—and who might champion specific gap fixes that affect their foot traffic. ## Core Features 1. **Quick-Report Drop Pin**: User taps map or uses current GPS location to drop a pin, selects hazard type (missing sidewalk segment, no curb cut, severe damage, obstruction), adds optional photo, and submits in under 30 seconds. 2. **Hazard Type Classification**: Structured categories that map to ADA compliance language: "Sidewalk Ends" (no continuation), "Missing Curb Cut" (no ramp at crossing), "Width Under 36 Inches," "Surface Impassable" (cracks/heaving), "Temporary Obstruction" (construction, overgrowth). Each generates appropriate urgency signals. 3. **Community Verification Voting**: Other users can "confirm" or "mark resolved" existing reports. Reports with 3+ confirmations get elevated priority badge. Reports marked resolved by 2+ users get archived with date (creates historical record of fix timeline). 4. **Safe Route Overlay**: Map layer showing reported gaps lets users visually plan routes that avoid danger zones. Color-coded severity: red for total barriers, orange for difficult, yellow for minor obstacles. 5. **Auto-Route Officials**: One-click button on any report to send a formatted email to relevant elected officials, pulling contact info from WellSpr.ing's officials endpoint. Email includes photo, location coordinates, hazard type, and confirmation count. 6. **Neighborhood Priority Dashboard**: Aggregated view showing which blocks have the most reported/confirmed gaps, sorted by density. Exportable as PDF "Infrastructure Brief" for council presentations or grant applications. 7. **Accessibility Score by Block**: Simple 1-5 star rating auto-calculated from report density per block, shown on map. Lets advocates quickly say "This corridor scores 1.5 stars for wheelchair accessibility" with data behind it. ## WellSpr.ing Integration Points **MCP Tool: `get_city_services`** Pull current city services related to sidewalk repair, ADA compliance offices, and public works departments. Display relevant contact info alongside reports so users know where official channels exist. **MCP Tool: `get_civic_ideas`** Check if similar walkability initiatives already exist in the local civic idea pool. Surface related efforts on the landing page to encourage collaboration rather than duplication. **MCP Tool: `ask_ody`** Power a help feature where users can ask natural language questions: "How do I file an ADA complaint about missing curb cuts?" or "What's the city process for requesting sidewalk repairs?" Ody provides contextual local guidance. **MCP Tool: `search_civic_services`** When user files a report, search for relevant civic services (disability services offices, neighborhood associations, pedestrian advocacy groups) and surface them as "Organizations working on this" in the report detail view. **REST Endpoint: `GET /api/officials`** Fetch elected officials with contact info for the "Route to Officials" feature. Match official jurisdictions to report locations when possible. **REST Endpoint: `GET /api/geo/portals?area_code=NNN`** Determine which geographic area a report falls into for proper routing and dashboard aggregation. Use portal boundaries to organize reports by neighborhood/district. **Future: Covenant Commerce** *Roadmap: not yet live* — Eventually, local hardware stores or contractors could offer discounted materials/services for community-prioritized repairs, surfaced alongside high-priority gaps. ## Data Model ### reports | Field | Type | Notes | |-------|------|-------| | id | uuid | Primary key | | location | point | GPS coordinates | | hazard_type | enum | sidewalk_ends, no_curb_cut, width_violation, surface_impassable, obstruction | | description | text | Optional user notes | | photo_url | string | Optional uploaded image | | created_at | timestamp | | | status | enum | active, verified, resolved, archived | | confirmation_count | int | Incremented by community votes | | reporter_id | uuid | Optional, anonymous allowed | ### confirmations | Field | Type | Notes | |-------|------|-------| | id | uuid | Primary key | | report_id | uuid | FK to reports | | user_id | uuid | Who confirmed/resolved | | action | enum | confirm, mark_resolved | | created_at | timestamp | | ### official_contacts | Field | Type | Notes | |-------|------|-------| | id | uuid | Primary key | | report_id | uuid | FK to reports | | official_email | string | From /api/officials | | sent_at | timestamp | When email was triggered | | response_received | boolean | Manual toggle for tracking | ### areas | Field | Type | Notes | |-------|------|-------| | id | uuid | Primary key | | area_code | string | From geo/portals | | name | string | Neighborhood/district name | | boundary | polygon | Geographic bounds | ## Vibe Coding Prompt to Get Started ``` Build a Sidewalk Gap Mapper web app using React + Express on Replit with a PostgreSQL database. FIRST MILESTONE: Basic map with report submission (2-3 hours) Frontend (React + Leaflet or Mapbox GL JS): - Full-screen map centered on user's location (ask for geolocation permission) - Floating "Report Gap" button that opens a quick-report modal - Modal has: map pin (draggable to fine-tune), hazard type dropdown (5 options: Sidewalk Ends, No Curb Cut, Width Under 36", Surface Impassable, Obstruction), optional photo upload, optional text description, Submit button - After submit, pin appears on map with hazard type icon Backend (Express + pg): - POST /api/reports - receives location (lat/lng), hazard_type, description, photo_url, stores in PostgreSQL - GET /api/reports - returns all active reports as GeoJSON for map display - GET /api/reports/:id - single report detail Database schema (use Replit's PostgreSQL): CREATE TABLE reports ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), lat DECIMAL(10, 8) NOT NULL, lng DECIMAL(11, 8) NOT NULL, hazard_type VARCHAR(50) NOT NULL, description TEXT, photo_url TEXT, status VARCHAR(20) DEFAULT 'active', confirmation_count INT DEFAULT 0, created_at TIMESTAMP DEFAULT NOW