In the immediate aftermath of the Kaikoura earthquake a well practiced response went into effect. Within a few days information about the event increased exponentially as the various agencies began reporting. The tide of information was overwhelming. Organisation such as Environment Canterbury began requesting GIS support to help make the relevant information visible to people who could use it. I was lucky enough to be selected to go down and help out at the Environment Canterbury offices. Here is the process as I experienced it.

 Step 1: First responders know what to do, it’s everyone else to worry about

In the immediate aftermath of the quake first responders were quick to do what they train for. It’s a well practiced routine, constantly being improved upon. As days turn to weeks the information they collect becomes overwhelming, people move, status’ change and the entire picture of the emergency rapidly evolves. It’s the later part of the emergency going into recovery which is less well practiced.

Step 2: The world’s most epic spreadsheet

As the well trained first responders complete their various jobs they inevitably begin reporting. Fixing the most obvious issues leaves enormous amount of information about the event and situation. In the aftermath of the initial response there will be hand annotated maps everywhere. Hand written notes about who needs what and someone has probably started making the world’s most epic spreadsheet. And underpinning all of this will be location. Where problems exist will either be recorded by address or drawn onto a map. This became my particular problem to deal with as best I could. It was such a common task that we even had an emoji to describe it

We termed it zombie apocalipse by excessive spreadsheeting. During the event we used www.slack.com as a means of quick communication. If you’re in the New Emergency Channel then feel free to use our emoji by typing :zombie_apocalypse: I spent a considerable amount of time geocoding from spreadsheets using python, which I’ve written tutorials on here.

It took many hours to geocode the addresses into locations which could be used. During this time there was a lag on the real time maps. I couldn’t help but be reminded of the world war 2 war rooms. Because the objects were physically moved around there was an implicit understanding that the map was only as good as the information update. During the Kaikoura event I believe it was largely assumed that all information was up to date and real time which led to some of the unnecessary revisits as we processed data. The ideal scenario would be for surveys to upload directly to the map.

Step 3: Trying to get data on the map

Turning the incoming data into a usable intelligence product was critical. The only way to approach collating all of this information into a Common Operating Picture (COP) is by mapping it online. Because so many people from different agencies need to collaborate working inside a network has very limited use. We used AGOL (arcgis online) to host, share and manage access to intelligence.

It seemed to me that we were dealing primarily with two kinds of information. Routinely updated data such as road status and bulk data such as welfare that just needed processing.

Step 4: Targeted map apps

The team at ECAN used targeted apps as much as possible. With confidential data and licensing for some third party sources the more access can be controlled the better. People who care about roading dont need every welfare assessment. They divided up the core data requests and started building applications based on those requests. These maps and apps needed constant updating as new information came in. They were projected onto walls in the EOC, used to communicate across the local agencies and leveraged to report to national government.

App 1: The Road Status App

The first app I was introduced focused on updating travel conditions. A simple web app with clear traffic lighting symbology. It was kept it light and fast, as it might get a lot of traffic. It was hosted in the cloud for scalability rather than in house server infrastructure. Servers in cupboards in an earthquake don’t work well.

We actually helped put up online services for a department when their servers, which were in the cupboard, broke because someone crashed into the building.

There was another version of the road closure map with security to show landing sites for light aircraft and helicopters as well as especially licenced satellite imagery.

App 2: Political Boundaries App

In the face of a disaster political issues tend to get set aside in the immediate aftermath, they come back very quickly. Some of the issues which come up after the initial response are

• Areas of responsibility
• Jurisdiction
• Ownership of data
• Hosting of data

Areas normally maintained by a local authority might be cut off due to road conditions are either under a state of emergency or moved to another council’s jurisdiction.

App 3: Flight Path App

Live aerial photography of the problems are great. A map to specifically visualize flight paths and geotagged imagery was quite helpful. A hosted web map was used with local server infrastructure. The comms team would simply rename the new photos on the server without having to update the web app. The app was embedded into story maps for public consumption.

App 4: Inland Dam’s App

Visualizing the actual event causing the issues. Points with pictures associated worked well using ESRI feature attachments for data points which didn’t need to be constantly updated. Critical inland dams (the red ones) had static urls pointing at server locations so that they could be updated by the comms teams.

You can also access live earthquakes in real time in New Zealand through the GEONET consuming the latest events automagically from a .csv file hosted there. The US geo is another great source.

App 5: Building Assessment App

Even in a small township there will be hundreds of properties to be assessed after a natural disaster. Building inspectors will be flown in from all over the country. Collating that data into a single map is one of the most important jobs. Without a single source of the truth multiple inspections will be down on the same properties.

From what I understand the holy grail here is getting building assessments associated with actual buildings rather than addresses or parcels. This is a real challenge though. I was dealing with 9000+ building inspections at one point, all of which needed to be on a map now, while all the records are in excel with a creative variety of addressing standards including with every conceivable typo.

In the more recent flooding event in Edgecombe the data capture seems to have been much more uniform. Some of my colleagues used forced geopoint in Survey123 which restricts users to a list of known addresses when surveying the site. Also since the Kaikoura event MBIE have taken a role in developing standard forms across with two forms now available for welfare and building assessments.

App 6: Underground Infrastructure App and my final task

In the final day of my deployment the water network was being repaired but the pipe locations were not available. The IT infrastructure in Kaikoura was not in good shape so the guys zipped up the existing network information and sent it to me in Christchurch. We loaded it to AGOL and did some minor configuration work on the domains, changing the status to unknown, and letting contractors update the status of piping as they repaid segments.

Side notes

I was deployed in Christchurch for 11 days, of which I worked all 11 days, mostly doing 12 hour shifts.

It’s weird to be deployed to help with an emergency yet be in an area where everything is normal. I spoke with lots of emergency responders who were coming and going to Kaikoura yet we were a little bit removed from the chaos.

ECAN have an amazing building to work in. It was pretty cool being there on the weekend while no one else was around. Someone from the logistics team had organised for a local cafe to do catering for us. I was expecting MRE type rations but we actually got amazing cafe food everyday.

The staff of ECAN were great to work with, very competent with loads of experience dealing with emergencies. They put in place a really efficient technology stack that I’ve continued to use. Trello for organising tasks. Slack for quick easy communication.