Flood damage cost estimation in 3D based on an indicator modelling framework

Abstract

Flooding and other natural disasters pose risks to cities and residential homes, and these are set to increase in the face of climate change. Single-family residential buildings are of particular interest because they are difficult to insure and often highlight wealth discrepancies in society in the wake of natural disasters. Calculating building replacement cost based on a specific natural disaster is of interest to municipalities and city planners who are working to prepare their cities for potential future costs of recovery. There are models designed by flood modellers, and there are models designed by city planners. This paper presents a novel Indicator Modelling Framework (IMF) by bringing together a model from the flooding domain (HAZUS) and a model from the geospatial application domain (e.g. CityGML) and weaving them together. The weaving process automatically calculates the building replacement cost for buildings based on a flood scenario as well as generates domain-specific metadata. The weaving process capitalizes on the strengths of both models, and future work will focus on weaving between models in other domains.

Keywords:

• General Indicator Model
• metadata
• CityGML
• flood modelling
• Indicator Modelling Framework
• model-driven engineering

1. Introduction

The recent growth in the availability of data, models and software has presented both opportunities for new types of analysis and at the same time confusion with information overload. It is often difficult to understand which model best fits a specific application and which data is suitable within a particular analysis. This is increasingly difficult when a subject is highly specialized, and a domain specialist has only the knowledge related to their specific domain. Despite the growing usage and availability of 3D city models, not many domain specialists, spanning various fields, understand the possibilities that are available to them from these models. One such application is within the field of flood damage modelling to ascertain insurance risk. This is especially relevant when considering the risks posed by climate change through both sea-level rise and through flooding introduced by extreme weather events such as hurricanes. For example, in 2017, Hurricane Harvey wrought severe damage in south-east Texas and inundated the Houston area, damaging many buildings and homes (Hayden et al. 2017). Hurricane Sandy, which occurred in October of 2012, brought devastation to the east coast of the United States, including heavy damages in the city of New York with subway and road tunnel flooding and blackouts across Lower Manhattan (BBC 2012b). The severe flooding included many residential homes, which experienced severe damage. Thus, it is essential to assess the damages/losses caused by flood in a comprehensive way. This, in turn, raises questions about the information required to carry out building replacement cost assessment. In other words, what are the indicators that play a role in building replacement cost assessment caused by floods? This exact question has been investigated by the model HAZUS.

HAZUS is a standardized methodology for estimating the potential losses from national disasters and has been developed by the Federal Emergency Management Agency (FEMA) in the United States (FEMA 2017). As further explained in Section 4.1, it is based on indicators, which can be utilized to estimate the replacement cost of residential buildings damaged in a flood, and while it can be run with a minimal amount of data, increased information facilitates a more in-depth level of analysis. HAZUS is based on various indicators, such as building construction class and number of stories. Hence, HAZUS requires specific information about a building in order to assess the building replacement cost.

The international standard of the Open Geospatial Consortium (OGC) for the representation and storage of 3D city models is CityGML (Gröger et al. 2012); it defines the geometry, topology, semantics and appearance of various city objects in 3D, including buildings. In order to obtain the required indicators for HAZUS, information from large-scale 3D city models can provide most of the required information (Kolbe et al. 2008). Although there has been research studies on how to represent indicators, as shown by Barone et al. (2011) and Kaplan and Norton (1992), there has not been a unified standardized way to express indicators that allows them to be linked to existing geospatial data sets represented according to geospatial information models, such as INSPIRE and CityGML. Given that more and more cities worldwide are maintaining their 3D city models according to CityGML (e.g. New York, Vienna, Singapore, Zurich, Lyon, Berlin), it would be helpful if the HAZUS flood damage analysis model could be utilized with a CityGML model to estimate building replacement cost.

The structure of the HAZUS model assumes that the indicators’ computational algorithms is developed independently from the 3D city model. Hence, the structures of both the HAZUS and city models are not necessarily coherent, e.g. one model may call the levels of a building stories, while the other refers to floors. In order to link the HAZUS model with the city model, this paper utilizes a new framework called Indicator Modelling Framework (IMF), i.e. a weaving process, to test the applicability of CityGML with HAZUS damage estimation. Therefore, IMF helps in connecting different geospatial application schemas, such as CityGML and INSPIRE with domain-specific indicators using the weaving concept (Elfouly et al. 2015). IMF aims to bridge the structural and semantic gap between HAZUS and city models.

This paper introduces a novel framework, called IMF, for the modelling of indicators and the computation of their values based on explicit linking with existing 3D geobase data as initially proposed by Elfouly et al. (2015) and Zirak (2015). The IMF demonstrates how damage and associated repair cost can be computed on the individual building level and even aggregated to the city level. IMF provides explicit formal representation of the relevant indicators using Unified Modelling Language (UML) class diagrams. The model also links the indicators with respective physical objects of the real environment. Furthermore, it establishes explicit links between these reference objects required to compute the indicators and geospatial datasets as provided by authorities or communities, such as mapping agencies and OpenStreetMap. By employing a weaving concept, most of the required information to compute the indicator values can be extracted from the linked geospatial data sets. The output determines the fitness-for-purpose, as well as generates domain-specific metadata. The process was tested utilizing a sample of buildings that were affected by Hurricane Sandy and remain in a flood-risk area in New York City.

2. Flooding and homes

