Last week we explored Ushahidi as a mapping platform for crises, in particular the earthquake in Rabat, Morocco. More recently we used Google Earth to map the cases we wished to deal with on the ground. After having experience with both platforms, we came to the conclusion that Google Earth offers better resources for our goals. For example, Google Earth provides better visualization of geographic satellite information such as the location of roads and buildings, and paths from aid stations to where it is needed. This was especially useful to us because CRS’ mandate targets the poor and the disaster stricken, who typically live in areas that aren’t mapped. For example, our crowdmap could not provide details of the shantytowns; thus, we felt that Google Earth was much more useful to plot the reports in coastal shanty towns and mark out the roads in detail in order to provide relief more efficiently. It gives us a better sense of the situation on the ground, especially since we have not been there before.

Another thing that Google Earth provides is the ability to add different layers and types of information. Adding pictures, videos and links allows us to present a more holistic picture of the situation on the ground. In addition we could add and customize different relevant points, like the Moroccan Ministry of Health who we plan to collaborate with for our intervention efforts. By plotting its location on the map, we can easily see its distance from our target populations. This will be very useful because it will provide a visual map of paths to and from the reports CRS plans to help with.

On the other hand, we found that it was a little difficult to share and collaborate on the information easily. Multiple people cannot work on a specific kmz file on different computers at the same time, as we could do with the crowdmap and with other programs like google docs. Instead, one person had to work on the same file and then send it around for others to add their input one at a time. This made it difficult to share and update information easily. This process also required quite a bit of familiarity with certain computer functions not commonly used by the general public.  Most of the Ushahidi platform, for example, was either self-explanatory or only required minimal instruction.  With Google Earth, we lost some information on the way and duplicated a lot of effort because it took awhile to understand how to use it. For Google Earth to be used by NGOs, mappers will have to be trained.  If they are not kept on staff, time will have to be spent on this training.

What our Google Earth map showed: what we wanted to convey, and why we chose our specific data visualization

We wanted to use Google Earth to visualise how we and other organisations could provide aid, ensuring a comprehensive plan that matches the situation on the ground. Google Earth could help by showing us the location of each report from the coastal shantytowns, and the most accessible paths to take in order to allocate resources and aid. It could also pinpoint the main resources that we may be able to leverage off, particularly the Ministry of Health.

Hence, we chose to divide our target population into three areas – the northern, central, and coastal shantytowns. By outlining each area with a polygon, we isolated the reports in each of the three areas in order to see the resources like hospitals, roads and aid centers nearest to those reports.  This can facilitate the division of CRS’ efforts based on geography, and each faction will have its own sub-map.

We also decided to mark out the three paths between the airport in Rabat and each of the three areas as we will be using those roads when CRS does enter Rabat. The ministry of health could be a base that we might work from, so we also marked out another two paths from the ministry of health (which is in the area marked northern shantytowns) to the other two areas.

This also explains why we customised certain icons. Specifically, we chose the icons of the places that we thought were most important, so they would stand out on the map immediately as the point places to pay attention to. We customized a CRS Morrocco relief icon as a representation of our organization in Rabat. The Moroccan Ministry of Health icon was also customized as we plan to affiliate with them as our liaison in Rabat. The only aid station was also picked out. This allows us to plan the aid distribution, and allows others viewing the map to pinpoint our bases immediately, which could help the planning process.

We also wanted to use Google Earth to gain a better idea of the situation on the ground, above and beyond a cartographic representation. This could be useful to us, considering that CRS does not have a substantial experience working in Morocco. Hence, we picked photos, videos and links to websites that could help to provide a more comprehensive picture. We chose photos from past Moroccan Earthquakes that would give an idea of how the situation would look like, away from a mere cartographic representation. For example, we chose a picture of a situation near the coastal areas to illustrate one of the data points. We also chose videos and documentaries of previous Moroccan earthquakes to showcase the effects of past earthquakes, as well as an explanatory video on earthquakes to provide knowledge. A video on CRS was included under the CRS icon to introduce what CRS has done.Website links to CRS and the ministry of health were picked so that people could gain a better understanding of the key actors.

CRS’ target audience

Since Google Earth contains incredibly detailed geographical data, it is probably not the most efficient platform by which to share information with the public. In general, Google Earth map is probably most useful for aid organizations themselves.  Knowledge about specific terrain can, for example, be useful in planning the transportation of supplies and people.  Accordingly, our map includes not only the locations of aid requests, but the locations of certain NGO assets including our own.  It is our hope that we will be able to share this Google Earth map in order to facilitate CRS’ collaborations with other organizations and interoperability among all sources of aid.

