Category Archives: Crowdsourcing

Maptivism: Live Tactical Mapping for Protest Swarming

My colleague Adeel Khamisa from GeoTime kindly shared this news story on how student protesters created a live tactical map to outwit police in London during yesterday’s demonstrations.

Check out these real time updates:

The students also caught the following picture:

The map depicts the tactics employed by the students:

The limits of using Google Maps

As I looked closer at the map, it occurred to me how much this resembles a computer game with moving characters. The strategy employed by the police can be discerned by the pattern below.

But I doubt that students were able to update their Google map in real-time directly from their mobile phones, let alone via SMS, Twitter, Smartphone App, camera phone or Facebook. Nor can they subscribe to alerts and receive them directly via an automated email or SMS. Indeed, it appears they were using Google Forms to “crowdsource” information and this Twitter account to disseminate important updates.

This is why I got in touch with the group and recommended that they think of using Crowdmap (free and open source):

Or GroundCrew (partially free, not open source):

See the following links for more info on Maptivism:

Quick, Stop All Ushahidi Deployments in Egypt!

Has the world gone crazy? There are now at least five Ushahidi deployments in Egypt. Somebody stop this proliferation before things really gets out of control. This is ridiculous, who knows what could happen!

Oh how I long for the days of  expensive, proprietary software that prevented the widespread use of commercial platforms by the unwashed masses. Life was good back then, and simple. Only external organizations with millions of dollars of funding could monitor elections. Centralized, top-down hierarchical control was such a blessing. You’d think that those using Ushahidi in Egypt would at least make their deployments password protected. But no, they have the nerve to share their data publicly. The nerve.

Someone please force these groups to use one (and only one) platform and to use a password. In fact, people should be required to apply for permission to use an Ushahidi platform by completing a 10-page form, providing 5 references along with a financial statement for the past 3 years. They should also sign a binding contract that obliges them not to share any data publicly. The golden rule should be one platform per country per year. All this needs to be controlled. Seriously, don’t people understand the consequences of democratizing tools for trans-parency and accountability?

Just look at what’s happening in Eygpt. Ushahidi was never used in the country before the lead up to the country’s Parliamentary Elections. But now, because the platform is both free and open source, no fewer than 5 different groups have decided to add more transparency to the elections. How irresponsible is that? I mean, this is only going to give people more ideas on how to hold their government accountable in the future.

Indeed, there may end up being twice as many platforms during the Presidential Elections next year as a result. And then what? This will just make each platform weaker since the data will be split across platforms. (Down with open data!). Don’t people understand that they can’t just do whatever they want? (Down with more choices!). Doesn’t anyone care about our rules anymore? The masses need to listen to us and do as we say. Oh how I do miss the good old days. Sigh.

This careless proliferation of Ushahidi platforms in Egypt will only add more data (down with more data!), which means even more monitoring of the government’s actions during the elections (down with transparency!). The first Ushahidi platform that was launched already has 351 mapped reports and the other four platforms have already mapped a total of 461 reports. This is terrible. The additional data means that triangulating some reports may be possible, either manually or by using Swift River.

This needless proliferation also means that many more issues will be monitored. At least the first Ushahidi platform that was launched didn’t have a specific category on women. But the platform launched by the Independent Coalition for Election Observation includes a category on women. And that platform is only in Arabic! Don’t people understand that election monitoring is supposed to be for English-speaking outsiders, i.e., the West?

It gets worse. The Muslim Brotherhood is also using the platform to create more transparency around the elections. As the screenshot below reveals, they even have the audacity to monitor and map assaults on journalists, observers and human rights organizations. This is worse than blogging. But don’t get me started on blogs. The fact that anyone can blog is a travesty and an assault on everything we hold holly. The printing press? Don’t even go there.

Crisis Mapper Anahi Ayala Iacucci clearly disagrees with me in her blog post on this topic. She writes that the whole point of Ushahidi is “to make it available to everybody to be able to have their voices heard, to allow for sharing of information. If people have some doubts please read the Ushahidi website: ‘Ushahidi builds tools for democratizing information, increasing transparency and lowering the barriers for individuals to share their stories.'”

