1 Introduction

1.1 Introduction

Landmass on earth, the dwelling place of human beings, is prone to several natural disasters such as floods, cyclones, landslides, earthquake and forest fire. These disasters cause loss of lives and properties, both natural and man-made. The major tools available to counteract the risks associated with hazards are land-use controls, engineered protection works and construction standards, disaster response plans, emergency warning systems, etc. Warning system is the line of protection after engineering solutions have been applied to reduce the occurrence of an event. People at risk can be made aware of any impending disaster through warning system. These systems are economically rational only when a risk becomes an actual event and when having inadequate or no warning systems is unacceptable (Sorensen 2000; Mileti and Sorensen 1990). The number of people who need to be warned varies across events. For most events, only a few dozen persons need warning. However, some events affect population of substantial size. Furthermore, a warning event is often unique, and in some regions, warnings are more commonplace. Warning communication systems are used to disseminate information about risk as well as safety (Sorensen and Mileti 1987; Sorensen 2000; Mileti and Sorensen 1988).

Existing hazard warning systems are expensive, site-specific and require elaborate administration procedures. They are designed using elaborate network of site monitoring devices, towers and even positioning instruments (Wenling et al. 2007). Different groups of experts are required at the sites to administer the instruments. The alarm usually is handled by the experts who then notify authorities (Wattegama 2007). This restricts the use of such systems. It would be worthwhile to implement popular technologies for the designing of a geo-hazard warning communication system, so that people, in as large a number as possible, are able to receive information on time.

Existing early warning systems are based on intensive dedicated infrastructure (Montanari et al. 2007; Avasthy et al. 2006; Bhandari 2006) and proclamation through telephone, fax, television, radio, etc., but not through SMS (Pries et al. 2006). One of the major drawbacks of the existing systems is that they have been developed for site-specific hazards. And most of these are authoritative warning systems (Waidyanatha et al. 2007a, b, c, d) and cannot disseminate automated warning to the affected people.

A system capable of disseminating adequate and timely warning to the public is of great value (Bhandari 2007). The architecture of a warning system needs to be automated as well as generalized enough that can be used for any hazard and setup requirement should be minimum (Wenling et al. 2007; Nayak and Zlatanova 2007). Further, a warning system using prevalent technology based on popular usage helps to proclaim warning quickly and easily. Thus, it is prudent to look for a system that could be developed with available infrastructure, instruments and setups and reaches affected people on time (Enck et al. 2005). The ever increasing number of mobile phone subscriptions around the world facilitates the prospect of reaching more than 75 % of population on an average in a given locality, more so via short message service (SMS), a mobile phone service (Cioca et al. 2008). Moreover, mobile communication infrastructure, being airborne, is ubiquitous, and a local disaster cannot shut its communication totally. Finally, a warning communication system that can be easily integrated to any hazard evaluation system will really help to augment the existing hazard communication capability.

The concept of an automated hazard warning system addresses many complex issues related to geo-hazard mitigation (Bhattacharya and Ghosh 2009). Such a system can be centrally coordinated and can run multiple tasks simultaneously and repeatedly, thereby emulating multiple expert groups (Dow and Cutter 1998). Typically, many expert groups and agencies cooperate in response to an emergency, and communication with the public is one aspect of the response that must be coordinated among the groups. It is very difficult to keep groups and agencies under a single/central control. The content of warning messages may originate with different responding agencies, but it is important that messages to the public are consistent with one another and their dissemination coordinated to achieve the best effect. Inconsistent messages would lose credibility; too many messages lead to losing affectivity; too few messages would have inadequate impact (McGinley et al. 2006). In large, rapidly emerging emergency events, coordination between responding, supporting and managing agencies requires a high level of overhead, and maintaining this effort in the context of an emergency can be problematic (Standing and Jackson 2007; Stockdale et al. 2006). Hence, to address these challenging issues, the development of an automated warning system is needed.

