Further Thoughts on Disaster
I’m not suggesting a Web panacea for humanitarian aid. Disaster is not flickr, not Wikipedia. The issues of accountability, reliability, protection are serious and real. Katrinalist and other disaster wiki projects didn’t experience problems of non-cooperation, but it’s easy to imagine open disaster coordination systems being gamed .. like the stories of some Sri Lankan fisherman receiving new boats, even though they were not affected by the disaster. That’s partially a beauracratic, systematic error .. and underscores the necessity for automated trust, attention and attenuation in open systems (if that sounds like the etech theme, it’s part of a potential session there).
One surprising thing on GDACS, the software is developed in a propreitary-ish model (the code is technically free, but you need to go through an official request process). This is not for lack of desire for open source, but rather institutional inertia encoded in licenses and beauracracy. With the altruistic mandate and requirements for transparency, open source software development by agencies and NGOs seems natural. Interagency projects only stand to gain by adopting an Open Source model of development, a community model more inline with the complexities of coordination among all the current, and potential, stakeholders. There are other potential costs of organizing OS development, but funding the project becomes more flexible, open to whichever agency currently
has resources to contribute. Agencies can interact with the project independently; competing systems can be engaged by shared code.
The common conceptual model and standards of disaster data is not a given. GDACS is self-limiting to “sudden onset natural disasters”. The line here is blurry .. when exactly does a disaster event start? An earthquake is clear. Perhaps also a volcano, though volcanic events are becoming more accurately predictable — does it start when the prediction is 75% certain? The path of hurricanes is somewhat predictable. The speed of a flood flowing downstream is calculatable (though flashfloods are less so). Drought emergencies are complex combination of natural, ongoing processes and deliberate unpreparedness. By these agencies cooperating in a technical manner, they are forced to come to common consensus on definitions.
Mapping in these agencies is another major openness opportunity. The JRC has a Digital Map Archive, UNOSAT gathers and processes satellite data .. all of it somewhat in the public domain, but not so readily accessible. Even though the JRC is coordinating INSPIRE, commercial data is licensed and used, considered to be of more consistent quality than national mapping agencies’ products.
Sounds like a case for OpenStreetMap. They got the usefulness immediately, for many places where these agencies operate have no digital mapping data whatsoever. We discussed how agency field workers could use and contribute to the project. Potentially, they could dynamically create and share maps as they are deployed. One thing to address is the technical constraints in the field, where limited connectivity would require some additional affordances in the OpenStreetMap model: offline editing and conflict resolution would need more support. Even with limited connectivity, something close to real time locative coordination and needs assessment is a huge potential field application. Accuracy is another issue; mislabeled places have resulted in official diplomatic incidents. The UN Cartographic Unit maintains a list of official, treaty agreed, place names. ReliefWeb protects itself with a disclaimer .. “The names shown and the designations used on this map do not imply official endorsement or acceptance by the United Nations.” For OSM, I’d add “You are free to fix it yourself”.