CRS and mapping: Ushahidi verses Google Earth

Ushahidi seems most useful for the initial organization of aid requests.  Data can be collected and input to a crowdmap relatively quickly.  We would use Ushahidi at the beginning of a relief effort, to preliminarily gauge where need is concentrated and which resources are most needed. It is also useful during this stage as a sharing platform, which other organizations can refer to as well.

Google Earth is preferable when planning the actual deployment of a response team.  The increased detail of geographical information is invaluable for planning travel routes and determining natural assets and obstacles.  Again, it is not our preferred platform for sharing information with the public because it is too detailed.

Benefits and Challenges

As we mapped relevant data on Google Earth, we learned a lot about the benefits and challenges of using this platform. We enjoyed the ability to easily create categories (folders) and then sort data points into these folders. This allowed for easy navigation of the information. Google Earth also allows for the embedding of content, which makes it easier to see what’s going on, serving as a visual accompaniment for any data or information. If one puts enough time into clearly organizing data, it can easily be shared and interpreted. On Google Earth we can additionally see the terrain and land affected. The inability to access updated road and land information is an ongoing problem in crisis mapping, and this is more easily solved with access to (recently updated) satellite images.

While moving data into Google Earth, we did find that it was more technologically advanced than other platforms we had previously encountered. However, once we determined the most appropriate method to input data using the information we learned in class, the data customization process went relatively smoothly. One additional challenge arose during customization is that only one person could work on the map at a time, as it is saved to one individual computer.

Visualization of Data

We chose to create different icons based on the type of information. All points are organized into folder categories for easy cataloging:

This legend serves as an accompaniment to our map for quick interpretation of the different data points.

Customization of data

We decided not to title specific data points (besides IDP camps) so as not to clog up the map with words. This also allowed the category of the data point as indicated by the icon to be easily visualized and interpreted. We created a few sample paths to show potential routes from areas needing water to areas with available water, as well as polygons around areas where more extensive aid is needed. Additionally, we embedded videos, pictures, and websites so that those viewing the map can better familiarize themselves with the area and its history. As a native organization we do understand the area, so a quick visual refresher (such as a video walking tour of Rabat) will be the best way to prepare our volunteers for field work.

What we wanted to convey

Through our map we aimed to determine the relationships between data points, not simply compilations by category as viewed on Crowdmap. The Google Earth platform allows us to better see the relationships between various aid requests. From this compilation, we can extrapolate information such as where a potential IDP camp may be forming and where we most best be of use.

Importance of target audience

This map can be used for several purposes. Within our organization we can utilize our Google Earth map to determine where to send volunteers so that we can reach the most affected individuals possible. Putting our data on Google Earth allowed us to locate citizens’ positions and connect need to aid through paths, and we will hopefully be able to reach these individuals to let them know where to find water.

Path from a hotel with water outages to a restaurant supplying clean water.
We also feel that this map would be a useful resource for individuals outside Morocco to better understand the extend of the damage regarding water and sanitation in Rabat and the surrounding areas. For example, we can reach out for aid from the IFRC with a map clearly displaying need.

Ushahidi vs. Google Earth

From our experience with both Ushahidi and Google Earth, we have determined that an organization should choose between these platforms based on the work they wish to do. Ushahidi should be used if an organization is doing an SMS campaign or the like, something that requires multiple people to have access to and be able to contribute to data in real time. Google Earth is more of a visualization tool, with better visual separation of categories with the ability to create paths and other shapes. It can possibly aid in the implementation of relief efforts of a single organization, as well as spreading the word to those outside the crisis.

We also have to take into consideration that our supplemental meal plan may not be as effective as we had hoped it might be. After participating in the simulation and making our crowdmap, we now have a greater awareness of how people are going to react. There is a change that people may lie about the need of resources, or steal resources from one another. Without a way to satisfactorily verify data about families in the area, we have no way of determining which families are taking in orphans and where resources really need to go. To help combat this, we will add a voucher program to the plan, giving a voucher to families that we match up with orphans. That way, we would be able to tell which families we know for sure have taken orphans in, or those that are trying to exploit the system. It would still be difficult to determine genuine need, but it may prevent families from trying to live off of our meal plans without actually needing the assistance.

