Canopy

Inspiration

Finding time to get outside can be harder than finding a park. Even when green spaces are nearby, deciding where to go, checking the weather, estimating travel time, and understanding whether a location meets your needs can turn a short break into a surprisingly complicated decision.

I built Canopy to make that decision easier. The project is designed for people who may only have 10, 20, or 30 minutes available but still want a meaningful moment outdoors. Instead of presenting a long directory of parks, Canopy turns a few simple preferences into one practical, explainable recommendation.

Trust was also an important part of the idea. Location and accessibility data are often incomplete, so Canopy does not pretend to know more than its sources provide. When accessibility information is missing, the app clearly identifies that limitation instead of making an unsupported claim.

What It Does

Canopy combines a user’s location, available time, preferred activity, access requirements, and current environmental conditions to recommend a nearby Portland green space.

Users can enter a city or postal code, or optionally use their current location. They then choose how much time they have and select the kind of outdoor experience they want:

Listen offers a short sound-awareness exercise
Move suggests a simple walking observation
Notice encourages close observation of plants and natural details
Care prompts users to notice litter, blocked access, or habitat damage

Canopy searches official park records within three miles of the selected location and ranks the available options. Each recommendation includes:

The name of the recommended park or green space
Live weather, precipitation, and air-quality conditions
Straight-line distance from the selected location
An estimated total outing time
A calculated fit score
A short nature-based field prompt
The source and limitations of the underlying data
A clear warning when accessibility information is unavailable

The goal is not to claim that one park is objectively perfect. Instead, Canopy provides a useful starting point and explains why that result was selected.

How I Built It

I created Canopy as a responsive web application using HTML, CSS, and vanilla JavaScript. I chose a lightweight front-end approach so that the experience could remain fast, accessible, and understandable without requiring a large framework.

The application connects several public services:

Open-Meteo Geocoding API converts a city or postal-code search into coordinates
Open-Meteo Weather API provides current temperature, precipitation, and weather conditions
Open-Meteo Air Quality API provides the current U.S. Air Quality Index
PortlandMaps ArcGIS REST API supplies official City of Portland park boundaries and records
Leaflet provides the interactive map
OpenStreetMap supplies the map tiles
The browser Geolocation API allows users to search from their current position when permission is granted

After receiving the park data as GeoJSON, Canopy processes each park boundary to calculate an approximate center point. It then uses the Haversine formula to estimate the straight-line distance between the user and each park.

The recommendation system compares that distance with the user’s available time. Estimated outing time assumes a walking speed of approximately 4.5 kilometers per hour, an out-and-back journey, and a 10-minute pause at the destination. Parks are ranked according to how closely their estimated outing matches the selected time limit, along with the completeness of the available data.

Canopy also adjusts how it communicates confidence. If a user requests step-free access, the app does not award accessibility points because the park-boundary dataset does not include wheelchair-access details. The result remains visible, but the limitation is placed directly beside the recommendation.

Challenges I Faced

One of the biggest challenges was coordinating multiple live APIs while keeping the interface responsive. Weather, air quality, geocoding, park records, and map tiles come from separate services, and each request can succeed, fail, or take a different amount of time. I needed to create clear loading messages, disable actions while data was being processed, and provide understandable errors when a service was unavailable.

Geographic data created another challenge. The PortlandMaps service returns park boundaries rather than a single latitude and longitude for each park. I had to process nested GeoJSON coordinates, extract the latitude and longitude values, and calculate a representative point that could be used for distance estimates and map placement.

Designing the ranking system also required careful judgment. A numeric score can appear more authoritative than it really is, so I made the assumptions behind the calculation visible. The app explicitly explains that distance is straight-line distance and that outing time is based on an assumed walking speed, an out-and-back route, and a short pause.

Accessibility was the most important data challenge. The official boundary dataset used by Canopy does not contain enough information to verify wheelchair or step-free access. It would have been easy to hide that limitation or infer accessibility from incomplete fields, but doing so could mislead users. Instead, Canopy treats missing information as missing, reduces confidence when access is required, and communicates the gap in plain language.

What I Learned

This project taught me how to combine several public APIs into one coherent user experience. I gained practical experience working with asynchronous JavaScript, browser permissions, REST endpoints, GeoJSON, geographic calculations, interactive maps, and dynamic interface states.

I also learned that creating a recommendation is only part of the problem. A useful recommendation should explain where its information came from, how the result was calculated, and what the system does not know. Showing data sources and assumptions made Canopy more honest and more useful.

From a design perspective, I learned how much clarity matters in a short interaction. Users should not need to understand APIs or geographic calculations to use the application, but they should still be able to inspect the reasoning behind a result. Canopy therefore presents a simple recommendation first while keeping its methodology and source limitations visible.

Most importantly, I learned that trustworthy software does not eliminate uncertainty by hiding it. It helps people make better decisions by communicating that uncertainty clearly.