Again, has the world gone crazy? My ultimate nightmare, however, are APIs and RSS feeds. These allow data from different Ushahidi platforms to be easily shared. Just look at the screenshot below and you’ll understand my concerns. I was able to create one list of all reports simply by cutting and pasting the five website links into my Google Reader. This link will take you to a public website with one list of integrated reports from all five platforms updated in real-time. If you’d like to add this to your own Google Reader, use this Atom Feed.

And if this isn’t disturbing enough, people can actually subscribe to automated email alerts of incoming reports based on specific areas of interest. I also hear a rumor that each Ushahidi platform comes with a unique key and that swapping keys allows for the automatic sharing of data between two or more Ushahidi platforms. Networked Ushahidi platforms. The nerve. Maybe the Egyptian government will be able to crack down on these platforms and curb this proliferation of transparency. After all, the US government has already invested billions of dollars to keep this repressive regime in power.

Stop Crowdsourcing? Remember, Remember the Fifth of November…

… because a man can fail. He can be caught. He can be killed and forgotten.
But four hundred years later an idea can still change the world. I’ve witnessed firsthand the power of ideas. I’ve seen people kill in the name of them; and die defending them. But you cannot kiss an idea, cannot touch it or hold it.
Ideas do not bleed, it cannot feel pain, and it does not love.
V for Vendetta, 2006

The power of crowdsourcing crisis information has little to do with the people behind Ushahidi. If individuals, communities, organizations want to crowdsource and access  information, they’ll find a way regardless of the challenges or the number of blog posts that try to stop them. Cynics warned that the  printing press and telephone would lead society to ruin. They failed to stem an idea more powerful than them. They’ll fail again. Information wants to be free, and people want the freedom to source and access this information. Increasingly, these people include grassroots activists, seasoned humanitarian professionals, students, established media groups, local organizations, volunteer networks and amateur professionals. Cynics will realize that their voices have long been drowned out by the voices of the many drawn by the power of an idea.

Technologies and Practice for the Prevention of Mass Atrocity Crimes

I’ve waited years for a conference like this: “Early Warning for Protection: Technologies and Practice for the Prevention of Mass Atrocity Crimes.”

This high-level conference combines my main areas of interest: conflict early warning, crisis mapping, civilian protection and technology. I’ll be giving a keynote presentation on “The Potential of New Technologies in Conflict Early Warning” at this conference next week, and I’m particularly looking forward to the panel that will follow, co-organized with my colleague Phoebe Wynn-Pope.

The conference will explore a number of issues.

  • What is the role of new technologies in conflict early warning and how do they interact with more traditional monitoring systems?
  • How can we harness, coordinate, and utilize the sometimes overwhelming amount of information available?
  • What systems and mechanisms need to be put in place to ensure effective early-warning is given?
  • How does the humanitarian sector work effectively with communities at risk once early-warning has been sounded?
  • How can a change in attitude and behavior at a policy level be brought about in a way that forestalls a descent to violence?

In preparing for the presentation, I started re-reading some papers I had written several years ago including this one from 2008: “Bridging Multiple Divides in Early Warning and Response: Upgrading the Role of Information and Communication Technology” (PDF). I will base my presentation in part on this paper and welcome any feedback readers may have. If you don’t have time to read a 25-page paper, here’s a short summary in bullet point format:

  • The field of conflict early warning has largely been monopolized by academics who are obsessed with forecasting conflict.
  • Operational conflict early warning systems are little more than glorified databases.
  • The conflict early warning community’s track-record in successfully predicting (let alone preventing) armed conflict is beyond dismal.
  • State-centric and external approaches to conflict early warning and rapid response have almost systematically failed.
  • The disaster early warning community have long advocated for a people-centered approach to early warning given the failures of top-down, institutional methods.
  • The disaster early warning community has been an early adopter of new technologies, particularly those engaged in public health.
  • The purpose of a people-centered approach is to empower individuals so they can mitigate the impact of a disaster on their livelihoods and/or to get out of harm’s way.
  • Preparedness and contingency planning are core to a people-centered approach since natural hazards like earthquakes can’t be easily predicted let alone stopped.
  • Given the dismal failure of conflict early warning systems, the conflict prevention community should make conflict preparedness and contingency planning a top priority.
  • Precedents for a people-centered approach to conflict early warning  exists in the fields of strategic nonviolent action and digital activism.
  • More importantly, communities that experienced conflict have developed sophisticated coping strategies to evade and survive.
  • Some of these communities already use technologies to survive.