The need for a reliable, coordinated approach to disseminating information originating from diverse hazard management agencies has led emergency professionals and incident inquiries to call for a centralized entity with this responsibility for public warnings (McGinley et al. 2006; Zlatanova and Dilo 2010). The very reason for the existence of so many channels is that none of them is suitable for every situation. One medium that might fit best under a certain set of circumstances might be of little use under another. Hence, it is necessary to maintain multitasking and centralized control, which could be well imparted through an expertly designed warning system.

Warning systems are complex in nature because of involvement of many specialties and organizations—science (government and private), engineering, technology, government, news media, public, etc. (Sorensen 2000; Sorensen and Mileti 1987; Mileti and Sorensen 1988; Xu and Zlatanova 2007). The mitigation of hazards due to flood, hurricane, tornado, tsunami, landslide, etc., has required research efforts toward hazard prediction (Altan et al. 2010; Gruntfest and Huber 1989; Dow and Cutter 1998; Sorensen 2000; Zlatanova 2009, 2010) as well as warning dissemination (Rogers and Sorensen 1988; Mileti et al. 1992; Perry 1979; Perry et al. 1982; Quarantelli 1984; Liu et al. 1996; Mileti and Sorensen 1988, 1990).

There have been separate systems for warning hazard as well as for assessment of hazard, but their integration has been problematic. Hazard warning has been researched by information technology experts and hazard assessment by geo-engineers (Li et al. 2007; Nayak and Zlatanova 2007, 2008; Ramasamy et al. 2006), but the case studies remain confined to the respective domains (United Nations 2010; Samarajiva 2005). This leaves incompleteness as far as the safety of end-user is concerned. A warning system with the ability to receive information from external source could be a solution to the problem. The information could be the output of another system, viz., hazard assessment system. This requires development of warning communication system having functionality to associate with external information.

Thus, a hazard warning system consists of an input subsystem, a processing subsystem and a warning subsystem (Mileti and Sorensen 1990). The mutual interactions among the different subsystems, through predefined rules, make the system feasible and workable. Mileti and Sorensen (1990) in their seminal work have summarized the advancements in hazard warning systems over the past few decades. They described the components of a generalized hazard warning system, their broad functionalities and an overview of the interactive monitoring and responses. The structure is valid generally and can be improved upon by focusing on the respective subsystems. The need of the hour is the integration of the subsystems for hazard evaluation and warning dissemination (Sorensen 2000; United Nations 2010).

Hence, a communication system to warn against such hazards needs to be developed. It needs to aim to be independent, fast and pervasive. It has to be designed to be a generalized system that could be deployed for any geo-hazard across any region. The system should be modular in structure consisting of functional units and get activated once it is fed with threat level and geo-locations. The existing cellular network better be utilized for disseminating hazard information as short messages.

1.2 Objective

With the background, the objective of this paper is to explain the development of an automated geo-hazard warning system. The challenges associated with the development of a geo-hazard warning communication system are the following:

  1. 1.

    Development of a geo-hazard evaluation system.

  2. 2.

    Designing of popular usage-based warning communication system using prevalent technologies.

  3. 3.

    Integration of hazard evaluation system with the warning communication system.

  4. 4.

    Development of methodology for automated working of the integrated system.

1.3 Proposed strategy

The major requirement toward development of a warning system is to integrate a hazard evaluation system with a warning communication system. The integration requires an introduction to a common platform. One possible solution could be a system capable of inculcating information regarding the possibility of hazard and using available communication infrastructure to notify the same to the public. The communication of warning to the end-users may be achieved by communicating through the existing cellular network infrastructure. One of the good practices of system design is to keep it modular and compartmentalize the tasks according to the modules. There has to be transmission of data between modules in a system for which well-defined prior mutual agreements are required among the modules.

2 Proposed system

The challenges that come with such an endeavor are multifarious in nature. As the intention of development is individuals to get notification directly of the hazard in time, the necessities are that the system needs to be designed to do basic functions of evaluation, receiving, processing, storing and transferring of data. These broad functionalities could be provided by the combined working of the information and communication technologies in the framework of geo-spatial technology (Backhaus and Beuleb 2005; Carrara et al. 2004; Gomarasca 2007; Kang et al. 2007). In this section, the overall architectural framework of the system has been described and put together the modules, the interconnectivity among the modules inside the system and the system requirements.

