OpenStreetMap, a Disaster Waiting to Happen

This talk is about the application of OSM & related technologies, and the principles underlying this tech, to Disaster Response.

OpenStreetMap, GeoRSS, Wikis, Weblogs .. these are the technologies I advocate every day, because they work and because they're infused with values I support -- Simplicity, Accessibily, Transparency. And generally we really like this word OPEN.

In 2005, the Southeast Asian Tsunami caused destruction on a scale beyond comprehension. And Katrina later in the year showed that no country, however developed, is beyond disaster. And I watched these events, and like many people, wanted to do something, but couldn't. There's no outlet for our drive to help. And my thought, and many people's thought, was that these shiny tools from the web were ideally suited to a distributed response to disaster, where a hierarchical one was failing.

Now Web 2.0 seems to be pre-occupied with finding the perfect restaurant, and maybe for OSM that would be the perfect pub. But there's people out there worrying about the "Grim Meathook Future", which is that future reality where things get worse rather than better .. unless we start focusing our "collective energies" on fixing problems facing our world. And I don't mind be called an earnest hippie for saying that.

Perhaps you think we have more pressing problems in the world than sporadic natural disasters, and I think that's probably true .. but I'd say that dealing with these problems in their most extreme form, particularly the social ones, can lead to change in the problems faced every day.

Or maybe you read The Sun, and don't care what happens beyond the Crown Copyright owned coastline of the UK .. well this is a picture of Sheffield from last month.

And in case only technology gets you excited, the engineering problems are unique and challenging.

To give you an idea how OpenStreetMap could fit into this, here's an example where the traditional data providers get things really wrong. My friend Jesse Robbins, he's both a geek and a firefighter, and when Katrina struck he was at Burning Man. He headed down and helped lead the set up of a relief operation, not too far from where this bridge on US Route 90 had been completely destoryed. However, the Red Cross was giving evacuation directions to cross this bridge, so loads of cars would stop at the edge of this pennisula with confused drivers. Jesse phoned the Red Cross multiple times to complain the bridge wasn't there anymore .. and they responded "but that can't be -- it's still in Google Maps!". Even worse, Navteq data continued routing people over this destroyed bridge until this spring, when we started complaining about it. They finally got the message and changed their data .. but just a few weeks ago,  the bridge was reopened! So the data is out of date again. OpenStreetMap, obviously, would do better.

So note, this presentation sums up my personal, idiosyncratic path through the convoluted world of disaster response. I'm not a professional in disaster response, and have no official position in any agency. But I have been collaborating on some projects, talking and thinking about this problem for a couple years, and realize that it's a combination of approaches we need .. both the informal, amaturized, distributed methods of the web, and the official, authoritative stuff that's harder to do distributively, like keep stockpiles and move massive amounts of materials. And most everyone is keenly interested in how OpenStreetMap could fit into the picture.


I think it's pretty hard to get a sense of what it's like to experience a disaster. This picture is of London after the Great Fire, and the white area, most of the City of London, is completely destroyed. The closest I've been through is the Loma Prieta Earthquake in California in 1989. 7.1, 10 seconds of shaking. We had no water or electricity for three days. Supermarket shelves were bought out within an hour. The sporadic radio reports were contradictory about what had happened 100 miles north in San Francisco, and it was hard to guage just how bad it was, and how long we'd need to support ourselves or if anyone was coming to help. It was the first time we met the most of our neighbors. And this was really a very minor event on the scale of things.

A disaster is by definition, a complete failure. You can't rely on anything. The scale and type of disaster demands very different responses. And the standing resources are going to differ greatly .. in the Pakistan earthquake last year, there was huge international donations of relief supplies, but delivery was limited by one thing .. the number of donkeys in the area, and donkeys were the only way to get into the isolated mountains. Cuba, despite it's other problems, is extremely well prepared for hurricanes.

So building information technology for these situations may seem like the last thing needed, but it really is crucial for coordination and communication. Disaster management has stages .. initially  The technical conditions are just about the worst you can imagine, and the system needs to be robust to all kinds of failure. Connectivity probably won't exist initially, or will be severely bandwith limited, maybe via Sat Phone. You'll need your own power. And you probably need to bring in and set up all your hardware yourself.

