A Web GIS Platform to Modeling, Simulate and Analyze Flood Events: The RiverCure Portal

Abstract

Flood events are becoming more severe, causing significant problems to human communities, including physical, psychological, and material damage. For both flood forecasting in emergency response situations and flood mapping, georeferencing and data curation are paramount in the context of prevention or preparedness. Hence, data display, data management, and articulation with numerical simulation results must occur on GIS platforms. Our research is motivated by recent advances in Web and GIS technologies, social sensing and high-performance computing, and an envisaged wider availability of remote sensing data. This paper presents and discusses an innovative Web GIS platform named “RiverCure Portal” or “RCP” for short. This platform combines observations and hydrodynamic modelling tools to support various stages of the flood risk management cycle, including operational response, emergency preparedness, and risk assessment. RCP is a multi-organization, multi-context digital platform with flexible configuration features to define and support multiple sensor types and modelling options, satisfying the various needs of different organizations and stakeholders. In addition, this paper discusses the RiverCure Approach, which encompasses the following tasks directly supported by the RCP platform: defining the context and involved geometries, associating sensors to the context, pre-processing and generating the context mesh, defining the simulation event, running the simulation event, and analyzing the results from the simulation event. Thus, the RCP streamlines and simplifies data analysis and simulation procedures to meet decision-makers’ needs. The novelties discussed in this paper include the design and discussion of a Web GIS platform that allows (i) to manage flood data and results of simulations at several contextual levels by different stakeholders such as domain experts, decision-makers, researchers, or students; (ii) to process and curate sensed data obtained from physical and social sensors; and (iii) update the state and values of the parameters of simulation tools through continuous data assimilation techniques for forecasting purposes. Finally, this paper supports the explanation and discussion with a running example, “Águeda 2016 flood” event, which dataset is publicly available for further study and experimentation.

1. 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 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 to 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 those 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, and 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 and multi-context digital platform, and it 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.

2. RCP Overview and Technologies

2.1. Overview

In general, to set up simulations of hydrodynamic simulation tools, the main steps are (see Section 4 for further details): (i) collection and preparation of topographic, bathymetric and land cover data; (ii) definition of the geometry of the region of interest (herein the context) and discretization of the area of interest into calculation units; these may be cells of a regular grid or of an irregular polygonal grid (the case of two-dimensional simulation tools); they may be cross-sections of river in case on one-dimensional modelling; in exceptional cases, calculation units may three-dimensional (usually parallelepipedic with polygonal bases); (iii) collection of hydrological and hydraulic data; (iv) definition of boundary conditions from the time series of hydrological and hydraulic data such as discharges and water levels in the inlets and outlets of the area of interest, to be made available as hydrometric data via virtual sensors; (v) definition of the initial conditions inside the domain; (vi) simulation event creation and configuration of numerical options, model parameters such as resistance coefficients, frequency and location of model outputs, etc.; (vii) running the simulation event and; and (viii) post-processing, visualization and mapping of flood exposure, hazard and derived products. Figure 1 suggests this general process (in BPMN notation).

The RiverCure Portal (RCP) is a collaborative Web GIS digital platform streamlining most of the above steps. RCP allows multiple users and organizations to set up and manage their geographic contexts, set up the sensors that feed information through the boundaries of the geographic area of interest, and create and run simulation events; thus, RCP is a sophisticated tool to manage the flood risk of these contexts.

The RCP is currently available at http://rivercure.inesc-id.pt (last accessed on 1 June 2023); the interested reader can create his user account on this website and request specific access to manage his contexts and events directly.

2.2. Supported Technologies

RCP has been developed using Web and GIS technologies, namely Django and GeoDjango as the Web framework with geospatial capabilities (based in Python), and PostgreSQL and PostGIS for data storage.

Python is a versatile interpreted programming language used for various purposes, including web development, machine learning, and complex data analysis. It has a vast set of open-source libraries that provide functionalities such as creating geojson files programmatically, which is the standard format chosen for geographic data exchange between RCP and the hydrodynamic simulation tool. Additionally, Python is compatible with major platforms and paradigms, essential to leverage the integration with external systems.

Django is a high-level Python web framework for rapid development and clean and pragmatic design [34,35]. It is focused on developing web applications following a model–view–controller (MVC) architecture. Django design is based on three main principles [36]: Do not repeat yourself (DRY); explicit is better than implicit; and loosely coupled architecture. Additionally, a vast set of data formats, especially GIS formats, are supported by GeoDjango [37].

