When the map starts moving
For much of GIS history, a map could be out of date without anyone noticing for a while. A road changed, a subdivision appeared, a river shifted or a new building was added, and the database caught up later. Emergency mapping makes “nearly current” a much less comfortable phrase. When the ground has just moved, a river has left its channel or a road has disappeared under a landslide, yesterday's perfectly maintained layer may describe a world that no longer exists. The problem is no longer simply how accurately an organisation has mapped New Zealand, but how quickly it can recognise that New Zealand has changed and distribute a useful new picture.
That sounds like a technical problem, but the difficult parts are often organisational. Information has to arrive, be understood, checked, combined and published. Several agencies may hold different pieces of the same situation, while staff in an emergency coordination centre, field team or infrastructure company need answers to different questions. A live interface does not solve this by itself. It can simply display several incompatible uncertainties in a more attractive browser window.
By the 2010s and early 2020s New Zealand had most of the technical pieces needed for rapidly updated mapping: sensor networks, enterprise databases, web services, cloud-hosted platforms, APIs, smartphones, field forms, satellite imagery, aerial survey, LiDAR and UAVs. Chapters 34 to 41 followed those pieces separately. Major emergencies show what happens when they have to work together at speed. They also reveal the less fashionable part of the story, because earthquakes and storms damage the communications and electricity that connected GIS increasingly assumes will be available.
GeoNet normalises the live map
GeoNet provided New Zealand with a long-running example of geography that changes because the physical event has just happened. The project was established in 2001 to build and operate a modern geological hazard monitoring system. A 2004 strategic review records a July 2001 launch, while the current institutional history describes the March 2001 funding decision and the early programme of upgrading earthquake monitoring, communications, data management, volcano surveillance, landslide response and earth-deformation monitoring. The national system was built around instruments, communications, automated processing, data infrastructure and staff who could interpret what those systems reported.
An earthquake did not have to wait for a survey team to reach the site before it acquired a coordinate and appeared in a national information system. Instrument readings could be transmitted, processed and disseminated rapidly enough for the event itself to become a changing digital object. Over time the public also became accustomed to seeing recent earthquakes, shaking information and other hazard data on maps soon after an event. The expectation that a map might be updated because something happened minutes earlier became ordinary.
GeoNet also demonstrates why the word real-time needs discipline. Different parts of the system operate at different speeds. Instrument streams can be continuous or near-continuous, automated locations can be calculated rapidly, and scientific review may refine an event later. A map that updates quickly can still contain provisional information. Shorter latency allowed people outside the specialist monitoring community to use the observations during events.
A common picture is harder
A sensor map answers a comparatively bounded question. Emergency response rarely does. A coordination centre may need to know where an earthquake or flood occurred, which roads remain open, which communities are isolated, where welfare centres are operating, what buildings have been assessed, which electricity assets are damaged, where imagery has been captured and what information is still unverified. Those layers may come from different organisations, use different update cycles and carry different access restrictions.
The phrase common operating picture describes the attempt to bring enough of that information together to support a shared understanding of the event. It does not necessarily mean one map, one screen or one national system. A regional emergency management group may need a different operating picture from a national coordination centre. A utility may need network status that cannot be published publicly, while a public map needs a simplified view that people can understand safely. The common part is therefore as much about agreed sources, responsibilities and current status as it is about software.
The enterprise and service histories from the previous chapters become practical in this operational setting. Authoritative data has to be discoverable. Services need to be reachable. Identities and permissions need to work. Someone has to know whether the road-status layer is current, whether the building-assessment layer is preliminary and who is responsible for correcting an error. In calm conditions these can look like governance details. During an emergency they decide whether several agencies are looking at approximately the same situation or several different versions of it.
Canterbury exposes the gaps
The Canterbury earthquake sequence beginning in September 2010 exposed the difficulty of sharing spatial information across a large recovery effort. Later accounts describe a landscape of many agencies, contractors and datasets that had not been designed in advance to function as one information environment. The response and recovery generated urgent demand for property information, zoning, infrastructure status, aerial imagery, geotechnical information, cadastral data and many other spatial layers. The need was immediate, but the institutional machinery for supplying it consistently had to be assembled while the work was already under way.
Practitioners exchanged earthquake mapping information within days of the event. On 8 September 2010 , GIS business leader at , circulated a crowd-sourced Google map of Christchurch and asked whether it was “a bit of Neogeography”. at replied that live crowd-sourced information had already been added to an earthquake Common Operating Picture alongside data being refreshed from authoritative sources. of Wellington consultancy pointed the list towards another Christchurch earthquake map. Official GIS, commercial systems and public mapping were already being combined within days of the 4 September earthquake.
The practitioner networks were pulled into that work as well. On 26 February 2011, four days after the February earthquake, 's used GISList to seek people with Esri skills who might be able to work eight-hour mapping shifts in the Christchurch emergency operations centre at the Art Gallery. The request went out before the staffing requirement had even been formally confirmed. In the following weeks the same list moved from finding people to finding usable data. pressed for reusable map services rather than links to finished web maps; pointed users towards Esri REST, WFS and WMS services; Beca's reported work by to establish WMS and WFS services; and practitioners circulated aerial imagery and demolition data. The thread captures an untidy but important part of emergency GIS: formal systems were essential, but so were people who knew whom to ask and how to expose the data quickly enough for somebody else to use it.
One of the most visible early products was Landcheck. It answered a narrow public question about land zoning after the 2011 Christchurch earthquake. CERA's later record says was asked to build the site in four days, did so at no cost, and Landcheck launched on 23 June 2011. By 16 September it had exceeded ten million hits. The numbers reflect public demand rather than geospatial sophistication. A simple property lookup was valuable because it connected an authoritative spatial classification to the question thousands of people actually had. In an emergency, the elegant GIS architecture sits behind the scene; what the public remembers is whether the address box gives them an answer.
Landcheck served public enquiries within the wider Canterbury recovery programme. The 2016 CERA SDI whitepaper records an initial LINZ-funded cloud-hosted GIS and a multi-agency GIS roundtable established in 2011 to guide the emerging infrastructure. At maturity the SDI delivered more than 4,000 datasets through 80 secure and public data services, including 10 imagery services, from 14 public and private organisations. The architecture used role-based security, catalogued services, web viewers and standards including REST, WMS, WFS and KML. The whitepaper described relationships, trust and governance as more difficult to establish than the servers.
The Government formally announced the Canterbury Spatial Data Infrastructure programme in November 2012. It was intended to remove barriers to information sharing between agencies, use web technology more effectively and support three-dimensional visualisation. In July 2013 the Forward Works Spatial Coordination project added a practical planning tool that brought recovery agencies’ works and utilities into one integrated view with locations, timeframes and other attributes. Its immediate purpose was operational: coordinate construction, avoid scheduling clashes and reduce repeated excavation of the same streets.
and documented the CERA spatial data infrastructure in a March 2016 business whitepaper. Ferriss was CERA’s Data and GIS Manager and had overseen the infrastructure’s continuing development and support for the wider stakeholder community. Their account explains the work of connecting organisations, establishing access and maintaining services during recovery. It identifies the management and information-sharing work behind the datasets and viewers used across Canterbury.
Canterbury Common Operating Picture, 2010
During the September 2010 Canterbury earthquake response, reported live crowd-sourced information being added to a Common Operating Picture alongside refreshed authoritative data. Web services, official GIS and public contributions supplied a shared operational view.
Sources · 1
- GISList crowd-sourced Christchurch mapping thread
One event, several systems
SCIRT's GIS Viewer was another system in the same recovery environment, serving infrastructure-rebuild operations rather than public land-zoning enquiries or the whole CERA data-sharing programme. The SCIRT learning record describes more than 600 layers, more than 1,500 users, 32 map configurations and information from more than 30 sources. The viewer was updated more than 2,700 times during the programme. The screen a user sees is the end of a long chain of updates, permissions, source changes and decisions about what belongs in each configuration.
Landcheck, the CERA SDI and the SCIRT viewer served different parts of the recovery. One system answered a public question at enormous scale. Another created secure and public infrastructure for sharing information between organisations. A third supported engineers and rebuild teams with a dense operational view of infrastructure work. They overlapped in data and context, but they had different audiences, governance and update requirements.
The Canterbury experience also shifted attention from map production towards information availability. A beautifully designed map was little help if the required layer could not be found, if two agencies had incompatible copies or if access approval took longer than the operational decision. Recovery GIS increasingly treated data services, metadata, custodianship and permissions as part of response infrastructure. It was a practical version of the spatial-data-infrastructure ideas discussed earlier in the book, assembled because the recovery could not afford to wait for a theoretically perfect national implementation.
Imagery after the ground changes
Emergencies also change the value of imagery. Under normal conditions a council or national agency can plan an aerial survey, process it carefully and replace an older image set on an orderly cycle. After a major event, the older image may be precisely registered and completely misleading. A road visible in the database may be buried. A coastline may have moved. A bridge may no longer exist. The question becomes how quickly a new observation can be acquired, processed and made usable.
Rapid imagery still involved acquisition, processing and delivery time. Aerial photographs still need aircraft, weather, acquisition, photogrammetric processing and distribution. LiDAR needs its own flight, processing and quality controls. Satellite imagery depends on overpass timing, cloud and the characteristics of the sensor. UAV surveys have local advantages but still need safe access and processing. Acquisition systems could be mobilised after an event and feed web services and operational workflows during response or recovery.
Canterbury demonstrated the long-term value of event-driven capture because pre- and post-earthquake datasets could be compared as the region changed. The July 2003 Christchurch LiDAR described in Chapter 37 became unexpectedly valuable as a pre-earthquake baseline years after it had been commissioned for ordinary council purposes. Disaster mapping often gives older spatial data a second life. A dataset collected for flood modelling, engineering or routine imagery can become the reference against which sudden physical change is measured.
Kaikōura moves the map again
The 14 November 2016 Kaikōura earthquake caused widespread fault rupture, landslides, coastal uplift and transport disruption across the upper South Island. LINZ coordinated post-event mapping with transport, science, regional and local-government partners. The 2018 Mapping New Zealand programme included aerial imagery, airborne LiDAR, offshore hydrographic LiDAR, building outlines and resurvey work.
These inputs covered different parts of the response. Aerial imagery recorded surface conditions; airborne LiDAR measured terrain; hydrographic LiDAR and bathymetric work extended mapping into coastal and marine areas; geodetic resurvey measured deformation in the reference frame.
Post-event survey also fed into the January 2018 NZGD2000 update. Chapter 19 covers the coordinate changes and the transformation grids supplied to GIS custodians.
Checking rapid updates
Speed creates its own information problem. During an emergency, reports arrive from field teams, call centres, agencies and the public with different degrees of precision. A road may be reported blocked and reopened before the first status is removed from a dashboard. Two people may report the same landslide under different place names. A building assessment may be provisional while an operational user reads it as definitive because the symbol looks reassuringly official.
GIS can make uncertain information look cleaner than it is. A point has exact coordinates even when the original report was approximate. A coloured polygon can imply a sharp boundary where the real condition is gradual or poorly observed. A timestamp helps, but only if users can see it and understand what was updated. Operational mapping therefore requires triage, status fields, source attribution, update responsibility and enough restraint not to publish every incoming observation as fact.
This is one reason common operating pictures are organisational products. Someone has to decide what goes in, whose data is authoritative enough for the purpose, what can be shared and how uncertainty is represented. Rapid dashboard updates depended on the collection, checking and distribution of observations. Real-time mapping is useful only when people can tell the difference between current, stale, confirmed and provisional information.
The network can fail too
Connected GIS creates a challenge during disasters. Cloud platforms, live services and mobile applications depend on electricity, telecommunications and authentication systems that may also be affected. During Cyclone Gabrielle, power and communications failures forced teams to use offline desktop tools and printed maps. Emergency GIS plans need to cover those outages as well as connected operations.
Offline mapping had already developed through field GIS, cached basemaps and synchronisation workflows described in Chapter 34. In an emergency the requirement becomes less optional. A field team may need the last available operational dataset on a device before entering an area with poor coverage. A coordination centre may need exported products that can be distributed without relying on a live dashboard. Printed maps remain useful when several people need the same stable briefing object, when batteries are limited or when a network connection cannot be assumed.
Paper maps, desktop tools, web services and cloud platforms continued to be used together. By 2023 New Zealand could operate sophisticated cloud GIS while still finding practical value in an exported PDF or a sheet of paper. Paper survived because emergency operating environments can be hostile to systems that depend on continuous connectivity.
Cyclone Gabrielle
Cyclone Gabrielle reached New Zealand on Sunday 12 February 2023. Two days later a national State of Emergency was declared, remaining in place until 14 March. Severe effects were spread across Hawke's Bay, Tairāwhiti, Northland, Auckland, Waikato, Bay of Plenty and Tararua. The geographic scale meant no single regional team had all the staff, systems or information required. By this point, however, New Zealand had a mature community of emergency GIS practitioners and a service environment that allowed people and data to be brought together quickly.
The multi-agency account Cyclone Gabrielle: The Geospatial Story records GEMA helping NEMA coordinate staff who worked remotely and deployed into affected regions. Once the national emergency had been declared, NEMA's geospatial team scaled with surge staff from Waka Kotahi, Canterbury CDEM, , Fiji Response, , MPI, DOC, GNS, LINZ, EQC, Taranaki CDEM and Herenga a Nuku. The national geospatial sub-function produced more than 100 products, including dashboards, web applications and datasets. The products served different operational teams and information requirements.
Different audiences required different products. National coordination needed a broad operating picture. Regional teams needed detailed road, welfare, flood and infrastructure information. Field teams needed forms and observations that could be collected under difficult conditions. Agencies such as Police, Fire and Emergency, transport organisations and utilities brought their own operational data. The job of the geospatial function was partly technical and partly diplomatic: find the source, understand what it means, get permission to use it, make it fit the operational question and keep it updated.
NZTA during Cyclone Gabrielle
During Cyclone Gabrielle in February 2023, NZTA used its ArcGIS Enterprise on Kubernetes environment for field survey and situational awareness.
The event response drew on the shared-service platform described in Chapter 40.
The NZTA and Esri case study records this operational use. Its benefit and performance claims remain attributed to the customer case.
A geospatial surge
Tairāwhiti developed a regional approach. The StoryMap records that Tairāwhiti Emergency Management and 's GIS team deployed GIS tools and applications to support 3,600 welfare assessments, 310 building assessments and monitoring of more than 90 active road closures. Those are not abstract layers. Each number represents a stream of observations that had to be captured, located, stored, summarised and made available to people coordinating work across the region.
's GIS contribution shows a different mix of tasks. Its staff supported situational-awareness viewing, sourced and mapped road-impact intelligence, mapped significant incidents, supported civil-defence-centre and public-information dashboards, supported the flood room, procured and processed orthophotography of maximum flood extents, handled rapid oblique imagery, assisted with landslide-risk modelling and facilitated sharing of geospatial data. The list is long because the event produced many separate information problems. No single application could solve all of them.
Fire and Emergency New Zealand developed a web-based common operating picture using ArcGIS Online. The operational account says it combined Fire and Emergency assessment information with data contributed by other public and private organisations, including power information, Police missing-person information and Hawke's Bay road-network outages. Connected spatial services had to operate under disaster-response conditions. The platform could assemble several maintained sources quickly, but staff still had to decide which layers were appropriate and how to present them to different users.
NZTA’s newer enterprise platform was used during the Cyclone Gabrielle response in February 2023. The NZTA and Esri case describes centralised field survey and situational-awareness workflows supported by ArcGIS Enterprise on Kubernetes. ’s platform work and ’s contribution from Eagle belong to the preparation behind that operational use. The response brought field observations, shared transport information and applications together when damage and access conditions were changing rapidly.
The response capability also depended on people and networks assembled before an event. Jeremy Gulson’s SCIRT role placed geospatial expertise inside the Canterbury rebuild, while Derek Phyn’s NZGIS4EM work created a national practitioner network focused on emergency-management readiness. Those records show disaster GIS developing through sustained organisational and community work between major events.
Field capture becomes operational data
KiwiRail used field assessments and photographs to record damage on the Palmerston North to Gisborne line. Cyclone Gabrielle damaged more than 300 sites on the Hawke's Bay rail network described in the StoryMap, including severe damage in the Esk Valley. KiwiRail deployed Survey123 to four teams of consultants to assess and record damage, with photographs captured from the air and on the ground. Incoming information could then be visualised through ArcGIS Online applications as it was captured.
The workflow is a direct descendant of the mobile GIS developments described earlier in the book, but the operational context is different. The field form replaced paper while also controlling required fields, identifiers, location and later synchronisation. It was feeding a changing shared picture of infrastructure damage while decisions about access, repair and priorities were being made. Structured fields and photographs helped turn individual observations into records that could be compared and mapped across a long transport corridor.
The same principle appears in welfare and building assessments. A location-enabled form creates a record that can immediately join other geographic information. A dashboard can summarise progress without someone retyping every field sheet into a separate system. That speed is valuable, but it also makes data design more important. Poor categories, missing timestamps or ambiguous status values can propagate just as quickly as good information.
Emergency mapping products
The national geospatial sub-function produced more than 100 dashboards, web applications and datasets for different response tasks. These products addressed many separate information needs. Road access, welfare, damage, power, communications, imagery, landslides, field activity and public information can each require different combinations of source data, audience, security and update frequency. A single all-purpose map would become unreadable long before it became useful.
The scale also explains the need for surge staffing. Building and maintaining many products during an event requires more than cartography. Analysts need to clean and join data. Platform administrators manage permissions and hosted services. Imagery staff process new acquisitions. Liaison staff locate datasets and understand what operational teams are asking for. Someone has to maintain the product after the exciting first publication, which is usually when the less glamorous work begins.
The Gabrielle response therefore resembles the enterprise and application histories from Chapters 35 and 40, but compressed into emergency time. Systems that might normally evolve over months had to be configured or adapted in days. Existing services, templates, user communities and professional relationships reduced that burden. The geospatial response could surge because much of the technical and institutional groundwork already existed before the cyclone arrived.
Paper still works
Teams continued to use static maps and reports alongside interactive tools. Research for this project records that power and communications failures during Gabrielle made offline desktop work and printed maps essential in some workflows. A printed map has obvious limitations: it cannot update itself, cannot be queried and begins ageing as soon as the printer stops. Those weaknesses become acceptable when its main advantage is that it still works with no network, no login and no battery.
Static outputs are also useful for coordination because they freeze a known state. A live dashboard can change while a meeting is discussing it. An exported or printed map can be marked, handed around and retained as a record of what was believed at a particular time. Paper therefore remains one component in a resilient information system that recognises different operational conditions.
The historical progression is therefore less tidy than a technology diagram. New Zealand emergency mapping moved from manually assembled products towards sensor feeds, services, dashboards and mobile forms, but the old formats remained available when the new infrastructure lost one of its assumptions. By 2023, response teams selected the tools that could keep geographic information moving under the conditions they faced.
Update intervals
By the end of 2025 real-time mapping had become an ordinary phrase across hazard monitoring, emergency management, transport and other operational GIS. In practice, 'real time' usually meant information refreshed quickly enough for operational use, not zero delay. Sensors have sampling and processing delays. Human reports take time to collect and verify. Aerial imagery may be hours or days old by the time it appears in a service. Road status can change faster than a database can be updated. Even a dashboard that refreshes every few seconds may be displaying one source that is much older than the others.
Operational value depended on whether information was current enough for the decision being made. GeoNet's automated event information may need minute-scale latency. A road-closure layer may be operationally useful if it is maintained carefully across the day. Post-event LiDAR can be extremely valuable even when it arrives days later because it measures change that no field team could map comprehensively. A recovery dataset may remain valuable for years after the emergency has ended.
Operational mapping depended on managing delays between observation, checking and publication. New Zealand built sensor networks, spatial-data infrastructures, services, field systems and professional communities that shortened the distance between something happening and a usable geographic record reaching the people who needed it. Canterbury showed the cost of incompatible information environments. Kaikōura showed that the landscape and reference framework themselves could change. During Cyclone Gabrielle, agencies shared geographic information while working with disrupted networks and changing reports from the field.
The next stage reduces the manual work inside those chains. Scripts, ETL tools, models, scheduled processes and later machine-learning workflows increasingly automate repetitive GIS operations. The speed problem becomes a workflow problem: deciding which steps can be repeated safely, how errors are detected and who maintains the process after its original author has moved on. Chapter 43 follows that longer history of automation, from small pieces of code that saved an analyst an afternoon to pipelines that keep whole spatial information systems moving.
Resilience as a geospatial capability programme
LINZ’s Brown Bag Resilience Series, documented from February 2019 to July 2021, brought hazard science, mapping, risk modelling and policy into a recurring public forum. Sessions covered iwi and hapū management plans, natural-hazard readiness, Kaikōura transport resilience, national flood-risk approaches, community climate adaptation, Project AF8, insurance, the Resilience to Nature’s Challenges programme, wine-industry resilience, RiskScape and property insurance under climate change. Rob Deakin also presented LINZ’s own resilience and climate-change work programme, including improvements to high-value geospatial datasets and support to agencies during emergency response and recovery.
The capability material connects this programme with the practitioner pipeline. Kasey Oomen’s LINZ graduate profile describes GIS study leading into resilience work and exposure to the Coordinated Incident Management System. The LINZ networks directory also includes Geospatial Emergency Management Aotearoa, while later Ngā Poutama sessions used freshwater, climate, coastal and earthquake datasets for community planning. Together these sources show resilience mapping becoming a shared practice spanning technical specialists, emergency managers, researchers and community users.
The LINZ Brown Bag Resilience Series records presentations by Jacob Pastor Paz, Richard Woods, Rob Deakin, Nick Cradock-Henry, Ilan Noy, Caroline Orchiston, Mat Darling, David Middleton, Richard Smith, Ainslie Ryder, Janet Stephenson, Sophie Bond, Gradon Diprose, Andrew Jackson, David Johnston, Doug Mason, Daniel Headifen, Adam Dennett, Wendy Saunders, Lucy Kaiser. These names are retained as event relationships unless wider GIS evidence supports a fuller person profile.
Chapter source notes
1. GeoNet’s institutional history and the 2004 Strategic Review support establishment in 2001 and a July 2001 programme launch within a ten-year plan for a modern national geological-hazard monitoring system. The chapter uses GeoNet to establish continuous observation and rapid geospatial dissemination. It does not describe GeoNet itself as a conventional GIS platform or use the current interface as a 2001 visual.
2. Ferriss and Erasmuson’s 2016 CERA Spatial Data Infrastructure whitepaper is the principal Canterbury infrastructure source. It records the LINZ-funded cloud GIS, the 2011 GIS roundtable, more than 4,000 datasets, 80 secure and public services including ten imagery services, and participation by fourteen public and private organisations. Landcheck, the CERA SDI and the SCIRT GIS Viewer remain separate systems with different purposes.
3. The SCIRT Learning Legacy supports the operational GIS Viewer scale: more than 600 layers, more than 1,500 users, 32 configurations, more than 30 source systems and more than 2,700 updates. The figures are programme records and do not imply every user saw every layer or that the Viewer was itself the CERA SDI.
4. De Raadt, Blick and Hodge’s 2018 Kaikōura response poster supports post-event aerial imagery, LiDAR, offshore hydrographic LiDAR, building outlines and resurvey work following the 14 November 2016 earthquake. Exact capture dates are not assigned where the source does not establish them. Chapter 19 retains the detailed coordinate-update history.
5. “Cyclone Gabrielle: The Geospatial Story” is the principal late-period operational source. It supports NEMA incident-data sharing, GEMA coordination, surge staffing drawn from multiple organisations, more than 100 national geospatial products, regional and agency common operating pictures, field workflows and assessment figures. The phrase is “more than 100 products”, not more than 100 maps. Sensitive operational information is not reproduced.
6. Offline desktop work and printed or exported mapping are retained as resilience findings where communications and power failed. The cited accounts document the continuing operational use of printed maps.
The practitioner account records live crowd-sourced information alongside refreshed authoritative information in a 2010 Common Operating Picture. It does not establish sole ownership by one organisation.
The NZTA and Esri case study records the 2023 field-survey and situational-awareness use. Benefit and performance descriptions are attributed to the customer case rather than treated as independent measurements.