There is a large "community" or people and organizations in disaster response, but it's very fragmented and most agencies work in a monolithic way. There's duplication of resources, and uneven distribution of resources. Information about the situation on the ground is not effectively communicated to other actors. And partially this is because the technical solution hasn't been built, but more significantly, there are social pressures which act against effective cooperation.

Many UN agencies are involved in disaster response (UN-OCHA, UNHCR, WFO), there are large NGOs and charities like the Red Cross and Doctors Without Borders, and myriad small operations. There's national, local, and regional governments. And individuals caught up in the disaster and individuals volunteering to help. And there are donors .. the countries called aopon to donate money to fund these operations. And these big agencies and NGOs are in competition for that funding. So they have to demonstrate that their organization, particularly, is effective. And, these beauracratic organizations don't have a "networked culture" -- by default they don't share their knowledge. And there's simply inertia .. these huge orgs are slow to respond and change.

On the individual level, people in disaster response are incredibly passionate about their work, so there's lots of potential to tap. But the work is so demanding on every level, there's a high burnout rate, and relatively inexperienced people end up in authoratitve positions. As a result, people in different orgs don't know each other, and there's fewer cross-institutional links.

There are of course efforts to cut across these institutional barriers. HICs, or humanitarian information centers, is an operational center that helps cross-agency information sharing. The goal is to have a "Common Operating Picture", where situational awareness is effectively shared across all actors. And a map is absolutely at the center of this. Knowing which infracture, bridges, are destroyed; the location of people in distress, and the location of responders and relief supplies .. a map gives a compressed, comprehensive view, and it's hard to imagine operating without one. 


So, crude cartoon sketch of the major components in a collaborative mapping platform for disaster response. At the center is perhaps OpenStreetMap or something like it, and there's connections to multiple data sources, on the ground or remote.

First, there needs to be a standing collection of deployable information. OpenStreetMap, VMap0, names and sizes of population centers, and any other useful statistics. Landsat imagery. Maybe a mechanism to cache some data from mapping providers.

This data needs to be easily accessible, and easily portionable for the affected geographic area -- we don't need any extra crap. This data and the whole software system could be loaded on a laptop, or small computer appliance, or DVD .. even run entirely from a USB thumb drive. 

The core is a p2p collaborative mapping platform. Since there's multiple actos and no well defined central authority, everyone can be a center. Connectivity is sporadic, so it needs to function offline and online, and sync with other nodes when possible. The data collected could be both as fundamental as OpenStreetMap, or simply annotations above the base layer. The source of information is crucial -- we want this to be open to anyone from a official responder, to the relative who receives a cell phone call from a victim in distress -- and agents need a measure of trust of their sources. Being open source is crucial, so that every actor can trust and contribute to the software .. and potentially for field hackability, since during a disaster most everything gets used in ways not intended by design. There are major elements of OpenStreetMap here, and some new or tangental ideas, and I think it would be an interesting discussion on how to proceed towards this.

Up to date aerial imagery is incredibly useful in a disaster, so we need a mechanism to request, process, and distribute imagery. And that might even take the form of "amateur remote sensing" -- kites, or weather balloons, or RC planes, sent up directly from the ground.

Ham radio is often very effective in emergencies. And cell phone networks are often the first instructure available. So we want interfaces for contributions from mobile devices and radio. Twitter is wonderfully useless right now, but it could be very useful in disasters -- responders could all friend each other and SMS to share information, and there's even lightweight ways to specify geocoordinates, ala TwitterVision.

It needs to tap into the external GeoWeb of GeoRSS and KML feeds, for information from outside, and it should be contributing back out.

And yes, paper is still useful .. so these maps need to be easily printable.


So that was a sketch of a system for during the event, but we also want to prepare as much as possible before to mitigate the effect of a disaster.

Analysis. Pretty under-emphasized in "neogeography" but it shouldn't be. For instance in humanitarian response, you'd want to be able to predict the likely trajectory of Sudanese rebels, to help and prepare for evacuees.

The "community" of disaster response really lacks transparency, so anything that would help outsiders, and insiders, get a better picture of who's involved, what their capacities are, and who their connected to, would be great. Social networking for disasters. Encouragingly, the mySociety crew is starting to turn their attention to transparency at the UN with projects like UNDemocracy.com.

