BY 4.0 license Open Access Published by De Gruyter Open Access September 15, 2021

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

Dunlong Liu, Lei He, Qian Wu, Yan Gao, Bin Liu, Shuang Liu and Han Luo
From the journal Open Geosciences


As geo-hazard monitoring data increases in category and size, conventional geo-hazard information management systems, without a unified integration framework and visualized data display, are unable to satisfy the urgent needs of geo-hazard information management. Representational State Transfer (REST), a resource-centered service architecture, abstracts data and services into resources for unified Uniform Resource Identifier access, enabling it to take full advantage of HTTP with great flexibility and scalability. Based on the REST service architecture, this paper constructs a 3D geo-hazard monitoring and early warning platform with sound service compatibility and scalability by integrating geographical information, real-time monitoring data, and early warning models into the 3D Digital Earth framework. The platform displays topography, stratum lithology, and relevant information, as well as real-time monitoring data in a 3D visual, and provides early warning services for geo-hazards through access to real-time early warning models. As a result, it is capable of providing comprehensive information management, monitoring, and early warning of multiple geo-hazards, aiding decision-making in disaster prevention and mitigation, and enhancing the information level of geo-hazard prevention and mitigation work.

1 Introduction

Geo-hazards are diversified, widespread, frequent, intense, and highly destructive in China, making it one of the countries most seriously affected by geo-hazards in the world. Currently, there are over a million geo-hazard sites in the Chinese mainland, among which over 34,000 are destructive. These hazards seriously restrain economic development in disaster-prone regions and threaten people’s lives and properties [1]. According to statistics, except for earthquakes, geo-hazards lead to an average of over 1,000 deaths and renminbi 10 billion (about $1.5 billion) economic and property loss per year, making geo-hazard prevention and mitigation an imperative [2].

In recent years, as new technologies including remote sensing satellites, drones, Internet of Things (IoT), and Geographic Information System (GIS) are utilized to investigate and monitor geo-hazards, their data manifests in multiple sources, multiple time phases, uncertainties, heterogeneities, multiple scales, and multiple resolutions. Meanwhile, geo-hazards become diversified, the monitoring data streams in real-time, and higher resolution is available for the dynamic updating of geo-hazard investigation data. Massive data have been generated [3,4,5,6,7,8]. Therefore, an information integration platform with sound practicability and scalability based on modern information technology (e.g., IoT, 3S technology, and artificial intelligence), which automatically conducts remote monitoring, analysis, and early warning of disaster monitoring data and displays them in an integrated and visualized way, will aid decision making in disaster prevention and mitigation, and play a significant role in enhancing informationalized level of geo-hazard prevention.

With more categories and a bigger volume of geo-hazard monitoring data, conventional geo-hazard information management systems, without a unified integration framework and data visualization, are unable to satisfy the urgent needs of geo-hazard information management [8,9,10,11]. As a lightweight software framework, Representational State Transfer (REST) is quite easy to use and has widely replaced interface design based on Simple Object Access Protocol (SOAP) and Web Services Description Language. REST represents a group of constraints and principles of framework, and symbolizes the idea of “interlinkage.” With these constraints and principles, it is possible to design Web services with system resources (a combination of data and their representations) at the core, such as map services used by the platform, management services for monitoring data, and calculation services for early-warning models. Based on the REST framework, even clients coded in different languages will be able to process and transmit the status of resources through HTTP [12,13,14,15]. Currently, data for geo-hazard monitoring and early warning has become diversified. By integrating data services with the REST framework, it is also possible to integrate services across platforms and ultimately consolidate services from multi-source data, providing unified data services for the platform and enhancing its scalability and service compatibility. In addition, the platform support both REST service and message queue at the design level. However, REST services can be better integrated with the microservices architecture used in the platform, the acquisition and presentation of monitoring data and warning information are implemented using REST architectures. In terms of real-time monitoring data, the platform supports both HTTP and MQTT national standards. However, due to the early construction of the platform, the monitoring data are uploaded to the server through HTTP at present. Therefore, all data services in this paper will be provided using REST, and be ultimately integrated and displayed through the 3D GIS platform (ArcGIS Globe).

Developed in component development pattern, the 3D geo-hazard monitoring and early warning platform are oriented to the frequent geological disasters in the complex mountainous areas in southwest China, targeted at the emerging needs and development trends of comprehensive management and real-time early warning from geo-hazard monitoring data. By combining with REST that has good scalability and extensibility, the platform can reasonably and effectively organize, manage, and integrate various geo-hazard monitoring data to achieve multi-source data fusion, access to a variety of warning models to realize multi-level chain early warning and release, and build a data visualization based on the 3D Digital Earth, to carry out fine monitoring and early warning of geological disasters in complex mountainous areas. Meanwhile, the platform is universally applicable, reliable, open, scalable, and interoperable, and is hence significant for improving the functions of the geo-hazard information management system, increasing its efficiency and data sharing.

