After dozens of Google employees spontaneously self-organized to respond to the 2010 Haiti earthquake, we formed the Google Crisis Response team to continue the mission of making critical information more accessible in times of disaster.
Fast-forward more than fifty responses later to our most recent Nepal response, and providing timely access to geographic data continues to be a focus of our work. Disseminating disaster-related data such as shelter locations, evacuation zones and warning areas and alerts, the team has helped hundreds of millions of at-risk users stay informed and stay safe. This article explores how the Google Crisis Response team reaches and empowers at-risk, non GIS-savvy users during a disaster, taking into account lessons learned from several recent responses.
Google Crisis Map shows preparedness at left, and 2015 Nepal earthquake at right.
Empowering the Community — Sandy
Hurricane Sandy affected 24 states in 2012 and caused billions of dollars in damage along the U.S. East Coast. As this disaster unfolded, we worked to provide victims with information via Google Crisis Map.
Google Crisis Map, a product from the Google Crisis Response team, is a mobile-first geo-mashup web app, providing disaster-affected users with relevant geographic data — shelters, road conditions, weather, etc. -— in context. Since its launch for Hurricane Irene in 2011, Crisis Map has been a core response tool for the team and others in the community, and has evolved and adapted itself to the changing information and disaster landscape. In addition to being a tool used by the Google team, it’s also an Open Source project, giving the community open access to a great geo-mashup tool, to bring together third-party geo content in a variety of open standards.
The Sandy Crisis Map shows gas data from a number of sources.
Our challenge with Sandy wasn’t finding relevant data for this map — it was organizing it. The Crisis Response team worked with over 30 data partners, helping promote and disseminate 50 diverse Sandy-related layers to over 15 million Sandy crisis map visitors over the course of a few days.
However, what we saw in the aftermath of Sandy was that official data quickly became stale, as the affected community became the on-the-ground experts, providing timely updates on all things response-relevant, for example, flood water depth, power status, etc. Of course, the majority of this communal knowledge came in an unstructured format, with people reporting their observations, often on Twitter, and didn’t directly map to the existing official data, making it hard to visualize. As an example of how this problem manifested itself, with many gas stations closed, our Sandy map combined four different gas availability layers, each from a different provider, and updated at varying time intervals. This mixing of gas data introduced obvious usability issues to the map, and at best, reduced the usefulness of the content itself.
The tack we took to tackle this problem is something we call Crowd Reporter. This tool, which lives within the open source Crisis Map project, is designed to address the problems we saw during Sandy; its design principles applicable to Crisis Map, but elsewhere too, we believe. This crowdsourcing workflow is as follows:
- Use an existing reference layer, such as gas stations via Google Places API, as the basis for collecting crowd reports.
- Cluster multiple crowdsourceable layers by distance in the case of ad hoc or overlapping POI data.
- Let a map curator attach questions to specified layers, enabling the collection of structured data to better understand the event. For example, the curator can add “Does this gas station have gas?” and provide customizable answer options.
- Attach a feedback/crowdsourcing widget to the individual map features. The audience of map viewers are also the experts and may not know to download a separate app.
- Leverage the community to help combat spam, provide simple vote-based widgets to gauge the usefulness of updates and hide automatically past a given threshold.
- Provide feeds of user updates back to the community, enabling a shared understanding of the on-the-ground situation, to ideally be incorporated back into the official data — a virtuous cycle.
Since its launch, we’ve seen Crowd Reporter being useful for smaller events like 2014’s Great Fire of Valparaíso, and for adding attributes onto existing preparedness layers, like the pet-friendliness of Red Cross shelters. We’re also excited to see new projects such as the Department of Energy's Lantern Live app, which also takes lessons learned from Sandy and applies many of the same principles towards providing better shared situational awareness for the next disaster.
Challenge: With crowdsourced data now readily available, how do we more effectively share and make interoperable these data during the next major disaster?
The Crowd Reporter interface allows structured and unstructured user feedback.
Beyond the map — Yolanda (Haiyan)
2013’s Tropical Cyclone Yolanda was one of the largest recorded typhoons on record and the deadliest to make landfall in the Philippines. Working with the local authorities in the Philippines, Google’s Crisis Response team was able to assemble and promote a map in advance of landfall showing the storm path, along with locally-relevant third-party content including evacuation centers, traffic alerts and landslide-prone areas.
What made Yolanda unique among recent disasters was the level of destruction of infrastructure, with network connectivity down or damaged across the country for an extended period of time. While the Yolanda Crisis Map provided a lot of potentially actionable map data, that content was simply not available to many users given the heavyweight format of the map — ~800kb of html/js/css. To work around that limitation, we went back to basics. What we realized was that users need locally relevant information centered around a particular need, like a shelter, presented in a very easy-to-read format with geographic context. Backed by a bunch of field research in countries where there are significant bandwidth and device constraints, we’ve recently launched “map cards”, which:
- Collapse feature and attribute — infowindow content, like shelters — into a lightweight list-based text view.
- Order features within the card by distance from a default location, such as Manila, which a user can re-sort using their current location, using HTML5 geolocation.
- Provide ready map linkage for users who do want to see specific feature on a map, and/or want routing instruction.
Map cards for Fla. shelter locations near Vero Beach are shown with the Crowd Reporter interface.
Launched for Typhoon Ruby in the Philippines last year and now being integrated with our Google Public Alerts product, these map cards take the required bytes to view a particular layer down to <50kb and open the data up for display across a much wider range of formats and devices, such as feature phones. The API for including these map cards is included within the Crisis Map open source code repository, and is something we hope to see others adopt as the developing world continues to see its share of major disasters and more heavyweight mapping solutions become out of reach for those affected.
Challenge: With the most disaster-vulnerable users tending to be those on lower-end devices or lacking bandwidth, how can cartographic principles help us make geographic information more understandable and actionable, where the canvas is no longer a map?
Supporting the Community — Nepal earthquake
In April 2015, a major 7.8M earthquake struck Nepal, displacing almost 3 million people and causing over 25,000 casualties as of this writing. With limited internet penetration in Nepal, especially in the rural areas, Google’s ability to reach those affected was limited.
With a limited ability to reach those directly affected, the team focused its efforts on supporting those working in the field, providing more on-the-ground support. One major area of effort for Google’s Crisis Response team was getting fresh satellite imagery made available to those in the field. In partnership with DigitalGlobe and Airbus/Astrium, along with our own Skybox assets, via Skybox for Good, we were able to make over 150 traceable imagery scenes available to the community. Those using this imagery for Nepal included the Humanitarian OpenStreetMap Team, which used Crisis Map to discover newly-published imagery scenes, track progress of mapping efforts — publishing their own crisis map — and as a hosting platform for Google-served tiles for their mapping workflow.
This tasking crisis map was published by the Humanitarian Open Street Map team.
Challenge: With the so much imagery coming online for current and future crises, how can the community better discover and catalog available scenes? How can we use machine learning to automate the manual work of identifying damage and shelters with this influx of new imagery?
If you’re interested in exploring these features within Crisis Map further, the product can be found at google.org/crisismap, and a hosted version for creating your own crisis mashup is at google.org/crisismap/a/.maps. Code is available at https://github.com/google/googlecrisismap.