1 Introduction

RiskScape is a modelling software for multi-hazard risk analysis. In this context, ‘multi-hazard risk’ refers to a system that analyses the occurrence and frequency of impacts from multiple hazard types and their associated phenomena occurring independently, in sequence or simultaneously (Kappes et al. 2012). Disaster risk management is moving from hazard to risk centric approaches with increasing importance on analysing present and future risk across multiple hazard and socio-economic domains (Cremen et al. 2022). Effective implementation of risk management interventions requires researchers and practitioners to have accessible analytical tools that quantify risk from the evolving and uncertain complex interactions between hazards and socio-economic elements (Fraser et al. 2016). RiskScape aims to meet the challenge of implementing multi-hazard risk analysis methodologies within modelling software (Delmonaco et al. 2006; Schmidt et al. 2011; Kappes et al. 2012; Komendantova et al. 2014). Achieving the aim expedites modelling software as a tool to inform social and economic hazard risk research and disaster risk management in any global location (United Nations International Strategy for Disaster Reduction, 2015). To this end, RiskScape has progressed a flexible modelling engine for multi-hazard risk analysis.

A RiskScape prototype desktop software was released in 2012. The software operated system prescribed model workflows for single-hazard risk quantification across multiple hazard types (Schmidt et al. 2011). In 2015, the World Bank Global Facility for Disaster Reduction and Recovery (GFDRR) reviewed open-source and open access natural hazard risk analysis software. The review concluded that RiskScape prototype’s graphical user interface (GUI) and builder tools were “very easy to understand and a pleasure to use” but, software features were ‘quite simplistic’ and methods for vulnerability functions and calculating risk metrics ‘lacked transparency’ (Global Facility for Disaster Reduction and Recovery 2015). Standardised model workflows in the prototype software offered limited support for modeller-customised workflows and functions for different multi-hazard risk analysis contexts. In particular, risk quantification from single-hazards (e.g. single or multiple hazard metric intensities and their variability at a location) and their interactions and interrelations with multiple other hazards (e.g. tsunami inundation following earthquake damage, extreme rainfall following wind damage etc.) were not supported by standardised model workflows. These issues led to the RiskScape prototype desktop software application being discontinued, with a renewed design and development focus to progress a platform-independent, transparent and user configurable modelling software for multi-hazard risk analysis.

RiskScape software implements a model design centred on an established conceptual framework for risk quantification:

$$R = f_{C} \left( {H_{i} , E,V_{i} } \right)$$
(1)

where risk (R) is a function (\({f}_{C}\)) of the consequences from a hazard event (H) impacting an exposure (E) (i.e. element-at-risk). Consequences are determined from the exposure vulnerability (V) to an impact type and magnitude in response to either single or multiple hazard events (i). This framework is implemented in software that support model workflows for hazard risk analysis (e.g. Delmonaco et al. 2006; Schneider and Schauer, 2006; Schmidt et al. 2011; Cardona et al. 2012; Silva et al. 2014; Rossi et al. 2016; Aznar-Siguan and Bresch, 2019). Risk quantification principles are often similar between modelling software however, implementation of model workflows and functions may differ. This is particularly relevant for risk quantification of (1) multiple types of single-hazard events as independent scenarios; or (2) spatio-temporal interactions between multiple hazard events occurring at a location. While acknowledging the principles and implementation approaches of other modelling software, several functional and non-functional requirements focus RiskScape software development for multi-hazard risk analysis (Table 1).

Table 1 Summary of RiskScape software development requirements
Full size table

Model workflows and functions for multi-hazard risk analysis are critical functional requirements for RiskScape software. Model workflows must be modular and adaptable to support modeller configuration of workflow components. Several modelling software practised for single or multi-hazard risk quantification (e.g. HAZUS (Schneider and Schauer, 2006); CAPRA (Cardona et al. 2012); OpenQuake (Silva et al. 2014)) operate using standard model workflows or ‘calculators’ based on prescribed data classifications or standards. RiskScape should operate model input data as independent entities enabling risk quantification for any hazard and exposure type combination, including spatio-temporal interactions. The challenge of multi-hazard risk analysis methodology implementation in modelling software is significant for researchers and practitioners, tasked with quantifying risk from complex hazard and exposure relationships, evolving under social, economic, and environmental changes (Komendantova et al. 2014).

