PolyWater

PolyWater is a crowdsourced map that tells Cal Poly students which refill stations for water bottles actually have a green filter light, before they walk across campus for it.

Comment

Inspiration

All through my first year I would try to refill my bottle between classes and find the filter light sitting in the red. It happened again today. I stopped to fill up after the gym on my way to a club meeting, and there it was, red again. You never find out until you are standing in front of it, and by then you have already spent the walk. When I went looking for a list of refill stations on campus so I could seed this project, I could not find one anywhere. OpenStreetMap has four drinking water points tagged for all of Cal Poly, and the official hydration station page is behind campus login and only tells you a station exists, never whether it works today. That gap is the whole reason PolyWater exists, because the only people who know a filter went red are the students standing in front of it.

What it does

PolyWater is a live map of Cal Poly refill stations colored by their current filter status. Anyone can browse it without an account and see which stations are green. Signed-in Cal Poly students can report their status in one tap, choosing green, yellow, red, or out of order, and can attach a photo as proof. The map updates for everyone instantly. A fountain's status is simply its most recent report, so there is no maintenance database to integrate with, just students telling each other what they saw. If a station is missing from the map, anyone can drop a pin and add it.

How we built it

PolyWater is vanilla JavaScript and Leaflet on the front end, Supabase for the database, authentication, photo storage and live updates, and Vercel for hosting. I skipped frameworks on purpose. There is no build step and no bundler, just an HTML file, a few scripts, and a stylesheet, with Leaflet and the Supabase client vendored into the repo so that no CDN outage can break the site. The data model is two tables: fountains and reports, carrying a status, a note, and an optional photo. Login is a magic link restricted to calpoly.edu addresses, enforced both in the browser and by row-level security policies in Postgres. Instead of using a generic street map, I drew the campus from scratch by pulling every Cal Poly building footprint, lawn, footpath, road, and parking lot from OpenStreetMap and rendering them as vectors in Cal Poly green and gold, with any building containing a refill station filled in gold.

Challenges we ran into

The worst bug never threw an error. I seeded my first coordinates by eyeballing where buildings were, and Vista Grande ended up about 850 meters from the actual building, with the Rec Center off by 640. The map looked completely convincing and was completely wrong, so I rebuilt every pin from real building footprints. I also lost time trying to hide my Supabase key in a Vercel environment variable before realizing that is impossible in a static site, since environment variables are injected at build time and there is no build, and the browser needs the key regardless. The real protection is row-level security in Postgres, which I verified by trying to insert and delete rows as an anonymous visitor on the live site. Both attempts were refused. On top of that, Supabase's free tier sends only two authentication emails per hour, so I had to plan the entire evening's testing order around a rate limit.

Accomplishments that we're proud of

The custom campus basemap is the piece I am happiest with. Rather than settling for a generic tile layer, PolyWater renders 242 real Cal Poly building footprints plus lawns, sports fields, paths, roads, and parking in the school's own colors, and it highlights exactly the buildings that have refill stations. Getting the map data from 1.6 MB down to 92 KB meant I could ship it with the site instead of calling an API at runtime, so nothing external can fail during a demo. I am also proud that the whole thing is a working, deployed, secured application with no build step at all, and that I tested my security model by actually attacking it rather than assuming it worked.

What we learned

The biggest shift was understanding that security is not about keeping a key secret; it is about what the database will allow that key to do. I also learned that silent wrongness is far more dangerous than a crash, because nothing on my map complained when the pins were most of a kilometer off target. Building the basemap myself instead of dropping in a tile layer turned out to be easier than I expected and is the single thing that makes the project actually look like Cal Poly. Finally, cutting scope early is what made this finishable: no framework, no build step, two tables.

What's next for PolyWater

Moderation is the obvious next step, since right now one bad actor could spam reports. Requiring two agreeing reports within a time window, or weighting reports by a user's history, would fix that. Beyond that, the report data is already a live record of which stations have been red the longest, which is genuinely useful to whoever changes the filters, so a facilities facing view costs almost nothing to add. The best outcome would be getting Cal Poly's official hydration station inventory into the map, which would take it from 25 seeded stations to complete coverage on day one.

Built With

Share this project:

Updates

Submission history