Construction and application of the 3D geo-hazard monitoring and early warning platform

2.1 Architecture of the basic 3D GIS platform

The basic platform provides the fundamental operation environment of 3D GIS, including basic functions such as the construction of the ellipsoid model of the Earth, browsing control of 3D scenes, visualized display of vector data, topographic data, and video data, graphic data cache, and projection transformation. In addition, by extending the business function module, the platform will be more adept at geo-hazard monitoring.

In order to fully leverage local computing capacity to better realize 3D display, the platform takes the form of a desktop client and is developed using the C# language and .NET Framework 4.0, with reference to the distributed architecture of a Xugu Database and third-party control DevExpress. DevExpress control has a full range of functions and an attractive interface, and it is easy to use and customize. Additionally, its easy-to-use help system reduces development costs and improves working coordination. This Xugu Database, an independently developed product from Chengdu Xugu Weiye Technology Limited, has obtained the certification of military information safety products and is a relational database management system with distributed architecture and full functional properties. Based on the non-sharing distributed architecture framework, the Xugu Database allows for distributed storage and computing at the data level and supports strong transaction consistency, which makes it possible to build cost-effective PC servers into super-large clusters that have dozens or even over a thousand units, and are capable of dynamic adjustment online. In addition, they are fully compatible with (or able to replace) all traditional RMDBS and fully retain their functions. Furthermore, the research and development company of Xugu database, Chengdu Xugu Weiye Technology co., LTD., has been maintaining a good cooperative relationship with our team, providing us with free technical support for the database used in the platform, such as real-time access of multi-source data and daily maintenance of data. Therefore, the Xugu database has been used to store all kinds of monitoring data for the platform construction in this paper. Definitely, the Xugu database used in this platform can also be replaced by other databases, such as non-relational database. In addition, according to the difference and relation between NewSQL, NoSQL, and SQL databases [16,17,18], a composite database that is not strictly relational will be adopted to improve the throughput efficiency of the system in the future release of the platform.

The basic platform adopts the ArcGIS Engine development component in its GIS functional module, DevExpress controls in its user interface, and 3D Digital Earth by ArcGIS Globe in the construction of the fundamental Earth structure. Based on the needs of the monitoring and early warning platform, its business logic includes function modules such as layer management, sphere roaming, spatial measurement, spatial tagging, data visualization, and REST request processing. The user interface and business logic from the 3D GIS platform, with its general structure, is shown in Figure 1.

Figure 1

General structure of the basic platform.

The core object for the basic platform to realize the 3D GIS function is the GlobeControl 3D spherical control, and the foundation categorization to obtain the entity object of the 3D sphere is GlobeDisplay. The realization of the sphere depends on the GlobeClass categorization and encapsulates the GlobeViewer object. GlobeControl, a high-end development control, enables different types of overlapping spatial data to be displayed and analyzed on the real Earth surface. Usually designed for scenes with massive data, GlobeControl is capable of data caching, thus improving display efficiency and effectiveness of high-speed roaming. By mapping data onto the spherical surface, it is closer to the real world. Its layers are divided into three types, including esri GlobeLayerTypeDraped, esriGlobeLayerTypeFloating, and esriGlobeDataElevation, which are particularly adaptable to the needs of 3D platforms.

2.2 Application model of the 3D GIS platform

The basic 3D GIS platform is mainly formed by four modules, namely the 3D model, visible view, event monitoring, and layer data. The 3D model consists of the spherical model, foundation layer, and splicing control; the visible view is built on the 3D model, displayed by the displayer, and receives the visualized view via user feedback through scene control; event monitoring covers all events and executes corresponding programs, and layer data can be obtained through local cache data or HTTP-based Web services accessing the map server. The application model of the 3D GIS platform is shown in Figure 2.

Figure 2

Application model of the 3D GIS platform.

Besides constructing the basic 3D sphere, the 3D GIS platform also has the following main functions with regard to GIS application:

1. Map zooming and perspective control: Map zooming is used to control the scale of the current view, and decides the current display area and corresponding scale. Perspective control is the main function that realizes 3D display and decides the current display area and inclination angle based on the viewpoint.

2. Query for basic geographical information: Obtains the height of the viewpoint according to its current location, and picks up basic geographical information such as altitude, longitude, and latitude of the current location identified by the cursor.

3. Spatial reference system: With the mean level of the Yellow Sea as the benchmark, the platform is configured against the parameters of the WGS84 ellipsoid and demonstrated by the geographical coordinate system (geodetic coordinate system), i.e., longitude and latitude. Spatial coordinates have three parameters, with X representing longitude, Y latitude, and Z altitude, and planar maps can only be loaded and presented in the platform following projection transformation.

4. Measurement tools of map elements: The platform can measure the height, length, surface, and other parameters of cursor-rendered figures.