2.1 Architecture

The system has been designed as an integration of two broad divisions: hazard evaluation and warning proclamation. The hazard evaluation has been implemented through several modules and sub-modules. The prototype system presently functions in the domain of a geo-hazard called landslide. The knowledge base (KB) for landslide hazard pertains to the Indian Standard Code (IS 14496 1998), and the expert module has been architected to be generalized enough to hold any geo-hazard KB. A KB understanding system for landslide has been adopted to generate the landslide susceptibility zonation (LSZ) map. The modules carry out automatic extraction of information about causative factors from thematic maps. The methodology is based on the development of a knowledge-based system having expertise of Indian Standard Code (IS 14496 1998) in its KB. It implements extraction (based on legend matching) of information about causative factors from their scanned thematic maps as inputs; conducts pixel-based reclassification (compatible to the KB) of the input geomorphologic maps; forecasts rainfall from the Tropical Rainfall Measuring Mission (TRMM) data (Hong et al. 2007); addresses expert knowledge as rules (qualitative approach); evaluates the intensity of hazard on the ratings of causative factors (deterministic method); and finally transfers the calculated threat to warning module for outside communication (Fig. 1).

Fig. 1
figure 1

Architecture of proposed system

Full size image

The framework of the system includes the functionalities categorized as modules: the input, the understanding, TRMM rainfall prediction (Hong et al. 2007), the expert, the output or decision, and the warning module. The input module is where the causative factors of a given hazard are fed, understanding module deciphers the inputs, rainfall being an important parameter for many of the geo-hazards, has been kept as a separate TRMM rainfall prediction module for data gathering and processing, the expert module is responsible for the decision making process with the help of the KB and inference engine. The decisions arrived at is stored in the output module. The set of decisions varying spatially is transferred to the warning module, which stores the information in its server database and client database sub-modules.

The threat susceptibility classification for any hazard in the region is basis for the communication to the user. In this study, the classified landslide threat information is provided by a landslide susceptibility assessment system (Ghosh and Bhattacharya 2010). The purpose of this paper is to report the success of the integration of hazard evaluation and hazard dissemination in an automated system. The input module has been developed to accept scanned images of thematic maps of causative factors of hazards. Presently, landslide causative factors namely soil and rock condition, land use, land cover, relative relief, ground water condition map, rainfall map and TRMM real-time precipitation map over the given region are being utilized in the prototype system. TRMM is an additional component of antecedent rainfall data input from United States NASA Tropical Rainfall Measuring Mission (TRMM 2011; Hong et al. 2007). A new series of quasi-global, near-real-time, TRMM-based precipitation estimates is now available to the research community via anonymous ftp. The estimates are provided on a global 0.25° × 0.25° grid over the latitude band 50° N–S within about 7 h of observation time (Hong et al. 2007) for precipitation estimates (three-hourly accumulations); a geosynchronous infrared estimate that is calibrated by the merged-microwave data (hourly estimates); and a combination of the first two fields (three-hourly accumulations).

The Understanding Module consists of a matching algorithm that emulates the map interpretation capability of a human interpreter. The algorithm is based on correlating the color code of the legends with the different color regions present in the map. This is being achieved by matching the digital values of the scanned legends with that of the digital values of the pixels present in the scanned maps (made available through input module (Fig. 1)). This leads to understanding of the digital maps to correlate the information with the next functional module, that is, the expert module having knowledge base (KB).

The KB incorporated in the system is derived from the inventory prepared by the Indian Standard Code (IS 14496 1998). The six causative factors with their sub-factors and ratings (Ghosh and Bhattacharya 2010) are stored in the Knowledge module. The KB has been represented in the system by an object-oriented KRS (Bhattacharya and Ghosh 2008). In the example considered, the input of each factor was searched and matched in the instance of the KB, and a hazard rating (LHEF) was determined in the inference module.

