Gav's Blog

After checking the interior of the house and finding little damage, I actually retreated to my bed for the next hour or so and started replying to people that had been asking if I was OK, and trying to track down more information on the extent of the quake and damage. Power and water was of course out at this point, so I was limited to the very long battery life on my laptop and mobile broadband. Despite Vodafone 3G coverage being far from ideal at home, the speeds were still pretty good.

Next steps as it became light enough to see outside was to do a reccy around the outside of the house looking for external damage. Couldn’t see anything indicating damage and this was indeed a good thing.

Now it was about 0630 or so, and other than the utilities being out, everything was in pretty good order. The plan from here was to get prepped, go and check the office, and then another couple of properties of relatives/friends around Christchurch. Despite having a ready kit in the past with boots, overalls, helmet, gloves and other stuff – a mixture of using some of these items, and a fair amount of recent travel, meant they weren’t all in one place, so a little hunting was required to get them back into a bag. Water for the day was easily dealt with, as I have a wine rack at the front door, which in addition to holding wine, also stores a number of recycled plastic water bottles that are used for exercise, days-out, roadtrips, and of course, emergencies. These were chucked into the bag, along with some dark chocolate and some OneSquareMeal bars, and we were ready to go. Of course, as keen photographers, we also had cameras with plenty of batteries and cards.

The last thing that I did before leaving was to turn the water off at the street, and turn the power off at the mains switchboard. Just in case there had been damage to utilities within the house, or more damage was caused by a large aftershock when we weren’t there, then we would hopefully minimise the risk of a broken pipe and lots of water, or an electrical fire.

It didn’t take long to find notable damage to road and infrastructure, and only about 300-400 metres from the house I found the road cracked, the first signs of liquefaction (and yes, I knew about liquefaction before the earthquake) and broken pipes. After taking a few photos, and driving on, we struck more around Travis Wetlands by Timara Park – lots of cracking in the road and significant leans on some powerpoles. In addition, the liquefaction process had clearly raised the in-ground infrastructure, as the grates had noticeably raised up beyond the road surface, anywhere from 50 to 250mm.

At this point we decided to pretty much drive straight on to the office. On the way, we saw the first evidence of fallen chimneys, collapsed block fences, and on Cranford Street the first old unreinforced masonry buildings (URM) that had partially collapsed. Also drove past the Chinese Methodist Church on Papanui Road that had lost a fair bit of brickwork, and had fair-crushed a van.

Got to the office and it was in very good nick – nothing broken, but certainly evidence of the odd small item being thrown around. I grabbed the Networked Attached Storage (NAS) that acts as our fileserver and moved it to the car. Just in case. Sure, I had backups, but if needed to run from another location for a while, it is just easier to plug the NAS in.

From there it was onto a couple of other properties for a quick walk-around and checking the utilities and make sure everything was safe. Which they were.

The second place did have two brick chimneys, and both of these had fallen, and one had significantly damaged two cars – one of which was later written off. However, all the utilities were working, and we had power, phone, water, and Internet via wifi. So for the next couple of hours we camped out there getting more information about the quake as it came to hand, and starting making some phonecalls to colleagues to let them know we were OK, and to see what we could do to help respond.

Yep – it has taken a M7.1 earthquake for me to awaken my blog. I’ve been meaning to starting writing again for some time, but after having been through a bit the past week, I figured that now was a good time to upgrade the software, dust off the spam filter, and start writing again.

I’m probably going to have a pile to say over the coming weeks as I try to capture what I experienced and learnt. In the meantime, I want to start with the main quake, and my immediate response.

I want to preface this by saying, in case you haven’t taken the hints by some of the words in the tag cloud to the side, that I am an emergency management consultant by trade – I work in the profession that deals with disasters.

Pow, right between the eyes
Oh, how nature loves her little surprises
– Joe Walsh – A Life of Illusion

I recall being awoken by the timber in the walls creaking. I am somewhat of a heavy sleeper so I probably missed some of the early grumbles but I woke up fairly quickly. I knew it was a strongish one, as I’ve experienced a few (as we do in the Shakey Isles) including many in the 4-5.5 range, as well as the M6.7 Arthurs Pass earthquake in 1994. I didn’t immediately get in a door frame, but when my flatmate turned up in the doorway to my room I quickly went to the doorway in my closet, right about the time that the shaking seemed to be intensifying.

Unlike the 1994 earthquake, this one seemed to go on for a lot longer – or at least it certainly felt like it. I know at some point I heard glass shatter. And as quickly as it arrived, it passed.

Both my friend and I are emergency managers, so we knew that it was quite a strong one, especially with some of the car alarms going in the street. At that point I didn’t think that it was a Christchurch quake, instead either a large Wellington quake, or something from the Alpine Fault that is well overdue for a large rumble anyway.