I will expand on these points with several real-world examples and, more importantly, will combine these with what I have learned over the past two years, specifically in terms of crisis mapping, new technologies and civilian resistance. I’m excited to put all of my thoughts together for this conference, and I especially look forward to feedback from readers and conversing with participants.

 

Crowdsourcing the Angry Skies: The SKYWARN Volunteer Network

SKYWARN is a volunteer network of 290,000 trained storm spotters who provide localized weather reports to the US National Weather Service (NWS).  The concept was developed in the late 1960s and comprises a network volunteers who report “wind gusts, hail size and cloud formations that could signal a developing tornado” where they live.

According to Weather.gov, “the information provided by SKYWARN spotters, coupled with Doppler radar technology, improved satellite and other data, has enabled NWS to issue more timely and accurate warnings for tornadoes, severe thunderstorms and flash floods.”

This illustrates how crowdsourcing can be combined with “techsourcing” to provide better results.

Who Are SKYWARN volunteers?

Volunteers include police and fire personnel, dispatchers, EMS workers, public utility workers and other concerned private citizens. Individuals affiliated with hospitals, schools, churches, nursing homes or who have a responsibility for protecting others are also encouraged to become a spotter. NWS encourages anyone with an interest in public service and access to communication to join the SKYWARN program. (1)

Why Join SKYWARN?

There can be no finer reward than to know that their efforts have given communities the precious gift of time–seconds and minutes that can help save lives. (2)

How Are Volunteers Trained?

NWS has 122 local Weather Forecast Offices, each with a Warning Coordination Meteorologist, who is responsible for administering the SKYWARN program in their local area. Training is conducted at these local offices and covers:

  • Basics of thunderstorm development
  • Fundamentals of storm structure
  • Identifying potential severe weather features
  • Information to report
  • How to report information
  • Basic severe weather safety

Classes are free and typically two hours long. To find out when a SKYWARN class will be conducted in local your area, contact your local Warning Coordination Meteorologist. (3)

What else?

In some areas where Emergency Management programs do not provide storm weather reports, people have organized SKYWARN groups that work independent of a parent government agency and feed valuable information to NWS. While this provides the radar meteorologist with much needed input, the circuit is not complete if the information does not reach those who can activate sirens or local broadcast systems.  To this end, SKYWARN also distributes information from the National Weather Service. (4)

So What?

There has been much talk about the potential role of “Volunteer Technical Communities” in the context of disaster response. VTCs, as they are now called, came to the fore in the wake of the Haiti earthquake when their crisis mapping efforts helped the US Marine Corps and US Coast Guard save lives. VTC is the new buzzword, but technology-able volunteer communities have been around for decades. SKYWARN has been active for almost half-a-century.

As my colleagues and I continue to operationalize the Standby Volunteer Task Force (see this blog post and recent article on CNN), it behooves us to learn as much as possible from others who have set up volunteer networks in the past and in other sectors. The SKYWARN example shows how volunteer networks can interface with formal organizations in an effective manner.

The Spotter Network is a newer and less formal volunteer community that is not sanctioned or affiliated with the NWS or any other government agency. Nevertheless, “several National Weather Service employees and other officials have taken an interest in the capabilities [that this network] brings to them to integrate ground truth provided by spotters into their operational responsibilities. All at zero cost to them.”

The National Weather Service has responded positively to increasing public participation by launching the eSpotter, a system “developed to enhance and increase timely & accurate online spotter reporting and communications between spotters and their local weather forecast offices. The use of the system is currently available for trained spotters and emergency managers.”

Conclusion & Recommendations

  • Volunteer groups and government organizations can work together.
  • Volunteers networks include professionals as well as amateurs.
  • Training is an integral component of volunteer technical networks.
  • Government participation is key to leveraging volunteer groups.
  • Government can provide the infrastructure for collaboration.
  • Government reps should sit on the board of volunteer networks.
  • Generating unique data sets will get government attention. Fancy technology, bravado and media coverage won’t.

