On December 26, 2004, the Boxing Day tsunami killed over 35 thousand people and displaced over half a million people in Sri Lanka alone. A massive humanitarian crisis played out in numerous other countries also affected by the magnitude 9+ Great Sumatra-Andaman earthquake and resulting tsunami. Within days it became apparent that an information system was needed to manage the massive amounts of information being generated about who was doing what, and where – at one point there were approximately 1,100 registered NGO’s operating in Sri Lanka.

It was decided by a group of Sri Lankan IT professionals that a system needed to be built to better manage the information as they couldn’t find any existing free solutions that could be quickly deployed. Free, was critical, as they couldn’t afford any commercial solutions.

Sahana was implemented within a week by around four hundred IT volunteers, and it was named after the Sinhalese word for relief. Initially it provided tools for tracking missing persons, organisations involved in response, locations and details of camps set up in response to the tsunami, and a means of accepting requests for resources such as food, water and medicine.

Following the tsunami, the Swedish International Development Agency provided funding to take the lessons learnt from writing and deploying software during a disaster, and to rebuild Sahana from the ground up, and release it as free and open source software to the world. After all, Sri Lanka had needed an open and available system to manage disaster information, surely other countries should benefit from their experience?

Since 2005, Sahana has been officially deployed to earthquakes in Pakistan, Indonesia, China and Peru; a mudslide in the Philippines; and has been deployed in New York City as a preparedness measure to help manage storm evacuations.

Being free and open source software has been critical to Sahana’s success. The more accessible a system is, the more likely it is to be adopted, used and improved. Even in developed countries, many disaster agencies are poorly funded and often cannot justify significant expenditure on systems – commercial systems are too expensive. With pressure being applied to many public budgets, the significance of this is even greater now. Perhaps the greatest benefit of applying open source approaches is that it encourages a collaborative and communal approach to improving the system. As more countries with experience in disaster management contribute to its development, this will also act as a form of expertise transfer to countries that may not have as much experience with disasters.

Following Hurricane Katrina, there were nearly 50 websites created to track missing and displaced persons – all using different systems, all collecting duplicate information, and few of them sharing. Many of the potential benefits of the technology were lost due to a lack of co-ordination and massive replication of data. Access to tools such as Sahana will be more efficient as they can be deployed faster than solutions developed after an event occurs.

Normally, management involves a ‘leisurely’ process to collect as much information as possible, to then decide what actions should be taken. This is completely the opposite immediately following a disaster whereby decisions have to be made, sometimes with little or no information and no time to gather it.

A key benefit that IT can provide is in linking silos of information held by different organisations – everyone has a better shared picture of what has happened, what is occurring now, and what is planned.

Software, however, is just one aspect. There is a need for open data (such as maps and statistics) and standards to ensure that the multitude of systems can connect to each other and share information.

The most important aspect is having the relationships between organisations set up in advance of a disaster. This results in organisations having the confidence to connect their systems and share information. Without shared information the rest of the system will lose many potential benefits that IT can bring to disaster management.

Often, little or no information is available to support decision-making – emergency managers are forced to make complex decisions without having the luxury of all the required information.

A disaster can produce a massive number of tasks requiring hundreds of organisations and thousands of people to co-ordinate activity – meaning that there will always be some prioritisation needed. What should be done first? What can wait until later? How should an impacted community prioritise response and recovery with limited resources?

The benefits are not just limited to agencies and NGO’s. The next evolutionary step will be to adopt an approach called ‘crowd sourcing’ whereby members of the community are provided with tools to interact with each other and emergency managers.

This may be achieved with applications that run on mobile phones linking people and even submitting information from the field directly to Sahana servers. Imagine the situation where a passerby can take a georeferenced photo of some disaster damage, and if communications networks are working, send that directly to the system emergency managers are using to manage the event. There are a numberof efforts underway looking at how social networks and websites such as Facebook and Twitter can be utilised during a disaster.

Disaster IT is really a force multiplier. It won’t usually save lives, but it will allow a better shared understanding of the problems, and will lead to more effective and co-ordinated response. It allows those responding to an event, whether an organisation or individual, to quickly access information and better inform decision-making. This can lead to less suffering and a quicker recovery for affected communities.