The inference scheme picks up the facts from the input images and applies searching and matching logic to fire a rule. The searching and matching in this case is of the string derived from the legend with the strings in the KB to come up with a match (Bhattacharya and Ghosh 2008). As soon as a match is found, the hazard rating of that factor is put in a variable, from the KB. This is repeated for all the causative factors, and their ratings are stored in variables. The estimated hazard is calculated based on hazard-causing factors and hence determines the landslide susceptibility in that pixel region into one of the three broad categories low, medium or high (Ghosh and Bhattacharya 2008).

The output module stores the decision for each pixel as a function of the degree of threat for the region represented in that pixel. The success of classification results is detailed in the paper (Ghosh and Bhattacharya 2010). The hazard class associated with each pixel was assigned first, and then an output array was prepared for the image pixel-by-pixel. For each pixel, a hazard class (high, moderate or low) was assigned. The extended example is explained in (Ghosh and Bhattacharya 2010). A separate class was kept for unclassified pixels. The x,y location parameters are also stored. For each pixel and its associated threat perception, an appropriate message is stored which would be accessed by the communication module to be sent to users moving into the region if threat perception is high. The location details from the x,y coordinates are useful here. Message is sent even if threat is low to bring in confidence to the user.

The validity of the system output has been established by comparing its performance with those reported by other experts. From the validation studies, it has been found that the proposed system provided output commensurate with that provided by experts (Ghosh and Bhattacharya 2010).

Once the hazard output is achieved, now it is the turn of the warning module to send the correct messages. The warning module holds the network coverage details and the location of service towers/base stations in its database sub-module. It also has the display-related configuration for a friendly GUI (graphical user interface) environment for the operator which is the web application housed in web-content handler sub-module. This application is a JAVA program and has the logic of notifying the appropriate trigger. The level of hazard determines the trigger to be generated. There are separate ranges for mild, moderate and high hazard triggers. The trigger sub-module initiates the trigger and calls the communication sub-module.

The data pertaining to a geo-hazard warning system consists of spatial, instructive as well as communicative details. Spatial details such as latitude and longitude, instructive details such as guidelines for an emergency, and communicative details contain whom to send the warning to. Accordingly, the database module has been developed to contain the geo-referenced locations of hazard prone area, the threat levels in that area as communicated by hazard evaluation system through the communication module, and the mobile numbers of the registered users. Essentially, it acts as the storehouse of the system, and the design grants access to the other modules as and when its data are required.

As soon as the system gets fed with classified hazard information (geo-location and levels of threat), database module parses the dataset and stores as server and client database sub-modules separately. The data are organized sequentially and indexed according to the exact ground location. The mobile numbers in that zone are registered separately. The web-content handler module is designed to utilize the data from the database module. It encapsulates the data and ensures that the parameters reach the communication module for launching the message dissemination utility. It creates the GUI of the system using HTML and controls the web (Internet) application data transmission applying HTTP. Data transmission security has been ensured by using the HTTP-Secured, which provides a secure channel between the client station and the system residing on the server. It also controls the display-related configuration of the web (Internet) application creating a GUI environment for the operator.

The primary task incorporated in the trigger module is to check the condition of threat present at a location, from the evaluated hazard information. Accordingly, whether the condition turns out to be severe or otherwise, appropriate message dissemination trigger is raised. It is interfaced to the web-content-handler to be able to accept the encapsulated information packet, read the threat message for that geo-location and extract the hazard level for that particular geo-location. On the basis of the level of threat, it incorporates the frequency of message in the packet and then passes the upgraded packet to the communication module (Bhattacharya et al. 2011).

The communication module contains the design to receive information packets from the trigger module. On receiving a packet, the mobile numbers and the associated threat message are extracted by the communication module. It then opens the SMS sending utility and fills the mobile numbers as well as the threat message in the vacant fields in the body of SMS utility. After that, it communicates the data from Internet to mobile network through appropriate gateway. Through the mobile network, it broadcasts the SMSs to all registered mobile users present in the threat-prone and/or affected area.

2.2 Hardware

2.2.1 For hazard evaluation

The processor and main memory requirements are modest, with anything greater than 500 MHz and 512 MB memory being sufficient. Processing time depends on the size of the input images, in which for six images of 1,000 × 1,000 pixels, the output required 5 min on a 1.6 GHz processor and 512 MB memory.