This paper presents the architecture and features of RiskScape software, hereafter referred to as ‘RiskScape’. RiskScape is open-source software with a flexible modelling engine for multi-hazard risk analysis. RiskScape is used in several previous modelling studies (e.g. Craig et al. 2021; Paulik et al. 2021; Williams et al. 2021; Woods et al. 2021); however, this paper is its first formal description. The RiskScape engine, system architecture and features are presented, with a focus on ‘model pipelines’ for risk quantification. Model pipeline components and functions are described in the context of deterministic and probabilistic-based risk quantification, with emphasis on applications for multi-hazard risk analysis.

2 RiskScape software and implementation

2.1 Software

RiskScape is implemented using open-source Java programming language. Java is a platform-independent object-oriented programming language operated by numerous operating system software. Java’s parallel processing meets the high computational demands for risk quantification at different spatial scales. Parallel processing also enables the consistent application of geospatial and statistical data processing operations in risk model workflows. Java supports geospatial data processing operations from open-source GeoTools (LGPL) (GeoTools, 2021) and JTS Java libraries with open geospatial consortium (OGC) standard compliant file and database formats, webservices, coordinate reference systems, geospatial predicates and transformations.

RiskScape architecture centres on a core data processing ‘engine’ (Fig. 1). The RiskScape engine implements the conceptual framework in Eq. 1 by supporting plugin functions that enable customised risk quantification workflows as a ‘model pipeline’. A scientific code library of default functions (i.e. ‘riskscape-defaults’) performs geospatial, statistical, or other data handling operations in a model pipeline. Default functions are implemented using Java methods from GeoTools, JTS, Java Maths (i.e. ‘java.lang.Maths’), and Apache Common Maths code libraries. These libraries are customisable, enabling default functions to be extended and implemented as independent objects in a model pipeline.

Fig. 1
figure 1

A simplified conceptual diagram of the core RiskScape engine components and plugins

Full size image

The RiskScape engine supports additional programming languages as plugins. The Python programming language is supported by RiskScape engine default plugins. Python is an interpreted, high-level and general-purpose programming language supporting libraries (e.g. NumPy, SciPy) with extensive collections of mathematical functions. These features support mathematical functions or relations that represent vulnerability functions (see Sect. 2.2.4) executed in model pipelines. Here, vulnerability functions are engine independent and executed in model pipelines using modeller-defined data classifications and logical expressions. This flexibility enables modeller-defined logic, conditions and relations for vulnerability function application to quantify exposure and impacts from single-hazard or multi-hazard events. The RiskScape engine supports two default Python plugins for vulnerability function implementation. These include CPython, the C programming language standard Python implementation and Jython, a simple stand-alone Python version operating within the Java environment.

The RiskScape engine currently operates on a command line interface (CLI), implemented using the open-source Picocli Java library. The RiskScape engine CLI supports model pipeline configuration and execution. A RiskScape CLI Wizard plugin simplifies this process, while help documentation libraries (i.e. riskscape-i18n) support CLI operation. The plain-text help documentation can be modified to translate the RiskScape CLI for international languages or operate in different modelling domains. RiskScape use for research and development purposes is licenced with the Affero General Public License (AGPL) (GNU Operating System, 2007). The software is available at https://riskscape.org.nz/ for download and use on Windows, Linux and Mac operating systems. Here, modellers can track feature development, view worked examples and access scientific code documentation. A glossary of current RiskScape terminology is also provided here as supplementary information.

2.2 Model pipelines

