StreetClear

Consumer

Original Idea

Neighborhood Snow Plow Tracker A web app that crowdsources and maps which streets have been plowed after snowstorms so drivers can plan routes.

Product Requirements Document (PRD): StreetClear

1. Executive Summary

StreetClear is a community-driven, real-time snow removal tracking application designed to provide commuters and residents with granular, street-level passability data during and after winter storms. By combining crowdsourced reporting with municipal GPS feeds and a sophisticated time-decay confidence algorithm, StreetClear empowers users to plan safer routes and assists local authorities in identifying neglected residential zones.

2. Problem Statement

Municipal snow removal maps often focus on primary arteries, leaving residential side streets as "black holes" of information. During significant snow events, commuters risk getting stuck, emergency services face delays, and delivery logistics fail due to unplowed local roads. Existing navigation apps do not provide the specific "plow status" of a residential block, leading to dangerous driving conditions and community isolation.

3. Goals & Success Metrics

  • Safety Improvement: Reduce the number of "stuck vehicle" reports in pilot neighborhoods by 20% year-over-year.
  • Data Freshness: Maintain an average report age of < 2 hours during active storm windows.
  • Accuracy: Achieve a >90% validation rate (reports confirmed by other users or municipal data).
  • Engagement: Reach a 15% penetration rate of residents in key target municipalities.
  • Performance: Map tiles must load in < 200ms to ensure usability in low-bandwidth winter conditions.

4. User Personas

4.1. The Essential Worker (e.g., Sarah, Nurse)

  • Need: Must get to the hospital regardless of weather. Needs to know if her specific side street is cleared before she attempts to move her car.

4.2. The Delivery Professional (e.g., Marcus, Logistics)

  • Need: Efficiency and vehicle safety. Needs a route that avoids unplowed "traps" while fulfilling residential deliveries.

4.3. The Good Neighbor (e.g., Tom, Retiree)

  • Need: Community contribution. Wants to report his street status to help others and enjoys the "reputation" of being a reliable source.

4.4. The Municipal Transit Planner

  • Need: Identifying gaps. Wants to see heatmaps of where community reports contradict "cleared" official statuses.

5. User Stories

  • As a commuter, I want to see a color-coded map of my neighborhood so I can decide if it's safe to leave my driveway.
  • As a resident, I want to submit a report with a single tap so that I can update my community on road conditions without removing my gloves for long.
  • As a driver, I want to upvote a report if I see a plow on a street so that the map stays accurate for others.
  • As an app user, I want older reports to fade away automatically so that I am not relying on outdated information from yesterday's storm.

6. Functional Requirements

6.1. Interactive Map Engine

  • Render street segments color-coded by status: Plowed (Green), Partially Plowed (Yellow), Unplowed (Blue/White), Icy (Purple).
  • Support 3D terrain and building rendering to help users orient themselves.
  • Implement "Mapbox Standard" style with dynamic lighting for high visibility in night/storm conditions.

6.2. Crowdsourced Reporting System

  • One-Tap Interface: Large tactile buttons for reporting current street status.
  • Geolocation-Lock: Reports are automatically snapped to the nearest OSM street segment.
  • Verification: Users can "Confirm" or "Refute" existing reports.

6.3. Time-Decay Confidence Logic

  • Implement an Exponential Decay Model: $C(t) = C_0 \cdot e^{-\lambda \Delta t}$.
  • Initial confidence ($C_0$) is determined by the reporter's reputation score.
  • Reports disappear or turn "Grey" once confidence drops below a 0.2 threshold.

6.4. User Reputation & Security

  • Points awarded for accurate reports (verified by others).
  • Geospatial rate limiting: Users cannot report segments more than 5 miles apart within 10 minutes (prevents "ghost plowing" spam).
  • Anonymized user IDs to protect home addresses.

7. Technical Requirements

7.1. Tech Stack (2026 Standards)

  • Frontend: React 19.2.2 (utilizing React Compiler and Server Actions).
  • Map Library: Mapbox GL JS 3.18.0 via react-map-gl 8.1.0.
  • Styling: Tailwind CSS with Konsta UI for mobile-first tactile components.
  • Backend: Node.js 24.13.0 (LTS) with Express 5.1.0.
  • Database: PostgreSQL 18.1 with PostGIS 3.6.1.
  • Cache: Redis for tile caching and real-time report buffering.
  • Infrastructure: AWS Fargate for API/Processing; AWS S3 + CloudFront for Map Tiles.

