Flüme

See your current location, risk factor, danger level and nearby evac zones!
With location off, view all active wildfires and the evac zones near each one.

Inspiration

We wanted to create something that might have a real-world use, since many of us have done more "fun" projects in the past, although this one was still very fun to make.
Especially with the recent LA fires and the ongoing impacts from them, we decided to make something that could help people in need when in emergency wildfire scenarios.

What it does

Our app, Flüme, tracks all active wildfires in California and displays nearby evac locations such as hospitals and community centers. If given your location, the app additionally displays evac zones close to you and tells you both the current level of danger you face from active wildfires and the risk of a wildfire breakout your area currently faces.
With our easy-to-use UI and dynamic map features, a user can quickly identify nearby wildfire-related dangers and enact an evacuation plan if the need arises.

How we built it

We wanted to use a Python Flask API on the backend because of the development speed that it provides and the flexibility it offers in terms of libraries and web services. Python also makes getting and parsing through JSON data that we pulled from the Cal Fire and OpenWeather APIs a fast and smooth process.
As for the frontend, we used React-Vite with TypeScript, as it's a dominant frontend tool used in the industry, and we wanted to gain more experience using it. It also provides a very friendly interface for cross-origin API calls, which we had to do to communicate with the backend. The dynamic map was created using Leaflet, a map library, and building the frontend UI components was streamlined through the usage of MUI.

Our largest challenge and greatest accomplishment

There was a major miscommunication between the backend and the frontend, but it ended up improving the overall project. The frontend team wanted everything to be centered around the user's location: the evac zones, the fires, everything. The backend team, however, made an API that sent generic data about all active fires and the evac zones around each one. The way we worked around this was to simply make both.
Since the frontend's idea revolved around sending location data, we figured we could implement their idea if the user gives their location to the site and even include specialized information about the user's location (such as the danger level and risk factor, which were implemented later). However, if the user doesn't share their location or doesn't click that option, we still made a more generic and working website that provides a greater scope of information. Although the frontend had to scramble to make a UI for the generic site, and the backend had to hastily throw together a personalized location-based API, we were able to finish both, and I think the resultant product shored up some of the weaknesses each version had on their own, making it greater than the sum of its parts.

What we learned

None of us wanted to spend too much time on the planning stage, but as we ended up realizing, that stage might be the most important for team-based projects. Although it worked out quite nicely this time, that won't always be the case, and having a detailed project framework that all teams understand beforehand is imperative to making a cohesive and functioning web app, or any other project.

What's next for Flüme

We want to expand our coverage to include more than just California. We could cover the whole USA, or even the entire world. We included two types of evacuation and reconnaissance areas in the event of a wildfire, hospitals and community centers, but we could include more and make the range of search for those zones and the number that appear customizable.
Additionally, we want to improve the methods we use to calculate certain variables. Although our fire maps did look similar to those from other, more established government websites, we created a lot of the algorithms for estimating the danger zone of a wildfire, the risk factor, and the danger level of a user, etc., ourselves because it was a lot more fun and increased our understanding of the subject (even if it posed more of a challenge).