The first quick check was the light switch, and as that didn’t result in any further illumination, I went and got the torch beside my bed and had light. The next check was the water which appeared to have lost pressure. Next was the Internet, and that of course was inaccessible due to the power failure. Luckily, I had a mobile broadband card, so stuck it in the laptop and jumped online. The iPhone also proved useful.

What happened next surprised me. Within 45 minutes I’d had email enquiries from multiple friends in the US and China. So quickly responded to them letting them know that I was OK, as well as getting a quick I’m OK message up. Around the same time, we wanted more information, and that is where my American Red Cross emergency radio came in soooooo handy. As it turned out, I hadn’t charged the rechargeable batteries for a long time and they were flat. I also hadn’t put real batteries in it. It did however have a kinetic hand crank, so I was able to give it a spin, and get a few minutes radio listening before having to crank it again. Needless to say, since the evening of the 4th, it has been plugged back into mains power to charge the rechargeables!

The radio was the first real view into the outside world and what was going on, and when I first heard reports on NewsTalkZB that it was felt in Dunedin, that it was when it became clear it was a fairly sizable quake. For some reason I wasn’t able to get National Radio early on – not sure if it was my radio, or if the transmitter had actually been knocked out for a bit. I did also jump on Twitter, but didn’t get too much information there that I wasn’t already getting from other sources.

Of course during this period there were a pile of largish aftershocks, and this constant activity also reinforced that it was a rather large quake, and possibly quite a bit closer. I was quite surprised when I heard that the epicentre was around Darfield. Sometime during this first hour, I also went to Geonet to have a look at the quake drums and one look at the chart instantly told me that it was very widely felt.

Naturally, the two of us also did a quick reccy around the inside of the house and apart from a few things being knocked over, the only actual damage was the glass in a mounted photo frame that smashed near the front door during the shake.

We were very very lucky compared to many others.

(this is the first in what is likely to be a number of posts on the earthquake)

Update: I’ve updated this blog entry to become my index page for all of my post relating the the earthquakes in Canterbury and Christchurch triggered by the 4th September 2010 quake, and including the 22nd February 2011 aftershock.

This isn’t a blog post so much, rather it is going to be an index page to an increasing number of posts that I intend to make on what I learnt on both a personal and professional level during the September 4 Darfield Earthquake that hit Canterbury. I’ll be breaking these out into various groupings, and will also include links to other relevant sites.

The main intent in sharing this information, is to give some of my colleagues that develop software for emergency management, particularly within the Sahana Software Foundation, a better insight into real life experiences, so that can be factored in when developing new IT capabilities. I’m also going to be specifying capabilities based on my observations during response.

Personal Experiences
I’m a past Civil Defence volunteer (joined in 1997, mostly headquarters/incident management, but also rescue) and a director of an emergency management consultancy – Kestrel Group – since 2003. I’ve reviewed and written a number of emergency response plans for public sector and infrastructure companies, as well as the National Disaster Plan for Niue Island.

• My first hour of the Christchurch M7.1 Earthquake – my immediate reaction and through to daybreak
• So there’s been an earthquake. What next? – what I did with my Saturday morning

Building Safety Evaluation
I spent most of about 6.5 of the first 7 days (afternoon of Sat 4 through Fri 10) working in the Building Evaluation team at the CCC Emergency Operations Centre based at the Art Gallery. Previous to that, one of my colleagues, Dave Brunsdon, has been heavily involved in the Building Evaluation Guidelines for the NZ Society for Earthquake Engineering, and I’d taken quite an interest in it. Just a month before I had actually started implementing an application in Sahana Eden to provide a means of managing BSE information. Sadly this was nowhere near a workable state to be used following the 4 Sep earthquake. So, the articles I’ve written below are a means of capturing my observations in the hope that we can use these learnings to create a system before the next time a large urban centre is struck by an earthquake and needs a system to handle the thousands of assessments required.

• Some background to building safety evaluations… – a brief introduction and history to the NZSEE Building Safety Evaluations and how I became interested in it
• Saturday afternoon and evening – helping get the process set up for a big day Sunday

Geospatial and Photography
I’m a bit of a techno-geek and I love mapping, GPS and photography. In October 2009, I was involved in purchasing and preparing 6 Garmin Oregon 550 GPS units with inbuilt geotagging cameras for use in the NZSEE team that went to Padang, Indonesia to perform BSE evaluations following the earthquake there. I’m very interested in the collection of geotagged imagery following an event, so that these can easily be plotted on a map to help visualisation of damage.

Until I get around to writing more about this, some of my publicly available earthquake photos are available:

• Canterbury Earthquake 2010 – my set on Flickr. Note that the position of all the photos, including those from the Iroquois have been geotagged with GPS, allowing you to click on the map to view fairly accurately where they were taken.

Ideas and Things I’d Like to See Done
Coming soon. I learnt a lot, I have a bucket-load of takeaway points, and I think there are a lot we can build so that not only New Zealand, but other countries have excellent building safety evaluation systems in future. Not only this, but we also need to think carefully on how we can share this information with multiple systems.

• Inhouse solution versus standalone? – a quick overview of the key pros and cons of the bespoke vs open source approach to building a BSE software tool
• Christchurch Recovery – A Centre of Excellence – one idea towards rebuilding Christchurch better, to consolidate and strengthen the various emergency management and related disciplines into a single campus.

This is the original text I submitted to The Box feature on Disaster Tech on Tuesday the 2nd of June, 2009. It is archived here for my records. It also includes some additional content that didn’t make it to the print edition.

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.

Microsoft recently released an invitation-only beta of Vine, a social networking application to allow people to share information with their networks, and receive news and public safety alerts for areas they are interested in. It appears to integrate with Twitter and Facebook, and allows you to post and receive information. Microsoft is targeting Vine as a tool for both routine and emergency use. It has just entered testing, but has some potential as a social networking tools for disasters. To ultimately be successful, it will need to run on Mac, Linux, and popular mobile phones such as Symbian, and the iPhone so we can carry it in our pockets. It also needs to interoperate with similar applications from other vendors, but most of all be free so that price does not dissuade adoption.

Update – I received an invite, but the current beta is really only keyed for US usage.

The issue of community-produced maps has reared its head on the IAEM email list today – closely linked to my post back on the 26th. The following issue was raised, and I wanted to share my reply to this.

Lack of citation was my major concern with the other available maps that have been in wide circulation. The second concern with the other maps is that they showed push-pins when they did not have or could not cite the data to support specific points.

My reply follows:

I think you’ll find that most of those maps do actually have references, in the case of the Google Maps mash-ups, they are contained in the hundreds of comments accessible from the same page as the maps. In fact, it is generally from the posting of these references in the comments, that the Google Maps get updated. What they have failed to to is to make it easier to reference the citations, by not including the reference in the popup bubble above the marker. But if you read through all the comments, you’ll likely find most of the citations there.

Another big failure is to create a timeline/history so that one can see the growth/change in numbers over time for each marker. Most of the maps are purely a snapshot of the here-and-now, and give no context via history.

The real point that emergency managers should take away from this is the following.

Agencies that ‘own’ the source information (e.g. CDC, WHO, and health agencies in every other country in this case), really should be publishing authoritative georeferenced data at the source. If agencies did this, then there would be no need for these ‘amateur’ cartographic efforts to hack together information from news, rumours and other sources. It would sure save a lot of time and effort in people trying to recreate information that already exists and either hasn’t been released, or has not been converted to a georeferenced format.

Likewise, it isn’t really the role of companies to provide this information. Once again, they are just filling a gap that we, as emergency managers, have failed to meet.

The mashup culture is a direct result of a failure by emergency managers to make information available in a form that end users clearly want it (as evidenced by the time and effort they will put into recreating the data in the form that they want to use it).

Perhaps we really should start thinking seriously about how we can produce authoritative information in formats that our communities want.

If you have a look at the example map I created in under an hour on the 26th, you’ll note that I created a little table in each popup for a marker that contained a link to the source article, and in the case of the San Diego marker, included daily figures for three days so it was possible to track the state of that marker over time.In addition, I scaled the marker images so that they were more proportional to the number of cases – a marker for each infection quickly produced an unreadable map, hence it seemed a better approach is to produce summary markers for each location, with the size of the marker indicating the numbers.

The real trick is going to be to produce a web application to track and manage this information, that can then export it in a suitable form to display the information as discussed above. This is clearly something we should look at for Sahana.

Three months ago I blogged about the Conficker worm and its relevance for emergency managers. Since then, I’ve rumours that a number of health agencies were still having problems with their email systems. The reason I raise this again, is that now, with a large national response to a potential pandemic taking place, one hopes that Conficker has been well and truly removed from all Health systems (both Ministry and DHB).

If Conficker is still impacting on health agency IT systems during this period of increased activity, then honestly, heads need to roll at MOH.

Well, it has been a lot of work for the admins, the mentors, and the students, but it has paid off. The Sahana has been awarded 10 projects in the 2009 Summer of Code. We have some great projects lined up! The include:

• Person Registry for Sahana
• Warehouse Management
• Disaster Victim Identification
• J2ME clients for form data collection in the field
• Optical Character Recognition for scanning forms
• Peer to peer synchronisation of Sahana servers
• CAP Aggregation and Firefox CAP plugin
• CAP Editing and Publishing
• Mashup/Aggregation Dashboard
• Theme Manager