The case study for this paper is to calculate the building replacement cost for single-family residential buildings (RES1) in various flood-level scenarios. National disasters are often seen as an issue that affects society indiscriminately but in practice, different fractions of society have different vulnerabilities to not only natural disasters but to recovering in the aftermath (Fekete 2009). Both in developing and developed nations, poorer people suffer the largest disaster losses and have the most limited access to recovery assets in both the public and private domains (Fekete 2009). RES1 buildings are of particular interest because they are often difficult to insure affordably and the private insurance sector often sets enormous premiums in hazard-prone areas (Kousky and Kunreuther 2014). In an effort to tackle this, many governments have subsidised the cost of insurance policies, such as the National Flood Insurance Program (NFIP) in the United States (Kousky and Kunreuther 2014). Despite the availability of NFIP, it is not affordable for all; for example, in the case of Hurricane Katrina in New Orleans, it was found that planning districts with a high percentage of poverty also had a low percentage of flood insurance coverage, and this then severely increases a neighbourhood’s recovery time (Masozera et al. 2007). Hurricane Katrina was a wake-up call for government agencies in New Orleans and Louisiana to better plan for pre- and post-disaster, with one key recommendation being the preparedness of government to facilitate equal access to loans post-disaster and to offer financial incentives to encourage flood mitigation measures in homes (Masozera et al. 2007). Determining building replacement costs are a key in assisting relevant government agencies in preparing financially for disaster relief. Additionally, the credit rating agency Moody’s has warned cities and states that their bond ratings can be affected if they fail to act on and mitigate climate risks, and this can potentially affect the trillions of dollars that are received by coastal municipalities (Price 2018).

3. Indicator modelling linked to geodata

In this section, we introduce the so-called General Indicator Model (GIM), based on the earlier presented GIM by Elfouly et al. (2015) which will form the basis of this paper.

3.1. Indicator modelling

A considerable number of related approaches for modelling indicators can be found in various publications. Barone et al. (2011) focus on composite indicators consisting of a hierarchy of indicators. They seek to link indicators to business objectives in order to achieve business intelligence. One such example is Balanced Scorecard, developed by Kaplan and Norton (1992), which is a very common technique for choosing indicators, mainly in management. During the course of its development, they tackled questions, such as how to transfer values across different hierarchies of indicators, and how to derive values for composite indicators. In order to determine the indicators, they relied on two relations: evaluates and measures. In addition, an Eclipse-based prototype was implemented as a proof of concept for their work. Although they follow clear and accurate semantics and syntax, they do not offer a UML representation of their model, which would allow for extendibility and integration within other frameworks. Moreover, although Balanced Scorecard does allow for financial and operational measures, it was not investigated whether it can be linked to the geospatial domain.

A General Indicator Model (GIM) was proposed by Elfouly et al. (2015) in order to model a comprehensive indicator system. This GIM allows domain specialists to express indicators, which in the use case of this paper are Building Replacement Cost (BRC) indicators, using a model-driven approach. Consequently, by employing model-driven engineering (MDE), this facilitates the linkage of concrete subclasses, such as BRC indicators, to the geospatial feature classes of a geospatial data model for cities (e.g. CityGML or INSPIRE). This, in turn, allows the linking of attributes from the geospatial domain to the indicators, which facilitates the computation of indicators. Additionally, GIM is modelled using UML class diagrams which makes it readable, understandable, as well as extensible with constraints formulated in Object Constraint Language (OCL) rules (Atkinson et al. 2006). It also allows breaking down complex indicators into discrete pieces that can be easily understood (Tedla and Grant 2004).

Additionally, an object-oriented data model for the abstract GIM formally specifying concepts such as indicators, numeric indicators, Boolean indicators or categorical indicators, and their compositions has been defined at a metamodel level (see Figure 1). Specific indicators from different decision contexts, such as energy or flood analysis, are then defined as concrete subclasses of the GIM at the application schema level (M1) as seen at Figure 1. This aids stakeholders and domain specialists in establishing indicators and their dependencies from their respective decision context and computing the value of these indicators by connecting it to concrete physical objects at the instance level (M0). It also facilitates the linkage between these different domains and their respective geospatial application schema, such as CityGML (see Figure 1).

Figure 1. Multi-perspective indicator modelling.

Additionally, as will be elaborated further in the following section, different aspects of the relationships that may exist between classes in the GIM have been thoroughly studied, subsequently allowing domain specialists to further extend the whole GIM and employ it in their domain of interest which enriches it with their computational algorithms adhering to the corresponding ISO standards.

Therefore, this research work introduces an authentic GIM which follows the ISO 19109 Rules for Geographic Information – Rules for application schema and ISO 19103 Geographic Information – Conceptual schema language standards, respectively (ISO 2015a, 2015b). This, in turn, allows for interoperability, re-usability, and decreasing the cost for data loss due to lack of standardization (Buxmann 1999).

3.2. Linking indicators with geodata

Figure 2 shows the IMF in a real-life scenario, in this case it is for computing building replacement costs due to flood, where the city modeller feeds the domain specialist (e.g. flood analysis specialist) with the data required to perform the indicator evaluation computation. The city modeller belongs to the geodata provider domain, while the flood analysis specialist belongs to the domain of the application specialist. Geodata required for the evaluation task by the energy planner is being weaved by employing the model weaving concept (Elfouly et al. 2015). The IMF is defined purely from the viewpoint and requirements of the domain specialist. Whereas the data is modelled and structured according to application domain needs only – and not according to a given geospatial data model, this enables the IMF to be plugged with various geospatial application models.

Figure 2. The General Indicator Model (GIM) and domain-specific indicator models in the MDE perspective applying the model weaving concept.

