Introduction
Floods have caused severe damage in many regions of the Earth, including many human losses. They have been the most frequent cause of natural disasters between 1998 and 2017, as CRED [
1] reported. There have been changes in the frequency and magnitude of floods, including an increased severity, for instance, as reported to Central and North Europe [
2], based on numbers by Hall et al. [
3] and Hamidifar and Nones [
4]. Flood risk management consists of several stages, including prevention, protection, and preparedness before the event, and response and recovery measures following the event [
5,
6].
Concerning prevention and protection, it is fundamental to know the hydrological characteristics of the catchment and, in particular, the hydrodynamic consequence at critical river reaches in the case of rainfall events. To reduce the flood magnitude, it is necessary to investigate the best practices, notably land use management, urban planning, and soft engineering measures [
7,
8]. Flood maps can be created using hydrological and hydrodynamic tools validated with historical records and flood landmarks. These maps depict the extent of inundation and quantify flood hazards for various rainfall scenarios. Flood protection can be achieved through complex engineering measures, such as building dams to curb flood peaks, building dikes along river margins to contain the flow, and changing the river morphology, among other strategies [
9,
10]. These measures are generally avoided and replaced by building techniques that reduce vulnerability, increase resilience [
11], or enforce prevention measures. To decide the adequate protection or prevention measures, simulations of different protection scenarios must be conducted and analysed with specialized hydrological and hydrodynamic tools. Preparedness includes the effective communication of the flood severity to all involved stakeholders, including the general population, media, state agencies, or decision-makers (e.g., at water authorities and civil protection organisation levels) [
12], and ensuring that responsibilities, chains of command, and eventual self-protection actions are clear to all [
13,
14].
Early warning systems provide a framework for preparedness and put in practice response protocols [
15,
16,
17]. If a flood is imminent or already occurring, it is encoded in these systems when entering alert mode and when and to whom issue warnings. Most commonly, early warning systems rely on data from sensors, e.g., sensors of water levels located at strategic points, with calibrated thresholds to indicate the onset of a flood. Ideally, early warning systems should combine monitoring (sensed) interpretation with the flood forecasting and nowcasting capabilities of hydrologic and hydrodynamic simulation tools [
18,
19,
20], as the latter may provide a better spatialisation of the flood hazard. Activities related to recovery (“build back better” with applications such as discussed by Dube et al. [
21]) may also involve flood simulation tools to support the planning of structural or socio-political solutions that could improve the resilience of riverine communities.
While planning for flood resilience (prevention, protection, and preparedness) is very different from forecasting or nowcasting within early warning systems, these activities rely on analysing available hydrological data and hydraulic modelling, even if at different time scales, georeferencing and data curation is paramount. This justifies that data display, data management, and articulation with numerical simulation tool results should occur on GIS platforms. The tasks of conveying available input data to carry out hydrodynamic modelling, possibly combined with the assimilation of input data, and collecting and organising results into datasets ready to be interpreted by decision-makers, should be done within decision support systems designed with GIS technology. Data curation should be implemented and embedded in these systems through services compatible or aligned with the Open Geospatial Consortium (OGC) standards, such as the WaterML [
22] or SensorThings [
23] specifications.
As further discussed in Section 6, some examples of GIS technology are employed to make flood maps available for preparedness and planning, build platforms to handle flood-related information, including forecasts and nowcasts, and support emergency response activities. Web GIS platforms operate at global, transnational, national and regional levels. For instance, at a worldwide scale, the Copernicus Management Service offers the Global Flood Awareness System [
24] to support preparatory measures for flood events and the Rapid Mapping service to help emergency management activities in the immediate aftermath of a disaster [
25]. There are platforms for the different flood risk management at national or regional levels that combine observations and numerical simulations, albeit under other concepts and modes of articulation. In some cases, these systems are akin to an industrial SCADA where only sensed monitoring data determines the alert level and sends out warnings [
26]. Other platforms include hydrological modelling to refine forecasting and even nowcasting scenarios [
27,
28,
29]. However, given the computational cost of hydrodynamic modelling, its use is rare in nowcasting, and its outputs are usually unarticulated with monitoring data. Hydrodynamic modelling is mainly employed for planning [
30] to generate surrogate models [
20] and to generate awareness in the preparedness stage of the flood risk mitigation cycle [
31]. The degree of sophistication of GIS platforms tends to increase due to advances in Web and modelling technologies and improvements in data sensing, where curation and analysis become available. One future direction is the deliberate construction of digital twins for each risk-prone area. However, digital twins are only viable if a comprehensive sensor network exists [
32]. Another future direction is increasing the versatility of GIS platforms, accounting for the need to conduct planning activities in ungauged (or un-sensed) river networks or the desire to accommodate the ever-growing amount of informally sensed data.
To fully leverage the advantages of recent advances in Web and GIS technologies, in social sensing and high-performance computing, and by an envisaged wider availability of remote sensing data, we argue that a new family of software tools is needed for versatile Web GIS platforms for flood risk management. This paper addresses this research need: it proposes a specialised Web GIS platform, named “RiverCure Portal”, shorthand “RCP”, that combines the definition of geographic contexts with sensed data and hydrodynamic modelling tools for the risk assessment, prevention, emergency preparedness, and operational response stages of the flood risk management cycle. The RCP is designed to make efficient and systematic use of crowdsourced (or socially sensed) and authoritative data in the form of curated outputs of sensing instruments, or data from virtual entities that conjoin lower-level modelling results or other types of information not directly acquired by physical instruments. At this stage, RCP integrates a flood simulation model, the HiSTAV tool [
33], but it is designed to incorporate others in the future if necessary. RCP offers complex features and workflows to make hydrodynamic models more accessible to domain experts and other stakeholders such as decision-makers, researchers, or even students. RCP is designed as a multi-organisation, multi-context digital platform and includes a flexible model to define and support multiple sensor types, which satisfy the needs of diverse organisations. Ultimately, the RCP generates flood risk information that can be disseminated through different stakeholders at local, regional, national, or even supra-national levels.
This paper presents the key design aspects of the RCP system and is structured in the following sections. Section 2 introduces the general principle of the RCP and the involved technologies, stressing its cohesive integration with hydrodynamic simulation tools. Section 3 presents the main concepts of RCP, from a user perspective, including sensors, contexts, and the context's geographic features and events. Section 4 describes the operational aspects inherent to the RCP approach. It briefly introduces a running example named as “Águeda 2016 flood” event. This supports the explanation and discussion of operations such as defining a context and respective geometries, associating sensors to the context, generating the mesh, and creating, running, and analysing simulation events. Section 5 presents and discusses the related work. Finally, Section 6 presents the main conclusion and open issues.
RCP main concepts
The main concepts involved in the design of the RCP are sensors, contexts, context's geographic features, and events. All these concepts are managed in the workspace of a given organisation; however, for the sake of simplicity, not all aspects (e.g., organisations, users and roles, hydro features, sensor classes) will be thoroughly discussed in this paper.
As suggested in
Figure 2, the context is the top-level concept with several properties and geographic features. Complementary, organisations set up and manage different types of sensors deployed in some geographic place, thus being associated with one or more contexts. Real or simulated events (e.g., flood, heavy precipitation, storm, tsunami) occur in the scope of a context, have multiple properties, and use sensor observations that provide useful data streams. In the following paragraphs, we offer a comprehensive analysis of these concepts.
Contexts. A context (or geographic context) represents a geographic area relevant to modelling and analysing flood events. A context is usually associated with a hydro feature (a river, river basin, estuary, lake, etc.). It has a name, privacy level (i.e., public or private), assigned sensors, and several geographic features (see below for further details).
Geographic Features. To properly define the geographic scope of a context and ensure a visual representation, it must have several mandatory features that need to be manually defined or imported by the user.
Figure 3 summarises these geographic features and their respective multiplicity constraints, including Domain, Refinement, Alignment, Boundary Line, Boundary Point, DTM (Digital Terrain Model), and Mesh.
The definition of the features represents the visual aspect of a context. While the DTM also has a visual representation within the context, it is not a geometry but a raster, and therefore cannot be defined by the user. Instead, it must be uploaded as a raster file format. The structure of these geometries is similar since they follow the same design principles: they are all geometries that the user can define by simply drawing on the map. However, the definition of these geometries is subject to two geographic constraints: (i) the domain geometry must contain all the other geometries inside its boundaries, and (ii) the boundaries of these geometries cannot intersect each other under any circumstance. Each feature is further described in the following paragraphs.
Geographic Features: Domain. The Domain geometry represents the general area that is analysed for potential flood risk of the flood, and is typically the first geometry defined by the specialised user. The refinement and alignment geometries must be contained within this geometry while the other two geometries, boundary and boundary points, must be on the boundary line. A context can only have one Domain, which is defined as a single Polygon. The Domain has only one property: the cell length (CL) represented by a float number and defined by the user.
Geographic Features: Refinement. The Refinement geometry is a polygon that must be contained within the Domain geometry. Typically, it is defined around the river's area of interest that should also be included inside the polygon. However, some rivers may have tributaries or other features requiring multiple polygons to accurately represent the pre-processor geometry and input. Unlike the Domain, multiple refinement definitions can exist within the same context, optionally nested inside each other, with each defined by a polygon with individual property values. The only property of this geometry is also named CL, and if multiple refinements are defined for the same Context, each refinement has its own CL value. To improve accuracy, the user can change the resolution of the computations by specifying refinements in the context.
Geographic Features: Alignment. The Alignment is a LineString geometry (i.e., GeoPolyline) that must be contained within the Domain and usually represents the path of a river. It can be seen as drawing the river on the map as a LineString. Similarly to the refinement, it might be necessary to define several alignments for a context if tributaries and other river features exist. A context can have several alignments as long as they do not intersect each other. Unlike refinements, which require at least one to be defined, alignments are optional if the refinements provide enough detail to create the Mesh grid. The user can assign a single property to Alignments, called CL.
Geographic Features: BoundaryLine. The Boundary is defined by a LineString (i.e., GeoPolyline) and must be overlaid on the domain boundaries. All its points must be points used for the domain definition. Consequently, it is defined by joining at least two sequential points from the domain. If the points are not sequential, the simulation will not be performed correctly. In almost all cases, a context has more than one boundary. The user can define several boundaries for a context as long as they do not overlap or share any points. Each boundary has two properties: the type and the data type. Both properties are multiple-choice fields and are defined by the user after defining the boundaries. The type can be either Input, Output, or InputOutput. Regarding the data type, the choices are “H” for depth, “Q” for discharge, “Z” for elevation, and “V” for velocity. When converting this geometry to geojson, each geometry is transformed into a feature, and each feature has its LineString geometry and properties with corresponding values.
Geographic Features: BoundaryPoint. Boundary Points are points from the definition of boundaries, which are automatically created when boundaries are created. One Boundary Point is designed for each vertex of the Boundary geometry. Each Boundary Point has one property named series representing an association of the boundary point to a sensor, which becomes a context sensor (described later). The association is defined by selecting a sensor from a boundary point popup interface within a specified distance to the Boundary. The length for possible sensors association is also defined in this popup interface.
Geographic Features: DTM. The DTM is a topographic model of the bare Earth. It contains the elevation data of the terrain in a digital format modelled as a rectangular grid [
20]. The DTM is mandatory and used for two main reasons. On the one hand, it is a useful visual aid for specialised users when defining a context. As such, they shall add a DTM and represent it on the same map where they draw the context. On the other hand, the DTM is used at a pre-processing stage whereby each discretisation cell is assigned a topographic elevation and other relevant parameters for hydrodynamic simulation (see Mesh).
Geographic Features: Mesh. The Mesh discretises the domain into cells, dividing the area in calculation units, where the model outputs are obtained. The size of these cells may vary in space, and they may have triangular or other polygonal shapes. For HiSTAV, an unstructured triangular mesh is used with a variable resolution.
Sensors. A sensor is a device, module, machine, or subsystem that detects events or changes in its environment and collects them as a given set of observations. Usually, sensors are physical devices that convert signals from one energy domain to an electrical domain (and then to a digital domain). In RCP, sensors represent commonly hydrometric devices located inside or near the geographic boundary of the context, usually near the respective river. A sensor collects multiple observations according to some frequency or in an ad-hoc way; each of these observations represents the measurement of some quantity (e.g., length, weight, velocity) according to some predefined metric (e.g., mm, cm, m, kg, g, m/s). In RCP, each sensor element has a code, name, description, visibility, status and is aligned with a sensor class (defined by the organisation manager), which defines the relevant observation's properties. Currently, the most common sensors for shallow-water solvers are of the class “Hydrometric Sensor”, which collect observations based on the properties “Depth” and “Discharge”. For the current uses of HiSTAV, rainfall must be converted into discharge outside the RCP, through hydrological modelling. If other hydrologic/hydrodynamic solvers are to be embedded in the RCP, sensors can be set up to input directly udometric data.
Events. A context has several events that reflect a significant set of actions and occurrences during a given period in that geographic area and are commonly associated with extreme natural accidents. In RCP, an event is defined by a name, a start and end date-times, a description, and other simulation-specific properties (e.g., return period, warm-up). Moreover, an event is classified as a type, e.g., flood, heavy precipitation, hydrological drought, hurricane, tsunami; and sub-type, e.g., hindcast, forecast, nowcast, or planning. A
hindcast event represents the running of a model for a historical period or event, calibrating the model and evaluating the simulations' fidelity, or obtaining thresholds for variables of interest and their probability of exceedance. A
forecast predicts the context state in the future, and a
nowcast applies to the current state and a few hours in the future. A
planning event is a simulation based on inputs (discharge or rainfall) with a given probability of exceedance or return period (Detailed definitions are given in
Appendix A).
RiverCure approach and using the RCP
The approach supported by the RCP is summarised by the process illustrated in
Figure 4 (in BPMN notation). This process consists of the following main tasks: (T1) Define Context and Geometries, (T2) Associate Sensors to Context, (T3) Generate Mesh, (T4) Create Simulation Event, (T5) Run Simulation Event, (T6) Analyse Simulation Event.
Figure 4 suggests that the RCP directly supports these tasks. In contrast, Tasks T3 (Generate Mesh) and T5 (Run Simulation Event) are supported by the joined interaction of RCP with the hydrodynamic simulation tool HiSTAV.
The Águeda 2016 flood: A running example
The RCP has been validated by defining, modelling, and simulating multiple geographic contexts and associated flood events. To support our discussion, we introduce the February 2016 flood in River Águeda as a running example (herein, “Águeda 2016 flood” event for short). It describes the flood that occurred between the 9
th and the 13
th of February 2016 in the Portuguese river Águeda.
Figure 5 shows a photo of downtown Águeda during the peak flood on the 12
th of February. The Águeda city is regularly flooded by the river with the same name, on some occasions causing critical damages. As a prone flood area, Águeda municipality had invested considerably in its flood protection. For instance, in 2015, around two million euros were dedicated to constructing a secondary river channel to divert the main river flow. However, those efforts were not enough to prevent the severe flood event of February 2016, considered the most significant flood of the previous 15 years.
This flood resulted from heavy precipitation associated with strong instabilities in the North Atlantic (see
Figure 6). It caused significant disturbances in Águeda city, affecting mobility, public services, and its main infrastructures. This flood revealed weaknesses in the flood defence infrastructure of Águeda. As seen in
Figure 5, the river's water level was below the crest of its containing walls, almost everywhere. Yet, the perimeter had two weak points from which the flood could propagate to the urban mesh. Also, the pumping system employed to drain the accumulation of pluvial waters was not functioning during this period.
The complete dataset of this “Águeda 2016 flood” event is publicly available [
67], and there is a companion paper that provides an explanation and instructions for independent researchers to be able to replicate the experiment [
68].
Define Context and Geometries (T1)
To simulate flooding events on the RCP, the first step is to define the context and the corresponding geometries. The context represents the geographic scope (i.e., a bounding box) that contains the area under analysis. Once the context is defined, the next step involves defining the necessary geometries, such as the Domain and Refinements polygons, Alignment, and Boundary lines and points. To create these geometries, the user must select the “Geo Edit” button, in the RCP context interface, which activates the edit mode. There are two approaches to creating the geometries: (i) create them outside of RCP, save each of them in a separate file using the geoJSON format, and upload them through the available form (i.e., each geometry has its specific upload space in the form), or (ii) draw the geometries directly in the map by selecting the “Define manually” button, which activates the edit mode inside the map and allows the user to define each of the geometries manually. A hybrid option is also available, allowing the user to manually upload some geometries and create the missing ones. Apart from these geometries, it is mandatory to upload a DTM raster file, and optionally, a friction coefficient raster file, which allows changing the default coefficient set up otherwise.
After adding the geometries, the user must validate them to comply with predefined spatial relationships' requirements. For example, all geometries must be fully contained within the domain, and boundary lines must coincide with domain segments.
Figure 7 illustrates an example of a context created for flooding simulation in the Águeda region of Portugal, including the Domain, Refinement, and Alignment geometries.
Associate Sensors to Context (T2)
Sensors can be crucial in providing relevant and timely data for flood simulations. If they exist within the context, they can be associated with the domain to improve flood simulations. Sensors must be within a reasonable distance from the Domain geometry and can be related to the Boundary points located at the entry or outflow of the domain. Besides, sensors must either belong to the user's organisation or be publicly available; otherwise, they will not be available for use in the simulation.
As suggested by
Figure 8, to associate a sensor to a specific Boundary, the user needs to activate the edit mode by selecting the “Geo edit” button from the context interface, and then select the Boundary point to which the sensor will be attached. This operation will open a popup window connected to the selected point. The user can choose a sensor from a list of available options and add it to the selected Boundary point or line. The user must also define the type of boundary associated, such as input discharge, transmissive, or constant water level, and link a time series of the measured variable to the boundary.
Generate Mesh (T3)
After fulfilling the previous tasks (i.e., adding and validating the geometries and sensors, which are mandatory), the next step is related to generating the calculating units. In the two-dimensional case, this amounts to generating a computational mesh. Generating the mesh is performed by an appropriate software tool (e.g., Gmsh,
https://gmsh.info/), but the user needs to request it from the context interface in pre-processing step. After requesting the mesh generation, the user can track the progress since this task might take some time to finish, depending on the area under simulation and the spatial resolution set by the domain, refinements, and alignment. Generally, mesh generators allow for gradual and smooth transitions in mesh resolution. The finer mesh is used in the river network and areas of interest, while coarser meshes are used in areas seldomly inundated. Only when the mesh is generated can the user proceed to the next step, creating simulation events.
Create Simulation Event (T4)
The user can now define simulation events after creating all the needed geometries and mesh. The user must select the “Events” option from the context interface and create the event in the following window by filling up the displayed form shown in Figure 9. To create the simulation event, the user must define the name for the simulation, the type of simulation (i.e., by selecting from a list of available types such as, for instance, flood, heavy precipitation, among others), the start and end date and time, the writing and update maximum value periodicities (i.e., how frequently the model will output maps of the hydrodynamic variables and register the maximum at a given cell) and time unit. Besides these mandatory elements, other optional elements can be filled up, such as the return period (i.e., a measure of probability or how frequent this flood event is expected to be), the subtype (e.g., forecast, hindcast, or planning), and description.
In this example, as shown in
Figure 9, it was created the event “Águeda 2016 Flood”, defined as a hindcast (SubType) Flood (type) for the period between 2016/02/08 and 2016/02/16.
Run Simulation Event (T5)
As discussed in the previous section, end-users can run (or re-run) the simulation based on the defined simulation event, as shown in
Figure 10. This complex operation sends all the relevant data (i.e., the mesh, top-bathymetric data, configuration data, and boundary conditions) to run the simulation by the hydrodynamic simulation tool. Then, this tool produces the simulation results as maps of hydrodynamic variables values at the mesh points. Because this operation can take an extended period (depending on the size and resolution of the geographic context), end-users can monitor the progress of the simulation event by selecting the appropriate option, as illustrated in
Figure 11, which shows the different steps and their respective progress.
Analyse Simulation Event (T6)
The RiverCure approach's final task is analysing the simulation event (Task T6). The event outputs a time series of maps of water depth, elevation, and velocity, including the maximum values registered throughout the event. This output allows the analysis and evaluation of elapsed time between the beginning of the flood at river basin headwaters and the reaching of an alert water level at a location of interest.
Figure 12 shows the most affected area by this “Águeda 2016” flood event, which peak occurred at 5 PM on February 13th, 2016, and had a total impacted area of 3.813.000 m2.
Post-processing can produce maps of the dangerousness of the flood, calculated as the product of the depth and velocity or some other combination of variables. Thus, as intended by the proposed approach, comparing flood extents and dangerousness to satellite images, building cadastre and roadways can estimate economic damages and disruption, displacement of populations, and loss of life.