2.2.2 For warning dissemination

The system design and architecture has been implemented to be web-based. Since it is designed to have interfaces with external events such as hazard evaluation system, local servers, the Internet and the warning communication server, commensurate hardware allocation has been provided. It has been operating on a general purpose computer with Windows operating system having 4 GB RAM and 250 GB secondary storage with Internet connectivity. Further, Web browser (Firefox, Internet explorer >5.5, Netscape) with HTML and HTTP compliance has been used to meet the proposed objectives. The programming environment has been JAVA J2EE, and the database has been handled using DBMS language MySQL 5.x.

2.3 Software

2.3.1 Hazard evaluation

The system was developed with an open-source code. The language of programming used was JAVA.

2.3.2 Warning dissemination

In the Java 2 Platform, Standard Edition (J2SE) having version of compiler JDK 1.5.0.03, it has been possible to get Java Advanced Imaging (JAI) libraries that help in recognizing as well as manipulating different image formats. The connectivity with the KB has been provided by developing a Java Database Connectivity—Open Database Connectivity (JDBC—ODBC) bridge—with the help of JDBC-ODBC driver provided in the JDK.

3 Working of the system

3.1 Hazard evaluation and warning dissemination

A database consisting of geo-location-based geo-hazard threat levels and its associated registered mobile numbers are prerequisites. The working of the developed system has been tested on a landslide-prone area. The threat susceptibility classification for any hazard in the region is the basis for the communication to the user. In this study, the classified landslide threat information is provided by a landslide susceptibility assessment system (Ghosh and Bhattacharya 2010). Communication of hazard has been achieved using existing cellular network infrastructure available in the locality. The approach requires the data to be processed only at one terminal as well as having no need of executing any other separate application for every mobile phone, and the functionality is coded in the warning system itself. Once the data from the evaluation system get fed into the communication system, the warning messages get communicated automatically.

The hazard data were provided along with the registered mobile subscribers’ data to the communication module of the system through an external_event system-call. The communication module forwards the system-call to database module to create the full database tables out of the hazard information and subscriber list.

In Fig. 2 the GUI of the developed geo-hazard warning communication system is shown having the various processing capabilities programmed in the system. The knowledge base is selected for the hazard conditions as is seen in the top left corners of the screenshots. The causative factors that are processed are listed on the screen. There are processing commands for Process Maps and Send SMS as shown. There is a current execution display board toward the lower area of the screen shots where it displayed the various activities being performed by the system. The activities range from Processing Maps, Uploading hazard data, Creating database, Creating warning messages, etc. Figure 2a lists some of the causative factors being processed, and Fig. 2b lists the stages of uploading processed data, creating database and keeping ready the warning messages for dissemination. The dissemination process begins by communicating with the local mobile network.

Fig. 2
figure 2

a Processing of causative factors to yield evaluated map showing red, yellow and green zones. b Sending of SMS in the given map area

Full size image

The network communication broadcast facility has been used to freely send short messaging services to all users of mobiles moving into an area that has been perceived threat prone. Alternatively, a user can communicate his location and request the update of threat perception through a service called General Packet Radio Service (GPRS) on mobile. The output image obtained from output module is analyzed mathematically with the Base Station’s database and the BTSs which either itself or whose range lies in the danger zones are marked. The output database about the warning message is updated, and the information sent to the server and the warning module is invoked. All the processing steps are repeated again and again, at regular interval of time as desired (Ghosh et al. 2009).

The region is determined from the location database (Fig. 3a, b) of the cell and hazard message communicated. Corresponding to pixel locations on the image, each physical region is represented by a latitude–longitude pair in a location database table (Fig. 3a), which also stores the threat perception determined to be either low, moderate or high threat. For each such location in the location table, there is a corresponding message database table (Fig. 3b) that stores mobile numbers in that region to which hazard message is to be sent. This table also stores the message to be sent. Once a pixel is processed, each step shown in Fig. 4 is executed methodically and SMSs sent.

