Really, having technical tickets (issues, bugs, features and pull requests) and commits in the same place will help with the two big things: transparency and collaboration. We want to make it easier for you to see what we are working on, submit a ticket and lend a hand when you can. If you are busy creating great code, we’d like to know about it and be able to incorporate it into the core. Or, make it more visible for others to use your code for their Ushahidi-related projects. Git Issues is directly connected to our GitHub – Ushahidi. (E.g. Ushahidi core issues live under https://github.com/ushahidi/Ushahidi_Web/issues).

Migration Help and Schedule:

Our team has reviewed the Red Mine and have flagged issues to be migrated.

Please add a comment to any items that you think need to be migrated to Git Issues. We’ve added the document to our new beta wiki for your review. Every coders eyes will help us capture the active tickets/issues. Ping Hleson at ushahidi dot com if you have a questions.

Migration Schedule:

• Community Feedback on Issues to be migrated: February 8 – 15, 2012
• Migration Freeze on RedMine: Februay 15 – xxx
• Ushahidi Community Developer Skype Chat (time to be announced) Wednesday, February. 15, 2012
• Deprecate Redmine. February 29th, 2012
• Team cleans out the Github store procuring all the sweet Github Octocat hoodies. March 1st, 2012

Getting Help:

Tool soup is confusing. Duplication is less fun than collecting Nyan Cat mash-ups. Here’s a cheat sheet:

Forums: “How do I….”, “I’m troubleshooting”, “General Support”
Wiki: “Where are the documentation, best practices” and “How do I…”. Bonus points: document and share your knowledge
GitIssues: “Houston, we have a problem.” “Nyan, Ushahidi would rock it if…” (Issue/bug/feature)
Github: Commit, Pull Changes, Fork
Contact: General questions (eg. Erik’s favourite ihub story, business endeavours, events, press etc.)

Steps to get help:

Technical Issues:

1. Search the wiki or forums.
2. Collaborate with the community skype or dev mailing list. (This is a real-time stream of global chatter)
3. Search Git Issues for existing issues.
4. Add a Git Issue: (bug or feature) request.

Non-Technical Issues:

1. Search the wiki or forums.
2. Add a forum post for questions.
3. Share your knowledge on the wiki.
4. Collaborate with the Channel for Academics, Researchers and Community Skype Chat or mailing lists.
5. To ask general non-technical tickets, you can drop us a Contact note (http://ushahidi.com/contact-us).

We will review all Git issues weekly and assign priorities. The priorities could include assigning to a team member or requesting community help. More details as we get closer to launch.

To sum up: GitIssues, flag your tickets for migration, Octocat hoodies and Nyan Cat.

These badges are broken down into “badge packs”. For example, the Locations pack is a simple grouping of badges that follow a travel theme, with badges highlighting landmarks from countries around the world. The Ushahidi pack is a group of generic badges that the Ushahidi team has put together. New packs are expected soon, with contributions from the community and designers from other projects as well.

How can you use this as an Ushahidi administrator? Deployers of newer versions of the Ushahidi Platform and current users of Crowdmap have access to all of these badges already. Simply log into your admin panel and browse to the Manage->Badges settings page to get started. As an example, you may award the 25 Star badge to a user who has sent in 25 approved reports. This can be a manual process where you assign badges to users or set up Action Triggers to do this automatically. Just experiment with the platform to come up with interesting achievements to award your users.

We need your help! This collection of open source badges belongs to the community. If you’re a designer, developer or just interested in all things badgy, you can support this initiative. Your efforts will impact a multitude of projects, ranging from projects that crowdsource information in crisis and disaster situations to projects that reward people for submitting delicious pictures of cheeseburgers. Please check out our badge site for more information.

We’re really excited to see what everyone comes up with. We hope to see the badge image repository grow so other projects can get some value out of our open source badge initiative. Let us know in the comments what you come up with!

Okay, so what does that mean to regular folks? How about: We care about our communities and the world around us. So, we need to protect and improve it. How can we know more and be actively involved in the real changes, even at a incremental level?

Call to Map it, Change it.

The UN has stacks of resources about RIO+20. The Future We Want is an initiative focused on opening up the process to: Share your ideas. The UN’s Sustainable Future site includes a list of organizations and movements who demonstrate the power of: What Can You Do?

We invite you to join the fray: What can you map? There are countless local and global stories related to sustainable development. Take map aim at an issue that you care about to highlight the need for real change.

Mapsters in Action

At the recent United States Rio +20 pre-event, Ushahidi had a chance to feature the work of amazing deployers trying to share, understand and change their world. These examples should get your mind spinning on some of the untold map stories that you could activate. Citizen crowdsourcing can elevate and visualize your subject. And, you may be surprised who you hear from and how you can collaborate.

The Cost of Chicken project works with kids from around the world to collect data on local food conditions. It uses Crowdmap to track and share information ranging from the cost of chicken, water, and, even, candy. Learn more from Olga Werby, mapster advocate:

Can those kids be any more inspiring in their search to understand and connect with each other over food production? Thanks to each one of them for sharing their passion for change.

Take a World Tour:

Deployers around the globe are mapping about sustainability. These are some examples we shared at USRio+20:

• Global Energy Shortages This map includes a layer of Ajay Kumar’s project Powercuts.in.
• Find Fuel in Nairobi, Kenya
• Ministry of Agriculture, Irrigation and Livestock: Nangarhar Agriculture, Irrigation and Livestock ( DAIL ) (Afghanistan). More on this project: “A Moment of Discovery and Awe“.
• iWitness Pollution (Louisiana, USA)
• Spotting Fair Trade in North America (supporting sustainable products) (USA)
• Agrotestigo: Mapping Agricultural Social Networks (building collective resources about agricultural technologies) in Argentina
• Qiantang River Water Map 钱塘江水地图: A Collaborative Interactive Water Map for Qiantang River (China)

If you have more examples of great maps, please share them in the comments or add them to our Deployments Map.

And, when you create a new map, be sure to tweet to @UN_Rioplus20 and @ushahidi. Use the hashtags #futurewewant. We’d be happy to feature your map story on our blog. Simply drop us a line.

More Resources:

• Official United Nations Conference on Sustainable Development (UNCSD)
• UN Sustainable Future site
• United States Rio+20 Conference
• The Future We Want

Thank you: USRio20 participants and organizing team

Thank you to Noel Dickover, Richard Boly and Sarah Jessup for inviting Nat Manning and I to participate in USRio20. Special thanks to Carmelle Terborgh, ESRI, for supporting our participation.

We were delighted to meet participants and to brainstorm, learn and Speed Geek [video] about these important topics.

Thanks!

Heather L.

The first 72 hours of the SomaliaSpeaks deployment were particularly intense. The purpose of this joint write-up with Al Jazeera and partners is to share some of our early lessons learned in this novel collaboration.  Every deployment teaches us a multitude of lessons, so our partners at Al Jazeera, Souktel and Crowdflower joined us in this effort to share these. We look forward to future collaborations with them as we share this story with you.

This purpose of this pilot project was to let Somalis speak for themselves. For the first time ever, a prominent news organization, Al-jazeera, used crowdsourcing and SMS to let thousands of Somalis express for themselves how the crisis has been effecting their daily lives. More than 4,000 text messages were received within just a few days. Of these, over 1,000 were translated from Somali into English by about 80 translators. The resulting map of Somali voices received over 25,000 page views.

Before reviewing our lessons learned, we first wanted to thank K’naan and Sol for the initial inspiration behind this project. They got in touch with Ushahidi last year because they wanted to use the platform to help amplify Somali voices and show how capable the Somali people are. The initial version of this project was a prototype that was not activated. But thanks to Al- jazeera, Souktel and Crowdflower, we were able to revive the project to help amplify Somali voices in the international media.

Despite being a pilot, the project exemplified valid use cases in the application of pervasive technologies such as the web and mobile phone to news and information gathering. Somalia being a country run down by decades of neglect and war as well being rife with insecurity  provides one of the most challenging operational environments. Within a very short time we were able to curate information traversing through different parts of Somalia. This would have proved futile if not overly expensive or impossible had it been done using traditional news gathering techniques. Furthermore the information collected provides more insight on the realities of life in Somalia.

Projects like this involve a lot of effort and goodwill from the community and a chain is only as strong as its weakest link. Therefore, building a strong community around the project goes a long way to solving problems and mitigating challenges. The community goes beyond the volunteer translators. We saw lots of support from the Somali blogging community, technology and media enthusiasts as well as innovators or innovation centric minds across the globe who all narrated or reported the Somalia Speaks project in their own ways. Having a strong community and inculcating a community ethos in  project operations and goals goes a long way influencing success. Without the community backing and promoting this project, it would have only been another temporary spotlight on Somalia.

The project worked as follows. Al-jazeera editorial selected the following question for interview:

“Al Jazeera would like to know — how has the Somalia Conflict affected your life? Please also include the name of your hometown in the response. Thanks.”

Our colleagues at Souktel distributed the question via text message to 5,000 of their SMS subscribers across Somalia. The responses were then forwarded from Souktel’s SMS platform to a customized Crowdflower micro-tasking platform. There, Somali-speaking volunteers translated and geo-located the text messages which were then manually uploaded to Al-jazeera’s Ushahidi platform.

There are three points worth highlighting in terms of lessons learned:

1. Messaging

While the question that was posed via SMS in no way asked for individuals to reply with their personal names, a small number of responders still added their names; some even added their full names. So these were deleted as quickly as possible. (Note that the numbers posted in the title of initial reports were not phone numbers but an assigned sequential number generated by the Crowdflower plugin). In hindsight, the SMS sent out with the question should have specifically asked that responders not include personal identifiers in their SMS replies.

2. Volunteer translation

While we had recruited a small number of trusted volunteers to translate the incoming text messages using a Crowdflower plugin, a decision was subsequently made to make the call for volunteers public to cope with the 2,500+ SMS replies received. This means that anonymous volunteers could see the original text messages, some of which initially  included personal identifiers. So we immediately reached out to Crowdflower for guidance to take the plug-in offline. We then began to manually delete several dozen text messages inside the Crowdflower plug-in that contained personal identifiers. Our colleagues at Al-jazeera took over this process and set up their own micro-tasking platform, removing all personal identifiers from the text messages awaiting translation and geo-location.

3. Security

One of Ushahidi’s community members tested the platform and identified a search security issue on Friday, December 9th. We quickly fixed this on the deployment. And, we issued a security patch to all deployers. (http://security.ushahidi.com)

In the future, for this type of “The People Speak” project,  we recommend taking the following steps:

1. On large multi-partner deployments: Global organizations work in multiple timezones, so communications plans need to include 24/7 points of contacts for each organization.
2. Text potential interviewees to ask whether they agree to be interviewed and to have their responses made public before sending out the main question.
3. Text those individuals who have consented to being interviewed with the desired question and ask them to include the name of their town but not their personal names.
4. Recruit trusted translation volunteers well in advance and ensure that the micro-tasking translation platform has no personal identifiers.
5. Stagger the launch of the text messages and the live map. That is, start with the SMS broadcast and spend however many days/weeks doing the bulk of the translation with vetted volunteers. The system that holds the raw text messages should obviously be fully secure. When the majority of text messages are processed, launch the live map and gradually add the already translated text messages to grow the map steadily over a period of days/weeks.

At Ushahidi, we’ve also made some plans to help all deployers in our community:

• We’re building a program for privacy and security education for our users in 2012. (Blog posts, webinars, videos and meet-ups.)
• Best practices for security and privacy will be included as essential documentation on our soon to be re-launched wiki.
• Ushahidi is open source and the community is a large part of what makes it work.  We’ll build a security working group focused on our software, but it’ll take your participation to make it work.
• Alongside our partners within the CrisisMappers community, we will participate in a security and privacy working group. This field is growing and collective lessons can only improve each map action.

Crisis mapping and journalism are both in the nascent stages of collaborating on real-time news connecting diaspora and citizens alike. Al-Jazeera is leading the fray in testing and implementing live maps into their fast-moving news cycle toolkit. We are thankful for all their efforts and look forward to further collaboration.

On November 28, 2011, elections began in Egypt as part of the political transition plan overseen by Egypt’s Supreme Council of Armed Forces. The full plan calls for elections for the People’s Assembly, followed by elections for the Shura Council, a more consultative body that along with the People’s Assembly comprises the Parliament. According to the plan, the Parliament will then choose the members of a constitutional assembly to draft a new constitution before presidential elections begin in late June 2012.

The Development and Institutionalization Support Center (DISC), an Egyptian NGO, is using Ushahidi to crowdsource election monitoring during the Egyptian transition. The project is called U-Shahid or Enta Shahid, which in Arabic means, “You witness.” DISC first set up U-Shahid to monitor Egypt’s 2010 parliamentary elections. This year, it has so far been used to monitor elections for the People’s Assembly, the third and final round of which came to a close on January 11, 2012.

In getting the word out about U-Shahid, DISC counted on social media. DISC utilized its online following, which includes, for example, over 65,000 Likes on Facebook. In addition, many people working on U-Shahid, whether as employees or volunteers, have thousands of followers.

With our partner NGO, the Egyptian Democratic Academy, we trained volunteers to act as monitors and send in reports during the voting and a team to help manage incoming reports. DISC employees acted as backup.

Those sending in reports were asked for a quick description of what they were observing. They also had the option to attach a photo or video as evidence backing up their report, or to include a link to such evidence. They also categorized their report in categories such as “Intimidation” in the larger category of “Violence” or “Polling station closed early” under the larger category of “Polling Stations.” And it wasn’t all doom and gloom, “All Went Well” was an often used category for reports. Visitors to the U-Shahid site could vote (yes or no) whether they believed received reports to be true, allowing people to contribute in a small way to verifying the accountability of reports. Additionally, Egyptians could sign up to get alerts about reports, particularly reports within a certain proximity to their home or location, allowing access to dynamic and personalized news.

Volunteers receiving incoming reports then checked the classification of the reports, expanded the description, and filled in the location, if it was absent. The final responsibility of verification fell to the administrators.

Our most common verification strategies were to corroborate reports by checking online news, looking at attached photos or videos, asking our local volunteers to investigate personally or through their local contacts, or contacting the sender. We had an additional team on the ground that could travel to investigate and verify reports of large-scale fraud.

Our verification volunteers also had two additional trainings. First, they learned how to use ICT4Peace’s verification matrix plug-in, which helped administrators ascertain the reliability of reports. Second, they had training from Reuters reporters, as traditional media has developed a range of intricate verification strategies in the face of their need to draw from social media.

In broad strokes, the reports recorded widespread illegal campaigning (such as campaigning to people waiting in line to vote – a banned practice), some evidence of vote buying, and plenty of examples of disorganization, but relatively little evidence of violence being used or systemic fraud. While all reports were of course made available in real time, reports such as this one, on the first stage of voting, were emailed to journalists and organizations that we believed would benefit from the information. As the Egyptian military proved hostile to the idea of election monitors, and in fact banned official international monitoring, our reports were only as valuable as the attention they gained among the public and among groups with a role in policy.

In evaluating the project, DISC found that U-Shahid was less successful than in 2010, receiving fewer reports and less media attention. A number of lessons can be learned and observations made:

-       U-Shahid was less well known in comparison to 2010, when it became so popular that it inspired four additional Ushahidi maps to monitor the election. This can be attributed to media focus being on the violence and protests in Tahrir Square in the lead up to elections, as compared to 2010 when a number of television programs featured U-Shahid. Also, in 2010 DISC purchased advertising space on Youm7, a popular Egyptian news service, but could not do the same this year, as our grants were less generous. This should serve as a reminder of the inadequacy of social media by itself and the necessity of a robust marketing campaign.

-       Two additional factors led to a decreased volume of submitted reports. First, this year saw even more election monitoring projects with and without the use of Ushahidi by organizations and newspapers offering cash to monitors. Depending on volunteers, we could not compete for reports with those organizations offering cash. And the proliferation of maps reduced the attention given to each. Attempts made to build a coalition with other NGOs and newspapers to work with DISC on U-Shahid were rebuffed due to a culture in Arab countries of organizations being more interested in getting credit than in forging effective partnerships. Second, monitors feared violent reprisals for documenting cases of fraud at the hands of police, the military, or hired thugs. During clashes on Mohamed Mahmoud Street in the run up to the election, for example, people recording abuses on camera were specifically targeted.

-       The feature allowing visitors to the U-Shahid site to vote on whether they believe a report to be true was rarely used and of no particular benefit

-       In December, the military raided a number of international and local NGOs as part of an “investigation” into the foreign funding of NGOs and their potentially suspect motives. This complements an ongoing smear campaign against NGOs. While this threatens DISC’s ability to continue work on the project, it also points to the resilience of crowdsourcing, as traditional election monitoring projects were cancelled by a number of NGOs in response to the military closing their offices and leaving their legal status in limbo.

-       DISC is planning a complementary follow-up project called Enta Sharek (“You Share”) in which focus groups in five areas will be shed light on their experiences during the elections. No reason that traditional information gathering techniques can’t be used to complement our efforts!

The world was shocked to learn about Kyrgyzstan’s second revolution within five years. The country’s anger resulted in the ousting of two presidents, and the 2010 revolution was followed by interethnic violence in the south of the country – making 2010 a challenging year. Some doubted whether Kyrgyzstan could remain independent and sovereign.

At the time, UNDP sent experts to the country to assess the situation and provide  technical support. Jens Wandel visited the UNDP office in Kyrgyzstan to learn about our projects including our support to the elections.

He asked me if I had heard about Ushahidi, a free, and open source software for collecting, visualizing and mapping information. Ushahidi is Swahili for “witness” or “testimony” and was used  for the first time in the 2007 Kenyan elections.

Since then, I have become addicted to the idea, especially since it coincides with our plans to use information and communication technology in our work to support democratic governance.

Since Jens arrived just before the Kyrgyz parliamentary elections, we didn’t have time to properly explore how the platform had been used, and ways to adapt it to the Kyrgyz reality.

Later, we learned that Ushahidi had already been used in Kyrgyzstan several years ago by a local NGO that recruited local election observers. However, they used the available software without adapting it to local circumstances and didn’t coordinate their activities with other partners.

I consulted local software developers and not only did they know about Ushahidi, but they also knew about the first time it was used in Kyrgyzstan and had a clear idea how to adapt the open source software to moderate activity on election day.

The beauty of the concept is that the final product would become a universal platform focused not only on electoral violations, but on other issues such as natural disasters like the earthquakes inHaiti and Japan.

The next step was also quite challenging: Could I convince my colleagues and our national partners that this is a useful and inexpensive way of exposing electoral violations during elections day?

Some of my colleagues were skeptical, mostly because of the complexity of information and communication technology. There were some doubts that local civil society would buy into the concept and participate.

In the end, proponents of the Ushahidi software prevailed and we hired a local group to develop the supplementary software and to moderate the process on election day.

Another requirement was to ensure strong coordination at all stages between the developers, the Central Electoral Commission (CEC), and key NGOs that would be providing information on violations to the system.

About 3,000 text messages with information on electoral violations were verified and posted online. More than half the violations were observed and reported in Osh and Bishkek, the biggest cities in Kyrgyzstan, and there were more than 27,000 hitswith an average duration of about  two minutes.

Kyrgyz NGOs gained experience with the Ushahidi platform and adapted it to the country’s needs. We saw firsthand that the platform can be used to monitor and increase the transparency of elections.

The CEC not only supported the idea and monitored the site, but also used some of the information for their own purposes.

Well, the statistics shown are quite impressive, however, the main question is this:

What is a non-expensive way of making sure that information from the website reaches each potential voter right way? Especially to the first voters, to demonstrate that the electoral processmust be and can be transparent, and any violation will be recorded and shared with the community?

What do you think?

In September, I began teaching my first upper-level University course at Grant MacEwan University. Having taken some (and heard about some other) lack-lustre undergrad Software Engineering courses, I really wanted to make this course practical, project-based and interesting for the students. One inspiration was the Undergraduate Capstone Open Source Project (UCOSP) where final-year students select a project and are mentored by faculty across Canada to work on an open-source project for course credit. I also loved the practical approach of the Software Carpentry course taught by Greg Wilson and Paul Lu, which I was involved in a few Summers back and frankly preferred to some of the “Ivory Tower” Software Engineering that is common in undergrad courses.

It was Greg Wilson that pointed me to Ushahidi, and I felt Ushahidi’s humanitarian focus would be a great added benefit to my students. Computer science is so often focused on science, business, marketing and advertising that I felt this was an opportunity to show my students how a small group of dedicated people can use software to make a difference in humanitarian way. There were other great projects suggested too, such as the Sahana Foundation, but I made up my mind to go with Ushahidi once I was introduced to Heather Leson and got to peak in on a Ushahidi hack-a-thon from Nairobi via Skype. The energy of the group was obvious and very exciting.

Organizing the Curriculum

With much enthusiasm, I jumped into trying to build a course using Ushahidi as the core project component. The first major hurdle was that 3rd year computer science students have minimal system administration experience. Except for a few exceptions, they haven’t run a database or a web server on their own. Moreover, PHP is not part of a course curriculum. The sysadmin challenges were answered by using Harvard’s CS50 Virtual appliance. This VM is based on Fedora Linux and comes with PHP, Apache and MySQL already installed. The VM runs on VirtualBox, which is free so students could install it on their laptop (this is how most students ran it). As for PHP, I felt that PHP was accessible to undergrads coming from a Java background. It’s syntax and object-oriented are quite similar to Java.

Our courses at Grant MacEwan involve a weekly three-hour lab component. The first lab was used to introduce PHP with some sample programs. The second lab was used to introduce Kohana and the MVC framework. After the second lab, the first assignment was given. The first assignment consisted of 4 simple tasks

• Apply a patch to get Ushahidi to work with non-clean URLs
• Change the site name and tagline on the admin page to match the main page
• Modify the labels in the API stream
• Add a ‘’pirate’’ response type to the API

These assignments helped the students become familiar with how MVC web servers work. I also felt that the API was an important concept for them to understand well. In the end, this assignment was a bit too easy in some ways. In general, it’s very challenging to judge the level of difficulty when working with an existing code base. To this point, most of my students would have only written programs from scratch (similar to most undergrad CS courses).

It was also to determine what kind of hints to give. For example, problem #4 from above become quite trivial once you show students how to search (using grep) through a code base. Without that hint, students will try to trace the code manually and search manually. So the dividing line between dozens of hours of work and 10 minutes is literally the knowledge of how to use grep effectively. Once the students had completed the first assignment, it was time to throw them head first into Ushahidi on some more significant projects.

Picking the Projects

One advantage I had was that there were only 10 students, which enabled students to work on separate projects based on their interests. Mistakes with a course of 10 students are much more fixable on the fly than with, say, 40 students.

In trying to gather project ideas, I searched the feature requests on the Ushahidi development site and also I asked the Ushahidi community for ideas for projects. Projects from the feature request list included selecting multiple categories and multi-coloured dots. Others came from the Ushahidi group, such as 2-way SMS communication, OpenStreetMap integration and white-labeling the J2ME app. Some were my own creation, such as the SQlite back-end.

In general, is very difficult to carve 10 appropriate projects from an actively developed open-source project like Ushahidi for the following reasons:

• Ushahidi developers are focused on moving the project forward, adding real features that users care about. As such, they are typically not willing to risk those features not being developed by leaving them to an undergrad.
  Course projects are in 3 month blocks whereas actual development in the project focuses on small increments or “many months away”, so carving off a piece that fits nicely into a 2-3 month course project is hard because that is not how developers think. Developers, from what I gather, focus on the next few week or two, or they may focus on large scale goals (significant re-writes of subsystems) which again are difficult to break down into course projects.
• The knowledge gap – real developers know the code, my students do not. This gaps adds to the difficulty of developers creating projects that can be handed off to an inexperienced student to complete.

Even with the above challenges, our results show that it is possible and extremely valuable to use real software in an undergraduate course project. I believe that our projects on Ushahidi went as well as I could have expected for three main reasons:

The Ushahidi developers cared enough to try and suggest projects. Some projects were fine just as suggested while others could at least give me ideas that I could try and distill into projects. In the end, my responsibility is determining and setting the educational goals, so this worked well. The developers were of a great help, quick to respond to questions and supportive of the students, and I can’t thank them enough for this. My students were willing to accept the “ups and downs” of this kind of project. They knew the alternative was a canned, built-from-scratch project that no recruiter would care about. I was able to convince them that saying they had worked on (and got patches accepted to) a real software project would be of at least some merit over a typical SE course project.

There were certainly some bumps in the road in terms of some projects being too easy (to which I would assign further work) or too hard (a completely working project was not required in some cases). In then end, the students were able to make significant progress on some real problems that the Ushahidi community cared about.

Student Project Review

All that said, let’s talk about the projects, cause they’re really cool.

Dale Douglas (code) added the ability to allow reports to be edited on the main display. His implementation was not secure by any stretch, so may not be deployment ready, but was an interesting project. Dale wished that plugins could overwrite system files so that he wouldn’t have to modify the main Ushahidi codebase.

Brett McKay (code) white-labelled the J2ME app. He also discovered that the J2ME app was in the middle of re-write. So he added the functionality to the new re-write version to add a deployment site and fetch reports. This an example where a student had to take on additional tasks once his initial task (white-labelling) was complete. Brett was challenged in there is actually no documentation of the J2ME app at all

Richard Laan (code) added the ability to select multiple categories on the main map page. Richard’s learning curve was even steeper in that he had to learn Javascript for this project. In the end, a very successful implementation. Tracing the javascript was the most challenging aspect for Richard.

Joel Joseph (code) added a search functionality to the API. This feature allows an API query to search and return results for particular keyword. Joel’s first project was a refactoring suggested by one of the developers. This was another example of a project that needed to be extended once the initial task was complete.

Ranjoat Panesar (code) added a plugin to support 2-way SMS communication between an SMS user and the system. For example, the could stop and start notices or search for incidents related to a keyword. The motivating idea was having a user search for incidents around their current area, but we didn’t get that far.

Alex Molzhan (code) Alex added a button that allowed the incidents to be shown in their incident colour when being displayed under All Categories. Richard Laan is currently continuing to work on this feature in relation to his “Select Multiple Categories” project.

Chris Proulx (code) Chris added an AJAX-based interface to the reports editting page under the administrator. The features chris avoided reloading all the reports when one was deleted. His changes made the reports editing noticeably snappier.

Wilson Liang (code) Wilson created a standalone Java app for the desktop. His application would follow a particular deployment. It may be useful in a situation when connecting to a particular deployment may have intermittent connectivity.

Ruben Estevez de Freitas (document) Ruben worked on getting OSM installed locally and working with Ushahidi. Most instructions for OSM are for Ubuntu, so Ruben learned about the mess that is Linux package management and the difficulty in translating Ubuntu package names to Fedora package names. Ruben’s submission is not a github repository, but simply a document describing all the steps to get OSM working with Ushahidi on a Fedora virtual machine.

Andrew Gergely (code) worked on creating an SQLite-based database for Ushahidi. Andrew ran into two major issues. The first was that the configuration scripts presumed MySQL and were difficult to debug. The second issue was that MySQL and SQLite SQL queries are not completely compatible with each other. The lessonhere was that “standards” such as SQL are sometimes not that standard.

The course ended with project demos some of which the students put up for recording. The students have all made their code available and some are continuing to work on their projects.

I think I can say that the students all enjoyed working on a real software project and found it valuable. There were certainly challenges that the students mentioned. The most difficult was the lack of an up-to-date, detailed technical description of how everything works. The lesson here is that such a document rarely exists, especially on open-source projects. For one, the document would be too massive to read or to keep updated. Updating is especially difficult due to the incremental nature of open-source development where developers’ time is already stretched thin. Know-how comes from mostly from doing and playing with the code, not from documents. Although, as always, more documentation would certainly be helpful both in the code itself and external to it. In particular I think a “How to get started with Ushahidi” document would be helpful for new developers. Second, I think a curated “To do” list for various levels of experience (new, novice, advanced) perhaps on the new wiki, would help with new developers looking for a way to get involved (or for a university professors looking for projects ).

In the end the course went extremely well. I learned a lot about Ushahidi, got to interact with some great people and, of course, some great students. A big thank you to Greg Wilson, Heather Leson, Dale Zak, David Kobia, and Aaron Huslage for all their help and interaction over the last several months.

********
Contact Cam Macdonnell via email

To Cam, all the students and Grant McEwan University:
Thank you being the first class of students to focus an entire semester on Ushahidi open source software development. Your hard work has taught us much about how to integrate Ushahidi software development into classrooms. We are close to launching more changes to make it easier for people to contribute, including more Git love aka a “To Do” list. And, a special thanks to Greg Wilson for advocating open source in Canada’s universities.

To the Ushahidi Community Developer Skype Chat folks:
Thank you for supporting this initiative and answering Cam’s and his student’s questions. We hope to do more of this in the future and hope that you will join us on that journey.

This week several members of our team attended the 3rd International Conference of Crisis Mappers (ICCM) that was held in Geneva, Switzerland and we were blown away by the turn out (Follow #ICCM on Twitter). This community has grown substantially over the last 3 years – when we attended the first conference held in Cleveland, Ohio back in 2009 there were about 100 attendees. Now there are more than 400 gathered here discussing crisis mapping and the challenges they face. There are really 3 main things that we keep hearing as it relates to GIS and mapping:

• How to collect and organize data from the crowd around the globe as it relates to crisis
• How to enable action from this data
• How to build, collect, and maintain reference data for crisis

Collecting and Organizing Data from the Crowd

As for the first topic, collecting and organizing data from the crowd, there is a good tool developed by our partner Ushahidi. Ushahidi is a platform that takes crowd sourced information like SMS messages, categorizes them, and displays them on the map as a point or cluster of points showing relevant location. The result of this effort is a point map that begins to illustrate where individuals are vocalizing need or disseminating information.

Enabling Action

While points are a good start, we have been working with Ushahidi and a focus group comprised of both GIS and Crisis Mappers to define requirements for new tools that will support analysis of this data. We have heard the need for spatial and temporal analysis tools within the Ushahidi platform as well as the need for tools to bring Ushahidi data into ArcGIS where analyses can be run.

We are very excited to announce that we have made the first tool available to support these requirements-the ArcGIS add-in for Ushahidi which can be downloaded and quickly added to ArcMap. This add-in allows you to connect to a Ushahidi instance with the API enabled, convert text between languages, and download the Ushahidi data into a geodatabase. This opens up the feed of data being captured in Ushahidi to the rich spatial and temporal analysis tools within ArcGIS allowing users to empower action and inform decision makers using a sound scientific approach. Curious how this might work? At the bottom of this blog is a good write-up of using this tool to analyze information coming in from the current Thailand flooding.

Reference Data

Having this information and resulting analysis is great, but without good reference/basemap data as a backdrop, it is hard to understand the context of any situation. A common theme discussed here in Geneva is the isolated and rural nature of many locations and the lack of base data. While there may be global vector and raster datasets available, they are often either severely dated or at a scale that does not support local action.

One data set that supports crowdsourcing of basemap data is OpenStreetMap (OSM). OSM is constructed and edited for all types of use by a global user community, and yes you can join! Crowdsourced basemap data is particularly valuable during a crisis response where current and often high resolution data needs are compounded.

In support of this open source effort, Esri offers a desktop tool for ArcGIS that allows you to join the crowd by editing and publishing to OSM from within ArcMap. This tool also allows you to download OSM data over your area of interest directly into ArcGIS for use in a disconnected and offline environment common in response. You can download the ArcGIS Editor for OSM.

Esri is committed to supporting the crisis response community thru our Esri Disaster Response Program as well as thru the continued evolution of ArcGIS to support the collection, management, analysis, and visualization of data in a collaborative environment. While these tools don’t solve all of the problems we face as crisis mappers, we hope you will find them valuable in your arsenal and as a starting point to a dialogue around enhancements to and construction of additional tools or data. We are already looking forward to ICCM 2012 in Washington, DC!

ArcGIS Add-in for Ushahidi

Getting Started

To get started, first download the Esri Add-in for Ushahidi. Once you’ve installed the Add-in you’re ready to add it to ArcMap. Go to the Customize menu | Toolbars | Customize… located at the very bottom of the list.

In the Customize dialog, click the Commands tab| type Ushahidi in the Show commands containing: text box. You will see the Ushahidi2ArcGIS Add-In listed in the Commands pane.

Drag the Ushahidi2ArcGIS command to any existing toolbar in your ArcMap window. You must drag this command onto an existing toolbar, not just onto the map. You will see a new button with a blue circle icon show up on your toolbar.

Connecting to a Ushahidi Instance

To connect to an Ushahidi instance click on the Download Ushahidi Reports to ArcGIS button and enter the parameters.

The key parameter to enter is the API Endpoint. This is the main URL to the Ushahidi instance, such as Thailand Flood Crisis Information Map or Bushfire Connect. You also have the option to translate the data (using Bing Translator) for either just the categories or all the incident data. Note that the more you have to translate and the more records you have the longer the time it will take to download and create the data.

Once the data is downloaded it is added to a layer. The tool automatically sets the data to render on Unique Values in the Category Title field and uses the default colors from the Ushahidi instance.

Additionally the HTML Popup set and the description of the layer has been populated to reflect the source, date and time the data was downloaded. This is critical temporal information for Crisis Mappers.

Perform Further Analysis

Now that the Ushahidi data is downloaded you’re ready to perform further analysis. You can look at data over time, limit your focus on specific categories, or do more in depth spatial analysis.

For example if we wanted to get a better understanding of the reports of flooding around Bangkok we can focus on those reports (i.e. just one category of the incidents).

We can then visualize the data as a “heat-map” (by using the Kernel Density tool).

To get more detailed information on the data and to further determine significance of the reports we can use spatial statistics to determine if there are non-random spatial patterns and statistically significant hot or cold spots in the data. To do this we can use the Spatial Autocorrelation and Hot-Spot Analysis tools. The basic workflow is shown here in ModelBuilder:

The results of this analysis are highlighted in blue on the map as areas (1 km^2 ) that have statistically significant clusters of flood reports (in this case 8 to 27 per km2 ). These are the high priority areas that should be focused on first. Then we focus on questions like why are there so many reports in this area? Is there a single authoritative source of SMS feeds on the ground or is there a large group of people that need help?

This is just one type of analysis that can be run in ArcGIS Desktop from Ushahidi data. We are interested in learning more from you in the type of analysis that you’ve run using this tool. Please use the comments section of the tool and let us know how the tool works and what needs to be improved.

*****

Thanks to the ESRI team for creating this valuable plug-in.

World Bank Managing Director Caroline Anstey recently announced a new partnership with Google that will apparently empower citizen cartographers in 150 countries worldwide. This has provoked some concern among open source enthusiasts. Under this new agreement, the Bank, UN agencies and developing country governments will be able to “access Google Map Maker’s global mapping platform, allowing the collection, viewing, search and free access to data of geoinformation in over 150 countries and 60 languages.”

So what’s the catch? Google’s licensing agreement for Google Map Maker stipulates the following: Users are not allowed to access Google Map Maker data via any platform other than those designated by Google. Users are not allowed to make any copies of the data, nor can they translate the data, modify it or create a derivative of the data. In addition, users cannot publicly display any Map Maker data for commercial purposes. Finally, users cannot use Map Maker data to create a service that is similar to any already provided by Google.

There’s a saying in the tech world that goes like this: “If the product is free, then you are the product.” I fear this may be the case with the Google-Bank partnership. I worry that Google will organize more crowdsourced mapping projects (like the one they did for Sudan last year), and use people with local knowledge to improve Map Maker data, which will carry all the licensing restrictions described above. Does this really empower citizen cartographers?

Or is this about using citizen cartographers (as free labor?) for commercial purposes? Will Google push Map Maker data to Google Maps & Google Earth products, i.e., expanding market share & commercial interests? Contrast this with the World Bank’s Open Data for Resilience Initiative (OpenDRI), which uses open source software and open data to empower local communities and disaster risk managers. Also, the Google-Bank partnership is specifically with UN agencies and governments, not exactly citizens or NGOs.

Caroline Anstey concludes her announcement with the following:

“In the 17th century, imperial cartographers had an advantage over local communities. They could see the big picture. In the 21st century, the tables have turned: local communities can make the biggest on the ground difference. Crowdsourced citizen cartographers can help make it happen.”

Here’s another version:

“In the 21st century, for-profit companies like Google Inc have an advantage over local communities. They can use big license restrictions. With the Google-Bank partnership, Google can use local communities to collect information for free and make the biggest profit. Crowdsourced citizen cartographers can help make it happen.”

The Google-Bank partnership points to another important issue being ignored in this debate. Let’s not pretend that technology alone determines whether participatory mapping truly empowers local communities. I recently learned of an absolutely disastrous open source “community” mapping project in Africa which should one day should be written up in a blog post entitled “Open Source Community Mapping #FAIL”.

So software developers (whether from the open source or proprietary side) who want to get involved in community mapping and have zero experience in participatory GIS, local development and capacity building should think twice: the “do no harm” principle also applies to them. This is equally true of Google Inc. The entire open source mapping community will be watching every move they make on this new World Bank partnership.

I do hope Google eventually realizes just how much of an opportunity they have to do good with this partnership. I am keeping my fingers crossed that they will draft a separate licensing agreement for the World Bank partnership. In fact, I hope they openly invite the participatory GIS and open source mapping communities to co-draft an elevated licensing agreement that will truly empower citizen cartographers. Google would still get publicity—and more importantly positive publicity—as a result. They’d still get the data and have their brand affiliated with said data. But instead of locking up the Map Maker data behind bars and financially profiting from local communities, they’d allow citizens themselves to use the data in whatever platform they so choose to improve citizen feedback in project planning, implementation and monitoring & evaluation. Now wouldn’t that be empowering?

]]> http://blog.ushahidi.com/index.php/2012/01/25/google-inc-world-bank-empowering-citizen-cartographers/feed/ 4 http://blog.ushahidi.com/index.php/2012/01/25/google-inc-world-bank-empowering-citizen-cartographers/ http://feedproxy.google.com/~r/ushahidi/~3/j0w0S_bjnL4/ http://blog.ushahidi.com/index.php/2012/01/23/syria/#comments Mon, 23 Jan 2012 14:46:07 +0000 patrick http://blog.ushahidi.com/?p=6699 [Guest blog post by Syrian activist, author identity withheld for security reasons]

Syria Tracker was launched on April 23, 2011 and has been able to log aggregate or individual reports since March 18, 2011 [accessed January 9, 2012], including 550 reports for the category “Killed (قُتِل)” and 356 reports for the category “Missing-مفقود or Detained-مُعتقل”. A total of 6,317 individuals killed over 286 days (March 18, 2011 thru January 8, 2012) were documented and verified. Killing ranged from 1-210 killings per day (median of 17.5 (95% CI: 14-19)), in 463 cities, affecting all age groups (median age of 36 years old (95% CI: 27-45)) with 427 individuals (~7%) less than or equal to 18 years old, and 289 individuals were female (~5%) and 6,028 were male (~95%).

Syria Tracker is collaborating with the following crowdsourced efforts to further validate, corroborate, and disseminate the information: Middle East Voices (Voice of America), Syrian Martyrs شهداء الثورة السورية, Silmya, and Syrian Youth Movement. Syria Tracker also incorporates complementary situation-awareness information (news, blogs, Facebook posts, etc.) from the HealthMap system, an information system that uses unofficial reports of disease—e.g., from clinicians or web-based health-related information from news media or blogs—to track disease outbreaks. HealthMap was tailored, referred to as “HealthMap Crisis”, to mine crisis information in English for evidence of killing, torture or arrest. HealthMap Crisis is provided as a news stream that is available to the public on the Syria Tracker’s website. Reports were primarily verified by a group of volunteers from the Crisis Mappers, Standby Volunteer Task Force (SBTF) in addition to cross-validating information against other sources or online posts. Please find Google Earth layer here.