GeoDjango [38] is a contributed module for Django [35] that turns it into a world-class geographic Web framework, facilitating the development of geographic web applications dealing with location-based services [37]. Its features include (i) Django model fields for OGC geometries and raster data; (ii) extensions to Django’s ORM (default object-relational mapping layer used to interact with data from various relational databases) for querying and manipulating spatial data; (iii) a loosely coupled, high-level Python interfaces for GIS geometry and raster operations and data manipulation in different formats.

PostgreSQL with PostGIS was the chosen database management system (DBMS), which has the highest compatibility with GeoDjango [39]. Most GIS DBMS allow performing geographic operations such as the intersection of polygons, checking if a geometry is contained inside another, retrieving the overlapping area of different polygons, or transforming between other coordinate reference systems performed on the DBMS layer. However, it is sometimes necessary to perform these operations on the application layer. Either because the data must be treated before being stored on the database or because the information being calculated is temporary and is not stored on the database. For this purpose, Geodjango integrates geospatial libraries capable of manipulating spatial data such as GDAL [40] and PROJ [41].

2.3. Embedded Hydrodynamic Tools

The RCP platform incorporates hydrodynamic and morphodynamic simulation tools that enable the delineation of flood areas and the determination of water levels, flow velocities, and bed elevations. These simulations also provide insights into flow severity. As shown in Figure 2, RCP is currently integrated with HiSTAV [32,33], a high-performance computing tool specifically designed for faster-than-real-time high-resolution simulations. HiSTAV leverages parallel, distributed, and graphics-based computing technologies and seamlessly integrates with open-source geographic information systems and scientific visualization toolkits for efficient data handling and analysis.

HiSTAV, originally named “High-Performance Version of Strong Transients in Alluvial Valleys”, is applied in various water resource domains. To properly use HiSTAV, a collection of geometries and raster resources is required, including domain, refinement, alignment, boundaries, and boundary points geometries, as well as digital terrain model (DTM) and friction coefficient rasters for any simulation context.

While HiSTAV is a standalone product widely available to engineering and research communities in the water resources field, RCP is designed to be compatible with other hydrodynamic simulation tools, allowing for seamless integration and collaboration.

3. 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, and sensor classes) will be thoroughly discussed in this paper.

As suggested in Figure 3, 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 4 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. Similar 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 input–output. 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 sensor 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 into 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, and 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 collects 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).

4. RiverCure Approach and Using the RCP

The approach supported by the RCP is summarised by the process illustrated in Figure 5 (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 5 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.

4.1. 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 9th and the 13th of February 2016 in the Portuguese River Águeda. Figure 6 shows a photo of downtown Águeda during the peak flood on the 12th 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 7). 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 6, 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. In addition, the pumping system employed to drain the accumulation of pluvial waters was not functioning during this period.

4.2. 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 setup 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 8 illustrates an example of a context created for flooding simulation in the Águeda region of Portugal, including the domain, refinement, and alignment geometries.

4.3. 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. Additionally, 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 9, 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.

4.4. 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/ (accessed on 22 June 2023)), but the user needs to request it from the context interface in a 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 seldom inundated. Only when the mesh is generated can the user proceed to the next step, creating simulation events.

4.5. 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 10. 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. In addition to 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 10, it was created the event “Águeda 2016 Flood”, defined as a hindcast (SubType) Flood (type) for the period between 8 February 2016 and 16 February 2016.

4.6. 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 11. 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 12, which shows the different steps and their respective progress.

4.7. 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 13 shows the most affected area by this “Águeda 2016” flood event, which peak occurred at 5 PM on 13 February 2016, and had a total impacted area of 3.813.000 m².

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.

5. Related Work

Some initiatives have used or integrated Web GIS technologies to manage flood-related information to support flood resilience, preparedness, emergency response, or recovery activities. The following sections discuss these platforms and initiatives at a global, transnational, national, or regional level.

5.1. Global-Level Initiatives

On a global scale, remote sensing from Earth observation satellites (e.g., from Program Copernicus or NASA), combined with numerical weather prediction, allows platforms to support flood preparedness and awareness worldwide, particularly in large transnational river basins. This is the case with the Global Flood Awareness System [24], one Copernicus Management Service CEMS component. Its forecasts are produced from 51 datasets of the ECMWF NWP approach [42]. The resolution of each dataset is 18 km, up to 15 days. The results of the meteorological forecasts (mostly precipitation) are used to force a distributed rainfall-runoff routing model LISFLOOD [43]. LISFLOOD is a hydrological rainfall-runoff model that uses a kinematic wave approach for flood propagation in the river network. However, the level of temporal (it calculates the complete water balance at a 6 h time step) and spatial detail (5 km grids) of LISFLOOD does not allow its use at local scale exposure.

