Overview
HydroSafe Mobile App is the phone half of the broader HydroSafe project — an all-in-one companion for whitewater kayakers that brings together everything needed to judge a river section before heading out: live gauge-based water levels, calibration data, community-reported hazards, and a personal paddle log. It works alongside the HydroSafe Garmin Watch App, pulling hazard reports and calibration data onto the wrist for on-river warnings, and pulling session data back afterward to auto-fill the paddle log.
The core idea is awareness: whitewater kayaking is a genuinely dangerous sport, and a lot of that risk comes down to not knowing the current condition of a specific section, or not knowing about a hazard someone else already spotted. HydroSafe tries to close that gap with live data and a community reporting layer.
Key features
- Map overview — all river sections plotted and color-coded by their live gauge reading against that section’s calibration (low / optimal / high water), so runnability is visible at a glance
- Section detail page — a 48-hour gauge level chart, calibration data for that specific section (including optimal flow range where available), and any community-reported hazards
- Community hazard reporting — paddlers can drop a hazard directly on the map with an exact location, note, photo, and severity, visible to anyone checking that section before heading out
- Favorites — save sections for quick access
- Threshold notifications — get notified when a section’s gauge level rises above a configured threshold
- Nearby gauges — useful when a section’s own gauge is missing or unreliable
- Practical info — intake/take-out locations and parking info per section
- Paddle log — review a paddled section with a fun score, scare factor, notes, and photos. Duration, gauge level, and section name are auto-filled when synced from the watch app, along with the exact gauge chart from the time of the session. Sections you’ve already run show your past review when you revisit them
Data & architecture
Gathering reliable river and gauge data turned out to be the hardest part of the whole build. HydroSafe pulls from a range of sources covering different parts of Europe — starting with an API key kindly provided by a community river-mapping project, then expanded with additional gauge and river data sources found independently, each with its own format and quirks. A Supabase edge function runs on a 5-minute cron schedule to fetch, normalize, and write all of this into HydroSafe’s own database structure.
River section geometry — the actual shape of each section on the map — is sourced from OpenStreetMap via a third-party OSM/Overpass integration, since none of the gauge data sources provide precise section-level geometry themselves. Because OpenStreetMap data is released under the ODbL (a copyleft license requiring attribution, and requiring that any publicly redistributed derivative database also be released under ODbL), OSM-derived geometry is kept structurally separate from HydroSafe’s own proprietary data — hazards, reviews, user content — so the licensing obligations stay scoped to what’s actually derived from OSM.
Stack: Flutter frontend, Supabase backend (Postgres + scheduled edge functions), Cloudflare, and open-source geographic data and tooling including OpenStreetMap.
UI design
The interface is deliberately kept close to monochrome, with color used sparingly and specifically for water-level status — so a paddler can tell whether a section is runnable at a glance, without needing to interpret raw gauge numbers. Charts and calibration indicators are built to be read in a few seconds, not studied.
Challenges
- Sourcing and normalizing gauge and river data from many different providers across Europe, each with its own format, update frequency, and reliability
- Building the geometry pipeline to extract accurate, section-level river shapes from OpenStreetMap via a third-party Overpass-style integrator
- Respecting ODbL licensing on OSM-derived data while keeping it cleanly separated from HydroSafe’s own proprietary hazard and review data
- Designing a UI clear enough that runnability is obvious at a glance, for users who may not want to interpret raw gauge data themselves
What I learned
- Building a normalization pipeline across multiple real-world data sources with inconsistent formats
- Supabase edge functions and cron-based scheduling for periodic data ingestion
- GIS-adjacent skills — extracting and working with river geometry via OpenStreetMap/Overpass tooling
- Correctly navigating open data licensing (ODbL) when building on top of community geographic data
- UI/UX design focused on at-a-glance clarity for a safety-critical, outdoor use case
Almost all core features are built and working, but several still need polish for navigation and clarity, and a few edge cases aren’t fully reliable yet.