We were inspired to work on OmniMap as we thought back to Harvey a year ago with several of our team members being from Houston. We realized that Hurricane Florence was making landfall in North Carolina. We knew we had to tackle disasters like this because they aren't going away any time soon. However, we didn't stop at hurricane relief, we wanted to develop a platform from which all could benefit regardless of their geographic location, conditions, and nature of disaster. OmniMap will help any population navigate through a natural disaster by providing a mesh-network, peer-to-peer distributed map system that persists even with downed cellular towers. OmniMap is powered by the people.
What it does
OmniMap is a mesh-network that is hosted by users who find themselves facing a natural disaster. Oftentimes during natural disasters, there are power outages and downed cell towers which can greatly affect communication. Communication is crucial for emergency services and to navigate when trying to reach safety in the midst of a natural disaster. By harnessing the large populations outbound during evacuation and inbound post-disaster, we are able to host a mesh-network that leverages peer-to-peer distribution to share and host a map with near-live conditions of the surrounding area. Each user serves as a node in the network broadcasting their local conditions crowdsourcing live information about conditions while getting messages out to the rest of the world when other traditional communication systems fail.
How we built it
We used HTML, CSS, and JS to build our web-facing application for both desktop and mobile users. Our backend work is largely done with Google Fusion tables to produce the map visualizations we used. We also leveraged data sets from NOAA (CSVs) and worked with KML files as well as SHAPE files four mapping.
Challenges we ran into
We spent a long time working with and learning about SHAPE files for the Google Maps and Google Fusion Tables backend we had never worked with. While we had done some map work in the past, we had never used SHAPE files. To work with Google Fusion Tables, we had to convert SHAPE files but the tools to do so have been deprecated and this caused lots of issues. We had to explore several alternatives to finally be able to present data in the way we envisioned.
Accomplishments that we're proud of
Building of prototype of this idea was really ambitious and we're really proud of the fact that we were able to pull all of the data we wanted to visualize and display it in a super user friendly way. Being able to send all of that data in a mesh network is the core idea behind OmniMap, and we were able to implement that. It was our team's first chance to work with shape files and Google's Fusion Tables, and it turned out pretty well.
What we learned
The power that Google Fusion Tables has is immense, we never knew Google Maps had such a capability for presenting all kinds of data from heat maps to special icons for points on a map. We really wish we had more time to explore the full capabilities of fusion tables to make even deeper analysis. It was very interesting to learn about the backend of custom maps and map layers as well as Google's geocoding.
What's next for OmniMap
We'd really like to be able to test OmniMap in a larger capacity with users to test the range and latency of the mesh network. We're considering the possibility of continuously pulling information from sites like NOAA, local weather stations, and the government to have the latest weather and infrastructure information for our users who are evacuating or trying to reach safety.