Fig. 3
figure 3

a Snapshot of location database table, b snapshot of warning module database table

Full size image
Fig. 4
figure 4

Schema for warning procedure

Full size image

Hence, as soon as the mobile numbers in the region are extracted from the table (shown in Fig. 3a, b), the SMS Protocol program is called and the mobile numbers filled in the program as command line parameters and the respective hazard messages are sent. The number of mobile numbers selected per region is fed in a loop, and the SMS program is called for each number for sending SMS.

3.2 Implementation

The open-source development environment of JAVA has been used to code the landslide warning system. The system is encapsulated in different functional classes as shown in Fig. 5. The initialization of the system occurs inside the StartUp class, which has functions for invoking all the other system classes in sequence as per the logic. The logic dictates that the input be processed, categorized, matched and evaluated, so that decision can be made for each stored value. This sequence of events is taken care of in the subsequent classes. The StartUp class calls the ThematicMap class to handle the input, which is the digital data for landslide causative factors pertaining to an area as 3-dimensional array images, the ThematicMapProcessor class to digitally process the images and LegendClassifier class to understand the images. The supporting classes used in this processing are imageMain, imageIO and Utility.java classes.

Fig. 5
figure 5

Integrated functioning of hazard evaluation and warning through classes invoked in sequence comprising the logic of the program

Full size image

Next in the sequence, begins the traverse through the knowledge module where the matching, selecting and inferencing of the expert knowledge take place. For this to happen, there is a vast database of expert knowledge kept in file systems inside the knowledge base (Fig. 1). With the help of the knowledge base, the system arrives at a decision for each processing phase. And each processing phase constitutes a single pixel representing the ground condition, as detailed in (Ghosh and Bhattacharya 2010). This is digitally stored in arrays that are traversed address-wise while processing. Corresponding to each pixel-address, a ground-location detail has been stored in a separate database. So the cycle of processing continues till all geo-locations get processed. Once a cycle gets completed, the system provides geo-location-based hazard intensity level, that is, corresponding to each pixel, a geo-location (in terms of latitude and longitude) with a hazard level (low, medium or high) becomes available as shown in Fig. 3a; the algorithm responsible for this landslide susceptibility zonation and its accuracy are mentioned in (Ghosh and Bhattacharya 2010). The database table maintained for the purpose of the threat message for each pixel according to the level of threat classified is stored alongside the location details as shown in Fig. 3b.

Next, the main system class StartUp invokes the warning functions which are actually being monitored by iObserver.java class (Fig. 5). This class has the trigger conditions for sending any SMS (Fig. 1). The warning module uses the location database and accesses the threat message strings corresponding to each. In its own database, the warning module has the mobile numbers in a storage format shown in Fig. 3b.

Hence, as soon as the mobile numbers in the region are extracted from the table (Figs. 3a, b), the SMS Protocol program is called and the mobile numbers filled in the program as command line parameters and the respective hazard messages are sent. The number of mobile numbers selected per region is fed in a loop, and the SMS program is called for each number for sending SMS. The SMS program connects to the SMS gateway via the Internet, and this gateway forwards the text message to the mobile environment (Peersman et al. 2000; Ghosh et al. 2010).

3.3 Results

Just as the system is defined in two parts, so are the results, which are also in two phases for the complete system. First is the output of landslide zonation, second comes the successful transmission of hazard messages. For the first part of landslide zonation, initially a LSZ map was prepared for a region of the Tehri-Garhwal district of the Uttarakhand state in India lying between 30°4′N and 30°52′5˝ N latitude and 77°50′E and 79°3′E longitude. The hazard results have been well documented and compared separately (Ghosh and Bhattacharya 2010) and show no more than 6 % variability with expert group results in critical landslide hazard areas. This hazard information in digital array format is the constituent input to the second major functionality of the developed system which is warning.

The second test site lies in the capital complex of Arunachal Pradesh, India, and is bounded by the 93°30′ to 93°50′N longitude and 26°56′ to 27°15′E latitude (Ghosh and Bhattacharya 2010). The LSZ system output using the expert-generated thematic maps was compared pixel-wise with system output. The trends of the hazard results in both are similar (Ghosh and Bhattacharya 2010). Hence, the hazard output capability of the system stands verified and could be proceeded to make the integrated warning dissemination.