Having been neck deep in the process; working with others to set up our assessment process, coming up with ideas (I’m stoked to have two students working on CAP ideas that came out of my earlier suggestion), and reviewing each and every of the 45 proposals we recieved, it has been exciting to get so many projects accepted.

I think that by the end of the year, we are going to have some great new functionality available in Sahana. Even more, I hope we’ll attract more open source developers to our ever growing community!

I’ve just uploaded the presentation I gave on Sahana at the Sahana 2009 Conference in Colombo, Sri Lanka on the 25th of March, 2009. I’ll put a link up to the associated paper soon as well.

Here’s another CAP idea I wanted to get out before I read a document I’ve been sent that may cover the same topic (just to make sure I don’t potentially draw on someone else’s idea). This concept came to me, again, last year whilst I was working on the CAENZ Public Alerting research report last year (I’m still waiting for this to be publicly released so I can link to it). My recent post proposing a browser plugin for CAP alerts is part of this bigger picture I am outlining today.

The background for it came from the realisation that there are a significant number of organisations in New Zealand that are responsible for the publication of alerts – whether to a secure group, or the general public. For example, there are 16 CDEMG Groups, 70 odd local authorities, GeoNet, MetService, Police and those responsible for infrastructure such as roads, and the Centre for Critical Infrastructure Protection.

Each of these agencies would need some means of hosting a CAP server, and incorporating some means of resilience into their CAP server(s). Given that there are potentially such a large number of CAP servers required, there are some aspects that could provide a strong and robust CAP network without seeing a proliferation of potentially fragile CAP servers. This is all built on the concept of a secure peer-to-peer network of CAP servers.

Federation
It should be possible to federate a group of CAP servers into a cluster. If we take a CDEM Group as an example, the group members may elect to deploy say 4 or 5 CAP servers to create a peer-to-peer network providing CAP alert hosting for the CDEM Group. Any authorised CAP message posted to one of the federated CAP servers would automatically distributed the CAP message to the other CAP servers in the federation. In this manner, the CAP message is instantly distributed and made available to other servers in the federation.

Peer-to-peer
I believe that the more robust approach to developing a CAP network is to base it upon peer-to-peer network technology, although tweaked to provide a secure means of publishing messages to the network These servers could of course be deployed any way to provide maximum resilience, and may be located close to major New Zealand Internet backbones, and quite possibly well outside of their geographic region. This has two potential benefits for resilience. Firstly, the message is available from multiple servers, so that the load (particularly for publicly accessible CAP servers) can be distributed across the multiple servers automatically. Secondly, should any particular server fail, the messages will still automatically be provided from the other CAP servers in the federation.

One example means by which this could be deployed is the following.

Provide a national CAP server network of federated CAP servers at key points – a nationally managed set of strategically located CAP servers. For example, Government internal CAP servers would be most likely located on the Government Shared Network (GSN) or whatever comes out of the recent restructure of this service. Public servers may be spread around both by geography and ISP (e.g. key ISPs may host a CAP server for their customers). In all circumstances these would fallback to other CAP servers in the federation in case of their failure.

Naturally, the open approach applied to peer-to-peer file sharing is not appropriate for a trusted network CAP service. To create a more secure network, something like a two-tier approach may be necessary.

CAP Publishing Servers
Private CAP publishing servers may be utilised to act as the publishing gateway to the public read-only peer-to-peer network provided by the CAP Read-only servers. Authentication, encryption and/or digital signing should be used as the basis to authorise the publication of a CAP message via the publishing server. The publishing server is responsible for verifying the digitally signed CAP alert, as well as the authentication details to verify the user is authorised to post the alert. Once authorised, the CAP publishing server publishes the alert to the road-only servers. This is the only channel to publishing CAP alerts to the network. Some form of CAP writing software (or service) may be useful for creating CAP messages and then publishing them to the servers. One protocol that may be useful for publishing is Atom as suggested by this IBM article.

CAP Read-only Servers
These are the user-facing servers that provide CAP messages to their end users. Only the CAP publishing servers are authorised to publish CAP messages to the peer-to-peer network for dissemination.

Naturally, this concept is part of a larger plan to build a CAP framework, and the circle would be able to be partly completed by designing web browser plugins that are capable of connecting to the peer-to-peer CAP read-only servers.

Widespread deployment of CAP browser plugins may mean that traditional servers may not be capable of supporting tens or hundreds of thousands of CAP clients regularly checking for new alerts. A peer-to-peer approach will probably provide the most scaleable and robust approach to disseminating CAP alerts via the Internet.