The RiskScape engine executes model pipelines based on a domain-specific expression language that connects modeller-defined steps and step-functions (Fig. 2). Data selection steps import (i.e. ‘input data’) and export (i.e. ‘output data’) to and from model pipelines. Steps where functions perform geometric transformations or numerical calculations based on input and output data selections include ‘geoprocessing’, ‘spatial sampling’, ‘consequence analysis’ and ‘risk analysis’. The engine passes model input data between pipeline steps as ‘tuples’. Each tuple represents a single data record or attribute list, such as an exposed object, e.g. building, road segment, and farm boundary etc. The tuple data structure is represented as a ‘struct’, a composite data type defining a grouped set of variables. Pipeline step-functions transform tuples based on math, geometry, logical and string operations that apply to the struct. Modified tuples are passed between each defined pipeline step.

Fig. 2
figure 2

A RiskScape model pipeline schematic representation of pipeline steps and functions

Full size image

Several configuration files support model pipeline step and data management. Text-based content files (.ini) provide a structure and syntax for the RiskScape engine to determine key-value pairs for properties and sections that serve multiple purposes organising and executing model pipelines. ‘Model’ files contain model pipeline data selection and step-functions, while ‘project’ files define model input data files or directories, and data configuration files. ‘Data bookmark’ files store modeller-defined file paths and spatial data transformations that are set to locate and prepare input data for model ingestion. ‘Data classification’ files store attribute information representing model input and output data structs. Data classifications are modeller-defined and used in logical expressions or conditional statements to pair vulnerability functions with exposed objects. These associations can also be defined from other external files supported as engine plugins, e.g. the vulnerability function arguments and return type metadata defined in a Python file.

2.2.1 Model input data

Model input data is the core component for risk quantification presented in Eq. 1. Required input data include 1) the ‘hazard’ event type, metric intensity, or temporal occurrence 2) the ‘exposure’ of objects (herein termed as ‘object-exposures’), and 3) vulnerability functions (see Sect. 2.2.4) that determine object-exposure impacts to hazard type and metric intensities. Data ‘layers’ represent hazard and exposure geometry and attribute information in common GIS raster and vector data file formats (Table 2). These layers form the minimum input data requirements for RiskScape to execute a model pipeline i.e. object exposures within a hazard extent. Multi-dimensional data files including hierarchical data format (.hdf5) and network common data form (.nc), are formats supported as engine plugins for model pipeline ingestion of hazard occurrence (e.g. event probability, time-series) and metric intensity information. These file formats store many hundreds or thousands of hazard realisations forming a stochastic hazard event set (SES) for probabilistic risk quantification (see Sect. 2.2.5). Optional input data include 1) ‘resource’ layers representing phenomena not classified in hazard or exposure layers but influences object-exposure vulnerability to hazard impact (e.g. water table depth influencing liquefaction probability), and 2) ‘area’ layers that represent geographical areas for model output reporting of exposure impacts (see Sect. 2.2.6).

Table 2 A summary of model input data supported by RiskScape model pipelines
Full size table

The RiskScape engine imports layers from project and data bookmark file settings called during model execution. Data bookmark settings determine whether single or multiple layer files stored in a directory are imported as model input data. These settings also specify geospatial, statistical, or other data manipulation operations to pre-process layer geometries or attributes. For instance, data bookmark settings for a comma-separated value (.csv) model input file will include a coordinate reference system and instructions on converting well-known text (WKT) into geometry objects, e.g. points, polylines or polygons.

2.2.2 Geoprocessing

The geoprocessing step transforms layer geometries for spatial sampling (see Sect. 2.2.3). Layers can represent various combinations of hazard, exposure, resource or area data layers as raster grids or vector geometries (Table 2). Here, step-functions perform object geometry processing operations such as spatial and attribute filtering and logical functions, segmenting, joining, buffering, intersection and indexing (Table 3).

Table 3 Summary of model pipeline geoprocessing and spatial sampling step-functions
Full size table

