PowderMeet
Ski Resort Optimal Meetup Navigation
Why logging matters
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
Resort-aware pathfinding
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.
Fingerprint-identical client graphs
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.
Realtime presence at scale
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.
Server-enforced safety
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.