A different Web-based platform is the NASA Global flood mapping initiative [44], based on the Global Flood Mapping System that uses MODIS Water Product to generate maps that identify regions undergoing floods. Their products are available online in both raster and vector formats. However, this initiative will be terminated in 2022 and be replaced by the LANCE flood product.

In the scope of the Copernicus Emergency Management Service, Rapid Mapping and Recovery Mapping are geospatial information systems with products to support emergency management activities immediately following natural disasters, including floods. Other global platforms such as these are discussed in [16,45,46,47].

5.2. Transnational-Level Initiatives

At a transnational level, there are systems such as the European Flood Awareness System (EFAS) [48], a platform from which the GloFAS or the African Flood Forecasting System have evolved [49]. These platforms provide services for the forecast and response phases of the flood management cycle. EFAS system entails a hydrological model and monitoring network, mainly aimed at large transnational river basins in Europe. It couples weather forecasts to the LISFLOOD hydrological model, giving national and regional authorities short to medium-range flood forecasts (i.e., 6 h to a day to weeks), flash flood indicators, and rainfall data. The spatial resolution of the mapping outputs is low (i.e., 1 to 5 km). Thus, no accurate hydrodynamic model exists, and the monitoring focuses on gauges and remote sensing. Nevertheless, the EFAS contains useful hydrological predictions that a hydrodynamic model could use.

None of these Web-Gis platforms is meant to assess local flood risks or provide a detailed account of the hydrodynamics of flood-prone river reaches, as proposed in this paper. They are aimed for use by national authorities as an additional information source or to embed in their early warning systems. They have little interaction with other users or with citizens in general. They do not provide the generic concept of “context” as proposed in the RCP: a geographic region of interest affected by one or more flood-prone rivers for which the terrain is modelled with great detail. Instead, they use globally available digital elevation models but simplified approaches to determine flow levels. In the case of the CEMS system, partner institutions are given flood alerts if the flow levels are above predetermined thresholds in the critical regions under their jurisdiction.

5.3. National and Regional-Level Initiatives

At a national and regional level, there is also a broad spectrum of Web GIS platforms [50,51], which differ in what concerns their primary use: early warning systems focused on emergency response, including issuing alerts and warnings; or preparedness, with a focus on risk assessment.

An interesting example of a platform that can be used for both planning and early warning is the IFIS (Iowa Flood Inundation System) [52]. IFIS is a comprehensive decision support system used by the State of Iowa in the United States that provides real-time information on streams and weather, forecasts, maps, and damage estimates for floods, among other functionalities. IFIS has augmented reality features to raise awareness and inform decision-makers, projecting holographic visualisation of inundation in some locations. As with the RCP, the IFIS allows customisation for specific objectives of different stakeholders and geo-locations. However, unlike the RCP, IFIS’s flood mapping abilities are not built around the combination of sensed data and hydrodynamic mathematical modelling. A hydrological model is currently under testing [53] but, unlike the case of the RPC portal, IFIS does not offer the possibility of running hydrodynamic simulations, of creating new contexts for numerical forecasting, and associating sources of data to force numerical simulation tools, either for planning or forecasting. Furthermore, IFIS lacks the RPC capability of defining and integrating new physical or social sensors that pipeline new data sources. Overall, compared with the RCP portal, it provides a broader range of products and visualisation tools, but less control to the end-users, notably the possibility of contributing and managing data and associating numerical simulation tools, particularly to aid flood forecasting or nowcasting.

Concerning early warning systems, some platforms offer a combination of the following features: the ability to (i) receive and analyse sensed rainfall data; (ii) convert rainfall data into runoff through calibrated hydrological modelling; (iii) receive and analyse sensed hydrometric data; (iv) conduct hydrodynamic numerical simulations forced with hydrometric data or other hydrological data; (v) translate the results of a combination of numerical results and sensed data into parameters that may be communicated to authorities to trigger alert levels or to issue warnings.