Object geometries represented in layers determine the applicable geoprocessing operations. ‘Attribute filtering’ is performed on any layer that applies conditional statements to extract objects based on their attributes, e.g. flood inundation depths > 0.5 m, ‘residential use’ buildings. Object transformations are geometry specific. ‘Buffering’ operations can be applied to vector geometries representing object-exposures to expand an object's area for spatial sampling (see Sect. 2.2.3). ‘Segment’ performs multiple operations that segment line or polygon object-exposures by either 1) a linear distance or area, or 2) the points where object-exposures intersect hazard object (i.e. original or buffered) boundaries. ‘Measure’ functions recalculate the new geometric dimensions of transformed line or polygon features. Single or multiple geoprocessing operations are performed on object-exposures for single or multiple hazard or resource layers. The operations also facilitate spatial sampling of multiple hazard types and metric intensities at object-exposure locations.

2.2.3 Spatial sampling

Spatial sampling joins object attributes from hazard, resource and area layers to exposure layer objects. The sampling process creates a georelational coverage data file by converting non-exposure object attributes into indexed values at defined locations, e.g. centroid or vertices. Indexed values are extracted to the coverage data file from raster, vector or multi-dimensional data file formats (e.g. two-dimensional, occurrence frequency, time-series, etc.). Coverage data represent returned indexed values for any direct position within another layer’s spatial or spatio-temporal domain. Here, a step-function joins indexed values for non-exposure object attributes to object-exposures using lookup functions. This operation supports shared access to non-exposure object attributes at object-exposure locations for multiple purposes, including consequence analysis (see Sect. 2.2.4) and model output reporting (see Sect. 2.2.6).

Coverage data can represent single or multiple hazard types, metric intensities and temporal occurrence at object-exposure locations. Spatial sampling operations based on object-exposure geometries determine the descriptive statistics for indexed values representing hazard and other non-object-exposure attributes (Table 3). Indexed values sampled at object-exposure centroids are the default operation, while ‘all-intersections’ samples are multiple index hazard intensity metric types and values (Table 3). The all-intersections operation derives descriptive statistics from all sampled indexed hazard intensity metric values within a specified proximity to object-exposures. For example, a simulated 1 in 100-year return period flood event represented as a 2 m grid could be sampled 50 times (i.e. 50 grids) to determine the maximum inundation depth intersecting a vector polygon for a 100 m2 building object. Object-exposures buffered during geoprocessing further expands the indexed value sampling area beyond original object geometries.

2.2.4 Consequence analysis

The consequence analysis determines object-exposure impacts from single-hazard or multi-hazard events. Here, vulnerability functions determine the impact type and magnitude for object-exposures based on hazard types, metric intensities, or other phenomena. Vulnerability functions are independent from the RiskScape engine and implemented using Python programming language plugins. Python supports mathematical function libraries for vulnerability function (e.g. fragility functions, damage functions, damage-to-loss functions), implementation in continuous or discrete forms. For multi-hazard risk quantification, it is critical to support numerous functions that determine impact types and metrics for different hazard and object-exposure combinations (e.g. Silva et al. 2014; Tarbotton et al. 2015; Wilson et al. 2017; Huizinga et al. 2017).

The RiskScape engine executes vulnerability functions for impact calculation based on modeller-defined object-exposure classifications. Exposed object classes (e.g. low-rise, unreinforced masonry building) are defined from logical expressions that identify conditions for function application to objects based on hazard and/or resource layer attributes sampled at object locations. Python enables vulnerability functions to be sequenced using conditional or nested statements, for example, conditional statements relating seismic fragility functions to building objects based on multiple attributes such as construction material, height, lateral load resisting system and seismic design level to calculate physical building damage states (Martins and Silva, 2021). The implementation also facilitates object-exposure impact quantification from single or multi-hazard event occurrences. In multi-hazard risk analysis, the functionality organises vulnerability functions to calculate single or multiple impacts for object-exposures. Here, impacts from single (e.g. tsunami flow depth) or multiple hazard intensity metrics (e.g. tsunami flow depth, velocity and hydrodynamic force) caused by multiple simultaneous, sequenced or cascading hazard events (e.g. earthquake peak ground acceleration and liquefaction, followed by tsunami flow depth and velocity) escalate to reach an overall impact outcome for object-exposures (Kappes et al. 2012).