2.3 Organization and management of frequently used data

2.3.1 Demonstration of image data

The stereo perception of terrain in the 3D GIS platform should be realized by integrating Digital Elevation Model (DEM) with Digital Orthophoto Map (DOM). While higher DOM resolution helps reproduce the real scene, it also means higher data volume. To organize and demonstrate massive video data, the platform adopts the tile-pyramid model in the local cache of image data. It is a multi-resolution, multi-layered model, where layers are produced by resampling original data according to different resolutions, and tiles are produced by evenly slicing data in the same layer in line with the designated size of the grid. Hence, the geographical scope remains the same from the bottom to the top, whereas the resolution of tiles decreases. To construct a tile pyramid, the map projection should be sliced according to the degree, normally into squares in the same size, among which the (N + 1)th layer keeps the quadtree inheritance relation to the Nth layer, as shown in Figure 3.

Figure 3

Layered pyramid model.

By adopting the quadtree structure, the platform slices video data into square tiles to construct the tile pyramid. When the size of the original lowest level data (highest resolution) is w ∗ h, the size or tiles is ts ∗ ts pixels (e.g. 256∗256), and the changing rate between adjacent layers is m (m = 2 in the platform, i.e., 2∗2 pixels produce 1 pixel in the tile matrix at the upper layer), then the total number of layers in the pyramid is:

(1) L tot = max { [ log m ( w / t s ) ] , [ log m ( h / t s ) ] } .

3.1 Monitoring service design

Geological hazard monitoring carries out uninterrupted long-term observation on the creation and development of geological hazards with various observational equipment and estimates the stability and trend of geological hazards based on the analysis, processing, and calculation of a certain amount of monitoring data. The goal is to develop better knowledge of the developmental pattern of geological hazards, promptly identify the warning signs, and improve technology-enabled hazard prevention and mitigation. The monitoring focuses on relevant information that can reflect the development of geological hazards, including rainfall, geosound, infrasound, surface displacement, soil water content, earth surface cracking, video, mud water level, and collision line [6,11,21,22,23]. The monitoring objects of this platform are landslides, collapses, and debris flows, which are also major geological disasters in mountainous areas in southwest China.

The data monitoring procedures in this platform are shown in Figure 4.

Figure 4

Data monitoring procedures in the platform.

Data collection layer: Use sensors such as rain gauges, GPS devices, infrasound monitors, laser mud level gauges to collect data in the monitored area, successively monitor physical quantities → electrical signals (analog electrical signals) → digital signals (analog digital signals), and use wired/wireless network to transmit monitoring data to the server.

Data processing layer: Having received the remotely transmitted monitoring data through the serial port, the server analyzes the monitoring data, and successively carries out preprocessing operations such as filtering and noise reduction, data classification, data formatting, and data interpolation.

Data persistence layer: By deploying the persistent storage interface, the preprocessed data is consolidated in databases or files, and stored in the data server in accordance with the universal rules of the platform.

Business logic encapsulation layer: In accordance with business logic requirements, the monitoring data in the database is encapsulated by “GET,” “POST,” “PUT,” and “Delete” or publishing as REST services, and builds a service supply layer for platform applications.

3.2 Data management design

The data management of the platform mainly includes four modules: monitoring equipment management, alarm threshold management, alarm data management, and user management. Details are as follows:

1. Monitoring equipment management includes two modules: measuring point management and equipment management. Measuring point management manages the information of monitoring sites/areas (such as “GET,” “POST,” “PUT,” and “Delete”) and then visualizes the measuring point locations. Equipment management administers the information generated by monitoring devices. A measuring point may contain multiple monitoring devices.

2. The alarm threshold management module sets alarm thresholds (of indicators such as rainfall, mud water level, and collision line) for monitoring equipment at various locations on a spectrum from red, orange, and yellow to blue. If the data exceeds the preset thresholds, the alarm at the corresponding level will be triggered either in the form of a short message or the flashing icon using the right color at the corresponding location on the system’s three-dimensional sphere. The threshold that may lead to geological hazards differs from place to place. Therefore, it is necessary to separately set the alarm thresholds of the different equipment in each area according to local characteristics;

3. Alarm data management manages the records of the alarmed data in the form of “delay warning” and “informed warning.” Delayed warning means that if the warning does not escalate within a specified time span (e.g., 2 h), the alarm will no longer be issued. If the situation worsens (e.g., from yellow warning to orange warning), the alarm will be issued again. If the monitoring data exceeds the threshold after the specified time span, the alarm will be sent again. Informed warning means that the alarm is duly learned, and if the subsequent monitoring data exceeds the threshold, the alarm will be triggered again.

4. The user management module manages the information of users categorized as users, administrators, and super administrators. Users are only entitled to browse and view the information, but cannot add, modify, or delete them. Administrators are authorized to manage measuring sites, monitoring equipment, alarm thresholds, and alarm conditions, but cannot operate on user information. Super administrators, as the name implies, have access to all operations in the system.