Analyzing Call Dynamics to Assess the Impact of Earthquakes

Earthquakes can cripple communication infrastructure and influence the number of voice calls relayed through cell phone towers. Data from cell phone traffic can thus be used as a proxy to infer the epicenter of an earthquake and possibly the needs of the disaster affected population. In this blog post, I summarize the findings from a recent study carried out by Microsoft Research and the Santa Fe Institute (SFI).

The study assesses the impact of the 5.9 magnitude earthquake near Lac Kivu in February 2008 on Rwandan call data to explore the possibility of inferring the epicenter and potential needs of affected communities. Cellular networks continually generate “Call Data Records (CDR) for billing and maintenance purposes” which can be used can be used to make inferences following a disaster. Since the geographic spread of cell phones and towers is not randomly distributed, the authors used methods to capture propagating uncertainties about their inferences from the data. This is important to prioritize the collection of new data.

The study is based on the following 3 assumptions:

1. Cell tower traffic deviates statistically from the normal patterns and trends in case of an unusual event.
2. Areas that suffer larger disruptions experience deviations in call volume that persist for a longer period of time.
3. Disruptions are overall inversely proportional to the distance from the center(s) of a catastrophe.

Based on these assumptions, the authors develop algorithms to detect earthquakes, predict their epicenter and infer opportunities for assistance. The results? Using call data to detect when in February 2008 the earthquake took place yields a highly accurate result. The same is true for predicting the epicenter. This means that call activity and cell phone towers can be used as a large-scale seismic system.

As for inferring hardest hit areas, the authors find that their “predicted model is far superior to the baseline and provides predictions that are significantly better for k = 3, 4 and 5″ where k represents the number of days post-earthquake. In sum, “the results highlight the promise of performing predictive analysis with existing telecommunications infrastructure.” The study is available on the Artificial Intelligence for Development (AI-D) website.

In the future, combining call traffic data with crowdsourced SMS data (see this study on Haiti text messages) could perhaps provide even more detailed information on near real-time impact and needs following a disaster. I’d be very interested to see this kind of study done on call/SMS data before, during and after a contested election or major armed conflict. Could patterns in call/SMS data in one country provide distinct early warning signatures for elections and conflict in other crises?

How Crowdsourced Data Can Predict Crisis Impact: Findings from Empirical Study on Haiti

One of the inherent concerns about crowdsourced crisis information is that the data is not statistically representative and hence “useless” for any serious kind of statistical analysis. But my colleague Christina Corbane and her team at the European Commission’s Joint Research Center (JRC) have come up with some interesting findings that prove otherwise. They used the reports mapped on the Ushahidi-Haiti platform to show that this crowdsourced  data can help predict the spatial distribution of structural damage in Port-au-Prince. The results were presented at this year’s Crisis Mapping Conference (ICCM 2010).

The data on structural damage was obtained using very high resolution aerial imagery. Some 600 experts from 23 different countries joined the World Bank-UNOSAT-JRC team to assess the damage based on this imagery. This massive effort took two months to complete. In contrast, the crowdsourced reports on Ushahidi-Haiti were mapped in near-real time and could “hence  represent an invaluable early indicator on the distribution and on the intensity of building damage.”

Corbane and her co-authors “focused on the area of Port-au-Prince (approximately 9 by 9 km) where a total of 1,645 messages have been reported and 161,281 individual buildings have been identified, each classified into one of the 5 different damage grades.” Since the focus of the study is the relationship between crowdsourced reports and the intensity of structural damage, only grades 4 and 5 (structures beyond repair) were taken into account. The result is a bivariate point pattern consisting of two variables: 1,645 crowdsourced reports and 33,800 damaged buildings (grades 4 and 5 combined).

The above graphic simply serves as an illustrative example of the possible relationships between simulated distributions of SMS and damaged buildings. The two figures below represent the actual spatial distribution of crowdsourced reports and damaged buildings according to the data. The figures show that both crowdsourced data and damage patterns are clustered even though the latter is more pronounced. This suggests that some kind of correlation exists between the two distributions.