The data model (see Figure 2) is split up into six consecutive sections. First, in our use case, abstract indicator classes are defined as numeric indicators. These classes are instantiated from the meta-model GI_IndicatorType. In the second section, domain-specific indicator types (DITs) are defined according to the domain specialists domain of interest, ReplacementCosts in our case, and inherit their characteristics from the abstract numeric indicator classes. Then in the third section, ReplacementCosts is simultaneously linked to the Object Related Domain Indicator Types (ORDITs), where the flood analyst specifies the corresponding objects related to that particular domain. Then, the domain specialist expresses the computational algorithms for assessing the damage that occurred on the building and district levels using OCL. Afterwards, these object-related domain-specific indicators are linked to concrete physical objects, such as buildings and districts. These Reference Feature Types (RFTs) that are defined in the context of urban planning are usually spatial objects (Franklin 1992). On the other side of the data model, denoted by number 5, comes the geospatial application schema, representing the geographical context, such as CityGML. Subsequently, the fifth section addresses linking the indicator model with a geospatial application schema. Intermediate classes (denoted by the number 6), BuildingConnector and DistrictConnector, link the RFTs to the classes Building and CityObjectGroup of the geospatial application model, respectively. In Section 6, OCL is used to map the required attributes for domain indicator evaluation computation to the domain of application specialist. Our results are visualized in the UML schema presented in Figure 3.

Figure 3. UML schema for interconnecting CityGML with building replacement cost estimation indicators using the GIM model. OCL is omitted for space reasons.

3.3. Metadata

On the simplest level metadata is data that describes other data, but more broadly it can be in reference to a range of information technology resources: data, services, knowledge stores or other information types (Danko 2011). Metadata exists in most knowledge sectors and has unique specifications and standards depending on the domain, and geospatial data is one such domain. The difference between data and metadata is that metadata is structured to some degree (Riley 2017). The structuring is what converts ‘raw information into actionable metadata’ (Riley 2017). Metadata is crucial for ensuring the interoperability of data, in that data can be not only exchanged but understood and usable after the exchange (Danko 2011). Metadata has four primary functions: locate, evaluate, access and employ (Danko 2011).

Metadata is often decoupled from the resource and stored separately in either human and/or machine-readable form (Danko 2011). This decoupling and the fact that metadata is often seen as cumbersome to produce requires methodologies to make its production and update an automatic process (Ellul et al. 2014). Additionally, existing standards are often not specific enough for all data types; for example, Dietze et al. (2007) examined the applicability of ISO 19115 to 3D city models and found that while there exist several attributes that are important, there are further categories that are missing, the most prominent being the level of detail and semantic object classes. Labetski et al. (2018) developed an Application Domain Extension (ADE) for CityGML that supports 3D city model-specific metadata categories. CityJSON¹ a JSON encoding for a subset of the CityGML model also incorporated extensive metadata support within its core (Ledoux et al. 2019).

4. Employed models

4.1. Domain-specialist model: HAZUS

The HAZUS 2.1 Flood Model developed by FEMA is a standardized methodology for estimating the potential losses from earthquakes, hurricane winds, floods, and tsunamis that is nationally applicable (Figure 4, [FEMA 2017]). The model works by first determining which natural disaster to model and then conducting an inventory of the relevant city objects such as buildings, transportation networks, agricultural products (FEMA 2012). The two portions are then combined in order to calculate the direct physical damage, the induced physical damage, the direct economic/social losses and the indirect economic losses at different stages of severity (FEMA 2012). The model is designed with governmental open data in mind so that acquiring data should not be an obstacle and the model also provides many default values and guides for setting parameters (FEMA 2012). In total, there are three levels of analysis: level 1 is the simplest and requires minimal effort by the user by relying on primarily default values, level 2 expects an increased technical knowledge, while level 3 expects advanced domain expertise and recommends consultation with a variety of experts (FEMA 2012). While each level can introduce further information and can tailor a model better to match a specific demographic or geographic area, it also introduces more uncertainty into a model. Tate et al. (2015) conducted an uncertainty and sensitivity analysis of the HAZUS model. They found that for the uncertainty analysis the estimate at the upper bound of loss distribution was a factor of three higher than the lower-bound estimate, while for the sensitivity analysis they found that the choice of digital elevation model was the most influential.

Figure 4. HAZUS Flood Model Schematic from Figure 2.1 in FEMA (2012). C_i,j is the cost per square foot for the given construction class (i) and the number of stories (j).

The HAZUS model estimates house type based on its census block and uses weights to calculate the building replacement cost as an aggregate value per census block. This paper modifies this to calculate the replacement cost and the flood depth on a building-by-building level in order to have a more accurate figure.

The output of the model is the total building damage estimate based on a specific flood-level scenario. The total replacement cost per building is first calculated, taking into consideration the square footage, the number of stories, the status of the basement and the size of the garage. The flood level per building is then derived from the flood surface, and utilizing a depth damage curve, the damage percentage is derived and multiplied by the total replacement cost of the building. The result per building is summed to derive the total damage estimate for buildings in a study area. The valuation can be summarized in three steps; first the replacement cost per building (modified from equation 14-1 in FEMA [2012]): (1) $$\mathrm{BRC}=\mathrm{SF}\times C_{i,j}+\mathrm{SF}\times C_{i,j,l}+C_{i,m}$$(1) where BRC is the building replacement cost, i is the construction class (1 = Economy, 2 = Average, 3 = Custom, 4 = Luxury), j is the number of stories (1 = 1-story, 2 = 2-story, 3 = 3-story, 4 = split level), l is the basement status (0 = no basement, 1 = unfinished, 2 = finished), m is the car size of the garage (1 = 1-car, 2 = 2-car, 3 = 3-car, 4 = carport, 5 = none), SF is the total floor area (square footage) of a building, C_i,j,l is the additional cost, per square foot, for the type of basement (l), for the given construction class (i) and the number of stories (j). Note: C_i,j,l = 0 when l = 0. C_i,m is the additional replacement cost for a given garage type (m), for the given construction class (i) and the number of stories (j). Note: C_i,m = 0 when m = 4 or m = 5.