Design for Disaster
Computer systems can often be fragile by their design – they are especially reliant upon power and communications. If any of these are lost during a disaster, the value of a system can quickly be lost if it has not been designed to operate in adverse environments. Here are some design decisions that are very important for disaster applications:

• Low bandwidth – we’ve all become accustomed to sucking bandwidth through massive broadband pipes, but during a disaster network connectivity for emergency managers may be limited to dialup speeds over satellite or digital radio connections. Disaster software needs to be designed for very efficient transfer of information, and should never assume vast quantities of bandwidth are available. At at extreme, some information may even be transferred by SMS or USB memory stick.
• Intermittent connectivity – during a disaster communications will likely fail multiple times before they are finally restored. This means that most ‘software as a service’ or web applications on the Internet will be of little use to emergency managers. Disaster software needs to be stored and run locally, and be able to work without a connection to the Internet.
• Synchronisation – one of the best techniques for designing around low bandwidth and intermittent connectivity, is to design a system to be able to synchronise information between two systems when communications are available. When communications later fail, both systems will have a copy of the same data, and can access it locally until communications are restored.
• Low power – power can, and will fail during a disaster, so disaster software needs to be designed to run on low power devices. Laptops and notebooks are good targets as they are self-contained, have built-in batteries, and can be charged from solar cells or generators. Large, power hungry servers can be difficult to move and support in a disaster environment.

How I became involved

One might ask how a Kiwi became involved in Sahana. Ever since training as a Civil Defence volunteer in the late 90′s, I had an interest in how information technology could be used to improve disaster management. The tsunami in 2004 acted as the catalyst for Sri Lankan computer programmers to produce Sahana. I have been volunteering with the project since 2005. In September 2005, he helped facilitate a workshop in Colombo that formed the basis for the current version of Sahana. In March this year he attended a Sahana conference and Board meeting in Sri Lanka. At the Board meeting the existing ‘owner’ of Sahana – the Lanka Software Foundation – agreed to hand the project over to the open source community. Gavin is a member of the transition Board that is in the process of forming an international non-profit foundation that can accept financial donations, and act as the ‘custodian’ of Sahana.

How you can help

There are numerous ways Sahana is looking for help. Once registered, we will be able to accept financial donations that will be used to fund development. In the meantime, we are looking for open source programmers with web development skills (including mapping). If you’re not a programmer, we are always looking for translators that can convert the english text and documentation into many different languages. Perhaps most importantly, we are looking for experienced emergency managers to help provide design advice to the Sahana community and guide the developers.

Garmin announced their latest high-end hand-held outdoors GPS unit recently, and the headline feature is the inclusion of a 3.2MP camera with built in geotagging. This means that any photos taken with the unit will be instantly plot-able on maps, and will be a convenient tool for people enjoying the great outdoors and travelling. Other nice upgrades to the flagship Oregon line include support for a 3d electronic compass for accurate bearings when standing still; increased storage for waypoints, tracks, routes; capacity for a massive 5000 paperless geocaches; and fast USB 2.0 transfer when connecting to a computer at last.

Garmin Oregon 550 Product Page

A recent report from the US Government Accountability Office has identified possible trouble ahead for the Global Positioning System (GPS). Due to governance failures of those responsible for the GPS, there is the risk that satellites may not be able to be replaced faster than the rate at which they fail over the next 10 years. Whilst replacement satellites have been ordered and developed, some technical and project management issues have delayed the launch schedule, with the next launch planned for November 2009. This doesn’t mean that the GPS will just stop working. There are currently 31 active satellites in the GPS constellation – only 24 are required for the agreed level of service. There are 13 satellites that are more than 12 years old, and are increasingly likely to fail. This happens as the solar panels age, and they produce less electricity to power the satellite. There are options for extending satellite life by turning off less critical secondary payloads that draw less power. A few satellites can fail without having a significant impact on end users. If the number of active satellites drops to 24 or below, GPS receivers will probably be less accurate as fewer satellites would be visible at any given time. Given the GPS is a strategic military asset for the US, it is highly unlikely it will be allowed to fail completely. This may drive innovation in GPS receivers to support multiple satellite navigation systems to reduce reliance on a single system.