And if local people have knowledge of this system, capacity, it will be much more effective. So basically, we want to throw more mapping parties! In out of the way places. We might have one in Serbia soon.

After the event,

we want any useful mapping data to be extracted and made openly available. This base map could be the basis of the longer process of reconstruction.

And we want to cultivate continuing relationships. During reconstruction, the disaster fades from the headlines, funding declines, and interest wanes .. which leads to greater vulnerability to another disaster. There are really exciting ways people are connecting directly to help each other, rather than through faceless or cliche aid beauracracies .. notably Kiva, a site which brokers micro-loans in the developing world, and let's recipients post photos and blog on how their projects are progressing.


There are many more orgs and projects in disaster response which do "get it" so here's a few..

The JRC Tsunami Model. This is a poor man's tsunami warning system, which monitors the USGS earthquake GeoRSS feed, and runs quick simulations to determine vulnerable areas, and sends out email, sms, and GeoRSS alerts.

Following on the success of GeoRSS there, the JRC built GDACS, a collobartion among several UN agencies and the EU to shared disaster alerts, and they chose GeoRSS because it was one less thing they needed to argue about.

RSOE Alert Map is a similar project, built on an even larger collection of GeoRSS feeds.

And underlying both are GLIDE numbers, which are globally unique identifiers for all emergency and disaster events. Used by almost all the major aid orginizations and UN agencies, and that greatly helps data collection.

Sahana is an Open Source Disaster Management system. Web based collaboration tool for finding missing people, managing aid, managing volunteers, tracking camps effectively between all the actors in a disaster. And they presently have two Google Summer of Code projects for building out GIS and GPS integrations in Sahana -- basically GeoRSS and OpenStreetMap like functionality. So that's one to definitely check out. 

MapAction is a UK charity that can rapidly deploy, and start producing more traditional GIS products within 48 hours of a disaster. They fill a vital gap, since the UN takes 1-2 weeks to set up the same thing. And they're open to new ways of doing things, like OpenStreetMap. One thing to note though is that they collect data "by any means necessary", which means they have no problem infringing copyright -- it's a disaster right? So maybe there's room for both a "pure" and a "polluted" strain of OSM?

ReliefWeb is a UN-OCHA project which creates loads of great mapping products, though doesn't distribute underlying data.

And PreventionWeb is the new effort from the founder of ReliefWeb focused on that pre-event mitigation.

Maps 2.0 is focuses on fostering a community in disaster response, and will launch online resources for nonprofit and humanitarian organizations to share best practices in (GIS) and digital mapping tools. And they've now a Netsquared featured project.

INSTEDD has a similar remit. Founded by Larry Brilliant, who had helped to eradicate smallpox, INSTEDD is now connected with Google.org, and they want to facilitate the use of open source and web 2.0 tools in disaster response, epidimiology, and other humanitarian efforts.

And they're working closely with a new partnership between Google & NASA. The Global Connection project, during Katrina and subsequent disasters, was responsible for processing raw satellite data from NOAA and others, and producing KML for Google Earth, making that imagery widely accessible. The new partnership is focused on smoothing out this path of acquisition, processing and distribution, and the sheer weight of these two is sure to change the dynamics of disaster response.

BrightEarth is a project based in the Holocaust Museum in Washington, and fosters a partnership among many organizations. They have produced a very well received Featured Layer in Google Earth on the genocide in Sudan. And they have plans to help implement a GeoRSS/KML collaborative platform for sharing early warning of humanitarian disasters. 

Jim Grey. A long time Silicon Valley guru, he was  -- TerraServer, OneUpManship .. Mechanical Turk, Imagery Providers


GeoEye Foundation


International Charter


Geobliki. OGC Sensor Web Enablement subtask (SWE) is itself extremely ambitious: “The ultimate vision is of a sensor market place where users can identify, evaluate, select and request a sensor collection regardless of sensor type, platform or owner. The goal is to enable a federation of sensors, platforms and management infrastructure for a single sensor enterprise. This enterprise will enable the discovery and tasking of sensors as well as the delivery of sensor measurements regardless of sensor type and controlling organization.” Rails, GeoRSS, Wiki

More than one initiative


Thanks!