Interactive demo · 2026
Ski Resort Optimal Meetup Navigation
Two skiers. One resort graph. A meeting point that minimizes the slower skier's arrival time.
Demo 01 / Core routing
Pick two skiers and let PowderMeet solve the trail-and-lift graph. The result accounts for ability, topology, lift queues, and the time each person actually needs to arrive.
Demo 02 / Run logging
Logging is not a side feature. It is what the routing runs on. PowderMeet learns your real per-edge speed from logged runs, so the meetup solver can predict when each skier will actually arrive. The problem: mainstream trackers cannot agree on the same run. Here Slopes and Apple Health clock the identical Rendezvous Drive descent at 28.3 vs 10.0 km/h and 0:54 vs 2:32. Garbage speed data means garbage routing. PowderMeet imports every source, reconciles each run against the resort trail-and-lift graph, and calibrates the solver from the truth.
Under the hood
Dijkstra over an OpenStreetMap trail and lift graph with alpha-weighted lift-wait penalty on max(tA, tB). Custom binary min-heap with lazy deletion and lexicographic edge-ID tie breaks so two devices converge on identical paths under equal-cost ties.
Server-side snapshot pipeline (Overpass + DEM) publishes a per-resort manifest to Supabase Storage. Quantized inputs (15-minute time buckets, 0.5°C temperature, 10m elevation) let two clients solve byte-identical graphs without coordinating.
Geohash-6 bucketed Supabase Realtime channels (1.2 km cells, 9-cell neighborhood subscription) cap presence fan-out by proximity instead of friend-graph size.
Postgres state machine on meet_requests and friendships uses CHECK constraints and BEFORE UPDATE triggers to reject backward transitions. Spatial trigger resolves resort_id server-side from lat/lon to block location spoofing, all gated by RLS through an accepted-friendship join.