In our plan, we would also like to implement frontline sms in order to foster communication between our HQ and all of our partner HQs. Using the frontline platform, we can easily send out messages and receive them from our partners. We would also likely use Google Earth in order to make an offline map that can be utilized by our partners for more efficient allocation of resources, and to determine the best routes for our workers to travel through the city taking danger into account. Ushahidi will be useful to take in information that we can then export to the previously mentioned google earth kml map.

We expect that the implications of using crisis mapping technologies for our team would be somewhat mixed. On the one hand, these technologies, particularly Frontline SMS, have the potential to give us better information and to visualize the populations we would be targeting with our programs so that we could effectively allocate project resources. However, the significant effort needed to get these systems up and running might easily sideline other projects for our staff. We also don’t know if community response to those programs would be positive or significant enough to adequately understand need without putting other mechanisms in place to better understand the situation. We would hope that implementing these projects would provide us with a favorable context in which to work, as it would show our genuine interest in having community input about their needs. However, this could also backfire: if the citizens of Rabat felt we were not responding to their needs in a timely manner, there could be significant fallout that might hinder our operational capacity.

1. Sending in aid supplies
a. Assessing the situation through communication with existing relief organizations
b. Using supplies to stimulate the economy such as recirculating money and putting in more money

2. Creating jobs
a. temporary relief-oriented jobs
b. restarting previous sources of employment and income such as agriculture and the phosphate mining industry.

Modifications?
Given our lack of experience in Morocco, including language and sociocultural barriers, it proved to be a wise decision to limit our target population to only the low social economic status areas of Rabat. It is difficult to identify operational problems when we are not actually responding to the crisis or simulating a response. At this point, our plans seem manageable.

That said, one of the things we may do differently is to draw on the existing resources of the affected population. While we noted in our original plan our desire to collaborate with them, we now realize just how important this is. We should avoid coming in with the flawed mentality that we are there to “save” them; rather we should act in partnership, in recognition of the skills that each side brings to the table. As such, distribution of supplies should be carried out in conjunction with the population. We hope to be in constant communication with the leaders of the community (either existing leaders, or those chosen to represent the community), so we can understand the local situation better and plan accordingly. This should also strengthen community empowerment which may be a very important factor in re-building the community after this disaster.

Moving off of that is the realization of the importance of culture and language in implementation. We realized that the assumptions we made, such as being able to overcome cultural differences, are major assumptions that may not hold in reality. Yet, being able to form a relationship with the people is crucial. As such, we will include as a preparation process an intensive attempt to understand the culture of Morocco beforehand. Our team that works in Morocco will include people who speak the language and are familiar with their culture. This would preferably include people who live in Morocco or have previously lived there.

Making use of crisis mapping tools
We explored a number of technologies – open street maps, crowdmap, google earth and frontline sms.

Open street maps could be incredibly useful to map the shantytowns on a map, that can then be exported onto crowdmap as the base map. In other words, it would be used as the first step, prior to using the other technologies. As we realized when using crowdmap, there is little cartographic data of shantytowns on existing maps since shantytowns are by their nature relatively unknown. This could make relief efforts in shantytowns difficult. Open street maps could then be used to circumvent this problem. A foreseeable problem would be getting the information to update open street maps. To solve this, we could collaborate with our contacts on the ground, as well as locals, to gather information that we could then input into open street maps.

Crowdmap would be used during both the short and long term stages of our project. In the short term, it may be helpful to input reports about need for food, aid, water etc, so that we could then send members to distribute aid, or rely the information to other aid organizations.
It could also help us to locate the major sources of short and long term employment, such as temporary disaster relief work in the short term, and the fishing, agriculture and phosphate mining industry in the long run.

Google Earth could be used throughout the entire process – both in the short term, but especially in the long term. It would be useful to understanding the situation on the ground, particularly by providing pictures that give a more vivid picture. It could also be used to map out the roads and pathways from one key point to another (e.g. hospital to airport etc) and to pinpoint the important areas. It could also provide explanatory information, such as videos and links that provide more info on CRS and its partners on the ground, or about earthquakes in general. Further, Google Earth would be an effective tool for monitoring and evaluating, as its historical timeline allows us to compare time periods to see whether our efforts are working.

Google Earth would primarily be a tool for our collaborators in Morocco, as the maps tend to be full of information, but complicated from a pedestrian standpoint. For similar reasons, Google Earth maps would be a good communication method to the financial donors.