The consequence analysis produces an event impact table (EIT), used for subsequent risk analysis and model output reporting. The EIT combines structs, representing impact and model input data for each object-exposure. Descriptive statistics are calculated for impact metrics and reported from the EIT based on object-exposure attributes or geographical location (Sect. 2.2.6). Risk analysis then requires numerical aggregation of object-exposure impact metric values for hazard events (i.e. event ID) defined in model input metadata (Sect. 2.2.5).

2.2.5 Risk analysis

The risk analysis step quantifies the impact occurrence frequency for object-exposures based on hazard event probabilities. Here, modeller-defined step-functions execute risk metric quantification methods from EIT information. Impact metric values are numerically aggregated for EIT event IDs representing each hazard realisation of a stochastic hazard event set (SES). The paired event ID and impact value list facilitates deterministic and probabilistic calculations of common catastrophe risk metrics (e.g. Cardona et al. 2012; Velásquez et al. 2014; Goda and De Risi, 2017).

Deterministic Risk Analysis The RiskScape engine’s plugin architecture enables modeller-customised step-functions for deterministic risk metric quantification. Object-exposure impact for a hazard event can be determined as follows:

$$Im_{ij} = f_{C} \left( {H_{ij} \left| {E_{ij} } \right|R_{ij} } \right)$$
(2)

where \({Im}_{ij}\) is the impact to a tangible or intangible exposure (E) in response to the hazard and intensity (H) imparted by event i and resource (R) at location j. Vulnerability function impact values (\({f}_{C}\)) are calculated for every event i affecting E. Single or multiple H can occur at location j from a defined event i set. The total impact values for object-exposures to event i can be numerically aggregated by

$$Im_{i} = \mathop \sum \limits_{j = 1}^{{N_{E} }} Im_{ij}$$
(3)

where \({Im}_{i}\) represents the total impact value for exposures and NE is the total number of independent events i. Impact values can be aggregated and reported by object-exposure attribute (e.g. residential building) or geographical area (e.g. suburb) based on input data and geoprocessing step-function selections. A modeller-defined deterministic-based step-function can be applied to calculate the event expected impact (EEI) for each paired event ID and impact value in the EIT by

$${\text{EEI}} = \frac{1}{{N_{E} }} \times \mathop \sum \limits_{i = 1}^{{N_{E} }} Im_{i}$$
(4)

Probabilistic Risk Analysis Exceedance probability impact (EPI) and average annual impact (AAI) are optional risk metrics calculated from modeller-defined step-functions. These risk metrics are generically termed to reflect the RiskScape engine’s capacity to quantify \({Im}_{i}\) for tangible or intangible exposures. The EPI, often referred to as exceedance probability loss, is derived from independent variable \({Im}_{ij}\) representing event i frequency as follows:

$${\text{EPI}} = \mathop \sum \limits_{i = 1}^{N} Im_{ij} F\left( {E_{i} } \right)$$
(5)

where the probability of impact (\({Im}_{ij}\)) is determine from Ei, and F is the annual frequency of occurrence for event i. N represents the total number of events i that are assumed to be independent. The AAI, often referred to as average annual loss (AAL) or expected annual damages (EAD), is calculated from EPI as follows:

$${\text{AAI}} = \mathop \sum \limits_{i = 1}^{{N_{E} }} \left( {EPI \cdot F} \right)$$
(6)

where the event i impact is determined from the weighted average of the EPI impact for all independent events (NE). Here, we describe several possible probabilistic-based step-functions to calculate EPI and AAI from the frequency of occurrence (e.g. AEP) for hazard events in the EIT (Table 4).

Table 4 Summary information for probabilistic-based step-function implementations in RiskScape model pipelines. Hazard frequency of occurrence is represented here as event annual exceedance probability (AEP)
Full size table