Corbane and colleagues therefore used spatial point pattern process statistics to better understand and characterize the spatial structures of crowdsourced reports and building damage patterns. They used the Ripley’s K-function which is often considered “the most suitable and functional characteristic for analyzing point processes.” The results clearly demonstrate the existence of statistically significant correlation between the spatial patterns of crowdsourced data and building damages at “distances ranging between 1 and 3 to 4 km.”

The co-authors then used the marked Gibbs point process model to “derive the conditional intensity of building damage based on the pairwise interactions between SMS [crowdsourced reports] and building damages.” The resulting model was then used to compute the predicted damage intensity values, which is depicted below with the observed damage intensity.

The figures clearly show that the similarity between the patterns exhibited by the predictive model and the actual damage pattern is particularly strong. This visual inspection is confirmed by the computed correlation between the observed and predicted damage patterns shown below.

In sum, the results of this empirical study demonstrates the existence of a spatial dependence between crowdsourced data and damaged buildings. The results of the analysis also show how statistical interactions between the patterns of crowdsourced data and building damage can be used for modeling the intensity of structural damage to buildings.

These findings are rather stunning. Data collected using unbounded crowdsourcing (non-representative sampling) largely in the form of SMS from the disaster affected population in Port-au-Prince can predict, with surprisingly high accuracy and statistical significance, the location and extent of structural damage post-earthquake.

The World Bank-UNOSAT-JRC damage assessment took 600 experts 66 days to complete. The cost probably figured in the hundreds of millions of dollars. In contrast, Mission 4636 and Ushahidi-Haiti were both ad-hoc, volunteer-based projects and virtually all the crowdsourced reports used in the study were collected within 14 days of the earthquake (most within 10 days).

But what does this say about the quality/reliability of crowdsourced data? The authors don’t make this connection but I find the implications particularly interesting since the actual content of the 1,645 crowdsourced reports were not factored into the analysis, simply the GPS coordinates, i.e., the meta-data.

Crowdsourcing the Analysis of Satellite Imagery for Disaster Response

I recently got a call from a humanitarian colleague in the field who asked whether it would be possible to crowdsource the basic analysis of satellite imagery.  They wanted to know because their team was sitting on a pile of satellite imagery but did not have the time or  staff to go through the high-resolution pictures. They wanted to use the imagery to identify where IDPs were located in order to know where to send aid via helicopters.

My colleague’s question reminded me of the search for Steve Fossett, a famous adventurer who went missing in September 2007 after taking off from a small airport in Nevada in a small single-engine airplane. The area where Steve went missing is particularly rugged terrain. The search and rescue aircraft were not able to find any sign of wreckage. However, high-resolution satellite imagery from GeoEye enabled Amazon to produce a Help Find Steve Fossett website, allowing volunteers to search small sections of the available imagery.

“This is an approach to more rapidly search a large area of imagery using many eyeballs of people around the world. A similar technique was used to search for Jim Gray, a Microsoft scientist who went missing on his sailboat off the coast of California.”

Micro-tasking the analysis of satellite imagery has already been done.  So why not in the context of disaster response? One could add this feature to a platform like Crowdflower, which is already being used as a plugin to micro-task the processing of text messages from disaster affected areas. Instead of text, volunteers would see a small subsection of satellite imagery. They’d be asked whether they could see any evidence of individuals in the imagery and if so how many approximately they can make out. A simple 5-minute guide on how to identify people and approximate population size using satellite imagery could be put on YouTube for volunteers to watch before getting started.

Like any type of micro-tasking approach (a.k.a. mechanical turk service), one could triangulate answers to maintain some level of quality control. For example, only when 10 volunteers each tag an image as having individuals in it would the picture be processed as such. The same would apply to the population ranged estimated in a given image. This wouldn’t necessarily produce perfect results, but it would take the bulk of the load off the shoulders of humanitarian on the ground. It would act as a first filter.

Of course the obvious question that arises is security and privacy. There are several ways this could be addressed. First, images would be stripped of any GPS coordinates. Second, images would be sliced up in small bits to prevent easy recognition of the territory. Third, a volunteer would not be given contiguous slices so they couldn’t piece together more information from the satellite imagery. These measures won’t provide 100% security and privacy. The only way to achieve that would be to use bounded crowdsourcing, i.e., only have trusted individuals analyze the imagery.