Have you ever wanted to quickly find all the photos taken at your family bach? Chances are that unless you’ve been meticulous in filing your photos or tagging them with keywords, this could take quite a bit of time. Wouldn’t it be easier if you could click on your bach on a map, and bring up all of your photos within 1km, or display all of your holiday photos on a map? This is the promise of geotagging.

Simply put, geotagging records the latitude and longitude of the camera at the time the photo was taken and stores it in the image file.

Geotagging is not a new technology. It has been possible to geotag images for several years now, but previously only enthusiasts or professionals geotagged their photos, as it added extra steps to processing photos. It also required a GPS receiver that could record tracks – a breadcrumb trail of where the GPS had been. By matching the time in the GPS track log with the time that photos were taken, it is possible to reasonably estimate where the photo was taken. This took extra time and effort, and except for a dedicated few it was not worth the effort. The GPS receivers also added extra weight and bulk to carry around.

Recently GPS functionality has greatly shrunk in size and power demands, making it more friendly for the photographer by enabling the technology to be directly embedded in cameras and mobile phones.  Already a number of camera phones support geotagging photos – including much of the Nokia N series, and the recently released Apple iPhone 3G. Nikon has embedded a GPS receiver in their new Coolpix P6000 compact, and provide an optional GP-1 GPS attachment for recent Nikon digital SLR cameras. As more devices support geotagging, especially more affordable cameras and mobile phones, the possibilities (and the risks) are going to grow exponentially.

Combining GPS receivers with other devices makes the whole geotagging process transparent and automatic, and requires no effort from the user. This is going to rapidly open up opportunities for all sorts of geotagged data. But is it just technology for technologies sake? Not really, there are existing applications for geotagging, and even more to be come.

Travel photography just begs for geotagging. It is a great means of recording where holiday snapshots were taken, as you can easily show people where you took the photos. Not only that, but as people upload geotagged photos, they become a great travel planning tool as you can see photos that other have taken in a location that you are travelling to, and find sights nearby that you otherwise may have missed.

Real estate also stands to gain from geotagged photos – by being able to quickly load photos of properties for sale into an online searchable map, it will be easier to browse location and appearance at the same time. Councils and infrastructure companies have been using geotagged images for a number of years now to assist with managing assets – imagine being able to take a photo of a pothole and send the image to the council without having to try and explain where it is. Geotagging even has applications after a disaster – teams performing reconnaissance of an affected area can take geotagged photos whilst they are there, and when they return to an operations centre, the images and their exact location can be loaded into a mapping system to help authorities gain a better understanding of the extent of damage.

Location-based technology does come with inherent risks – mostly privacy related. Although many people are comfortable posting photos online, they may not be comfortable allowing people to determine the location where the photo was actually taken. This may be particularly relevant in the case of photos taken at home. No doubt we will see tools evolve to help people manage the privacy associated with geotagged photos, but in the meantime it is worth thinking about the content of a photo before uploading geotagged photos online.

The benefits of geotagging for the most outweigh the risks, and will likely lead to novel applications. The Apple iPhone 3G already has interesting applications taking advantage of geotagged images. Exposure provides mobile to Flickr – a photo sharing website. The ‘Near Me’ function will get your current GPS co-ordinates from the iPhone, and use that to display geotagged photos from Flickr that were taken near your current location. You can then view a photo, plot its location on a map, and if you desire, Google Maps will give you directions on how to get there.

Geotagged images don’t have to be shared online to reap the rewards – it may be that the biggest benefit is just providing another means of managing the vastly expanding data in your own photo library!

When I purchased my first Global Positioning System (GPS) receiver in 2001, it was rare to see someone else with them. These days, you can find them just about everywhere – particularly suckered to car windscreens. But how does the GPS work?

It’s quite appropriate that in-car GPS receivers are usually located close to the radio, as the GPS is similar in concept to a radio. Instead of ground-based aerials to transmit radio stations with voice and music, the GPS uses around 30 GPS satellites orbiting 20,200km above the Earth’s surface to transmit signals that GPS receivers listen to, and use these signals to calculate their position.