2 Design of the 3D GIS 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.

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.

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. (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. (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. (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. (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.

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 wh, the size or tiles is tsts 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 ) ] } .

2.3.2 Display of vector data

The organization and display of vector data on the platform are mainly based on XML and Shapefile. With reference to the Geography Markup Language and Keyhole Markup Language, heterogeneous spatial data are generally defined and described as follows:

  1. (1)

    Description of spatial data: It describes the way of presenting the appearance and pattern of vector data including points, lines, planes, and solids.

  2. (2)

    Marking of geographical information: It tags geographical locations and other information in the 3D GIS platform, and stores their corresponding properties thanks to compatibility with HTML language.

  3. (3)

    Scene roaming control: This refers to scene roaming in the 3D GIS platform by realizing 3D positioning and perspective changes through defining properties such as the location, perspective, and direction angle of the viewpoint.

  4. (4)

    Representation of geo-hazard information: It renders geo-hazard information in a visualized manner by describing the features of topography and geological structure, information regarding geo-hazard classification and geo-hazard locations, data from integrated space–air–land monitoring, and a series of maps.

  5. (5)

    Realization of data integration: By describing spatial data files, spatial datasets, and services, it integrates spatial data and services scattered on the network to enable relevant applications.

2.3.3 Demonstration of terrain data

The DEM is an entity terrain model that uses a group of ordered digital array to represent ground elevation [4]. As a virtual representation of landforms, it can overlap with DOM or other thematic data to form the 3D earth surface, or be used in other terrain-related analytical applications. Also, the DEM provides basic data for producing DOM.

The most commonly used method to produce DEM is using discrete sampling sites. Point data can be sampled by the regular or irregular grid model. Correspondingly, in demonstrating 3D terrains, the paper adopts the Regular Grid Model (GRID) and Triangulated Irregular Network (TIN). Regular grid model

Mathematically, regular grids can be represented by a matrix, which is stored as a 2D array in the computer. Each element in a grid unit or array corresponds with elevation. Regular grids in the DEM can be represented as an elevation matrix:

(2) DEM = { H i j } , i = 1 , 2 , , m ; j = 1 , 2 , , n .

Terrain surfaces based on regular grids are formed by a series of coadjacent bilinear surfaces. Same as grid maps, it provides much convenience for data storage and processing and is suitable for large-area and overall DEM surface modeling with continuous topography. DEM is derived from the sampling sites in direct regular rectangular grids or produced by interpolation of irregular discrete data points. It is quite easy for computers to process 2D matrices formed by regular grids, derive contour, slope, aspect, and slope shading, and automatically retrieve the terrain of watersheds, which makes the model particularly suitable for applications in the geo-hazard monitoring system [9,19,20]. TIN

The TIN is another method to represent the DEM. The basic idea is to form the collected topographical features into a series of triangular nets that cover the entire area without overlap according to certain principles, with each triangular section representing an inclined plane on the undulant terrain surface, making it easy to integrate data such as fault lines. TIN overcomes the issue of data redundancy in the elevation matrix, and outperforms GRID in calculating efficiency in certain topographical analyses.

Based on the above features, terrain data in the platform is in the GRID format, which is downloaded from the Geospatial Data Cloud ( with the performance parameter of 30 m in horizontal resolution, 1 m in vertical resolution, and ±20 m in accuracy. In addition, the grid data in the regular grid format can be sliced in the same way as video data is organized in the platform, which facilitates unified data description, organization, and management, improves loading efficiency, and makes it easy to combine data on the client platform.

3 Monitoring and early warning design

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.

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. (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. (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. (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. (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.

Table 1

Conventional methods in geological hazards monitoring

Monitoring content Monitoring method
Surface deformation monitoring Geodesy method
GPS method
Surface crack observation
Groundwater monitoring Groundwater level
Soil moisture content
Osmotic pressure observation
Deep deformation monitoring Deep tilt monitoring
Sliding surface displacement monitoring
Accompanying signal monitoring Infrasound signal monitoring
Geoacoustic signal monitoring
Disaster process monitoring Mud water level monitoring
Line collision monitoring
Video monitoring
Weather monitoring Rainfall monitoring

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.

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:

(3) R = n i = 1 W i × P i ,

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.

Figure 6

The monitoring and early warning process of the platform.

4 Integration of the monitoring and early warning 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.

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. (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. (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. (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.

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.

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.

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.

Table 2

Major fields of the early-warning results listed in the database table

Field name Type Introduction
Id Int(32) Serial number
Warning_type Char(50) Timed or active trigger
Warning_level Char(50) Warning level (1–4)
Warning_time Datetime Create time of warning record
area_id Int(32) ID of Monitoring area
isdisposed Char(50) Has it been processed?

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. (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. (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.

5 Application of the monitoring and early-warning platform

The platform, based on .Net Core and database technologies of the Xugu Database, is combined with a 3D GIS engine (ArcGIS Globe), and leverages REST-style Web services to integrate geographic information, monitoring data, and early warning model services. It enables the loading of vector data, grid data, thematic data, and GIS data of all types, the access and display of monitoring data, as well as the demonstration of model-based early-warning results. By offering REST-style services, the system has excellent flexibility and compatibility, and as such it has the capacity to simultaneously access multiple business services. Currently, the overall operation of the system remains stable, which ensures effective loading and presentation of 3D geographic information, monitoring and early-warning data, and early-warning calculation results. Therefore, it will provide better decision-making assistance for the prevention and control of geo-hazards.

This platform has access to terrain data and image data services, vector data layers, thematic data layers, and chart element data, etc., thus enabling a 3D visual experience. In addition, the overlap and display of layers are configurable (Figure 11). Figure 11(a) loads the high-definition image layer and 30 m resolution DEM data of Jiangjiagou Village, Dongchuan County, Yunnan Province, which represents the real terrain. Based on the loading the base map of low-resolution images, Figure 11(b) presents the thematic layer of stratum lithology and exercises dynamic control of layer transparency. Based on the accessed geographic information layer, this platform integrates the REST services using the information of geo-hazard monitoring sites in the form of chart element data, monitoring data, and data of early-warning results. As shown in Figure 11(c), the information collected in some monitoring sites in the Nadigou Lake and Zhongjijiehai Lake of Jiuzhaigou, Sichuan Province, Peilonggou Gully, Tianmogou Gully, and Guxianggou Gully in Tibet Autonomous Region is loaded and presented on a 3D layer, with a goal to facilitate the realization of location-based hazard information management. Figure 11(d) reveals a response to early-warning services. By retrieving the spreadsheet of early warning results in real time, and displaying the early warning information in a list, the platform makes it more convenient for browsing and separately processing the early warning results.

Figure 11 
               Operating results of the geo-hazard monitoring and early-warning platform. (a) Integration and display of image data and terrain data. (b) Integration and display of thematic layer. (c) Location of hazard sites and display of basic information. (d) Statistical display of early-warning results.

Figure 11

Operating results of the geo-hazard monitoring and early-warning platform. (a) Integration and display of image data and terrain data. (b) Integration and display of thematic layer. (c) Location of hazard sites and display of basic information. (d) Statistical display of early-warning results.

6 Conclusion

Based on the REST service architecture and combined with the distributed system of Xugu Database and the third-party control of DevExpress, a 3D geo-hazard monitoring and early warning platform has been developed to bolster the functions of the geo-hazard information management system, improve the efficiency of the system, and facilitate data sharing. The platform has the following characteristics: the REST service architecture takes resources as its core concept and unifies network service constraints, so that developers do not need to worry about the underlying architecture of service providers or the differences in service interfaces and delivery approaches. Corresponding services may be obtained only with the resource locator URI. The platform simplifies the integrated access of several types of services including those for geographic information, monitoring data, and early warning model calculations. Combined with the basic 3D GIS basic platform, the platform can directly present monitoring data and early warning results in real time using a 3D perspective. A new method for the development of a monitoring and early warning platform for geo-hazards has also been proved reliable and effective in practical applications in monitoring and early warning projects.

  1. Funding information: This research was funded by the Project of the Department of Science and Technology of Sichuan Province (No. 2019YFG0505, 2021YFG0258), National Natural Science Foundation of China (No. 42001100), and the National Key Research and Development Program of China (No. 2020YFD1100701, 2020YFA0608203).

  2. Conflict of interest: Authors state no conflict of interest.


[1] Li ZQ, Leng XP, Liang J. Design of geological disaster monitoring and warning platform based on SOA. J Chengdu Univ Technol (Sci Technol Ed). 2018;45(5):606–14. Search in Google Scholar

[2] Yin YP. Initial study on the hazard-relief strategy of geological hazard in China. Chin J Geol Hazard Control. 2004;15(2):4–11. Search in Google Scholar

[3] Zerger A, Smith DI. Impediments to using GIS for real-time disaster decision support. Comput Environ Urban Syst. 2003;27(2):123–41. Search in Google Scholar

[4] Leng XP, Liu DL, Luo JS, Zhan YM. Research on a 3D geological disaster monitoring platform based on REST service. ISPRS Int J Geo-Inform. 2018;7(6):26–44. Search in Google Scholar

[5] Zhu SY, Wang BJ, Shi B, Sun YJ. GIS based stability calculation and zoning of Majiagou landslide. J Eng Geol. 2014;22(6):1187–93. Search in Google Scholar

[6] Wang YS, Tang C, He J, Zhang WX, Fang QS, Cheng X. Use of unmanned aerial vehicle for precise investigation of geological hazard in strong seismic zone. J Eng Geol. 2016;24(4):713–9. Search in Google Scholar

[7] Yue JW, Wang BJ, Liu GH, Cai HC, Zhou YC, Yu GW. Application study on early warning/forecast and information management system of geological disaster. J Nat Disasters. 2008;17(6):60–3. Search in Google Scholar

[8] Dong Y, Zhang SZ. Geological disaster monitoring and early-warning information management system in three Gorges reservoir area. Saf Environ Eng. 2008;15(3):6–9. Search in Google Scholar

[9] Huang J, Huang RQ, Ju NP, Xu Q, He CY. 3D WebGIS-based platform for debris flow early warning: a case study. Eng Geol. 2015;197:57–66. Search in Google Scholar

[10] Jiang RG, Xie JC, Li JX. Research and application of 3D early warning monitoring platform for flood prevention. J Hydraulic Eng. 2012;43(6):749–55. Search in Google Scholar

[11] Jia JK, Ma H, Cai XW, Chen BQ, Shen SH. Geohazard monitoring and management system based on IoT and 3D GIS. J Yangtze River Sci Res Inst. 2016;33(7):142–4. Search in Google Scholar

[12] Pautasso Cesare. RESTful Web service composition with BPEL for REST. Data Knowl Eng. 2009;68(9):851–66. Search in Google Scholar

[13] Muracevic D, Kurtagic H. Geospatial SOA using RESTful web services. In: IEEE Proceedings of the ITI 2009 31st International Conference on Information Technology Interfaces. Cavtat, Croatia: IEEE Computer Society; 2009. Search in Google Scholar

[14] Tang RF, Bai YQ, Wang T. Research and application of risk assessment in urban lifeline systems based on GIS and REST. Comput Technol Dev. 2011;21(3):209–12. Search in Google Scholar

[15] Li JG, Tang XM, Wang HB, Liu ZJ. Research and implementation of WebGIS Based on REST architecture. Sci Surveying Mapp. 2011;36(3):85–7. Search in Google Scholar

[16] Kepner J, Gadepally V, Hutchison D, Jananthan H, Mattson T. Associative array model of SQL, NoSQL, and NewSQL databases. In: IEEE High Performance Extreme Computing Conference (HPEC). Cavtat, Croatia: IEEE Computer Society; 2016. p. 1–9. Search in Google Scholar

[17] Corbellini A, Mateos C, Zunino A, Godoy D, Schiaffino S. Persisting big-data: the NoSQL landscape. Inf Syst. 2017;63(2):1–23. Search in Google Scholar

[18] Baruffa G, Femminella M, Pergolesi M, Reali G. Comparison of MongoDB and Cassandra databases for spectrum monitoring As-a-service. IEEE Trans Netw Serv Manag. 2020;17(1):346–60. Search in Google Scholar

[19] Li BR, Wu JP, Pan M, Huang J. Application of 3D WebGIS and real-time technique in earthquake information publishing and visualization. Acta Seismologica Sinica. 2004;28(3):223–31. Search in Google Scholar

[20] Roy DC, Coors V. 3D Web-based GIS for flood visualization and emergency response. In: Conference Proceedings, 73rd EAGE Conference and Exhibition incorporating SPE EUROPEC; 2011. Search in Google Scholar

[21] He MC. Real-time remote monitoring and forecasting system for geological disasters of landslides and its engineering application. Chin J Rock Mech Eng. 2009;28(6):1081–90. Search in Google Scholar

[22] Liu DL, Leng XP, Wei FQ, Zhang SJ, Hong Y. Monitoring and recognition of debris flow infrasonic signals. J Mt Sci. 2015;12(4):797–815. Search in Google Scholar

[23] Liu DL, Leng XP, Wei FQ, Zhang SJ, Hong Y. Visualized localization and tracking of debris flow movement based on infrasound monitoring. Landslides. 2018;15(5):879–93. Search in Google Scholar

[24] Huang J. Study on early warning of geohazards based on 3D WebGIS technology. PhD Thesis, Chengdu University of Technology; 2012. Search in Google Scholar

[25] Trilles S, Belmonte O, Diaz L, Huerta J. Mobile access to sensor networks by using GIS standards and RESTful Services. IEEE Sens J. 2014;14(12):4143–53. Search in Google Scholar

[26] Gou LM, Zhu MZ, Li YM. Study on web map tile service based on RESTful. Comput Eng Des. 2012;33(9):3609–16. Search in Google Scholar

Received: 2021-04-20
Revised: 2021-08-12
Accepted: 2021-08-30
Published Online: 2021-09-15

© 2021 Dunlong Liu et al., published by De Gruyter

This work is licensed under the Creative Commons Attribution 4.0 International License.