Standby Crisis Mappers Task Force: Apply Now!

Please click here to apply to the Crisis Mappers Volunteer Task Force.

_______________________________________________________

The disaster response to Haiti was unprecedented in terms of volunteer buy-in and contribution. It was also reactive. The hundreds of volunteers who rallied to the cause were certainly able and committed but one of the main challenges during the first few weeks was the need to train and maintain this informal network. The humanitarian community openly recognizes the important role that volunteer networks can play in crisis response. What they need now are guarantees that a trained and professionalized volunteer force can be on standby and activated within hours. The good news? Many of the volunteers I interacted with during the response to Haiti, Chile and now Pakistan are eager to join a professionalized volunteer standby team.

So what exactly are we waiting for? I posed this question to my colleagues George Chamales and Rob Munro in San Francisco yesterday. Indeed, there’s no reason to wait. We can get started now so we can take this initiative to the upcoming International Conference on Crisis Mapping (ICCM 2010) and get feedback from participants. The challenge, as mentioned in my previous blog post on Disaster Relief 2.0, is to find a way to interface an informal distributed network of volunteers with a highly organized and structured organization like UN OCHA. Three types of reliable networks are needed for this interface: (1) Tech Team; (2) Task Team; and (3) Crowd Force Team.

On the technical side, what colleagues and I have found to be particularly important is to have a group of software developers who are already highly experienced in deploying platforms like Ushahidi, FrontlineSMS, Sahana, etc. This is not about building new tools from scratch. The point here is to rapidly customize existing tools that have already seen action. On the Ushahidi side, there are more and more seasoned Ushahidi developers. These individuals are the ones who made the deployments in Haiti, Chile and Pakistan possible. This network of core technical and reliable volunteers doesn’t need to be large and it already exists.

What this group needs, however, is a support team that can take specific technical tasks given to them for implementation, e.g., fixing an important bug, etc. That way, the core team can focus on rapidly developing customized Ushahidi plugin’s and so on. We need to create a roster of standby software dev’s who are already qualified and ready to support the core team. This group largely exists already, but we need to formalize, professionalize and publicize this information on a dedicated site and turn them into a standby force.

The second type of standby group needed is the Task Team. These are individuals who are not software developers but savvy in media monitoring, geo-referencing, mapping, blogging on updates, etc. These individuals already exist, they played an invaluable role in contributing their time and skills to the responses in Haiti, Chile and Pakistan. Again, it’s just a matter of formalizing, professionalizing and publicizing the information, i.e., to render visible the capacity and assets that already exists, and to have them on standby.

This core task-based team also needs a strong support team for back-up, especially during the first few days of an emergency. This is where the Crowd Force Team comes in. This important team doesn’t need prior-training; only Internet access, browsing experience, an interest in online maps, news, etc. Perhaps most importantly, members of the Crowd Force Team are known for their energy, commitment, team-player attitude and can-do mentality.

We want to formalize this Standby Crisis Mappers Task Force in a professional manner. This means that individuals who want to be part of Tech, Task or Crowd Force Team need to apply. We will first focus on the Ushahidi platform. In the case of the Tech and Task team, interested applicants need to clearly demonstrate that they have the experience necessary to be part of the Standby Task Force. I would actually want to include representatives from the humanitarian community to participate in vetting the candidates who apply. Individuals who want to join the Crowd Force Team will also need to apply so we can keep a roster of the people power available along with their skill set.

There’s no reason we can’t do this. If we learned anything from Haiti, it’s that Community Emergency Response Teams (CERTs) don’t need to be physically present to contribute to disaster response thanks to online social networking tools and open source platforms like Ushahidi, etc. They can be part of the online community. We need CERTs 2.0 and just like traditional response teams, they should be trained and ready.

My experienced colleagues George Chamales and Anahi Ayala will lead the Technical and Task Teams respectively. Anahi will also coordinate the Crowd Force Team. They will help select the applicants, set up the appropriate communication channels and keep a calendar of which members of their teams are available for rapid response on a daily basis. Jaroslav Valuch and I will support George and Anahi in their efforts.