Each satellite accurately knows the time and its own position in space based on its orbit and onboard atomic clocks. This information is then broadcast from space for any receiver to hear. The GPS receiver uses the precise time and position information broadcast from each satellite to trilaterate and determine its location based on how far it is from known reference points – the satellites. Whereas triangulation uses angles to calculate location, trilateration uses distance.  Listening to one satellite, the receiver could be located anywhere in a circle around that satellite. If the receiver knows how far it is from a second satellite, then the number of possible locations of the receiver is reduced to two. The known location of a third satellite would identify a unique location, and reduce the calculation error to an acceptable level to generate an accurate location.

A GPS receiver is capable of listening to 12-20 satellites at the same time. Generally, the more satellites the handheld can listen to at the same time, the more accurate it is at calculating your latitude, longitude and to a lesser extent altitude. The receiver needs to be listening to at least 3 satellites to calculate a location. In good conditions the location is accurate to 3-5 metres.

The default model of the Earth used for calculation is the World Geodetic System 1984 (WGS-84). This is used on all new GPS receivers. Most receivers allow alternative display systems to be selected – in New Zealand the combination of Geodetic Datum ’49 and New Zealand Map Grid should be selected when using a receiver with the current 260 series topographic maps.

GPS receivers aren’t always able to report accurate positions – this is usually due to the receiver not being able to ‘hear’ the satellite signals correctly. When the receiver has a good clear view of the sky – for example standing on top of the Port Hills – there is nothing stopping the signals reaching the receiver. Problems arise when you place the receiver under thick bush canopy or in buildings where the signals have trouble penetrating. Similar problems can be found in gullies and valleys, or urban canyons in high-rise cities. In these situations, the receiver can only produce approximate locations and often will fail to even produce a location.

Over the past 2-3 years, the processing technology within receivers has reached the point where they can produce accurate locations even in many demanding environments. With a mixture of low and high sensitivity receivers on the market, this can be an important purchasing decision if you are going to be using the receiver in challenging locations.

Change is also afoot in space, with Japan, China, India, Russia and Europe announcing new or updated navigation satellite systems. The EU’s Galileo system recently announced an agreement that will make their system compatible with the US GPS. More satellites and updated receivers will make it easier to get a signal and more accurate location!

The rapid growth of the Internet and World Wide Web has spawned the creation of new and potentially useful software applications that may provide benefits to emergency managers. One of these applications that is currently drawing attention is the wiki.

Wiki is the Hawaiian word meaning to hurry, hasten; quick, fast, swift. Wiki software therefore refers to packages that are designed to make it quick and easy to create and modify collaborative web pages on the Internet. They have actually become more powerful and advanced than just for the creation of web content – wikis now power some very content-rich websites including the open source Wikipedia – the open encyclopaedia.

What are some of the key characteristics of a wiki?

• server-based software
• free, with few licensing restrictions
• accessible from any web browser
• can be run on a standalone laptop
• uses html links to reference other pages in the database
• designed for collaboration and sharing
• records all revisions of documents and tracks changes made by users
• immediately highlights recent page changes and by whom

What opportunities exist for wikis in the emergency management domain?

Wiki software has much potential to be used as a collaborative planning tool – whether planning occurs within or between organisations. Rather than passing a word processing document around via email to all participants in the planning process, the plan could instead be created and maintained using a wiki. A secured web site would provide an excellent home where plan developers could log in to check the latest changes and make modifications. The one key benefit over using a document-based approach is that everyone is always guaranteed to be reading and editing the latest version of the plan.

As certain milestones are reached in plan development, it is possible to lock the wiki, and create a ‘snapshot’ of the current plan before continuing the review and development process. Conceptually, this model of development is quite similar to techniques used for managing the development of computer software – with developers sharing a central repository.

In addition to planning, a wiki can also be used as a knowledgebase to store information and references to other documents. For example, certain pages in a wiki could be ‘tagged’ with a pandemic tag. Then, by viewing the pandemic category, it will show all pages that are tagged with pandemic. This provides quick and easy access to relevant information.

The benefits of wikis do not end when response starts. Conceptually, wikis can be installed on laptops or PDA’s enabling responders to have an entire knowledgebase available on a PDA including all the links and available plans.

Wikis could be used on a set of wireless laptops as a tool to assist your incident management system of choice. For example, the response plan developed in the EOC could be created in a wiki, and then planning/intel, operations, logistics, finance, information could collaborate on the one document with each section being able to view the other sections.

