We all looked at the prizes and tried to figure out which were cool and tried to gun it for those. However, we realized that we had pigeonholed-holed ourselves as we ere trying to come up with a solution for a prize rather than a solution for a problem. We went to the IBM talk and they spoke a lot about natural disasters and the massive flooding of Houston recently came to mind. We thought about how floods that don't get as much national attention can occur and how personal risk factors can disproportionately affect them. A little later we decided to use the same approach but with fires, since they were becoming more prevalent due to climate change.
What it does
Weather Guardian takes a zip code as input and uses it to figure out wind conditions in the area and nearby forest fires to figure out if the wind might blow smoke in your direction. This app would primarily be geared towards people with lung and breathing conditions such as asthma so that they can be better prepared. We planned to use altitude information and the Google Maps API to assess risks of flooding, but there was not enough experience or energy to implement that so we called it here.
How we built it
For the front-end, we used React and React Bootstrap for UI elements. We used Node and Express for the back-end. We also used the IBM Weather Company API to get location information and weather data and the USDA Forest Service for forest fire information.
Challenges we ran into
We first decided that we were not going to use a back-end and this project would be a single page web app that made a whole bunch of AJAX calls. However, we ran into an issue where every AJAX call we made from our React App would fail. We figured out that it was caused by a configuration detail that was default when running create-react-app to bootstrap our app. We then decided to use a back-end because it both circumvented this problem and it reduced the amount of work the clients computer would have to do. Our second major issue was the IBM The Weather Company API. Specifically it's documentation. It was pretty hard in the beginning to figure out what kind of information we could gather from each endpoint to figure out how we should use it. There isn't an exhaustive list of keys so I could instantly know what every field in the response object meant (though to their credit some of the names were intuitive) and the example code that was provided straight up did not work. All that being said, shout to the IBM guys (especially Mofi) who helped us above and beyond what we needed and the API itself is still very powerful. The third challenge was finding current forest fire data. Initially we looked for a convenient API that would give a nice list of forest fires with useful metadata. However, to our knowledge, there isn't one. We did find a nice webpage that contained a HTML table of forest fires that updated very frequently, the exact thing we needed. So then fashioned a way to parse the HTML data to data usable for our purposes. After a few long, frustrating, and caffeine filled hours, we made our own web scraper (with more than a little help from the internet) that would all the forest fire locations in a neat little list.
Accomplishments that we're proud of
For two of us, this is the first time we would be demoing at a Hackathon. Having something that we can point to and say "Yeah, that's something we came up with." is such an amazing feeling.
What we learned
We've learned what bad documentation looks like and the importance of good documentation. We learned about team management and how to effectively work together as a unit from three different machines. We've also learned what web scraping is and how to implement it and the plethora of useful APIs that IBM among many others offer.
What's next for Weather Guardian
Ideally, Weather Guardian is a mobile application, not a web application. So we would like to port our code to React Native. We also want to get the flooding warnings working and figure out how we can give advanced and personal warnings regarding other natural disasters.