3.3 Early warning model design

Geological hazard monitoring and early warning can be divided into two categories based on the differences between the objects: individual geological hazard monitoring and early warning, and regional geological hazard monitoring and early warning. In practice, regional monitoring is usually used in medium- and long-term prediction, while single monitoring is used in short- and near-term prediction. This platform mainly seeks to conduct single short- and near-term prediction through real-time monitoring data and make real-time observations of hazard sites with professional monitoring equipment. Based on the calculation and analysis of a comprehensive index system, a mathematical model of geological hazard early warning will be constructed to realize real-time monitoring and early warning of the monitored objects [9,24].

Common monitoring contents include surface deformation monitoring, groundwater monitoring, deep deformation monitoring, derivative signal monitoring, hazard process monitoring, meteorological monitoring, etc. Various monitoring methods will be used for different contents. See Table 1 for details.

In practice, multiple monitoring equipment is usually used simultaneously for observing an object. In this case, different results will be obtained if different quantitative values are adopted for the early warning of different monitoring contents. Therefore, this platform adopts a comprehensive early warning model under multi-criteria conditions to conduct early warnings. The evaluation model is constructed based on the weights of different indices to obtain more accurate results. The construction process of the early warning model is shown in Figure 5.

Figure 5

The construction process of a comprehensive early warning model.

The early warning grade of monitoring sites refers to the current early warning level of monitoring equipment deployed at the hazard point. The early warning grade is decided in accordance with the preset thresholds of the monitoring equipment at the monitoring point.

The comprehensive early warning grade analysis quantifies the early warning grade of each monitoring point and calculates the comprehensive early warning grade indices based on their weights to decide upon this grade. In accordance with the standards, early warning results are divided into four colors: blue, yellow, orange, and red, referring respectively to attention, warning, alert, and alarm. The calculation method for the comprehensive early warning grade index is:

where R refers to the comprehensive early warning grade index. W _i refers to the weight of the No. ith evaluation index, and P _i represents the single-factor grading index of the No. ith evaluation index.

The overall early warning process of the platform is shown in Figure 6. The business layer obtains various monitoring data belonging to monitoring sites from the database, and provides the obtained data interface as a service. The platform activates the hazard early warning module developed by the above calculation method and calculates the comprehensive early warning grade. It then deploys the service interface to save the results to the corresponding spreadsheet of the database and gives notification of warning results in the spreadsheet via the database monitoring program.

Figure 6

The monitoring and early warning process of the platform.

4.1 REST application model

Web services based on REST architecture are provided according to several basic principles. The first is to set address resources, that is, to define an ID for all objects, while each resource can be used to define a Uniform Resource Identifier (URI). The second is to specify standard approaches, requiring that standard operations such as “Put,” “Get,” “Post,” and “Delete” can only be performed upon request. The third is to facilitate stateless communication, meaning that each request is independent of one another, and must include its own parameters, in order to complete the operations. The fourth is to enable multiple representations of resources, realizing the rendering of request results in multiple forms [15,25,26], such as XML and JSON.

Based on the above advantages of REST architecture, integrating the required data with REST services through the platform interface can substantially improve the compatibility and accessibility of platform data services, and form unified, maintainable, and scalable service standards, which is conducive to expanding platform functions and enhancing the practicality and reliability of engineering applications.

The clients of this platform will integrate REST service data of all types. In order not to disrupt platform operation, a singular thread for REST service operations will be created at the business logic layer. The Http Client component will be used in this thread to encapsulate REST service operations and send the service requests “POST,” “GET,” “DELETE,” “PUT” or others with the HTTP method or URI. Meanwhile, the returned resources following the service requests, which are mainly JSON, will be submitted to the business logic layer for corresponding processing. On the server side, there is the IISHttpServer as Web and Application service container as well as geographic information servers such as GeoServer, SuperMap iServer, etc. When the service request following REST rules reaches the server, there will be a corresponding service program to parse and process the request, conduct corresponding operations on the database or spatial data, and return the result to the requester. In response to the requirements for platform functions, the backstage services mainly include data monitoring services, early warning model services, and geographic information services, etc. They provide the most important data services for the realization of platform functions. The application model of the REST interface of this platform is shown in Figure 7.

Figure 7

REST application model adopted by the platform.

4.2 Integration of geographical information

The geographic data required by the platform mainly includes map slice data displayed as a base map, DEM elevation data, and DOM data used for the representation of a 3D terrain, chart element data for monitoring devices, and necessary spatial vector data. At present, the software of most mainstream GIS servers is capable of providing REST services, such as the commercial software ArcGIS, SuperMap, and the open-source software GeoServer. Their REST application programming interface (API) encapsulates the GIS functions required for development, including those for maps and data, and is able to realize GIS functions in the form of resources. The clients of the platform can utilize resources from REST interface programming, thus obtaining corresponding GIS capabilities. The integration of geographic information services is divided into the client presentation layer, geographic information service layer, and geographic data layer (Figure 8).