Wikis are also starting to be used in response and recovery by those people that have access to power and communications. Probably the best recent example is the Katrina Help Info wiki that is used to consolidate response and recovery information following a disaster – in effect creating a portal for the event with links to other agencies websites. In this manner, a wiki could be used as a public information system where key infrastructure is available.

Another example is the Hurricane Katrina web page on Wikipedia which started as a collaborative effort to record open source situation information. In the case of the Flu Wiki, wikis are even being used to develop a community knowledgebase about a hazard before the event.

It is important to note at this point that public wikis with permissive access controls can have issues with the quality and authenticity of information provided. Restriction of editing rights to approved and trained personnel can ensure that quality of information contained in the wiki is not threatened.

The next likely development is going to be the consolidation of wikis and community mapping projects such as the Hurricane Information Maps that were developed following Hurricane Katrina and utilise Google Maps. The combination of information contained in a wiki linked to spatial references and presented on a map will provide a very powerful information resource for response and recovery.

In February 2004, I wrote an article for the IAEM Bulletin outlining some of the benefits that open source software had the potential to provide for emergency managers. At that time, little open source software existed for emergency management, and I had just come out of a simple attempt in 2003 to create a Web-based disaster management system. That effort failed, for while there was a well-recognized need for open source disaster management software, there were no real drivers to encourage development of a solution.

2004 Tsunami Spurs Development of Sahana

The driver came with the tsunami that struck Sri Lanka on Dec. 26, 2004, which prompted the development of a free and open source solution called Sahana. Within a couple of days, the need for a system to manage vast quantities of information became obvious, along with the need to attempt to coordinate 1,300 NGOs responding to hundreds of thousands of displaced people. In the following days and weeks, a Web-based system for managing disaster information was built on-the-fly based on the most pressing needs. Accordingly, the following were the first modules developed:

• People Registry – track and match victims of a disaster.
• Organization Registry – register, connect and track NGOs involved in response.
• Camp Management System – register and track camps.
• Request/Assistance Management System – record, track and match requests and offers of assistance.

Sahana development was initially led by the Lanka Software Foundation and supported by volunteers from the Sri Lankan IT industry. As the immediate need for Sahana subsided in the months following the tsunami, more international contributors became involved in the project, myself included. These ranged from programmers wanting to help out, to those who wanted to offer assistance drawing upon their disaster experiences, including emergency managers.The positive feedback to Sahana prompted further development to add more response and recovery capabilities applicable to any disaster management situation.Longer-term, the goal is to use Sahana as a means of encouraging comprehensive emergency management in communities by supporting preparation and mitigation. This will start by providing tools to incorporate plans and reference material, such as communication directories in advance and other techniques to encourage greater interagency co-ordination before an event.

Capabilites

Sahana has been designed to operate in a diverse range of environments due to the nature of disasters. It can run on Web servers and laptops, and has even been installed on a PDA. Over time, it will support both standalone and networked modes of operation and allow communication between multiple Sahana servers, including synchronization of data.There are a number of future modules planned or under development:

• Disaster Impact Assessment.
• Alerting.
• Inventory/Supply Chain/Logistics.
• Volunteer Coordination.
• Intelligence.
• Response/Rescue Team Management.

In addition, there are a number of key technologies identified for inclusion:

• Mapping/GIS, and GPS integration – it can already use Google Maps.
• Biometrics.
• Provision of information via open standards:
  • Common Alerting Protocol (OASIS/CAP).
  • Emergency Data Exchange Protocol (OASIS/EDXL).
  • Various OpenGIS Protocols (OpenGIS Consortium).
• Support of existing paperbased forms.
• PDA forms for remote fieldwork.

Deployment

Sahana has seen official deploy ments in multiple events, including the Sri Lankan response to the tsunami in 2004, the 2005 earth quake in Pakistan and the 2006 mudslide in the Philippines. It has also recently seen unofficial deployment in support of the Yogjakartra earthquake and in preparation for an eruption of Mt. Merapi. Sri Lanka’s largest NGO is also deploying Sahana within their disaster unit.

Recent Events

In mid-May 2006, a workshop was held in New York that brought together key members of the Sahana development community and IBM. The meeting served two purposes:

1. To discuss IBM support of the project, and
2. To consider further development of modules for Sahana that could be used during response to a pandemic.