Hazard-based step-functions are applicable when the hazard event frequency of occurrence is pre-determined for each hazard event ID and impact value. Here, hazard event frequency (F) and impacts (\({Im}_{i}\)) are paired for EIT event IDs (Table 4). Paired hazard event frequencies and impact values derive a hypothetical impact exceedance curve, often referred to as a loss exceedance curve or exceedance probability curve. EPI (Eq. 5) and AAI (Eq. 6) are calculated from represented event impact values using numerical integration or a probability distribution, assuming hazard event frequencies and impact values observe a monotonic relationship, i.e. as hazard event frequency decreases, impact values increase.

Event-based step-functions are applicable hazard event ID assumes an equal frequency of occurrence. Here, the number of SES hazard event realisations (e.g. 1000) for a modeller-defined recurrence rate (e.g. 10,000 years or 0.0001 AEP) is ordered to determine a mean frequency of occurrence for each EIT event ID representing a hazard event realisation and impact value (Table 4). The event impact level (EI) frequency of exceedance (\({\lambda }_{EI}\)) for a forecast time period (e.g. 1-year) is summed for all events exceeding the forecast EI (EI > ei) as follows:

$$\lambda_{EI} = \sum {F_{i} \left( {EI_{i} > ei} \right)}$$
(7)

The process is repeated for each defined EI within a modeller-defined recurrence rate. In addition, an impact exceedance curve calculated from a representative probability distribution applied to each EI facilitates AAI (Eq. 6) calculation. For instance, assuming a Poisson distribution represents the SES hazard realisations as independent events, the probability of exceeding the EI (P(EIi > ei)) in a forecast time period (T) is calculated as

$$P\left( {EI_{i} > ei} \right) = 1 - exp\left( { - \lambda_{EI} *T} \right)$$
(8)

A weighted event-based step-function is applicable when the frequency of occurrence is pre-determined for each hazard event ID and impact value. Here, the SES represents numerous hazard realisations for a single-hazard event. For example, ashfall from a single volcano source may cause 1000 s of impact outcomes in response to ashfall deposition under changing wind or rainfall conditions; the range of eruption volumes needed to account for all potential impact outcomes can also range my several orders of magnitude. In such cases, the pre-determined frequency of occurrence (e.g. AEP) for each hazard realisation is used to weight and calculate a mean frequency of occurrence (e.g. AEP) for each paired EIT event ID and impact value (Table 4). EPI (Eq. 5) is determined for each defined \({\lambda }_{EI}\), enabling AAI (Eq. 6) calculation from the impact exceedance curve for a representative probability distribution.

2.2.6 Model output data

Model pipelines executed in the RiskScape engine output data in tabular or common GIS file formats (e.g..csv,.shp). These file formats enable data post-processing and analysis in open or proprietary GIS or spreadsheet software applications. In addition, web-compatible file formats (e.g..kml,.json,.geojson) are options for model output data presentation on web applications, e.g. Google Earth. Model outputs (i.e. results) can be reported directly for object-exposures or filtered or grouped for numerical aggregation by attribute or geographical area. Risk metric derivatives generated by the RiskScape engine, such as impact exceedance curves in graphical form, are a planned future reporting option.

3 Discussion and conclusions

RiskScape is open-source software with a flexible modelling engine for multi-hazard risk analysis. The RiskScape engine implements an established framework for risk quantification. The engine is object-orientated and executes modeller-defined risk quantification workflows as model pipelines. Model pipeline steps and step-functions are linked by a domain-specific expression language. Step-functions analyse hazard, exposure, and vulnerability data across different spatio-temporal domains using geoprocessing and spatial sampling operations to transform data for impact calculation. The RiskScape engine supports deterministic and probabilistic risk quantification, with several probabilistic-based modes described in this paper, i.e. hazard-based, event-based, weighted event-based. Risk metric quantification methods are RiskScape engine independent as modeller implemented pipeline step-functions that are configurable for different multi-hazard risk modelling contexts.