Followed by calculating the flood depth per building: $$\mathrm{BFD}=\mathrm{FL}-z_{\mathrm{base}}$$ where BFD is the building flood depth, FL is the surface flood level and z_base is the elevation of the base of the house.

The final valuation can be summarized as such: (2) $$\mathrm{B}{\mathrm{D}}_{\mathrm{FL}}=\sum _{i=1}^n\mathrm{ }(i_{\mathrm{BRC}}\times i_{\mathrm{BF}{\mathrm{D}}_{\mathrm{FL}},\mathrm{CAT}})$$(2) where BD_FL is the total building damage estimate for a study area based on a given flood level (FL), i_BRC is the building replacement cost of building i, CAT is the building category class (1 = 1-story no basement, 2 = 1-story w/basement, 3 = 2-story no basement, 4 = 2-story w/basement, 5 = 2-story split-level no basement, 6 = 2-story split-level w/basement) and i_BFDFL,_CAT is the damage replacement percentage of building i determined from a depth damage curve that is based on a given flood depth (BFD) at the flood level FL and the building category class (CAT).

The total building damage cost estimate (BD_FL), which is the goal output of the model, is dependent on the calculation of the individual building replacement cost per building (BRC) and the specific building flood depth (BFD). Therefore, BD_FL is the sum of each buildings replacement cost multiplied by the damage replacement percentage as determined by the flood depth and building type. The building type determines which depth damage curve is selected. There are six depth damage curves that were derived from tables developed by the United States Army Corps of Engineers (USACE). All of the equations were found to be functions at the fourth order polynomial, and they are summarized in Table 1 and are visualized in Figure 5.

Figure 5. Depth damage curves.

Table 1. Depth damage curves for RES1 buildings.

Category class	Depth damage curve
1. Single-story no basement	y = − 0.001516 × 4 − 0.0409 × 3 − 0.0073 × 2 + 8.5759x + 14.4041
2. Single-story with basement	y = − 0.000732 × 4 − 0.0321 × 3 + 0.1269 × 2 + 6.4986x + 26.2951
3. Two-story no basement	y = − 0.000566 × 4 − 0.0188 × 3 + 0.0497 × 2 + 5.4415x + 0 9.6284
4. Two-story with basement	y = −0.000036 × 4 − 0.0128 × 3 + 0.1779 × 2 + 4.2194x + 0 4.2194
5. Split-level no basement	y = −0.001141 × 4 + 0.0052 × 3 + 0.3291 × 2 + 2.9103x + 0 6.4221
6. Split-level with basement	y = −0.000009 × 4 − 0.0156 × 3 + 0.1563 × 2 + 4.5241x + 19.0392

4.2. Geospatial application model: CityGML

Virtual 3D city models provide details about cities and have data integrating a variety of different types of geoinformation and georeferenced urban data, which can be utilized in multiple domains such as urban planning and disaster management. These interdisciplinary domains are interconnected, so that a change in one of the domains may have an impact on one or more of the others. Additionally, virtual 3D city models have proven to be an effective tool in visualizing different application areas that facilitate the decision-making process. Hence, these models can act as an information hub assisting decision-makers, executives and politicians in exploring urban data, conducting research studies, applying analysis and feasibility studies to a specific domain in a city model, and measuring its impact on other interdisciplinary domains (Döllner et al. 2006). Nevertheless, a considerable amount of contributions to such models is pure graphical representations neglecting the semantic and topological aspects of the city (Gröger and Plümer 2012). Therefore, these models can solely be used for visualization with no further thematic or geospatial analysis being applied (Kolbe et al. 2008).

Figure 6. Geospatial data model from the data modeller perspective (Here: CityGML). Schema, built in UML, to its corresponding geographic information (Interactive Instruments GmbH 2020).

As a result, the OGC has introduced an application schema for GML, allowing for modelling georeferenced 3D vector data with the associated semantics (Isikdag et al. 2009) called CityGML, which conforms to relevant standards from the ISO 191xx family, the Web 3D Consortium and the OGC. CityGML comes with five distinct levels of detail (LoDs) allowing for large- and small-scale city planning by enabling the visualization of spatial properties of regions and landscapes, cities, city districts, exterior and interior architectural models, and city furniture, such as street lights, traffic signs, and benches (Kolbe 2009). Additionally, CityGML provides several thematic modules, such as Building, Transportation Vegetation.

The data modellers then provide semantic attributes required by the flood analyst. Various city models, such as CityGML, INSPIRE or AAA, can be interconnected to the weaving class type. The availability of the data attributes required by the domain specialists computational algorithm varies based on the city model being used. This enables the domain specialist to decide on the desired city model, based on the attributes’ availability.

As shown in Figure 6, we can observe that CityGML allows us to store extensive information about buildings, such as storeys above ground, height above ground or the function of the building. Also, it allows us to look into the building in different level of details. This enables us to compute the area and volume of a specific surface. The building model allows us to calculate roof and ground surface as well. Thus, we can compute the ground surface area of a particular building and the different roof types that can be installed or structured. In addition to that, the water model is also utilized within the course of our research work. Thus, it allows for the representation of water bodies and the water level. Both the building model and the water body model have been utilized within the course of our research work.

5. Implementing the HAZUS models using the IMF