1. Geographic data layer: As the geographic data source of the entire system, this layer incorporates the ordinary relational database of geographic-related data, spatial databases accessed through spatial database engines, map data files, tile map cache files, etc.

2. Geographic information service layer: This layer covers map servers such as GeoServer, ArcGIS Server, and .Net Core application servers like IISHttpServer. Upon receiving REST requests from platform clients, the service layer can provide clients with corresponding GIS data resources, including map data such as video and image data, vector data, as well as the customized GIS data of the location of monitoring sites and others such as element data. In addition, the map server is also compatible with WEB service requests from OGC, such as WMS, WFS, and WMTS.

3. Client representation layer: This layer initiates REST service requests for geographic data to the service layer and renders the acquired data on the 3D earth model with the underlying graphical engine. It can also render browsing of the 3D sphere while adjusting viewpoint heights and inclinations.

Figure 8

Process of the platform’s geographic information service.

The client issues requests for map resources to the server through HTTP GET requests. The map server parses the requesting URI and returns the map resource. Upon receiving the image, the client renders it onto a 3D sphere, and continues to request other map data and renders the returned results in blocks according to the current viewpoint scope.

4.3 Integration of monitoring data

Geo-hazard monitoring data is stored in the database and released through the business logic layer according to the rules and style of REST. Compared with the traditional SOAP Web service that requires a tight coupling between the requester and the server, REST is designed with a focus on the interface of resources and adopted HTTP as the unified interface, leading to better scalability and flexibility, as well as greater convenience for the client to integrate monitoring data.

On the server side, to enable data monitoring, the business logic layer provides corresponding URIs and allowed HTTP operations, that is, APIs designed in REST style. The client initiates data service requests through URI and HTTP, to operate on corresponding monitoring data. In REST services, the main operations include “GET” (enquiry), “POST” (addition), “PUT” (update), and “Delete,” corresponding to the database operations of “Select,” “Create,” “Update,” and “Delete.” Take the operations of monitoring devices as an example to obtain the list of monitoring devices, “GET <URI>/devices” will be executed. After the business logic layer parses the URI, it retrieves the device list in the device table in the database by performing the “Select” function. Following retrieval, it returns the result to the client. If a new device is installed by the client, the request will be made as “POST <URI>/devices/{id}” with descriptions of the fields necessary for the device. For service programs, the Insert function will be leveraged to add the new device data to the devices spreadsheet. Similarly, to revise or delete a client, “PUT” and “DELETE” requests will be used with specified ID parameters from the device, and then “Update” or “Delete” database operations will be conducted. The mapping relationship between URI requests and database operations is illustrated in Figure 9.

Figure 9

Mapping relationship between URI requests and database operations.

After the client obtains the returned JSON data, it will parse and assess the data, and integrate it into the 3D GIS platform according to the data type and latitude and longitude information, to display relevant monitoring data on the 3D GIS platform through layer control of the program.

4.4 Integration of early warning model services

Within a system, the deployment of the early warning model is realized through an active or timing trigger, and the calculation results will be stored in the database. The timing mode is triggered by backstage timing tasks with timing intervals set by the administrator. Active deployment means that the user initiates a request on the client and performs an early warning calculation on the designated area monitored for geo-hazards. Take the POST request “<URI>/warning/monitoring/{area_id}” as an example. In this case, “areaid” is a unique identification for the monitored area. After receiving the request, the early warning model in the server will query data monitored by sensors deployed in the area through the use of “area_id” in the database. Upon completion of a comprehensive calculation, the early-warning model will record the analysis results in the database table. The deployment process is demonstrated in Figure 10.

Figure 10

Deployment process of the early-warning model.

Regarding the calculation results for geo-hazard early warnings in this platform, the major fields stored are shown in Table 2.

Querying the early warning results is initiated through the client by a GET request, and the query details are returned from the business logic layer. There are two main categories for enquiries:

1. GET <URI>/warning/monitoring: It is used to query all recorded yet unprocessed early warning information. The query can be triggered in an active or timed manner through the client, and the unprocessed early warning information with a field of is disposed = “N” will be shown. The revision and update of processed early-warning information are completed after the client initiates a PUT request of “warning/monitoring/{id}/{isdisposed}.”

2. GET <URI>/warning/monitoring/{area_id}/{date}: this is used by the client to actively initiate a query of all early warning records for a designated monitoring site/area within a certain period of time. Specifically, area id represents the monitoring site/area “id” in the date format of “startdate-enddate” that represents respectively the start date and end date of this query.