Multi-hazard risk analyses are multi-part and pose technical issues for modelling spatio-temporal impact sequences in multi-hazard events. (Kappes et al. 2012). RiskScape advances modelling software for multi-hazard risk analysis through several important implementation features. Firstly,RiskScape supports modeller-defined data classifications and model workflows. Data classifications in modelling software enable impact calculations from hazard and object-exposure interrelationships but system prescribed classifications can limit impact outcomes from standardised model workflows (Komendantova et al. 2014; Tilloy et al. 2019). RiskScape implements in a single software system either modeller-defined or existing data classifications (e.g. Silva et al. 2022; Dabbeek and Silva 2020) designed to quantify risk from multiple hazard, object-exposure and vulnerability interrelationships. Secondly, geoprocessing and spatial sampling operations perform spatio-temporal analyses for multiple hazard types and intensity metrics acting on object-exposures. Geometry-based geoprocessing (e.g. grid and polyline, polygon and grid, grid and grid, etc.) transforms object-exposures to georelate spatial (e.g. multiple hazard intensities intersecting an exposed building) and temporal (e.g. time-evolving hazard intensities intersecting an exposed building) hazard and object-exposure interactions. This enables simultaneous or sequential multi-hazard events acting on individual object-exposures to inform vulnerability function application in a multi-hazard impact sequence and supports modelling multi-hazard risk at any geographical location or scale. RiskScape geoprocessing and spatial sampling operations advance the modelling software’s functionality beyond single-hazard contexts (Kappes et al. 2012).

Another important RiskScape advancement is modeller implemented vulnerability functions executed in model pipelines. Vulnerability functions are often classified and embedded in risk modelling software to calculate impacts based on prescribed relationships between hazards and object-exposures (Global Facility for Disaster Reduction and Recovery, 2015). Here, python scripted conditional or nested statements enable modeller-defined vulnerability functions to establish hazard and impact occurrence sequences, with logical expressions matching functions to specific hazard and object-exposure attribute combinations. The flexible approach (1) avoids system-defined vulnerability functions for hazard and exposure data classifications and (2) facilitates spatio-temporal sequencing of hazard type and intensity metric occurrence for impact calculation of single, compound (i.e. two or more hazards acting together) or cascading (i.e. temporal order of exposure in a multi-hazard event) hazards acting on object-exposures (Tilloy et al. 2019). The functionality advances modelling software for multi-hazard risk analysis by enabling modellers to develop workflows where escalating impacts from multiple hazard and object-exposure interrelationships are quantified and aggregated to report an overall impact outcome. Impacts from multiple hazard interactions are not adequately represented when aggregating impact outcomes for independent single-hazard events (Terzi et al. 2019).

Several challenges focus RiskScape’s continual development and improvement. The platform-independent RiskScape engine supports parallelised model pipeline steps and functions for efficient operation on a standard laptop. Model workflows must be scalable for analysing object-exposures, impacts, risk, uncertainties and sensitivities for single and multi-hazard events occurring at different spatio-temporal scales. Hazard events forming an SES may represent many hundreds of thousands of realisations, creating high computational demands. The RiskScape data processing engine supports multi-threading, whereby a greater number of processors or CPU cores are utilised to perform model pipeline steps and functions in parallel. Increasing computational resource efficiency supports scaling model pipelines to operate with increasingly large, complex spatio-temporal hazard and exposure model input data and reduces model runtimes for real- or near-real-time impact forecasting for single or multi-hazard events (e.g. tropical cyclones). Progressing model performance characteristics is critical for RiskScape to deliver timely information to emergency managers on hazard event impacts, along with model uncertainties and sensitivities to guide emergency response and recovery activities (Merz et al. 2020).

RiskScape’s future development will also focus on improving the user experience. The RiskScape engine CLI provides a flexible light-weight tool for model pipeline configuration and execution. A CLI wizard assists modeller-defined pipeline configuration and execution, however, a planned web-based graphical user interface (GUI) for engine operation will support visual and graphical tools for model and data management. Software features that reduce barriers for modeller operation ensure modelling software such as RiskScape continue to meet the global demand for multi-hazard risk analysis tools.