Please click here to apply to the Crisis Mappers Volunteer Task Force. Once we have developed a robust model for interfacing with the humanitarian community using the Ushahidi platform, we hope to work with other colleagues from FrontlineSMS, Sahana, etc., so that their qualified volunteers can be part of this dedicated Task Force.

Calling 911: What Humanitarians Can Learn from 50 Years of Crowdsourcing

Before emergency telephone numbers existed, one would simply pick up the receiver and say “get me the police” when the operator answered. In fact, operators became the first point of contact for emergency dispatch. They would keep lists of specific numbers in their local towns (local fire department, local doctor, etc) to provide a very personalized emergency service and fast track response.


London was the first city to deploy an emergency number system. The number 999 was launched on June 30, 1937. When called, “a buzzer sounded and a red light flashed in the exchange to attract an operator’s attention” (1). The first number to be used in North America was the 911 system deployed in Winnipeg, Canada in 1959. The first US system, also using the 911 number, was launched in Alabama and Alaska in 1968. It wasn’t until the 1980s, however, that 911 was adopted as the standard number across most of the country.

Today, about 240 million 911 calls are made in the US each year, 30%-50% of which are placed using wireless services, and this number is increasing steadily.

When discussing the use of crowdsourcing to collect crisis information in humanitarian disasters, one of the overriding concerns is: “But what if the information is false? How can we trust that the information reported is true?” We forget that national emergency telephone systems have faced the same challenge for half-a-century. Indeed, 911 is a 50 year-old crowdsourcing system! So our colleagues in law enforcement may have learned a few things during this time, which could inform our work in the humanitarian field.

Incidentally, this may be a silly question but why in the world did governments set up  emergency phone numbers if the information collected using this crowdsourced approach is not immediately verifiable? Have the police gone nuts? What were/are they thinking? Were police crowdsourcing reports before telephone lines sprung up across the country? Maybe one had to run, bike or drive to the police station. Or if you were lucky, perhaps you’d have a police officer strolling the streets at just the right time.

So why not keep that good old analog system then? Well, lets face it, do we really want to leg it to the station every time something’s strange in the neighborhood?  No, we want to be able to call…

Can we assume that we’ll always be mobile during an emergency? Do we want to leave it up to chance that a fire truck might be patrolling the streets when the house next door house goes up in flames? Probably not.

In fact, the world’s oldest emergency (crowdsourcing!) call service—the UK’s 999—was introduced over 70 years ago after a London fire on November 10, 1935 killed 5 women. A neighbor had tried to phone the fire brigade but was held up in a queue by the telephone exchange. Neighbor Norman was so outraged that he wrote a letter to the editor of The Times:

A public outcry resulted (which could have been crowdsourced and mapped on an Ushahidi platform as a complaints mechanism):

This prompted a government inquiry. And thus was born the largest crowdsourcing system of the day. Rather ironic that it was ultimately user generated content that created today’s national emergency phone services. Wouldn’t it be great to get a UN inquiry along those same lines that established a crowdsourcing system for humanitarian crises? Sounds crazy, I know, but hey, 999 probably sounded a little nuts back in 1937 as well. And yet, they decided to test the idea in London, then extended trials in Glasgow and within 10 years the entire country was covered. I don’t see why a similar iterative approach couldn’t work in disaster response.

But what challenges does an emergency phone system face? The misuse and abuse of 911 can be divided into 2 categories: unintentional and intentional calls (2). The former includes phantom calls, misdials and hang-up calls. Lets focus on the latter issue, which be divided into the following categories: Non-emergency Calls, Prank Calls, Exaggerated Calls and Lonely Complainant Calls.

  • Non-emergency Calls: reports suggest that non-emergency calls account for a large percentage of 911 calls. For example, callers will phone in to report their car radio getting stolen, or ask for the results of a football game, the time of day, etc. 911 operators even get callers who ask them to transfer their calls to another number since calling 911 is free.
  • Prank Calls: most agencies apparently do not keep figures on total number of prank calls but these generally come from children and teenagers. Diversionary calls represent a sub-category of prank calls. Callers will dial 911 to send the police to a location where not emergency has occurred, sometimes to divert attention away from criminal activity committed by the caller. “There are only a few ways to determine if a call is diversionary: if the caller admits it; if someone informs on the caller; or if the dispatcher or police compare the caller’s location with that of the alleged emergency, to determine if the caller could plausibly claim an emergency at the called in location” (4).
  • Exaggerated Emergency Calls: callers will sometime intentionally exaggerate the seriousness of an emergency expecting that the police will respond faster. It is reportedly unclear how extensive this problem is.
  • Lonely Complainant Calls: other callers will repeatedly report an emergency over a series of month or years but the police never find evidence of there being one. These calls are often made by the elderly and those with mental health problems.