A novel framework structure, IMF, was utilized in the course of our work, whereas the domain specialists, in this case flood analysts, are capable of identifying the indicators that play a role in the replacement cost caused by flood. Then, flood analysts determine the entailed properties of their indicators’ computation and express their computational formulae using OCL to compute the building replacement cost caused by flood. This, in turn, allows the flood analyst to identify the indicators, where the decisive ones are called KPIs. In addition to that, it can be further extended to other geospatial domains, which enables sensitivity analysis.

The IMF was developed and realised using a UML analysis and design tool, known as Enterprise Architect² (Sparx Systems Ltd and SparxSystems Software GmbH 2020). Nevertheless, other UML language tools, such as Eclipse UML2 Tools, can be also used (Eclipse Foundation 2020). Due to the fact that both GIM and IMF were modelled in conformance to ISO/TC 19109 and ISO/TC 19103, the process of geographic information derivation from the application schema was facilitated. Thus, ShapeChange,³ which is an open-source software tool, was used for processing the IMF application schema, built in UML, to its corresponding geographical information (Interactive Instruments GmbH 2020).

5.1. Domain indicator types, object related domain indicator types, and reference feature types

Domain indicator types (DITs) are self-explanatory, it is where flood analysts define indicators for their domain of interest, as illustrated in Figure 7. Replacement costs are then specialised into NaturalHazardInducedReplacementCosts and WearOffReplacementCosts. Other natural hazards have also been identified, such as FloodCausedBuildingReplacementCosts, TsunamiCausedBuildingReplacementCosts and EarthquakeCausedBuildingReplacementCosts; however, this paper will focus on flood damage.

Figure 7. Building replacement cost indicators from the domain specialist perspective. Building replacement cost is being expressed using OCL. However, it is being omitted here for clarity reasons.

Afterwards, the ORDITs are defined by the flood analyst, in order to perform their computational formulae. Thus, associations among these parameters are established, allowing for flood analysis experts to identify the objects that play a role in their computational algorithm, such as FloodDepthCausedBuildingReplacementCosts and DistrictFloodDepthCausedBuildingReplacementCosts, which is an aggregation of the former one. Therefore, the ORDITs inherit their attributes from the FloodCausedReplacementCosts DIT. In addition to that, BuildingTotalReplacementCosts and its aggregation DistrictBuildingTotalReplacementCosts are defined as realization of the GIM by inheriting from ReplacementCosts. Then, flood analyst can apply the computational algorithm for calculating the building replacement cost caused by flood.

ORDITs are scalar values, in which objects, such as BuildingTotalReplacementCosts and its aggregations DistrictBuildingTotalReplacementCosts, that are only required during a specific domain indicator calculation are represented. The abstract GIM provides the computational formulas possibilities whether it is unary (e.g. sin, cos, fact), binary (e.g. add, sub, multiply) or a combination of both (e.g. sum, average, minimum). Accordingly, the flood analyst expresses the computational algorithms in OCL using the required semantic attributes. The result is stored in the value attribute that is inherited from the AnyNumericIndicator abstract class.

Afterwards, the ORDITs are interconnected with their corresponding physical objects from the RFTs. RFTs are representing relevant physical objects with their relevant characteristic specific values and act as a data hub for storing the attributes that are required by the flood analyst during the computation algorithm for the indicator, BuildingTotalReplacementCosts. RFTs’ main role is to link the ORDITs to their corresponding geospatial application schema classes via the weaving classes. The parameters that are required by the flood analyst throughout the computational algorithm are represented as attributes at the RFTs’ classes, such as Building, District and City.

5.2. Weaving classes

The flood analyst’s scope ends at Section 4, where they express the computational formulae needed to compute the building replacement cost. Thereafter, they connect their defined indicators with the corresponding physical objects (RFTs). As a consequence, in order to compute the actual building replacement cost due to flood, flood analysts must fetch the required values from their corresponding geospatial application schema model, such as CityGML.

Following the model weaving concept introduced in the MDE section, we create the weaving classes, such as BuildingConnector and DistrictConnector for linking the RFTs to the geospatial application schema model. Model weaving aids the flow of the spatial-related information from the urban city models, such as CityGML to the concrete KPI classes using OCL rules, which makes it precise and consistent. The unequipped data from the city modeller or the geodata provider is to be stored as constant attributes in the weaving class. This, in turn, allows the flood analysts to perform their computations based on the available data. Furthermore, it highlights to the geodata provider which data is missing, in order to acquire them in the future if possible (Figure 3).

6. Testing the model and results

6.1. Study area

New York City (NYC) was selected as the study area because it is a large coastal city with multiple residential houses along its coast. NYC has already been historically affected by flood damage, primarily due to hurricanes, a notable one being Hurricane Sandy. It also has an openly available highly detailed 3D city model. Five buildings were selected in Staten Island, in an area that was heavily damaged during Hurricane Sandy. These buildings are located in a residential area right along the coast, see Figures 8 and 9. It is an area that has some of the lowest elevation in NYC and is therefore vulnerable to flooding according to the NYC Office of Emergency Management (BBC 2012a). A visual comparison of the area utilizing Google Streetview⁴ indicated large damage in January 2013, just 2–3 months after the hurricane, and the damage was still visible in September 2013, almost a year after the hurricane (Figure 9).

Figure 8. Study area with sea-level rise projection.

Figure 9. Comparison of one of the buildings in the study area utilising Google Street View, from left to right: September 2007, January 2013, September 2013. The far left image is prior to Hurricane Sandy, while the middle image is 2–3 months after the hurricane and shows extensive damage to the sidewalk and fence. The image on the right is roughly a year after the hurricane and the damage to the fence was still present. Source: Google, 2018.