A pandemic presents an interesting opportunity for the deployment of Web-based disaster management systems, as most infrastructure should be operating normally (relative to a hurricane or earthquake).The Sahana project is interested in contributions, be they time or financial. Time contributions can be made in providing design advice based upon disaster experience, writing the code, testing Sahana or helping to write the documentation. Financial contributions will be used to target module development, such as sponsoring development of a specific module or supporting the core development team that works full time. An international community maintains Sahana, and all contributions are provided back to that community at no cost – a share-and-share-alike ethos to ensure that everyone benefits. Sahana is free to use and has no licensing costs associated with it.

Links

• Sahana Web Site
• Sahana on Wikipedia
• Dr Sanjiva Weerawarana’s Blog, a record of initial Sahana deployment (entry1, entry2)

What is Open Source and what are the benefits to Emergency Managers?

The spread of the Internet has given life to what some may say is a radical change in which software is developed. Traditionally, software development has been driven by commercial vendors that provide you with a software package that cannot be directly modified to suit your organisations needs. Yes, you may be able to customise it with options and configuration settings, but if it doesn’t implement a function you need, there is usually little hope of getting it implemented. This is because you do not have access to the source code – the human readable code that tells the program how to operate. Open Source Software (OSS) changes all that.

What is Open Source Software? It is software that people can freely read, copy and modify the source code. This allows people to improve software, adapt it, and fix bugs. Additionally, this can often happen at a greater speed than conventional software development. But, the essential point with OSS is that you have the source code to the software, and the freedom to modify it, and redistribute your modifications.

The Internet has brought about the spread of Open Source Software because it provides a means of linking programmers and users around the world. The individuals come together on a project-by-project basis to develop software for a specific purpose.

So how can Emergency Managers benefit from Open Source Software?

Repair and Maintenance
Have you ever found a bug in your software, but you’ve had to wait until the vendor releases the next version of the software to fix it? Well, if you are using OSS, you can fix it yourself, or pay someone to fix it for you. Additionally, your fix then is released back to the community so all benefit from fixing the bug.

Licensing and Cost
Emergency Management Agencies often are not well funded, with some having to make do with whatever hardware and software comes their way. OSS provides an extremely cost-effective means of providing functionality. For example, if you receive Windows PC’s with no office software, you could download and install OpenOffice.org – a suite of office productivity software for free, and it is also compatible with Microsoft Office files. Other day-to-day software solutions are available, including web-based groupware servers. Of course you can install the software as many times as you like – consider how expensive that would be with commercial software?

Extendibility
If you want a specific function added to your open source EM software, you can always pay a programmer to implement it for you. The real benefit of OSS comes when these additions are feed back to the community at large, so the community as a whole benefits, and spreads the cost of development. It also gives you a chance to support a programmer in you town, rather than across the country or the other side of the world!

Flexibility
Once again, with the source code in hand, you can customise the application to allow for internal consistency with jargon in your organisation. By changing the terminology used within the application, you can reduce the training requirements, and maintain consistency with other applications.

Economies of Scale
There is the potential for pooling of resources to achieve economies of scale. One EMA may not be able to afford to develop an EM application. However, by working with others and pooling resources, it would be possible to come up with enough funds to provide full time jobs for people to work on OSS – specifically an EM application (or suite of applications).

Speed
And finally, because you have the source code, you are not tied into the commercial vendors release schedule. Want that feature? Need a bug squashed? You can pay someone to do it right now.

At this stage however, there is little Open Source Software specifically designed for Emergency Management. But that is about to change. Some of the base functionality is the same across most organisations – such as a contact directory, basic message handling etc. Rather than having to build all this functionality from scratch however, we can take an existing stable OSS project (e.g. egroupware) that has some functionality required for emergency management, such as groupware which provides contact directories, calendars, user authentication etc, and then develop and integrate specific emergency management functions, such as alerts, and message handling. This translates to months not years to get a useable product into development.

Links to Popular Open Source Software and Information Sites

• Mozilla Firefox – a very popular open source web browser
• OpenOffice.org – open source office software
• Open Source Initiative
• The OpenCD – a CD containly a wide range of open source software packaged on a CD
• MediaWiki
• eGroupWare – web-based collaboration software
• WordPress – the software that runs this website is also open source