Frontline SMS would be most useful if the contact number were publicized immediately at the onset of the crisis, although it could have long-term applications. In the short term, text messages could alert our organization about immediate needs for food, shelter, etc. It could also later be used to monitor the impact of our economic relief efforts. People could send us reports about household income and industry success so that we could assess our efficacy in providing jobs in the area.

What benefit could this have?
We are hopeful that using crisis mapping tools will allow or program to be more adjusted to the situation on the ground. Crisis mapping tools allow us to modify our information sharing systems, and understand the local situation as it happens. As such, we will be able to flexibly adjust our program if need be.

Also, as previously discussed, crisis mapping tools will prove beneficial for both short-term relief and long-term sustainability. Although each tool individually has its advantages and disadvantages towards the relief process, the tools used in conjunction with each other should prove to be especially useful in the necessary steps of providing relief after a natural disaster. The CRS plans to utilize each of the crisis mapping tools and will continue to do so in its future.

In fact, using these crisis mapping tools may prove helpful to the overall situation. Other organisations carrying out aid relief may use information from our crowdmap and google earth to fill in their own knowledge gaps. (And vice versa, we may, of course, do the same thing). Observers may also look at these resources to gain a better picture of the relief efforts on the ground.

As the World Food Program, our ultimate mission in this scenario is to promote long-term food security. After assessing the needs of the population in the face of the Rabat earthquake crisis, we judged that doing so would require a two-phase approach. We first have to provide immediate aid as a part of the response effort. Concurrently, we should begin the development of programs to promote long-term food stability as an integral part of the reconstruction process. These will continue beyond the duration of the immediate crisis.

For each of these phases we designed plans to meet our objectives. As a part of the response effort, we would lead an aid-distribution effort that galvanized local fishermen into a network of distributors servicing the camps developing along the Bou Regreg River. We would also support the efforts of the Moroccan Red Crescent by providing food for volunteers (which in turn we expected to maintain stability amongst populations not at risk, speeding the transition to a period of recovery.) To promote long-term stability we expected to implement a Food for Work program — most likely based upon vouchers — and a distribution program targeting schools.
Alterations to the Original Program Design

Looking back at our original plans with hindsight of the crisis itself and a course-load of knowledge about crisis-response, we have a much stronger sense of the nuances of a crisis and of the political parameters that define a response effort by any one organization. Given the particular crisis in Rabat and our role as the WFP, we would make some very particular programmatic changes:

1. Closer integration with other NGOs and the French military working on the ground.
   • Working in conjunction with other organizations on the ground increases political influence, man-power, access to resources and information and avoids the redundancies obvious in multiple organizations gathering data and distributing resources.
   • As the head of the UN Food Cluster, this is one of our primary responsibilities.
   • Mapping technology can be utilized to share information in an easily accessible manner.
   • Despite collaboration, the WFP, must remain both neutral and independent, particularly as the election looms closer.
2. Develop a registration system to ensure food resources are distributed equitably and to the right people. This is particularly essential in an IDP camp setting and could be integrated into the fisherman galvanization model.
3. Ensure adequate shipments of resources are able to get into the region and onto the ground as soon as possible. This is essential in establishing ourselves as a legitimate NGO/actor on the ground. Not only does it build trust with the public and increase our recognition as a partner that actually provides what we promise, but this increases overall regional stability and weakens the sympathies that the public might generate towards the terrorist groups that might capitalize on the unrest.
   • During our planning process we greatly underestimated the disadvantage we faced due to our lack of office in Morocco. When a population is unfamiliar with the work that we do and we are unfamiliar with the needs of the population, collaborative efforts are more difficult.
4. Recognize that technology doesn’t solve everything. We can’t rely wholly on technology, particularly in programs involving locals. Technology is not always accessible to every portion of the population. Furthermore, because of its indirect nature, it can retard the building trust.

Incorporation of Technologies

Now that we have experimented with crisis mapping technologies, we are better able to understand the uses that they can have in a crisis. Bringing this knowledge to the process of designing a response strategy, we are able to design programs that maximize the usefulness of the technologies available while also recognizing their limitations. We have begun to discuss a number opportunities for programs designed around crisis mapping technologies. These include:

• Frontline SMS Grain Price Regulation
  • As part of our Phase II program promoting long-term food security: Use Frontline SMS-style software to both gather and distribute information on local grain prices.