Figure 10 shows the five buildings comprising the study area in the NYC coastal area. The instance diagram implemented in Figure 10 shows how the building replacement cost computation is for a particular building using the HAZUS model algorithms. By illustrating each and every equation parameter expressed in HAZUS model as a separate component, the instance diagram becomes a rather complex structure. Having too many classes and associations between them might not be an easy task. Although the model might rather seem to have a complex structure, it introduces a formal descriptive way to visualize, as well as formalize the textual computational algorithms that are expressed in books and models. An IMF shows the process chain, where the computations are being established by the domain specialists on one side, and the geospatial application domain or geodata providers weaves the required attributes to establish or perform these algorithms using the weaving classes on the other side. In addition to that, indicators are being visualized and can be updated easily and linked to their corresponding geospatial application schema model component from various geodata providers. Consequently, this allows for sensitivity analysis to be performed and comparing the different modelling standards and decides on which one fits our domain of interest the best.

Figure 10. The bottom left shows five buildings comprising the study area visualized in 3D. The figure shows a UML instance diagram of the building on the right and how it is connected to the different indicators. Each box represents an object with its attribute values. The lines represent the concrete interrelationships.

6.2. Results and validation for sample buildings

In order to validate the model integrity and credibility, we computed the BRC for the five sample buildings in a 5-foot flood scenario. The computation was performed manually and compared to the results generated by the IMF. Within the course of this research work, the IMF was developed and realised using Enterprise Architect.

The results indicated that CityGML is a suitable geospatial model for usage with BRC calculations due to the outputs producing the same values. A summary of the manual calculations can be found in Table 2 below. The results of the weaving (with details for Building 1) can be found in XML 1 to show that the same results were achieved manually and automatically.

Table 2. Building damage valuation results for the sample area in NYC with a 5 foot flood.

Building	Ci,j	Ci,j,l	Ci,m	BRC ($)	CAT	Flood level (ft)	Percentage	BD ($)
1	112.91	22.9	0	167317.92	4	1.65	11.6	19400.20
2	90.15	15.5	0	170730.40	4	1.65	11.6	19795.87
3	90.15	15.5	0	232430.00	4	1.65	11.6	26949.83
4	65.91	0	0	23068.50	1	1.65	28.3	6537.36
5	92.84	0	0	69444.32	1	1.95	30.8	21412.64

XML snippet 1: Output after weaving HAZUS model with CityGML – Required categories are omitted for space reasons but are all accounted for in the Derived and Underived Attributes tags

<GeneralIndicatorModel>

<ReplacementCosts>

 <FloodCausedBuildingReplacementCost>

  <Analysis>

   <NumberOfBuildings> 5</NumberOfBuildings>

   <TotalFloorArea unit=‘‘>5</TotalFloorArea>

  </Analysis>

  <District>

   <Buildings>

    <Building id=‘5068711’ address=‘‘>

     <name > House1</name>

     <BuildingConstructionClass > Economy</BuildingConstructionClass>

     <HouseType > OneStorey</HouseType>

     <NumberOfStories>

      <OneStorey/>

      <value> 1</value>

     </NumberOfStories>

    <CarGarageSize>

     <NoGarage/>

     <value> 5</value>

    </CarGarageSize>

    <BasementStatus>

     <Finished/>

     <value> 2</value>

    </BasementStatus>

    <CostPerSquareFoot currency=‘US-Dollars’>112.91</CostPerSquareFoot>

    <AdditionalCost unit=‘feet’>22.9</AdditionalCost>

    <AdditionalReplacementCost> 0</AdditionalReplacementCost>

    <BuildingCategoryClass> 1</BuildingCategoryClass>

    <SurfaceArea> 125,485</SurfaceArea>

    <SurfaceFloodLevel unit=‘feet’>1.65</SurfaceFloodLevel>

    <ReplacementCostPercentage> 11.6</ReplacementCostPercentage>

    <EstimatedBuildingDamage currency=‘US-Dollars’>19400.20      </EstimatedBuildingDamage>

    <BuildingTotalReplacementCosts currency=‘US-Dollars’>167317.92      </BildingReplacementCost>

   </Building>

   [.]

   <DistrictBuildingTotalReplacementCosts>

    <UnitOfMeasurement > US-Dollars</UnitOfMeasurement>

    <value> 662991.14</value>

   </DistrictBuildingTotalReplacementCosts>

  </District>

 </FloodCausedBuildingReplacementCost>

 <UnitOfMeasurement > US-Dollars</UnitOfMeasurement>

 <value> 662991.14</value>

</ReplacementCosts>

</GeneralIndicatorModel>

7. Discussion and outlook

There exists a plethora of approaches for computing building replacement cost caused by flood. Henshaw et al. (2014) developed and introduced an open-source web-based platform for risk assessment, within the context of the Global Earthquake Model initiative (additional information is available on the GEM website, Global Earthquake Model Foundation [2020b]). OpenQuake has been developed in order to allow stakeholders and domain specialists from various related domains to utilize the web-based platform to visualize and calculate earthquake hazard and assessment. The concept of object oriented programming is being realized in OpenQuake-engine development. Thus, it allows for easier integration of the risk assessment component with other existing software. In a related work, Silva et al. (2020) introduce a hazard seismic risk model, specifically for earthquakes. It aims to assess and measure the earthquake risk impact, in order to decrease economic and human losses, as per the Sustainable Development Goals (SDGs) using OpenQuake-engine (United Nations 2016). OpenQuake-engine is a open source software for earthquake and hazard risk modelling (Global Earthquake Model Foundation 2020a). It is used mainly for assessing potential impacts of earthquakes (Global Earthquake Model Foundation 2020c). Furthermore, the model comprises detailed information in respect of geographic location, the number of buildings and replacement costs.