For instance, the Gold Coast city council system combines most of these capabilities from Australia, albeit at a local scale [30] and with rather simplified hydrodynamic numerical simulation tools. At a national level, the Norwegian [19] and Finnish [54] early warning systems cover many of the features above, except they do not include the ability to run hydrodynamic simulations. The Finnish system [54] invests in data assimilation strategies to refine the results of hydrological modelling. The Portuguese Water Authority follows a different approach from the SVARH system [54]. SVARH is built to offer many of these features but only to a few rivers that are considered critical. However, the SVARH’s hydrodynamic forecasting module is (as of late 2021) not operational yet. Therefore, these platforms are specifically designed for water authorities and are streamlined to produce alerts from simple but verified data. The RCP may be extended to provide some level of integration with such systems in the future. At present, the principal investment is on the diversification of the sources of data and the ability to base forecasts and nowcasts on hydrodynamic numerical simulation tools, for which data assimilation techniques are sought [55].

Regarding flow forecasting, the Delft-FEWS platform [56] is closer to the RCP’s objectives: a generic Web GIS platform that integrates data sources and hydrological modelling tools to provide a decision support system for different stakeholders. As is the case of the RCP, the Delft-FEWS platform features interfaces designed to reduce complexity in the processes inherent to handling data (a concern shared by other platforms, e.g., [57,58]), including curating and contextualising the results of numerical simulations. RCP has been designed to be integrated with different hydrodynamic simulation tools, a feature implemented in the Delft-FEWS, but only for hydrological models.

SAFERPLACES [59] is a web platform that proposes open data for the planning stages of the risk management cycle. It is designed to gather open geodata sources to evaluate pluvial, fluvial, and coastal flood hazards and risks in urban environments. It allows the user to run flood scenarios due to rainfall, fluvial, and sea level, with damage estimates and the possibility to simulate the effects of mitigation measures, such as seawalls, asset reallocation, etc. It entails economic damage assessment and mitigation simulations, which are not available in RCP. However, its digital elevation model-based algorithm to estimate flooding is a crude simplification compared to the complete hydrodynamic modelling in the RCP. Moreover, features such as data curation or end-user contributions do not seem to be the focus of this initiative.

5.4. Other Related Work

It is envisaged that Web GIS platforms’ complexity and ambition tend to increase as advances in sensing, web technologies, and modelling tools become available. It may be the case with risk-prone areas represented with digital twins, which can become possible if a comprehensive network of sensors is available [31]. Another direction of interest concerns sensing from non-curated sources, including social media or through citizen-science observatories. In this respect, it is noted that temporary citizen science initiatives and observatories, mostly not related to the interplay between models and data, nor having a base framework, have been proposed recently [60,61,62,63,64]. However, most of these projects have one-way communication, where the users provide the data but have little interaction with the system or receive little feedback from the system. Nevertheless, these initiatives show the potential of social sensing and crowdsourcing for gathering flood-related data.

6. Conclusions

As the scope and impacts of climate change continue to emerge, accurate flood forecasting tools and early warning systems are increasingly required to support preparedness and improve emergency response to extreme events. To plan for flood resilience or to conduct nowcasting or forecasting analyses, decision-makers require robust decision support systems that can efficiently process input data, conduct hydraulic modelling, and possibly assimilate additional data. These systems must be capable of collecting and organising the results into complex datasets that support better analyses and decision-making.

The RiverCure Portal (RCP) streamlines the interaction of its end-users with specialised water management tools by automating crucial tasks that previously required manual interventions or multiple tools. This enhances the user experience, facilitating the work of domain experts and increasing productivity. As a result, the RCP simplifies data analysis and simulation procedures, meeting the needs of a wide range of stakeholders, such as domain experts and decision-makers (e.g., water authorities and civil protection organisations), researchers, students, and the general public, helping them to understand better the risks and decisions involved. With the increasing frequency and severity of extreme weather events, tools such as the RCP are becoming more relevant than ever. They enable these stakeholders to predict and analyse the impacts of moderate to serious flood events, as they can better prevent or mitigate the consequences of these events and protect their citizens and communities.

A complete dataset of this “Águeda 2016 flood” event is publicly available [65], and there is a companion paper that provides an explanation and instructions for independent researchers to be able to replicate the experiment [66], also included in Appendix B.

During the design and development of the current version of the RCP, some features were left out or just simplified and are identified as future work. First, continuous data stream support from the sensors would allow RCP to manage and send data continuously to hydrodynamic simulation tools, improving flood predictability accuracy. Second, it should support “social sensors” by integrating crowded-source flood-related data (e.g., georeferenced and timestamped images and photos of floods) submitted by citizens in their social networks or related websites. This would enable users to upload georeferenced images and pictures of floods, and machine-learning algorithms could extract relevant data from these images, calibrate the hydrodynamic simulation models, and produce accurate predictions.