The warning system functions by reading each pixel from the array of pixels and using the base address of the array to search the associated mobile information and message string to be transmitted. The validation consisted of creating a database of pixel-wise listed hazard messages and registered mobile numbers in data tables. These data tables correspond to the regions taken up for testing the system mentioned earlier. The mobile numbers to be communicated are residing within the latitudinal and longitudinal expanse of the Test site. The table entries were selected one after the other, and after this, the messages were transmitted six times 20 short messages (SMS) in a bulk to locally owned mobile numbers, resulting in a total number of 120. It was found that 58 messages got delivered within 10 s, rest within 40 s (Table 1). Progressively noticed that if one SMS is delayed, rest following it are cumulatively delayed too. But all messages generated were delivered, and the time frame is acceptable for emergency purposes.

Table 1 Results—SMS delay (in seconds)
Full size table

3.4 Discussion

In the working of the developed system, a geo-hazard communication system has been implemented in which once hazard level is fed in acceptable format (which could be best done by storing the information latitude and longitude area-wise and associating threat messages and mobile numbers in succeeding columns of the table), warning could be sent through mobile communication. The system functions by searching and matching the geo-address of the area as a tag to search the associated mobile information and message string to be transmitted. Once the table is accessed, the SMS program is initiated, and the mobile numbers filled in for the messages to be sent. It is sensible to develop a system using open-source technologies and software to as much an extent as possible. This avoids the problem of any proprietary issues and is cost-effective. Hence, the proposed warning system has been developed using MySQL as the database management system, HTTP and HTML as the Internet technologies and JAVA programming environment for system programming and mobile programming.

The developed system is capable of utilizing the software interfaces through the Internet in order to send messages to user mobiles, as well as utilizing the hardware interfaces in the case when a GSM modem or a mobile phone is directly installed in the computer where the developed system is running. The necessity of utilizing the hardware interface arises in case the availability of Internet is scarce at any location. The methods, parameters and classes all remain constant in both software and hardware interfaces procedures, only the situational knowledge base demands addition. The integrated working of all these interfaces leads to successful delivery of important warning messages to threat-prone areas as recorded in the results.

4 Conclusion

A geo-hazard warning system has been developed, which accepts hazard level from hazard evaluation system, and warning gets disseminated through mobile communication. The system works by searching and matching based on geo-address of the area as a tag, for associated mobile information and warning messages to get transmitted. The reliability of the system has been tested, and the critical threat messages have all been delivered. So it can be summarized that a novel and stand-alone system for dynamic hazard warning communication has been developed and implemented. Thus, cellular or mobile phone, a gadget used by common man, is the best proposition to effectively warn people individually and to propagate hazard messages to users in large regions ubiquitously.

The warning system presented in this research work provides a reliable and effective solution employing information and communication technology in the framework of geo-spatial technology, which is complementary to existing traditional warning systems. The proposed warning system increases the chances that registered users might receive the warning on time. The development of a popular usage-based warning communication system through integration of prevalent technologies has been achieved. The integration of the hazard warning unit with the hazard evaluation unit has been feasible through the design of an intersystem method call. The results of sending SMS showed that the communication module is capable of dispatching real-time warning messages about geo-hazards on time and to registered numbers.

The scope for improvement could be in many directions. Technologically seen, integration with sensors and other geotechnical instruments of geo-hazard monitoring could be included in the generalized framework of the input module itself. The problem of network congestion may also be a bottleneck, for which faster algorithms need to be implemented. Demographically, it is important that provision is made for well-defined instructions to the recipients for safe areas, contacts of hazard support agencies in the message, registration of mobile numbers beforehand for only those interested in receiving the alerts and interaction ability with the recipients and that the delivery of instructional messages may have the effect of out-of-order receipts at the consumer end. From the social point, the local language may pose a challenge in understanding of messages since English is hardly the language in many threat-prone areas.