• GPS / Open Street Map Information Collection
  • In conjunction with other aid organizations, create a live map of the infrastructure in the city during the immediate response. Utilizing volunteer networks on the ground, we would direct the creation of an OSM piecing together the physical status of the city. With the information be entered by trained sources close to the action it would be maximally reliable, enabling an efficient and targeted relief effort.
• Food Vouchers Program
  • Provide food vouchers in paper form, but enable verification through cell phones.
  • Also, request information of where the vouchers are being used and what they are used to purchase. We can train store owners accepting vouchers to send texts with this basic information.
• Work-for-food volunteers
  • Partial registration of work-for-food volunteers  and distribution of work opportunities through cell phones. We recognize that we cannot rely entirely on this new technology for this service, but it can decrease paper work and processing time.

Implication of changes and technologies for overall situation

-We recognize that with respect to our goals for this specific scenario, crisis-mapping technology requires a certain level of basic training. As such,
-We have come to believe that the use of Frontline SMS technology will be most successful in supporting long-term stability. We do not believe it will be as useful during the early response phase because we cannot be sure that those most in need and our high risk populations will be able or willing to send texts.
-We do, however, believe that implementing these programs will aid our field staff in communicating with the office and tracking food stability indicators such as grain prices and voucher usage.
-The use of GPS/OSM capabilities to create a map of the usable and unusable infrastructure in the city will take time, but will become an important resource for our staff as well as for the staffs of other organizations, and will help with the coordination and improved efficiency of food transportation as well as reconstruction efforts.

One of the first things we learned was the importance of cooperating with other groups. We worked with the World Food Program to start a work for food program (where they worked for our programs and in return were helped by the World Food Program), and in general it was very important to understand the role of our NGO in the scheme of the crisis response. We also learned in our group and especially in the FieldEx exercise that we must understand that the people reporting data are real people on the ground in the crisis not just data reporters, and that we should not take them for granted. Also, not everything will go well – technology is not perfect, people will not always give us accurate information, and it can be extremely challenging to collect and interpret data efficiently and accurately.

From these lessons that we learned there are several changes that we would make to our original plans. We would definitely want to have a plan and organizational structure in place before the crisis occurred (although this cannot always be guaranteed). We decided to incorporate FrontlineSMS into our plan, resulting in this workflow:

* SMS program (advertised through blogs, radio, loudspeakers, pamphlets, etc.)
o We will interpret and process SMS data with FrontlineSMS (provided that it works for us), and will use publicized categories as outlined below and also in our previous blog post.
o We will additionally use FrontlineSMS to communicate with our volunteers, also outlined below and in our last blog post.
* We will then export it to Ushahidi, if we possess the server capacity to utilize this program.
o While we wait for Ushahidi to set up we can use Crowdmap if necessary, but we must be careful not to map sensitive information.

This process will facilitate a smooth transition of data from the ground to those processing data, and from the data processors to Crowdmap/Ushahidi and also back to our volunteers on the ground. This circular flow of data proved beneficial during our FieldEx simulation, and we believe that this flow is vital in the urgent manner of crises.

Incorporating these new technologies has many potential benefits. We will be very easily able to visualize and chart our process, which will allow us to see what work we still need to do, and we will be able to work much more fluidly. However, because it is impossible to guarantee that software would work (as seen in our FieldEx exercise with Crowdmap AND FrontlineSMS). A breakdown of one of these systems could have catastrophic consequences to the rest of our program.

We added FrontlineSMS to our plan because it has the potential to be an extremely valuable technology. We plan to have a number system, since keywords can be confusing, spelled incorrectly, or misinterpreted. Different numbers would identify a different need or problem, and then people would be instructed to describe their location to the best of their abilities. This would make the process of sorting through data much simpler – it would already be sorted by need on FrontlineSMS, and then volunteers would identify and map the locations. Uploading the data to Crowdmap/Ushahidi would help us identify trends in kind of need or amount of need in certain areas. We could also use it to communicate with our population by sending messages about services available (such as food, water, medicine) and releasing other important updates about the crisis to the general population. The messages must have very specific composition (so as not to upset people or be ambiguous) and it should be very clear that people should not reply to the messages unless they are reporting need, so that our system doesn’t get backed up.

An additional benefit FrontlineSMS offers is that people we are unable to have physical contact with, but who have cell phones, can receive information from us. We can use FrontlineSMS is to manage and communicate with our volunteers in the field. Volunteers could report on supplies remaining, sanitation problems, and any other important information. This would greatly improve our communication and information exchange within branches of our organization, making our process of gathering and interpreting information from the field less complicated (providing this technology functions).