In order to tackle the accelerating impact of flood damage, a GIS-based model for estimating flood damage was being developed in 2014 by Albano et al. (2014) focusing on urban areas. They present on a GIS-based framework for estimating flood damage cost, as either direct or indirect damage caused by a flood event (Albano et al. 2014). This should assist decision-makers in where to allocate funds to address flood consequences. Based on the aforementioned research work, Mancusi et al. (2015) developed an open-source flood risk plugin, named FloodRisk, for assessing the direct damage to urban areas, whereby the number of people that are affected is calculated. This work was extended in 2017 by Albano et al. (2017), where they presented free open-source software, FloodRisk, for damage estimation caused by flood. Albano et al. (2017) developed an object-oriented framework for studying risk analysis. The framework was developed using Python, thus allowing for extensibility. Further, this allowed customizing the software to domain-specialists specific needs. In addition, they provide different assessment aspects, such as an economic damage calculator and social damages calculator.

Dottori et al. (2016) introduce a synthetic conceptual flood damage model. They developed an Indepth Synthetic Model for Flood Damage Estimation (INSYDE). INSYDE is a probabilistic methodology to assess damage on residential buildings. The presented model allows for different level of details to be analysed. This means, data availability is taken into account. Additionally, sensitivity analysis is performed to determine the hazard factors that are of higher significance in the damage assessment results (Dottori et al. 2016).

The above research studies provide diverse approaches for representing and modelling risk assessment. While these studies provide profound work in the domain of hazard assessment, a comprehensive information structure framework for representing the data flow between a formal data model (e.g. flood indicator model) and the geospatial application model was not addressed. For example, the linkage between geospatial application schemas, such as CityGML, INSPIRE or AAA, and the presented flood models was not demonstrated. Although linkages to the geospatial domain should be valid on a conceptual level, it was not investigated enough. Also, formal modelling language, such as UML was not used in the course of all the studies explained above which makes it harder to understand, integrate and extend. Furthermore, although the above research did demonstrate object-oriented implementation for their proposed approaches, it is not mentioned whether they follow the ISO 191xx series of geographic information standards allowing for easy extensibility and understandability, or not.

In this research work, IMF is utilized to visualize the computational process and the formulae that were used. Additionally, by employing the IMF, city models and data providers are connected to the domain specialists through weaving classes, where required attributes that are provided by the data modeller can be weaved. Thus, IMF is a domain-independent framework in which domainspecialists (here: flood analysts) can use to visualize the computational process and the formulae that was implemented. This also means, by employing the IMF, city models and data providers are connected to the domain specialists through weaving classes, where required attributes that are provided by the data modeller can be weaved. Within the course of this paper, the building replacement cost is computed as the total building replacement cost multiplied by the flood depth damage curve calculated by HAZUS, based on the housing type.

As mentioned in earlier sections, Sections 1 and 4.1, the HAZUS Flood Model is not necessarily built in coherence with city models represented in CityGML, INSPIRE or AAA. Furthermore, though the HAZUS Flood Model is not open-source software, it should not limit its linkage to the geospatial domain. The aim of IMF is to bridge the gap between different flood models, in this case HAZUS and geospatial application schemas, thus, enriching and feeding the domain specialists’ algorithms with the required geodata, in order to perform their computations.

7.1. Usage and benefits of IMF

The IMF is defined purely from the viewpoint and requirements of the flood analyst, whereas data is modelled and structured according to application domain needs only – and not according to a given geospatial data model, enabling the IMF to be plugged with various geospatial application models. Thus, it assists domain specialists in determining indicators, indices and their dependencies using a declarative, model-driven approach. However, we argue that our proposal sees the big picture of the indicator system and does not cover a narrow business-oriented or finance-oriented scope. It shows the whole information structure workflow not only from the application specialist perspective, but also from the geodata provider perspective, passing through the domain-specific indicators, object-related domain indicators, reference feature types and the weaving class type, injecting it with the geoinformation required.

Moreover, the advantage of a framework structure is that it allows the users to know where they are when a mistake happens and that it ensures that they can correct it. Also, some of the attributes and properties needed in the indicator measurement formulae might be missing at the geospatial application schema, which conceivably leads to inaccurate and unreliable results that, in turn, might lead to a wrong decision being made.

Therefore, in order to map the semantic attributes or properties from the geodata provider to the domain specialist a weaving concept was introduced for augmenting the missing attributes and mapping the existing ones to their corresponding properties. Thus, the weaving classes fill the gap between the city modeller and the domain specialist (here: flood analyst) and enable sharing and enrichment of geodata. In addition to that, the weaving model provides the domain specialist with detailed statistical results of what attributes the city model can provide and what is lacking.

In addition to that, IMF allows stakeholders to formally describe their ‘formulae’ and relates them to the corresponding geospatial objects. This, in turn, enables for indicator re-usability among different domains. Also, there exist various representation techniques and methodologies for indicators (Wetzstein et al. 2008; Zapata and Gil 2011; Rojas and Jaramillo 2013). This, however, increases the chances for a lack of comprehensibility and extendibility. A unified representation of indicators assists in overcoming the aforementioned concerns. Moreover, it allows representation of indicators that are hidden in documents that have not been explained before. Hence, this allows indicators to become more understandable and comprehensible across various geospatial domains by domain specialists.

7.2. Connectivity to various modelling frameworks

Within this research paper, we introduced a novel indicator modelling framework for representing flood damage and its impact on the individual building level, as well as district and city level. Also, IMF is demonstrated using a real-life use case for linking the indicator model expressed by the flood analyst for measuring building replacement costs with the geospatial application schema.

