The starting point was 50 cm imagery of Aghanistan, released by the National Geospatial-Intelligence Agency. Todd Huffman, known to me from the Beer for Data program, negotiated free use of the invaluable imagery. OpenStreetMap’s response to Gaza demonstrates just one application of the power of easily available imagery. The US government, and many other governments, purchase this imagery with our tax money, and it’s totally reasonable and to be expected that such imagery should be put to its widest possible use in times of crisis.
The Google Enterprise team brought a Google Fusion server, and processed that imagery into Spherical Mercator tiles. With just a little config, everyone was able to incorporate these tiles in their systems (Andrew, you could also highlight tiles as an enabling GeoWeb standard).
Walking Papers blew everyone’s minds. It’s fair to say that paper was the highest tech on display, and emergency responders and other observers coming through the exercises were inevitably intrigued by the possibilities. We got a great deal done in intense coding sessions to make WP more ready for emergency response, most crucially decoupling WP from web services that may not be available in an emergency, or may simply be too expensive to access over satellite data connections common in these situations.
The OSM rails app and tile rendering system were straightforward to take offline, and run locally. Walking Papers took some hacking. The print and scan storage was optionally disengaged from S3. Aaron’s ws-compose went through heavy modification to work with configurable, local tile sources, and allow for overlay of multiple layers. We took the Google processed imagery, overlayed semi-transparent tiles from the local OSM server, and published both in the WP pdf. Our hacking was captured on this github branch, and with some work will make it back into the main codebase.
Walking Papers are meant to be scanned and then digitized into OSM. Camp Roberts threw up another usage scenario: a remote team prints out WP before deployment, but only has access to low-bandwidth communications, like SMS, to report back changes to the map. We worked closely with the InSTEDD team to integrate with GeoChat. On each WP print, a 100×100 grid is overlayed. Along with the bounding box of the paper, this 4 character coordinate can be translated into a fairly accurate lat/long.
When a WP is printed, the local GeoChat server is pinged with the paper ID and the bbox. Their SMS gateway and server was installed at the forward operating base, which provided internet connectivity and solar power, completely off the grid. During the field exercise, SMS reports were sent to GeoChat, including the paper ID and grid coordinate, along with text description and tags. Certain tags trigger GeoChat to pass the message on to the local OSM server, in the form of a changeset with one new node.
Simply, via Walking Papers and GeoChat, OpenStreetMap can now be updated with just a text message!
From there, OpenStreetMap generates new tiles. These tiles are automatically incorporated in other tools. Sahana users automatically see the Kitfox report. Now imagine that this a report of a bridge out, a collapsed building, a shelter for refugees. We have extremely easy to update and share base mapping. This is a big deal.
The OSM server was also producing Shapefiles, KML, Garmin maps, all of which have unexplored potential in disaster response.
The roundup in the next post…