We would like to incorporate the use of Ushahidi into our plan. Crowdmap allowed us to create very easy to identify categories and we could connect aid available with aid needed. However, the Crowdmap platform may not be able to handle the volume of information and traffic to the website. Because of this, we may wish to use Ushahidi as an individual server will keep information private until we wish to release a map to the public.

Using and understanding these new technologies will allow us to more accurately determine the specific needs of the population that we are serving. We can better streamline how our system works (for example incorporating the same categories into our map that we use with FrontlineSMS) and this will make our program as a whole run more efficiently. Since we are based on the ground in Rabat and functioning in an extremely high paced stressful environment, having a streamlined system in place which we know how to use and how it functions will reduce the time spent on processing data and make our response to the crisis as a whole more effective.

Initially, our group assumed that we would direct the entire relief effort in Morocco.  As an official government agency, we planned that all entering NGO’s and organizations would report to us and we would delegate responsibilities and resources as we saw fit. This plan, while it showed understanding that the Moroccan government needed to approve international groups before they entered Morocco, was not actually feasible to create an efficient and quick disaster relief plan. We soon realized that we had to incorporate these different groups as independent factions, and that it was our job to facilitate effective cooperation between them.

While this was mentioned this in our hypothetical plan of action, we could have gone further and enacted this network of relationships within our class. We did not communicate with the other groups outside of class time or exchange any kind of information. In hindsight, setting up a Google Document or Skype Chat with a representative from each of the groups would have been beneficial to understanding what each group was trying to accomplish and how we could all work together to achieve an ultimate goal of providing relief to the Moroccan people. We would consider intergroup collaboration (or lack thereof) to be the major flaw of our program design and execution.

For example, the Moroccan Red Crescent was one of the other groups situated in Morocco, though not necessarily affiliated with the Moroccan government. We could have easily found common ground to reach out to each other; they served our interests because they had the tangible supplies we were lacking, while we had valuable knowledge due to having a better understanding of the different areas affected by the earthquake. Even a meeting between single representatives from each group would have been helpful in facilitating an effective response plan. In a real situation, this kind of cooperative work would make sure all needs of the population were being met and prevent groups from responding to the same populations or problems.

While our overall plan remained sound, a number of unforeseen concerns related to information sharing, the program design itself, and logistical details developed as we explored different platforms. These different problems could be easily corrected by altering our initial program design. First, by defining our program in terms of short term care and long term health care we created false expectations of maintaining a standing medical structure far beyond our resources, rather than more feasible health monitoring and periodic check ups. We quickly realized that additional logistical needs, specfically security and water needs, would have to be worked into the structure of the plan. To bolster our abilities to meet these needs, we also realized that our plan required a greater information-sharing plan, both with other groups and the international community (particularly donors).  Moreover, the quality and type of this information would have to be substantially different, a process that we would need to integrate into our plan from the get-go.

New technologies like Frontline SMS, Open Street Map, Ushahidi, and Google Earth directly serve our purpose as the Moroccan Ministry of Health. Using these resources would represent the first advanced recording of a disaster situation in Morocco. The rapid-response capabilities of Frontline SMS would be utilized to help those in need, and the map-drawing features of OSM, Ushahidi and Google Earth would be used to establish the locations of disaster areas and previously-unmapped slums. But these technologies also serve a longer-range purpose for the Ministry of Health, in that the data captured can be preserved on detailed maps to be studied in the future by those interested in both disaster relief and those who are working to fulfill our second action plan goal of follow-up health care.

After learning about all the different technologies that are utilized in the crisis mapping field, we would consider the incorporation of Google Earth, Frontline SMS and Ushahidi into our immediate response program for different purposes. For Frontline SMS, we would set up a system in which people can text their location and specified need for us to determine how and where to distribute our resources. This system, however, would require an automatic response mechanism in order to ensure that the people understand that their messages are being received and processed appropriately. We would then incorporate the information received onto Ushahidi Crowdmap in order to observe the trends concerning different needs and available resources. This tool would be geared more towards volunteers in the field, as well as information analysts such as crisis mappers. We would also utilize Google Earth to map information for potential donors and archiving information for future crisis response situations. We chose to use Google Earth to attract donors as we found it to be visually appealing and easy to quickly comprehend.