7.2. Spatial Logic

  • Vector Tiling: Database-level generation using ST_AsMVT().
  • Map Matching: Integration with Valhalla (Meili) for snapping GPS pings to OSM geometry.
  • State Management: Utilize setFeatureState in Mapbox GL JS for 60FPS color updates without re-tiling.

8. Data Model

8.1. StreetSegment (PostGIS Geometry)

  • segment_id (BigInt, PK)
  • osm_way_id (BigInt)
  • geom (Geometry: LineString, 4326)
  • current_status (Enum: PLOWED, PARTIAL, UNPLOWED, ICY)
  • last_updated (Timestamp)

8.2. Report

  • report_id (UUID, PK)
  • user_id (UUID, FK)
  • segment_id (BigInt, FK)
  • status_type (Enum)
  • confidence_score (Float)
  • created_at (Timestamp)

8.3. User

  • user_id (UUID, PK)
  • reputation_score (Int)
  • is_verified_municipal (Boolean)

9. API Specification

9.1. GET /api/v1/map/tiles/{z}/{x}/{y}.mvt

  • Description: Returns Mapbox Vector Tiles containing street segments and their current status.
  • Optimization: Cached in Redis with a 60-second TTL.

9.2. POST /api/v1/reports

  • Request: 
    {
  "coords": [longitude, latitude],
  "status": "PLOWED",
  "timestamp": "2026-01-20T14:00:00Z"
}
  • Response: 201 Created with confidence_score and reputation_delta.

9.3. PATCH /api/v1/reports/{report_id}/verify

  • Request: { "action": "CONFIRM" | "REFUTE" }

10. UI/UX Requirements

  • Adverse Condition UI: Minimum touch targets of 60x60px for gloved use.
  • Contrast: WCAG AAA (7:1) contrast ratio; use "Emergency Orange" for unplowed alerts.
  • Haptic Feedback: Success vibrations on report submission via Web Vibrations API.
  • Bottom Sheet: Use Vaul for the reporting drawer, allowing users to swipe up to see more detail.

11. Non-Functional Requirements

  • Availability: 99.9% during the winter months (Nov–March).
  • Scalability: Handle 100k concurrent users during peak "Storm-in" hours.
  • Privacy: Spatial cloaking for user home locations; no storage of precise GPS history > 24 hours.
  • Accessibility: Screen reader support for status updates; high-contrast mode by default.

12. Out of Scope

  • Forecasting weather or snowfall totals.
  • Reporting sidewalk conditions.
  • Official plow dispatching software for cities.
  • Routing for non-vehicular traffic (pedestrians).

13. Risks & Mitigations

  • Risk: "Ghost Plowing" (Users falsely reporting streets as plowed to lure traffic).
    • Mitigation: Bayesian reputation logic; require 2+ reports from different users to reach "Verified" status.
  • Risk: Municipal API failures.
    • Mitigation: Fallback to 100% crowdsourced data; mark municipal data as "Official" vs community data as "Reported."
  • Risk: High AWS costs during storms.
    • Mitigation: Implement aggressive Edge Caching for vector tiles and use Fargate Spot instances.

14. Implementation Tasks

Phase 1: Infrastructure & Core API

  • [ ] Initialize Node.js 24.13.0 project with ESM (type: module).
  • [ ] Set up PostgreSQL 18.1 with PostGIS 3.6.1.
  • [ ] Import OSM road network for target city using osm2pgsql.
  • [ ] Configure Express 5.1.0 with async error handling.
  • [ ] Implement ST_AsMVT endpoint for dynamic street tiling.

Phase 2: Map & Reporting UI

  • [ ] Initialize React 19.2.2 with Tailwind CSS.
  • [ ] Implement Mapbox GL JS 3.18.0 with setFeatureState for real-time styling.
  • [ ] Build "One-Tap" reporting component using Konsta UI (60px targets).
  • [ ] Integrate Web Vibrations API for haptic confirmation.
  • [ ] Create Bottom Sheet using Vaul for report details.

Phase 3: Logic & Security

  • [ ] Implement Exponential Decay algorithm in a background Worker Thread.
  • [ ] Build Reputation Logic (Bayesian updating).
  • [ ] Add Geospatial Rate Limiting (Max 1 report per segment per 10 mins per user).
  • [ ] Implement Spatial Cloaking (Anonymize coordinates to 100m precision for storage).

Phase 4: Integration & Deployment

  • [ ] Integrate National Weather Service API for live radar overlay.
  • [ ] Set up Valhalla for Map Matching logic.
  • [ ] Configure AWS Fargate scaling policies for CPU-intensive GIS tasks.
  • [ ] Set up Redis cache for MVT tiles.
  • [ ] Conduct "Cold Weather" UX testing (emulated high-latency/low-precision).