I initially learned about MapAction during an Infoterra event in the UK about a year a half ago. Impressed by their work, I’ve been following their activities ever since. After reading they had a team en route to Haiti to assist in the humanitarian effort there, I took a look at their Field Guide to Humanitarian Mapping. It’s an excellent introduction to mapping methodologies and GIS on a budget, with a heavy focus on concepts, data collection, and specific workflows.
Looking through their list of Open Source GIS applications, I thought it might be interesting to run through a small project: gather data for the affected parts of Haiti and think about data sources, workflows, and considerations in the field.
A few observations at the start, and then I’ll walk through the process I went through:
- Satellite Imagery: Very difficult to attain… GeoEye has graciously released post-earthquake imagery, but it is still difficult to get the full resolution processed imagery (not an ungeoreferenced jpeg). I think that remote sensing satellite operators would want to (a) process post-catastrophe imagery as quickly as possible, and (b) get the imagery into the public domain as soon as possible. It’s great that we can see post-earthquake imagery as a network-link in Google Earth, but people on the ground are not necessarily going to have internet access. I know we cannot rely on private companies to provide free data as a service, but I do believe there is a need to acquire imagery quickly and get it into the public domain.
- SRTM terrain data is a tremendous resource, but getting at the data can be tricky. More on that below…
- OpenStreetMap only needs a one-word description: fantastic. I read earlier today that there have been over 400 edits made to Haiti since the Earthquake. People around the world are donating their time to help out the cause. Another great thing about it is that it is extremely easy to check out data and then pull it into another application – more on that below.
Nothing fancy: I just wanted to see how long it would take and if it would be challenging to pull together base mapping data and then view it all together. No real geoprocessing, but just data acquisition and setup using open source software and publicly available data. This would be a similar to real-world workflows one could use for in-the-field mapping applications. With this software and data configuration, it would be possible to begin updating data in the field, performing analysis (e.g. slope analysis for areas that could have a greater potential for mudslides), and providing spatial resources to other humanitarian groups in the field.
Software: no better time to try out the new QuantumGIS version, 1.4.0 ‘enceladus.’ It’s a desktop GIS application, and the download and installation process is quick and easy.
Terrain: I decided to use SRTM as a terrain layer and primary base data layer. Why? Height information is valuable when combined with vector data. For example: a road network layered on top of an orthophoto won’t tell you that the road is on a steep slope – and terrain will.
Vector data: OpenStreetMap data was an obvious choice here. The coverage is pretty good, and it is also being rapidly updated.
Imagery: I thought about downloading some Landsat imagery but took a pass: for an urban application, the medium/low resolution publicly available data isn’t very helpful. What’s needed is 0.5 meter resolution imagery from the latest generation of sensors, which isn’t yet public at the time of writing.
Here’s a step-by-step overview of the process:
1) Download an install Quantum GIS from www.qgis.org. No extra instructions needed: this is easy.
2) Find the appropriate SRTM data. As much as I love working with it, this is my pet peeve with SRTM: it’s available from multiple host sites, with multiple processing levels, and it can be quite a challenge to find the data you need. Maybe it’s just me, but every time I grab some I’m left thinking about how much easier it could be to access. In this case I first went to the Consortium for Spatial Information site and downloaded the Google KML link, displayed below.
Looking at the KML link identifies srtm_21_09 as the file required for Haiti. Instead of navigating the maze of SRTM sites, I just Googled the filename, which took me here: http://collections.sdsc.edu/dac2/telascience/telascience_data/elevation/cgiar_srtm_v4/tiff/. I then downloaded the appropriate TIF file.
3) Acquire vector data. This was very straightforward: I’ve never tried to download or use OpenStreetMap data offline, but fortunately it is a fairly simple process. I went to www.openstreetmap.org, zoomed into Port-au-Prince, and then selected the Export button at the top. I exported the data in the OpenStreetMap XML format.
4) The next step is to start assembling the data in QGIS. I launched the application and loaded the SRTM data. If you’ve used a desktop GIS application before, QGIS is fairly intuitive.
The image above shows the SRTM data with a MinMax contrast stretch applied.
5) I had to use “Manage Plugins” and load the OpenStreetMap plugin prior to adding the OSM data (Plugins > OpenStreetMap > Load OSM from file). Now it is possible to view the vectors over the terrain data.
6) Once the OSM data is loaded, we’re ready for field mapping. Note that it is possible to query the OSM data as well. The image below shows a query on a hospital, which is identified in the table on the right.
This workflow isn’t very sophisticated, but it does demonstrate the ability to get up and running relatively quickly. SRTM and OSM data are both invaluable resources – ideal for humanitarian work in disaster areas. As for the timing: if you know where to get the data, I think the simple example above could be completed in under an hour. That includes software installation, data downloads, and then assembling the data in a GIS.