However, our reliance on this kind of technology for data collection and storage necessitates the inclusion of someone on our team with extensive experience with each of the platforms, and who would know how to fix them when they inevitably crash during the process of crisis mapping. We would most likely reach out to other organizations to assist us with initially setting up the platforms, such as the United Nations or the crisis mapping community. Ideally, using this technology will help facilitate cooperation with the other groups who are also on the ground, such as the Moroccan Red Crescent and the World Food Programme. These programs will give us the ability to share information as it becomes available, making our combined response more efficient.

As both the Ministry of Health and a group of university students, we were proud of our overall design and ability to adapt as the class progressed. We attribute much of our success to both our productive and creative group dynamic and a solid initial response plan and timeline.

We divided into 3 teams to assess and map data:

• Administration maintained phone contact with trusted sources on the ground as well as the public information officer who interfaced with the media.
• Logistics gathered and categorized SMS data, while maintaining and monitoring blog and twitter posts.
• Operations mapped raw data on Crowdmap to share with individuals to aid in NGO and UN efforts on the ground.

The process of mapping and verifying reports is an intense one, as reports come in faster than teams can approve them. The lightning speed of this crisis bonded our team together through an urgent shared goal. We devised a system to accurately and efficiently move information through our clearly devised workflow as we all kept in constant communication. David Meyers, our technical expert, commented on technology’s role with the group:

“At first, we tried using FrontlineSMS and things didn’t work out, which often happens when using technologies like this. Backlogged for an hour at the start of the day, we eventually created a new system using completely different software. But in the end, while it was tedious copying messages over into usable data, we managed to pull together as a group and get caught up to where we needed. Soon after our transfer we were back on track and stayed on top of it until the end.”

Miriam Ross-Hirsch, our social network liaison, speaks to the dangerous capacity of information to alter an outcome:

“It was hard to find a balance between tweeting sensitive information that seemed important for those on the ground to know, and keeping some information private to avoid increased turmoil.”

Operations member Ben Wang discusses the challenges of working with our mapping platform.

“Often reports we were mapping were not occurring in one place, which was difficult when creating static points on Crowdmap.”

When word reached us that a peaceful, democratic solution had been reached in Comootros, we were finally able to take stock of what a challenging and important experience this was. We are grateful for the opportunity to participate in this project and we sincerely hope our efforts aided in this favorable outcome.
-Tufts Crisis Mapping Team

Follow our work at:

www.crowdmap.com/comootros

www.twitter.com/comootroscmap

http://comootroscrisismapping.blogspot.com/

The inherent collaborative nature of crisis mapping and its reliance on a network of both professional and civilian workers has both its benefits and its challenges.  From our practical experiences working on class assignments and our crisis simulation, as well as from accounts drawn from the blogs of more established crisis mappers, we have quickly become familiar with the advantages, as well as the drawbacks, of a multi-member response team.

One advantage of the cooperative nature of crisis mapping is the efficiency that results from the ability to mobilize a mass of volunteers, sometimes numbering in the tens of thousands, who can respond to crises immediately.  In his blog post, Patrick Meier describes this massive force:

…in the wake of the Haiti earthquake…more than a thousand Creole-speaking volunteers in no fewer than 49 countries around the world contributed thousands of hours of their own free time to translate tens of thousands of text messages coming from the disaster-affected population in Haiti.

The thousands of volunteers that Patrick describes here are only those who aided in translations—many more participated in other stages of crisis mapping.  This massive manpower can accomplish much more than a mere team of five or six trained crisis mappers can, although neither the untrained volunteers, nor the trained crisis mappers can function without the other.

Patrick Meier video chatting with a group of crisis mappers (source: NY Times)

The collaborative nature of crisis mapping is also enhanced by the fact that it is an online cooperative activity that can span the globe.  As Patrick mentions, volunteers from all over the world can contribute to crisis mapping efforts—all they need is a computer and an internet connection.  Citizens on the ground during crises also are important elements in the crisis mapping teams, as they provide local knowledge, and information submitted to crisis mapping teams via text messages and other technologies is essential in monitoring situations on the ground.  The most effective crisis mapping teams will integrate all of these elements—trained crisis mappers, volunteers at least minimally trained in mapping technology and translation, as well as untrained civilians—into successful responses to crises.