As these news articles here & here show, false reports to 911 can claim lives. Does this mean that law enforcement is considering pulling the plug on the 911 system? Of course not. So how does law enforcement deal with all this? Lets stick to prank and diversionary calls since this comes closest to the most pressing concerns we face in the humanitarian context. (Note the other issues listed above are typically addressed by educating the public).

Law enforcement’s response to prank calls involves targeting violators and applying graduated sanctions, such as fines or jail time. In Ohio, a public service announcement made clear to users that “we know where you are” when you call 911. Prank calls reportedly dropped as a result (5). Police can also take action by targeting specific phones that are used for prank calls. In another example, a hotel in Vegas routed all 911 calls to hotel security for triage after a large number of false 911 reports were made to the fire department.

Could we do something similar within a humanitarian operation? There’s already precedent to prosecute hate-based SMS, as happened in Kenya. We could work with telcos in question to send out a mass SMS broadcast to all subscribers letting them know they can be prosecuted for deliberately reporting false information.

That’s not a silver bullet, of course, but it seems to help national emergency phone systems. We could also draw on natural language processing (NLP) technologies like Swift River to create veracity ratings for crowdsourced reports. Of course, when confronted with a major disaster, everyone may be calling 911 at the same time, thus overwhelming capacity to respond.

In terms of this operational response, one partial answer may be revitalizing Community Emergency Response Teams (CERTs). Another partial answer may be the idea of crowdfeeding, or crowdsourcing response as I blogged about here based on a recent presentation I gave at Red Cross Conference in DC. During that same conference, the Red Cross revealed the results of a study on the role of social media in emergencies, which showed that more than 70% of those surveyed expect a response within an hour after posting a request on an social media platform. Now, there are too few disaster response professionals to assign to every street to meet those expectations (not to mention the cost implications). So they can’t always be there, but the crowd, by definition, is always there.

In the case of national phone emergency systems, there are usually laws that require the police to respond (not that they always do). This may be difficult to work out in the context of humanitarian response. So let me share an anecdote from the Ushahidi-Haiti Project. One of our overriding concerns after launching the 4636 short code with colleagues was raising expectations among those texting that someone would respond to these SMS’s. Three points:

1) Colleagues and I spent hours on Haitian Diaspora radio and television answering questions from listeners and viewers about the purpose of 4636. We made it very clear that the service was simply an information service and that we couldn’t guarantee any kind of response. We also explained that some responders like the US Coast Guard and Marine Corps were prioritizing life and death situations and therefore were not responding to every text message. This helped callers understand the purpose and limits of the service.

2) As a result of these concerns regarding expectations, my colleague Jaroslav Valuch and I recommended that PakReport.org adjust their public messaging campaign by asking people to report their observations instead of their needs. One could also invite people to text in their complaints, thus crowdsourcing perceptions (real or otherwise) of frustration and discontent which could provide humanitarians with important situational awareness. But this too may raise expectations of response. So sticking with simple reports based on observations is sometimes more prudent.

3) As studies from Aceh (the 2004 tsunami) and Pakistan (the 2005 earthquake) showed, it is important to communicate with disaster affected communities, even if the message is that help is not yet on the way. See Imogen Hall’s research and the CDAC consortium, for example.

I’m using the 911 emergency system as an analogy and don’t pretend that the model can be automatically applied to the humanitarian context. But these phone-based emergency crowdsourcing systems have been around for half-a-century and it would be naive to discount any of the lessons learned and best practices that this wealth of experience has produced across such a large scale.