3. Case Study: Hydraulic and Hydrogeological Risk Simulator
This experimental work involves the creation of a geographical web platform for analyzing and simulating the hydrogeological risk on Italian soil in the event of flooding events, using soil elevation and existing watercourse beds as input data. Using this application, it will be possible to click on a point of interest, obtain elevation data for a 5-km area around the point itself, and simulate the overflow of watercourses in that area in the event of rain, also considering the external contribution due to the slope of the surrounding land.
3.1. Area of Interest
We chose to limit the scope of this work to the area of the Liguria region, given the presence of numerous cartographic data that can be freely downloaded from the dedicated geoportal (
https://geoportal.regione.liguria.it/).
These data include several thematic maps available in WFS and shapefile format (see) including the hydrographic network, river basins and many other maps useful for monitoring the region’s territory.
As far as the geometries of the watercourses are concerned, however, it was preferred to start from a polygonal representation of the watercourses, as this allows a starting situation, in which the watercourse is still within its bed, to be as realistic as possible. Since the geoportal does not provide this type of model, the choice fell on the free maps of OpenStreetMap
3.2. Type of Application
The application is a WebGIS 3D that can be consulted via the web at
http://150.146.207.228:8080/idro_simul. This choice allows it to be easily usable by any user with an internet connection without the need to install local software, and makes it possible to exploit the capabilities of modern browsers which, by means of dedicated libraries such as Three.js, allow the visualization of three-dimensional environments with a large quantity of polygons on the screen, as is often the case in the realization of simulations of this type.
The user interface will consist of two different screens:
- The initial screen is a 2D visualization of the region of interest, within which it will be possible to move, zoom and obtain information on the features of interest, as well as select an area in which to run the simulation;
- The second screen is a three-dimensional representation of the selected area, where you can set parameters and start the simulation.
The simulation is displayed on the screen as an animation, in which both the time steps and the total duration are user-selectable parameters. At the end of the simulation, it will be possible to compare the initial and final state of the water expanse to assess which surrounding areas might be most affected by the flooding.
3.3. Input Data—DEM (Digiltal Elevation Model)
The DEM (Digital Elevation Model) used for the project is TINITALY/1.1, a new version released in January 2023 of the original TINITALY/01 presented in 2007,
Figure 6.
The DEM (Digital Elevation Model) used for the project is TINITALY/1.1 (See
Figure 7), a new version released in January 2023 of the original TINITALY/01 presented in 2007. This model has a resolution of 10 meters and is downloadable in GeoTIFF format via WMS, WMTS and WCS services. In particular, the WCS (Web Coverage Service) service [
15] was used in the present study because it allows the download of a map portion of a specific size. In this case a size of 500x500 pixels was chosen where each pixel covers an area of 10x10m, thus obtaining an elevation map for an area of interest of 5x5km. However, the parameterization of this resolution allows even larger portions of terrain to be downloaded if necessary.
3.4. Geometries of Watercourses
For the areas covered by watercourses, it was decided to use map data from OpenStreetMap, a series of opensource maps managed by the OpenStreetMap Foundation and maintained by a large community of contributors. These maps form the basis of thousands of websites and guarantee an accurate and up-to-date representation of the world’s territory.
It was chosen to use such maps because watercourses are represented vectorially in the form of polygons rather than lines as is the case with several other cartographic sources representing water networks. Polygonal representation makes it possible to simulate as realistically as possible the initial situation of the watercourse and thus the simulation of its spread in the surrounding terrain in the event of a flood [
16].
The data were downloaded using the QuickOSM plugin for the QGIS software, which allows the download of data from the various layers of which the OpenStreetMap map is composed using filters on the type of layer and a bounding box to delimit the area of interest.
Specifically, all geometries were selected in which the key-value pair consisted of: natural = water which characterize the geometries of the water mirror layer in the OpenStreetMap map.
Once downloaded to QGIS in shapefile format, the geometries were then saved on the PostgreSQL database using the integrated functions of QGIS, to be subsequently retrieved in GeoJSON format by the services of the application for visualization in the form of layers for the Openlayers javascript libraries used by the platform.
In addition to the polygonal geometries of the watercourses, it was decided to add a layer to the platform containing the hydrographic network in the geoportal of the Region of Liguria. This layer shows the linear geometries of the hydrographic network, the information provided includes the name of the watercourse, the indicative specific surface area, the indicative surface area of the underlying basin (referring to the selected segment), whether it is hydraulically investigated and the relative Strahler order, which measures the branching complexity of the selected stretch.
The geometries were downloaded from the geoportal in the form of shapefiles. As before, they were imported into the QGIS software and then saved to the PostgreSQL database, whose built-in geographical functions were used to filter the results, retaining only those sections that intersect the polygonal geometries downloaded from OpenStreetMap.
3.5. Simulation Algorithms—Calculation of External Contribution
In order to simulate as realistically as possible the increase in water volumes following floods caused by major meteorological events, it is necessary to take into account not only the amount of rain that falls in the river basin, but also that which is deposited in the surrounding areas and then, due to gravity, pours from higher elevation areas into the riverbed, thus increasing the mass of liquid that could cause the river to flood.
areas with higher elevation towards the riverbed, thus increasing the mass of liquid that could cause the river to overflow. This type of rainwater movement is called surface runoff. In order to take this ‘external contribution’ into account, while keeping the simulation streamlined and executable in near-real time, it was decided to approach the problem with a simplification: for each pixel of the elevation map, i.e., for each 10x10m area within it, the platform selects the preferred path of the water towards neighbouring cells, based on the slope: of all the neighbours it will choose the one with the steepest downward slope.
The first step is then to calculate, for each cell of the elevation grid, the slope of the four directions with respect to the current cell. These four slopes are then compared with each other to decide which direction the water will take on its path to the lowest point.
In the example in
Figure 8, if we had to choose a path for the water from cell A towards adjacent cells B, C, D and E, the path towards E would be chosen because there is a negative slope towards B and C, while between D and E, E is the one with a greater downward slope than A.
The path is then continued until a flat area is found, or until an area within the initial riverbed is reached (or the boundaries of the map under consideration). Each pixel affected by the trickle of water thus created is increased by a certain value; repeating the operation on all the pixels of the map will thus result in ‘accumulation zones’ in which the water tends to stop, forming a static map that is kept in memory; when the dynamic simulation is performed, for each pixel reached by the mass of water simulated, a certain amount of volume is added depending on the external contribution of that pixel, thus taking into account the accumulated rain from the surrounding areas.
Figure 9 shows the complete map calculated for one of the zones of interest in the study area
The areas of greatest water accumulation are visible in orange. It can also be seen that at the base of the slopes, water accumulates more, making a strong contribution to the flooding of those areas; the effect diminishes as the elevation increases, until there is no external contribution at the top of the heights.
The starting data for the simulation are:
- −
the uniform grid containing the elevation data of the area of interest, from which a three-dimensional plane is derived to represent it.
- −
the initial geometry of the watercourse, represented by several cubes (one for each 10x10m cell of the DEM) with a very small initial height to simulate the initial body of water.
The execution of the simulation starts after the user has filled in the fields that determine the control parameters through the interface: it is possible to define the amount of water due to rainfall, expressed in mm/m2 per hour of rain, the time step between one frame and the next of the simulation, which can range from 15 to 120 minutes, the total time of the simulation duration, in the range of 6 to 48 hours. The last parameter to be selected will be a soil permeability index, which will affect the percentage of water that will be considered as absorbed by the soil and will therefore not increase the total volume of the overflow. This value can range from 0.0 (no permeability, found in rocky soils) to 1.0, (maximum permeability, which allows the soil to absorb the entire amount of water that falls, a condition that is obviously impossible in real cases).
Once this data has been collected, the platform will begin by first calculating a static map for external contributions. After that it will raise the geometries of the entire watercourse of the decided step, calculated as:
An object representing the edge of the watercourse geometry (called fringe in platform) will then be generated by selecting all the cells that lie on the outer contour of the geometry. This will be the area that will be compared with the elevation, to be possibly expanded if the top of the cube of each of its cells is at a higher elevation than the direction in which it would like to expand.
In this way it will be possible to obtain an approximate simulation of the expansion of the volume of water as the amount of rain received increases, with an expansion stop in the case of slopes and areas with a higher ground elevation.
The water volumes displayed will also be colored in a graduation from white to deep blue as the height of the water volume in a given cell increases; to make it even clearer which areas are most affected by flooding.
In
Figure 10 is the end result of a simulation that considers a time frame of 48 hours from the start of precipitation, assuming a constant amount of precipitation over time.
3.6. Simulation Platform
The platform uses the classic client - server scheme, thus allowing for use by several simultaneous users and publication on the web, possibly integrated within more extensive web portals that allow for different analyses of the territory for the mitigation of various types of risk (See
Figure 11).
3.7. Back-End
The back-end of the application is realized in the Java language and is published on a dedicated Tomcat 9.0 application server (See
Figure 12) [
17].
This takes care of both serving the html, javascript and css files to the browser and providing the services for retrieving the geometry for the layers of the Openlayers map used on the front-end. The geometry data is stored within a PostgreSQL database with PostGIS extension (see).
For the connection between the Java code and the database, the JDBC (Java DataBase Connector) driver jar file was added to the application libraries. These drivers
allow the generic Connector, PreparedStatement and ResultSet classes of Java to be used with different types of databases including Oracle, MySQL, etc. In the case of the present study, the driver named postgresql-9.4-1101.jdbc41.jar (contained in the project’s WEB-INF/lib directory and linked in the application’s build path) allows use with PostgreSQL databases.
The format used for the exchange of geographic data between front-end and back-end is GeoJSON, a textual format that respects the specifications of the JSON format while incorporating the geographic information in a standard form directly readable by the Openlayers library.
For the back-end part, the project consists of two separate Java packages. In the first, database, there is the DataManager.java class, which takes care of instantiating connections to the PostgreSQL database and is solely responsible for query execution.
In the second package, servlet, are the classes that are responsible for serving content to the front-end in response to calls from the browser. The classes within it extend the HttpServlet class and respond to the URLs indicated by the @WebServlet annotation, as in the following example: @WebServlet(“/layers/getlayercorsiacqua”).
3.8. Front-End
The front-end, usable via all the latest browsers such as Google Chrome, Mozilla Firefox and Microsoft Edge, is realized in HTML, CSS and Javascript.
Some auxiliary libraries have been used for two- and three-dimensional visualization, and to facilitate access to certain types of data:
Openlayers.js: an open-source Javascript library designed to create interactive maps on the web. It provides an API that allows viewing, editing and managing geographical data from different sources, such as raster maps, vector maps and map services (OpenStreetMap, Google Maps or WMS services). It supports advanced features such as managing multiple layers, geolocalization, drawing geographical objects and interaction with GIS formats.
Three.js: for the creation of navigable three-dimensional screens, for the visualization of polygonal models. It also allows the application of textures and advanced effects, thanks to the potential of WebGL (Web Graphics Library).
Geotiff.js: for reading and managing data in geotiff format, with direct access to RAW image data.
Jquery: library of generic utilities that simplify many Javascript operations, including for example the handling of AJAX calls to the back-end [
18].
The application is organized as a SPA (Single Page Application). This format is widely used for advanced web applications, and does not provide for the normal navigation between the various web pages as in a standard site, but manages any screen changes by means of javascript functions that regenerate the DOM, the object that takes care of maintaining a model of the current HTML document (See
Figure 13).
The libraries are called up within the <head> section of the index.html file. Instead of importing them into the project, it was preferred to refer to the URLs of the repositories where they are made available [
19]:
<!-- three.js v. 0.164.1 -->
3.9. Three-Dimensional Rendering
The key part of the platform is the screen that runs the simulation and displays it in 3D. This choice is based on two main reasons: the first is that the three-dimensional X, Y, Z coordinates of the points of the terrain model are necessary for the execution of the simulation, as the expansion of the water volume is decided on the basis of the height of the surrounding terrain in relation to the height of the water; the second is the possibility for the user to rotate and zoom the model while the simulation is running, for a better evaluation of the effects of the flooding.
The capabilities of modern browsers allow the simulation to run in real time directly on the user’s terminal, not overloading the back-end server when running multiple instances of the platform.
The Three.js library provides, in the form of an API, the tools needed to create a 3D scene complete with polygonal objects, lighting effects, cameras and post-processing within a normal web page, exploiting the potential of the WebGL graphics libraries.
Figure 14 shows the conceptual scheme of a Three.js scene.
Three.js is based on a number of software objects that encapsulate the main functionality of the software: The Renderer is the main object and is responsible for representing everything in a Scene on the screen, framing it as if the user were positioned at the point where the Camera is. This is modelled as a real camera with its own position, orientation and field of view (FOV) framing the scene (See
Figure 15).
Within the Scene we find all the objects that make up the structure of the scene we are going to frame: the Mesh are the actual 3D objects. These are in turn composed of Geometry, the polygonal geometries that describe their appearance, and Material, the materials that define their color, light reflection properties, etc.
Materials may in turn refer to textures, raster images that are applied to the geometries, suitably extended or repeated to cover the entire model.
The scene will then be illuminated by Light objects, which may be of different types to simulate various types of light, such as spot, ambient, omnidirectional and so on.
One of the aspects to which attention must be paid for the correct visualisation of three-dimensional space is the co-ordinate system: although they always consist of the three axes X, Y, Z, some applications consider Z as the vertical axis, others Y. Three.js uses the latter convention, as shown in
Figure 16.
Since in geographic systems longitude and latitude values are often traced back to X and Y co-ordinates, it would be more convenient, in the case of a geographic application, to use a reference system in which the Z axis corresponds to the vertical axis, representing the elevation of the terrain; the library allows the reference system to be changed via a simple function: THREE.Object3D.DefaultUp = new THREE.Vector3(0, 0, 1);
This creates a unit vector in the Z-direction and assigns it to the one that is considered ‘high’ (Up); in this way, the convention is restored to the desired condition.
3.10. Elevation Assignment
The terrain elevation comes from the DEM TINITALY 1.1 and is imported into the platform thanks to the use of the WCS services offered by the portal. These allow us to download a georeferenced GeoTIFF file directly to the browser, whose raw data can be used as the basis for the creation of a three-dimensional geometry that can be viewed using Three.js. The procedure begins with a call to the WCS services, as follows:
SERVICE=WCS &VERSION=1.0.0
&REQUEST=GetCoverage &FORMAT=GeoTIFF
&COVERAGE=TINItaly_1_1:tinitaly_dem
&BBOX= [coordinate iniziali e finali della zona di interesse] &CRS=EPSG:32632
&RESPONSE_CRS=EPSG:32632 &WIDTH=500
&HEIGHT=500
Among the various parameters passed to the caller, it is possible to note that the coordinate system used is 32632, which uses metres as the unit of measurement and thus facilitates the creation of the coordinates to be inserted in the BBOX (bounding box): for an area of 5km it will be sufficient to take the central point, in this case corresponding to the coordinates of the mouse at the click, and then add and subtract 2500 to obtain the start and end points of the GeoTIFF to be downloaded. In addition to this, the required image size is also specified, 500x500 pixels, corresponding precisely to an area of 5 x 5km, which corresponds to TINITALY’s definition of 10km per pixel.
The content of the response to this call is processed by the GeoTIFF.js libraries that allow the manipulation of the GeoTIFF raw data in the form of an arraybuffer, i.e., a sequence of bytes:
const arrayBuffer = event.target.response;
const tiff = await GeoTIFF.fromArrayBuffer(arrayBuffer); const image = await tiff.getImage();
const data = await image.readRasters();
renderData.demData = data [0];
In this code snippet, we create an object for the TIFF file by passing the contents of the response to GeoTIFF. From this object we extract the image, and in turn extract the raw data from it (remember that GeoTIFFs can contain multiple rasters within them, which is why the [0] element of the data array is selected, which in this case contains the data of the only image present).
This data is then saved within the renderData object, which is then passed on to the simulation.
Within the 3D visualisation, the elevation data will be realised by means of a plane with dimensions 5000 x 5000 metres, consisting of 499 vertices per side.
const geometry = new THREE.PlaneGeometry(5000, 5000, 499, 499);
The elevation values are stored within a one-dimensional array, as are the vertex positions in the Three.js plan. It will then suffice to create a loop with i ranging from 0 to the length of the array of positions, and assign the i- content of the array with the elevation data to each vertex:
position.setZ(i, data[i]);
The end result will be a mesh like the one shown in
Figure 17:
In order to cast the simulation in as realistic an environment as possible, it is important to be able to intuitively visualize the area in which it takes place: for this purpose, having a ground texture showing satellite images of the area can make a strong contribution to the effectiveness of the tool. To achieve this, it will be necessary to have an image available, even one of arbitrary dimensions, to apply to the mesh representing the terrain.
First of all, a service was selected that could provide these images without cost, and without the need for API keys that could limit their use in the future: the choice fell on the ESRI services, which make available on their Tile Map Servers the layer called World Imagery, which contains the aerial and satellite maps of the entire planet. The service can be called up at the following URL:
Again, the OpenLayers libraries were used, generating a new map positioned outside the screen, using CSS properties:
position:fixed;left:0px;top:- 1030px;width:1024px;height:1024px;z-index:20).
After creating a layer capable of accessing the ESRI service, this is added to the map, which will have an extent equal to the bounding box of the area of interest.
When the rendering of the map is complete, the following function takes care of copying the content of the image into a raster, and passing it to the 3D simulation together with the rest of the basic data:
const mapCanvas = document.createElement(’canvas’); const size = map.getSize();
mapCanvas.width = size [0]; mapCanvas.height = size[1];
const mapContext = mapCanvas.getContext(’2d’); Array.prototype.forEach.call(
map.getViewport().querySelectorAll(‘.ol-layer canvas, canvas.ol-layer’), function (canvas) {
if (canvas.width > 0) {
const opacity = canvas.parentNode.style.opacity || canvas.style.opacity;
mapContext.globalAlpha = opacity === ‘‘ ? 1 : Number(opacity);
let matrix;
const transform = canvas.style.transform; if (transform) {
matrix=transform.match(/^matrix\(([^\(]*)\)$/)[1].split(‘,’)
.map(Number);
} else {
matrix = [parseFloat(canvas.style.width) / canvas.width, 0, 0,
parseFloat(canvas.style.height) / canvas.height, 0, 0];
}
CanvasRenderingContext2D.prototype.setTransform.apply(mapCo ntext, matrix);
const backgroundColor = canvas.parentNode.style.backgroundColor;
if (backgroundColor) { mapContext.fillStyle = backgroundColor;
mapContext.fillRect(0, 0, canvas.width, canvas.height);
}
mapContext.drawImage(canvas, 0, 0);
}},);
mapContext.globalAlpha = 1;
mapContext.setTransform(1, 0, 0, 1, 0, 0);
render3Dview(renderData.demData, renderData.alveoData, mapCanvas.toDataURL(“image/png”).replace(“image/png”, “image/octet-stream”));
The data extracted in this way are passed to the 3D view creation function, and applied to the previously created plan using a standard Three.js material (See
Figure 18):
var materialTerreno = new THREE.MeshPhongMaterial({ color: 0x55854f, specular: 0x555555, shininess: 20, flatShading: true
});
plane = new THREE.Mesh(geometry, materialTerreno); scene.add(plane);
Polygonal geometries from OpenStreetMap were chosen for the watercourses, imported into QGIS using the QuickOSM plug-in and subsequently saved to the PostgreSQL database serving the application. To allow their use within the 3D simulation, however, it is necessary to map these geometries onto the cells of the 5x5km area under consideration. To do this, the getFeaturesAtCoordinate() method of OpenLayers was used, which returns all features present at a certain coordinate passed in as input. Below is an extract of the function that performs this operation [
20]:
const coordStart = ol.proj.transform([tiffData.bbox[0], tiffData.bbox[1]], ’EPSG:32632’, ’EPSG:3857’);
const coordEnd = ol.proj.transform([tiffData.bbox[
2], tiffData.bbox[
3]], ’EPSG:32632’, ’EPSG:3857’);
const startX = coordStart[0]; const startY = coordStart[1];
const stepX = (coordEnd[0] - coordStart[0]) / tiffData.width; const stepY = (coordEnd[1] - coordStart[1]) / tiffData.height; const arrayOut = [];
for (let x = 0; x < tiffData.width; x++) { arrayOut[x] = [];
for (let y = 0; y < tiffData.height; y++) {
let coords = [startX + (stepX * x), startY + (stepY * y)]; if
(layerCorsiAcqua.getSource().getFeaturesAtCoordinate(coords)
.length > 0) { arrayOut[x][y] = 1;
} else { arrayOut[x][y] = -1;
}}}
The function creates a grid of the same size as the elevation GeoTIFF, and scans this grid point by point: if a watercourse was found at that point, the corresponding element of the output array is assigned the value 1, otherwise the value -1. This array will then be inserted into the renderData object and passed to the function that is responsible for creating the 3D visualization.
Within this function, a parallelepiped geometry is created for each element of the two-dimensional array, with sides in the x- and y-direction 10m wide, and an initial height of 1m. This parallelepiped will be positioned at the height corresponding to the elevation plane for those coordinates, and the set of these parallelepipeds will constitute the initial riverbed of the watercourse on which the simulation will be performed. Below is the portion of the code that deals with generating the parallelepipeds:
const geometry = new THREE.BoxGeometry(10, 10, 1);
geometry.translate(x*10+offsetX, -(y*10+offsetY), val- baseZ+2);
const colors = new Uint8Array(72); for (let r = 0; r < 24; r++) { colors[r * 3] = 0;
colors[r * 3 + 1] = 0;
colors[r * 3 + 2] = 255;
}
const colorAttrib = new THREE.BufferAttribute(colors, 3, true);
geometry.setAttribute(’color’, colorAttrib); geometries.push(geometry);
All vertices in the geometry are assigned the colour blue (RGB 0, 0, 255). The array containing the vertex colours will have size 72, because it contains 3 integers (R, G, B) for the 24 vertices of the polygon (6 faces * 4 vertices each). When adding many polygons to the scene, a strong degradation in the performance of the application was noticed, and it was therefore decided to apply an improvement by merging all the different geometries into a single object:
const mergedGeometry = BufferGeometryUtils.mergeGeometries(geometries, false);
alveoMesh = new THREE.Mesh(mergedGeometry, materialAlveo); scene.add(alveoMesh);
This solution, although the number of vertices and faces is the same, allows for a considerable improvement in performance, because the drawCalls, the calls to the webGL services responsible for visualizing the scene, are reduced, since one is performed for each different object in the scene (See
Figure 19).
3.11. Two-Dimensional Map
The two-dimensional map is realised using the OpenLayers libraries. As OpenLayers does not support the 32632 (UTM32) coordinate system by default, it was necessary to import the proj4 library into the project, which is responsible for extending the projections supported by OpenLayers, via the tag:
within the index.html file. At this point, using javascript, simply define the desired projection via the instruction:
proj4.defs(“EPSG:32632”, “+proj=utm +zone=32 +datum=WGS84
+units=m +no_defs +type=crs”);
ol.proj.proj4.register(proj4);
The map will consist of three layers that are always visible:
1. the OpenStreetMap base layer
2. the watercourse layer, polygonal
3.12. The Hydrographic Network Layer, Linear
First of all, the styles with which to represent the two vector layers must be defined, as follows:
const styleCorsiAcqua = new ol.style.Style({ stroke: new ol.style.Stroke({
color: “#5566ff”, width: 1
}),
fill: new ol.style.Fill({ color: “#5566ff”
})});
const styleReticoloIdrografico = new ol.style.Style({ stroke: new ol.style.Stroke({
color: “#0000ff”, width: 1
})});
At this point, it will be necessary to indicate the source of the data for both layers: in the case of the present project, the geometries are stored on the PostgreSQL database and supplied to the front end thanks to two servlets, which execute the queries and return the result in the form of GeoJSON, a format ready to be consumed by the OpenLayers source object (the example is given for the ‘Watercourses’ layer, the process is equivalent for the hydrographic network):
const vectorSource1 = new ol.source.Vector({ loader: function (extent) {
var source = this;
$.ajax({
url: ’layers/getlayercorsiacqua’, context: document.body
}).done(function (response) {
source.addFeatures((new ol.format.GeoJSON()).readFeatures(response));
});},
strategy: ol.loadingstrategy.all, projection: ’EPSG:32632’
});
Once the data source has been populated, it is finally possible to instantiate an object of type layer:
layerCorsiAcqua = new ol.layer.VectorImage({ source: vectorSource1,
name: “Corsi d’acqua”, style: styleCorsiAcqua, zIndex: 5
});
The layer type chosen is VectorImage, which combines the flexibility and speed of vector layers with the possibility of generating cache images typical of raster vectors, for reuse in the case of tiles already previously shown on screen.
As far as the base layer is concerned, things are even simpler, since OpenLayers natively provides an object of type source.OSM that takes data directly from the OpenStreetMap services.
const OSMbasemap = new ol.layer.Tile({ source: new ol.source.OSM(),
});
In this case, the layer is of type Tile, as it shows a mosaic of pre-generated images. The map is thus complete, and we can instantiate it by inserting all the layers created previously:
olMap = new ol.Map({
target: ’map’, layers: [
OSMbasemap, layerCorsiAcqua, layerReticoloIdrografico
],
view: new ol.View({
center: [981941, 5496717],
zoom: 9,
}),
projection: ’EPSG:32632’,
});
Events such as clicking on a map and selecting features on certain layers can then be recorded, in order to perform the relevant operations required for the platform to function.
3.13. User Interface
The application consists of two different screens. The initial screen is a classic two-dimensional map showing the watercourses, the hydrographic network and the boundaries of the area of interest. The second is a 3D screen, which can be viewed after selecting an area on which to run the simulation, where it is possible to set parameters and launch the actual simulation.
The two-dimensional map view of the territory is the screen that is displayed when accessing the application URL (See
Figure 20) [
21].
The interface is very simple: the main element is the map, freely navigable and clickable. In addition to the zoom buttons on the left, which are provided directly by the OpenLayers API, there are two buttons for displaying the DEM in a 5km area around the clicked point, and the button for the 3D view, which is activated when the DEM is displayed (See
Figure 21).
On the map there are, in addition to the OpenStreetMap base layer, two layers: the first displays the watercourses downloaded from OpenStreetMap in vector form, while the second represents the hydrographic network downloaded from the geoportal of the Liguria region.
Clicking on a given point on the map will search for information on the latter layer. If elements are found, these will be colored in yellow and a pop-up window will open containing various information on the selected section of the grid (See
Figure 22).
The reported data are:
- The name of the watercourse
- The Strahler order
- The indicative specific surface area, expressed in square meters
- The indicative surface area of the underlying basin, expressed in square meters
- Whether the watercourse is hydraulically surveyed or not
When clicking on the ‘View DEM’ button you will be asked to click on a point on the map, and once a point has been selected the TINITALY WCS service will be called up which returns the GeoTIFF of the elevation for a 5x5km area around the selected coordinates. The GeoTIFF, in addition to being scanned to send elevation data to the simulation, is also displayed on the map for a better understanding of the area over which it will operate (See
Figure 23).
At this point, the ‘3D View’ button will be made active and, if there are watercourses within the area, you can move on to the actual simulation.
3.14. Three-Dimensional Visualization Map
Upon clicking the ‘3D View’ button, you will be redirected to the relevant page, where the 3D terrain model, the riverbed of the watercourse in blue color, and all user interface elements allowing interaction with the simulation will be displayed (See
Figure 24).
In particular, thanks to the panel on the left of the screen it will be possible to select (See
Figure 25)
- The amount of rain falling in the area in an hour (mm/h)
- The soil permeability index, from 0.0 (completely impermeable) to 1.0 (completely permeable)
- The time increment for each ‘frame’ of the simulation
- The total simulation time
In addition to these input parameters, there are two checkboxes: the first allows you to display, instead of the textured terrain, the map of external contributions, with a graduation from green to red depending on the contribution each cell makes to the volume of water. The second, on the other hand, allows the display of the simulation result to be activated/deactivated after the simulation is completed, as can be seen in
Figure 26:
This option allows a better comparison between the initial and final situation, and a better understanding of which areas have been flooded compared to the initial riverbed. Below the two checkboxes are the two main buttons: The first allows the simulation to be started, while the second allows it to be interrupted if intermediate effects with respect to the selected time horizon are to be assessed. During the execution of the simulation, the time relative to the current frame is indicated by the timer at the bottom of the screen.