In addition to that, model weaving concept, which acts as a bridge between the geospatial application model or the geobase data and the indicator models or domain specialists’ domain, was employed. It aims at effectively setting the object context or reference frame of the individual indicators and providing means to automatically derive the values of those indicators from characteristics and attributes of the linked spatial objects. This, in turn, on the one hand, helps in the automatic derivation of semantic and sensitive geospatial attributes from the urban city models to the KPI classes depending on the data availability. On the other hand, it helps in enriching the geospatial application model with indicators.

7.3. Automated domain-specific metadata generation

The output of the weaving generates an XML with derived and underived attributes and their type (XML 2). These indicate the attributes present within CityGML that match the needs of the domain specialist as well as an indication of which attributes are missing. This has a two-fold advantage: it generates metadata for the CityGML model, indicating which attributes are present and this leads to the second advantage, it helps the domain specialist determine whether the model is appropriate for their analysis, a fitness-for-purpose analysis. A further advantage is that certain attributes themselves are generated during the weaving process such as the number of buildings and the total floor area of the buildings for the study area, and these are easily calculated during the weaving process and can be recorded in the metadata. The domain-specific metadata generation, generated in XML, can then be easily integrated with other geospatial metadata standards, for example, integration with ISO 19115 is possible through the Metadata Extension Information class. Furthermore, this can be combined with the CityGML metadata ADE (which supports extendibility) to have extensive metadata support for flood modelling specialists (Labetski et al. 2018).

XML snippet 2: Output after weaving HAZUS model with CityGML – Required categories are omitted for space reasons but are all accounted for in the Derived and Underived Attributes tags

<GeneralIndicatorModel>

<FloodCausedReplacementCost>

 <Analysis>

  <NumberOfBuildings> 5</NumberOfBuildings>

  <TotalFloorArea unit=‘square feet’>6146</TotalFloorArea>

 </Analysis>

 <RequiredAttributes>

  <xs:annotation>

   <xs:documentation>

    These are the attributes that are required by the flood analyst, in order to perform their building replacement cost equations caused by floods.

   </xs:documentation>

  </xs:annotation>

  […]

 </RequiredAttributes>

 <DerivedAttributes>

  <xs:annotation>

   <xs:documentation>

    These attributes/parameters have been weaved/derived from the geodata provider.</xs:documentation>

  </xs:annotation>

  <FloorSurfaceArea dt:type=“area”/>

  <HouseType base=“xs:string”>

   <OneStorey/>

   <TwoStories/>

   <SplitLevel/>

  </HouseType>

  <ElevationOfBaseHouse dt:type=“length”/>

  <WaterLevelHeight dt:type=“length”/>

 </DerivedAttributes>

 <UnderivedAttributes>

  <xs:annotation>

   <xs:documentation>

    These attributes/parameters have been added manually and were lacking and were not successfully weaved/derived from the city model.

   </xs:documentation>

  </xs:annotation>

  <BuildingConstructionClass base=“xs:string”>

   <Economy/>

   <Average/>

   <Custom/>

   <Luxury/>

  </BuildingConstructionClass>

  <BasementStatus base=“xs:string”>

   <NoBasement/>

   <Unfinished/>

   <Finished/>

  </BasementStatus>

  <GarageType base=“xs:string”>

   <OneCar/>

   <TwoCar/>

   <ThreeCar/>

   <CarPort/>

   <None/>

  </GarageType>

 </UnderivedAttributes>

</FloodCausedReplacementCost> </GeneralIndicatorModel>

7.4. Conclusion

Based on the MDA principles, IMF allows for automatic code generation and eases software application schemas generation, which can be used for testing purposes. IMF allows for comparability between different geospatial data models and validation of which one fits which domain the best. The proposed study allows for the investigation of the relationship between the GIM and any given geospatial application schema in a formal way. For example, it can validate how well aligned the geospatial application model and the domain specialists defined indicators are. Further, it notifies the geodata provider as to which missing information is required by the domain specialists, in order to be able to perform their computation. Also, it allows for the augmentation of the information required by the domain specialist that is not stored in the geospatial schema, in the weaving classes. All of these elements that are automatically generated by IMF can then be saved as metadata. Consequently, the findings of this specific area of the research study point out that the level of augmentation can be treated as an indicator as well. It helps us in better understanding how the geospatial data schema should be extended, in order to become used in computation in a particular domain.

Based on this research work, the weaving model has the ability to work with heterogeneous geospatial data models, in order to link the information from the geodata model, such as CityGML and INSPIRE to the domain specialist to apply their computations. Future work will focus on dynamising the weaving model, and we will explore different models, such as hydrodynamic modelling. Furthermore, the missing attributes/values from the geodata provider that are currently added statically to the weaving classes can be used to compare different data models to allow for sensitivity analysis. This ability is currently being explored.

Acknowledgements

The authors wish to thank Tatjana Kutzner (TU München) for her valuable contribution in developing the Indicator Modelling Framework. The authors would also like to thank Thomas H. Kolbe (Technische Universität München), Hugo Ledoux, and Jantien Stoter (Delft University of Technology) for their guidance and helpful discussions concerning this paper. Finally, thanks to the reviewers for their helpful comments to bring the final paper together.

Disclosure statement

No potential conflict of interest was reported by the authors.

Additional information

Funding

This project has also received funding from the European Research Council (ERC) under the European Unions Horizon 2020 research and innovation programme (grant agreement No 677312 UMnD).

Notes

1 https://www.cityjson.org/

2 https://sparxsystems.com/products/ea/index.html

3 https://shapechange.net/

4 https://www.maps.google.com