# Conversation-Based School Building Inspection Support System
## 4 Implementation
### Development  
The database is designed to store the following data:  
* Public schools and their locations;
* Inspection targets including their names, types, intensity-scale thresholds, and the cascaded maps that lead to them;
* IM application account IDs and the contact information of the registered assessors;
* Checkpoints for the inspection;
* Responses to the checkpoints.  
For the N-module, the routine notifier runs per the schedule for the school. The post-event notifier is linked to the open data platform of the Central Weather Bureau (CWB), which is the authority on earthquakes in Taiwan. When an earthquake occurs, the N-module acquires seismic data from the authority and selects the schools that reached their intensity-scale thresholds. The NCREE sets the threshold of each school based on the school's condition. If the threshold of the school building is reached, the N-module is activated and sends messages to the registered school assessors for completing inspections. For schools whose thresholds are not reached, the school assessors do not receive messages.  
The C-module adopted diverse formats of messages from the LINE Messaging API. The \"template message\", which provides a set of buttons as the interface, is adapted for replacing typing if the expected response is from a set of options. For example, the confirmation of each checkpoint is implemented with the \"template message\", providing an alternative means of input by pressing the \"no problem\" button instead of typing \"no problem\" directly. We also adopted \"image maps\" and \"rich menus\", which are clickable images with covered invisible buttons. Typing can be replaced if the expected responses are limited and correspond highly to images. For example, the cascaded target specification is implemented with the \"image map\" and the \"rich menu\", enabling assessors to specify the inspection targets intuitively with the aid of maps. The C-module regards the LINE Messaging API as a proxylike interface between the chatbot and assessors. For providing checkpoints to assessors, the C-module sends requests with message objects in JSON format to LINE via HTTP. When assessors send messages to the chatbot via LINE, the LINE Messaging API calls the webhook of the C-module, and the C-module thus receives the assessors' messages. The C-module accepts multiple types of incoming messages, including text inputs, postback actions, and multimedia files.  
To implement the two-phase damage locating process, the campus plan and floor plans of each building in Taiwan Tech was collected. The campus plan was divided into several subplan areas that cover different parts of the campus considering their relative size. By pressing the subplan area, the chatbot leads the assessor step-by-step toward the inspection target, such as a room in a building,and thus completes the first locating phase. The assessor starts to inspect the room through the guidance of the checklist; if any damage is discovered, the assessor enters the second locating phase and indicates the damage location using the given plan image of the room, thus directly linking the description and the multimedia file to the location of the damage.  
HTML, CSS, and JavaScript (JS), which modern websites are usually built on, are used to implement the interface of the D-module. We developed a dashboard that instantly presents the inspection results to managers. The dashboard imports two JS libraries, _OpenLayers_ and _D3.js_, for data visualization. _OpenLayers_ provides several map-related features such as map loading, geographic data visualization, and overlaying [23]. _D3.js_ dynamically visualizes data and features functions to enable interactive graphics [24]. The dashboard acquires data using Asynchronous JavaScript and XML (AJAX) from the D-module. The D-module selects data from the database and performs analyses if necessary.