At the same time, as more and more parties get involved with the project and the response team grows, communication, work flow, accuracy, and group dynamics become more difficult to deal with.  Different individuals may have different ideas on how to best react to the situation, and it may not always be clear who is in charge of each level of the project.  According to crisis mapper Anahi Ayala Iacucci in a blog post on October 9, 2010:

The secret of managing a Ushahidi platform is to have a good work flow in place, instant communication and shared information between all the members. if you have those characteristic, then you don’t even need to be all in the same place.

Anahi highlights here the importance of clear ideas and task management, both of which are priorities that we have identified in our group interactions.  Anahi goes on to describe how group members of her PakReport project from England to Cairo are in constant dialogue with each other through Skype Chat and a Google Group.  Our Moroccan Red Crescent team similarly keeps in contact continuously via e-mail, and we collaborate on group assignments by sharing Google Docs and by editing each other’s work in this way.  Delegating tasks has also sometimes been a challenge for us, but it is nowhere near as big as a challenge as it would be if we were a team the size of one of Anahi’s projects.

It is important, however, in teams as small as our own, as well as in teams the size of Ushahidi, to have some kind of stopgap measures to ensure that tasks are delegated efficiently across all levels of the crisis mapping program, to streamline the process, to maintain order, and to ensure that the final products are cohesive and make sense.  For example, when we first began our group project, we occasionally skipped over having someone delegated to check over our work, and as a result, the project reports that we produced were not completely cohesive because they came as a result of the work of several different individuals.  Thus, it became evident that someone to check over the final product—a stopgap—was necessary.  In our team of only four members, one group leader suffices, yet in larger projects, a team of individuals (Anahi mentions several pivotal roles, such as a director, a crisis mappers coordinator, a verification coordinator, an emergency team, a tech person, etc.) is needed.

Crisis Mappers at work (source: venturebeat.com)

We have also learned that every good Crisis Mapping team should consist of a variety of people and talents. In Ushahidi, for example, there are more than just the technical developers–there are also website designers, content and branding experts, and a larger community of volunteers who input the information.  In such a team, not everyone will be experienced with technology or humanitarian aid, not everyone will have the same education, and not everyone will speak the same languages. A system of collaboration that creates fluid group work and that enables everyone to apply his or her specialties in the group is therefore necessary.

Current major Crisis Mapping initiatives are structured around “the collaboration between large established organizations and new decentralized volunteer networks.”  During the crisis in Libya, Ushahidi has been able to cooperate with and win the support of the UN Office for the Coordination of Humanitarian Affairs, which has requested the launching of a Task Force. This trust has helped to expand capabilities and learn from experiences.

Screenshot of Libya Deployment (source: libyacrisismap.net)

The structure of the Task Force in this particular instance may be a good source of inspiration for future Crisis Mapping teams. The group was divided into several teams with specific tasks, so that each of the volunteers can fully use their expertise to contribute to the goal. Such examples include the Tech Team, the Media Monitoring Team, the Geolocation Team, and the Reports Team.  This type of specific identification of skills may help organize a diverse group of people from all over the world, and make the most use of their potential. In our group, although we are not as diverse as the entire Ushahidi community, we certainly are from different areas, and were not familiar with each other before the start of this project. Thus, taking time to get to know each others’ strengths and weaknesses, and delegating specific tasks according to the project, is a potential strategy to lead to better results.

Patrick Meier mentions an alternative form of group collaboration on his blog, which he refers to as “collaborative analysis.” Researched and proven to be effective by the “Polymath Project,” this is a system which surpasses the end user system to allow an “end network” to think together and solve complex problems.  In essence, it abolishes the hierarchical system of organization employed by Crisis Mapping groups and most other organizations, and it opens up information to all the other members in the network—various individuals can contribute to solve one problem together. While the structure of open source mapping certainly moves towards this direction, most projects like Ushahidi are, as mentioned above, divided into specific groups. But perhaps we should also open the information up to the wider community and collectively try to tackle big problems. As Meier suggests, the positive effects of collaborative analysis are “precisely why Crisis Mappers should design platforms that encourage mass collaborative analysis to identify patterns in humanitarian crises.”  This is also a potential direction in which we can guide our collaborative process in our small Red Crescent group. We recognize the potential difficulties of working as a large collaborative without having a large hierarchical system of leadership. However, it does lead to the benefits of allowing everyone in the group to contribute their ideas in a fair and equal manner. This method of collaborative analysis also does not necessarily have to contradict the aforementioned method of delegating specific tasks: the two methods can be used interchangeably depending on the project we are working on.