ODK+Django: Geotagged Photos from Android to the Web
I took advantage of being snowed in during DC’s record-breaking blizzard last week to learn more about Open Data Kit. ODK is a suite of open source data collection and aggregation tools maintained by PhD students at the University of Washington. The software runs on Android phones, and allows users to collect text and multimedia data (including photos, audio, video, and GPS coordinates) through user friendly touchscreen forms. It’s a delight to use on my Motorola Droid.
Installation is as easy as downloading the data collection app (ODK Collect) from the Android market. Out of the box it transmits form data via an HTTP POST to ODK Aggregate, a server that runs locally or on Google’s App Engine and provides an interface for viewing and exporting your data. A selection of demonstration forms are included. One of these, Geo Tagger, allows you to capture a photo and GPS location, enter a brief description, and upload the result to Aggregate.
I thought it would be useful to be able to skip Aggregate and send a geo tagged photo directly to a website in Django, which turns out to pretty straightforward. It comes down to parsing the XML form data included in a multipart attachment to the HTTP post from Collect, which can be done with a few lines of code. If you’re interested in the details I’ve posted some of them here. The end result looks like this (click screenshots to enlarge):
which with a quick template becomes:
And there you have it: a basic mashup of two open source tools that is directly applicable to field-based data collection.
Things get interesting when you start to think about use cases. Over the past month I have had the opportunity to talk with several folks working on international development initiatives about their needs for data from the field. Examples include a private company selling solar energy products in Sub-Saharan Africa, groups distributing improved cookstoves in Haiti and Tanzania, and an NGO that offers a range of household energy and health services in Central America. What stands out to me is that these disparate organizations have strikingly similar data collection and reporting needs. They want to know who and where their users are, understand which sales staff and distribution channels are most effective, and optionally collect survey data and multimedia to use for internal business administration, reporting to funding organizations, and communicating with the public.
I think that the recent availability of robust, field-tested, open source data collection platforms (ODK, RapidSMS, JavaRosa, and FrontlineSMS are a few examples) presents an opportunity to start addressing this need for data in a very general way. Since the tools are open there are no barriers to linking them with each other and with the web (i.e. through Drupal, Django, etc.), and given the range of potential uses it makes sense to think carefully about how to define those interfaces. Ideally data could be passed between applications according to clear, open standards that are consistent with modern monitoring and evaluation practices. These may not need to be much more complicated than the proof of concept integration above, but they will have to be better planned.
My ideas on the subject and about what standards would be helpful are still evolving, so feel free to contact me if you’re interested in this topic.