Development of an Early Warning and Incident Response System for the Protection of Visitors from Natural Hazards in Important Outdoor Sites in Greece

Abstract

Safety in touristic destinations is of utmost importance since tourists’ preferences change frequently in response to emerging threats. Natural hazards are a significant risk and, as such, they need to be considered in the effort for safe tourism. Services and systems monitoring and predicting extreme natural phenomena and disasters in sites of special tourist and cultural interest can lead to more effective risk management and incident response. This paper presents Xenios, a system under development in Greece that provides early warning and risk communication services via web-based and mobile phone applications. We present the user requirements analysis contacted, which led to the design of a modular system architecture through a formal Business Process Model procedure. Currently, early warning systems for wildfire, floods, and extreme weather events are offered, based on a fusion of information from satellite imagery, meteorological forecasts, and risk estimation models. Moreover, visitors’ dispersion monitoring via unmanned aerial vehicles (UAVs) and Wi-Fi connection signals is also offered, along with emergency response planning and ticketing system’s interfacing. The system is built around a modular architecture that permits the easy integration of new subsystems or other danger forecasting modules, depending on the site’s actual needs and limitations. Xenios also provides a mobile app for site visitors, which establishes a communication link for sending alarms, but also serves them with useful tourist information, so that they are encouraged to download and use the app. Finally, the opportunities for supporting a viable business model are also discussed. The results of this study could prove useful in designing other natural risk management systems for sites of cultural and natural interest.

1. Introduction

With natural disasters being a major concern in modern societies and with predictions that their manifestation and impacts will trend upwards because of climate change [1] and global change in general [2], modern societies are highly concerned with the need for prevention and damage mitigation. Disasters have been found to affect world economies and to hit developing economies three times harder than the developed ones, both for individual fatality risk and for property destruction [3]. A recent study has shown that there is strong evidence for a sharp increase in the economic damages caused by extreme natural disasters [4].

For many countries, tourism is a key element of the economy. In many places (cities, islands, regions) the economy is based on tourism, which—under certain conditions—has proven to be a key driver for growth. This is attributed to the nature of tourism as an activity, which develops primarily at a regional and local level. However, as tourism is not an obligatory activity and is associated with well-being, its growth is vulnerable to a host of factors that can range from political and financial crises to socioeconomic changes, to disease epidemics, or even to terrorism [5]. Key among these factors is the issue of safety because tourists—as a rule—have every reason to avoid places where serious safety concerns may exist. Thus, the impacts of natural disasters in tourist destinations can be manifold and severe [6].

An example of such a traumatic experience that also caused negative publicity for Greek tourism was the case of the archaeological site of Olympia, which was hit by a major wildfire on 26 August 2007. The visitors had to leave the site in a hurry and seek refuge in the nearby town of Olympia, whereas the site received heavy damage [7]. The uniqueness of the site (a UNESCO World Heritage Site), which is very important for Greeks and the international athletics world, made the damage much more than simply physical or economic. The cost was very high because of damage to the prestige of the site, physical damages, and loss of income from visitors. Funding for a comprehensive site rehabilitation project has since been added to the total cost [8]. A similar situation but on a smaller scale occurred on 30 August 2020 when a wildfire passed through the important archaeological site of Mycenae, in Greece. Another interesting example is the Yangyang Forest Fire that destroyed the Historical Naksan Temple in the Republic of Korea in 2005 [9]. In this event, as in the case of Olympia, the fire started on the previous day, so the people were evacuated in time and there were no casualties.

Outdoor sites of cultural and natural heritage are particularly exposed to the threats posed by climate change: “The impacts of climate change are affecting many and are likely to affect many more cultural goods in the years to come” [10]. In 2013, the International Centre for the Study of the Preservation and Restoration of Cultural Property (ICCROM) has identified Disaster and Risk Management as one of its key programmatic areas, whereas several guiding principles were suggested both to reduce the risks from natural and human-caused disasters and to improve the management plans and the integration of hazard and risk in cultural heritage by several international organizations [11,12,13]. Similar guidelines are also produced by UNESCO’s Man and the Biosphere (MAB) Programme for its World Network of Biosphere Reserves (e.g., [14]).

Early warning systems on approaching disasters in highly visited tourist places, such as archaeological sites, are a key asset for the managers so that they can take proper emergency response measures including timely and safe evacuation of visitors. Prerequisites are early detection of the potential threat, assessment of its characteristics (magnitude, damage potential, etc.) and the time of arrival, and existence of planning on how to react given this assessment. Regarding visitors, a key issue is how to communicate warning messages and give directions to them about what to do.

The herein presented Xenios system aims to address the problems above introducing some significant innovations. The system provides early warning and decision support to the managers of a site regarding natural hazards of interest, but also serves the visitors with useful tourist information on their smartphones, simultaneously establishing a communication link for sending alarms, warnings, and risk avoidance directions in case the need arises. The objective of this paper is to showcase how this fusion was successfully achieved. We present the solicitation and analysis of user requirements, the formulation of the design principles, and the formal Business Process Model (BMP) analysis conducted, which led to a loosely coupled system architecture, permitting to remove or add modules—depending on the site’s needs—without changing its core. Furthermore, the opportunities for supporting a viable business model are also discussed. Hence, the results of this study could prove useful in designing other similar systems in the future.

2. State-of-the-Art

Regarding tourist safety, it is key to recognize that many tourism installations, from hotel resorts and cabins to archaeological and cultural monuments, ski areas, golf courses, and nature trails are located outdoors and are directly exposed to natural events. The same holds true for visitors who can be numerous at one location at a particular moment. As extreme events are manifested with increasing frequency and intensity in the last few years, the risks to which these sites and their visitors can be exposed should be considered very seriously. Management agencies have a legal obligation to warn visitors of the potential risks or hazards they may encounter and tourists visiting these areas also have an obligation to consider their own safety and the safety of others [15]. The legal and moral obligation of management agencies to ensure a high level of security in the areas they manage, seems self-evident and they are expected to plan accordingly. Tourists, on the other hand, are often considered more vulnerable in case of a natural disaster, as they are not aware of the local conditions or resources and rely on tourism operators to obtain necessary information, which, often, may not be available [16].

A recent study regarding tourism and natural hazard management for Northland, New Zealand, found that tourism is considered very little in existing disaster risk reduction (DRR) planning [17]. Evidence from Northland demonstrated a range of problems, which in the case of larger and more widespread disasters may be extremely damaging to the tourism industry. Furthermore, tourism stakeholders and representatives from the civil defense department and the government who participated in that research showed a high willingness to address this gap and link the tourism and DRR systems for mutual benefits.

When visiting an organized site, tourists are more interested in the sightseeing they visit and usually have little concern about security, which they take for granted. Tourist information is generally useful to them and, hence, welcome. Provision of such information using modern technologies is an obvious opportunity for tourism promotion innovation. Globally, numerous commercial applications with such objectives have been developed. Accordingly, a good number of application-development programs have been implemented in the last few years and are promoted over the internet, aiming to enable users such as managers of museums and parks to easily develop relatively simple tourist apps for their sites. Some are travel guide apps to help with trip planning, whereas others are more comprehensive and in-depth. An example of the latter is a relevant platform for the provision of tourism services in Greece, the so-called iGuide, which was developed a few years ago via a national funding program [18]. Through an online platform and mobile app, it offers guided tours in areas where there is no organized and structured access to relevant information, such as archaeological sites, areas of natural beauty, and other points of tourist and cultural interest. The platform is based on innovative technologies and provides exclusive tourist content. However, it does not in any way address the issue of visitor protection and safety.

Regarding the protection of people from natural disasters in highly visited sites, there are systems intended to be used by the site managers for the prediction and management of the risk, as well as mobile applications with the visitors as final users. Regarding the former, ideally, the system must have the capacity to predict and detect the onset of the hazard, to analyze the risk and support response decisions, and finally to communicate warnings and guidance messages to those that may be affected. Whereas separate systems achieve some of these tasks, few systems exist that try to combine all these functions. For example, in the field of forest fires, the BehavePlus [19] and FlamMap [20] fire behavior modeling systems of the US Forest Service are used very broadly as they are free and have been tested across the globe. However, they require users (managers) with an advanced understanding of forest fire modeling to run simulations, analyze the results, and take decisions, whereas collecting all necessary inputs for running the simulations is a very challenging task on its own. This is usually beyond the competencies of a tourist site’s manager, who expects ready-for-use decision support systems, rather than scientific tools for modeling risks. Few (and very recent) platforms that combine natural risk products to provide a ready-to-use decision support and risk management tool to non-technically inclined users have been proposed [21,22,23]. All of them target site administrators exclusively and usually provide natural hazard risk or impact maps. Most relevant studies of the literature simply exploit spatial products and/or remote sensing imagery to assess risk at a given point in time (or a predefined period) and usually for a single natural hazard, e.g., [24,25,26,27].

On the other hand, a growing number of systems and apps that take advantage of newly available resources, such as advanced satellites, aim to offer disaster prediction, detection, and safety guidance to the users mainly using smartphones. In Greece, for example, such applications include the Infofire system (http://www.infodim.gr/en/products-services.html, accessed on 2 May 2021), the Aratos Disaster Control system (https://aratos.gr/index.php/gr/solutions-2/aratos-disaster-control, accessed on 2 May 2021), and the OFire+ system (https://omikron-sa.gr/en/services/ofire-plus-plus/, accessed on 2 May 2021). Nevertheless, these systems target primarily site managers and follow a subscription-based model, often structured in different versions with increased functionality (e.g., basic and advanced services). Casual tourists visiting an archaeological site or other tourist installation are highly unlikely to be interested to subscribe for protection to such an application.

3. Materials and Methods

From its inception and in order to achieve its objectives, Xenios embarked on an effort to develop an integrated system that:

• provides to site managers a web platform that informs them on the risk of different natural hazards, allows them to monitor the current situation (e.g., visitors’ distribution), and establishes a communication channel with the site’s personnel and visitors,
• is built around a modular architecture that permits different modules to be included depending on the site’s actual needs and limitations, as well as new modules to be easily integrated,
• uses established messaging standards for emergency information sharing, thus providing a generic way to incorporate any natural hazard risk prediction module into the system, and
• provides a mobile app for site visitors that establishes a communication link for sending alarms, but also serves them with useful tourist information, so that the visitors are encouraged to download and use the app.

Thus, the methodology involved understanding user needs, the development of the necessary modules for achieving the functions above, the integration to form the Xenios system, as well as testing and demonstration of the system in real-world conditions. Obtaining user needs necessarily required efforts at two different levels. First, selection of specific study areas representative of the type of sites that Xenios aims to serve in order to develop a good understanding of the issues, studying the specifics of each site, and discussing in-depth with its personnel. Logically, the sites also serve for testing and demonstration. Second, a broader survey to obtain information about user needs from a variety of perspectives, including managers and visitors.

3.1. Study Areas

Two touristic destinations with diverse characteristics were selected as pilot areas for developing and testing the Xenios system, namely, the Samaria Gorge National Park in Chania, Crete, and the Archaeological Park of Dion at the base of Mount Olympus in Greece (Figure 1a). Samaria Gorge (Figure 1b) was selected as a test site for Xenios due to the challenges it involves in mitigating risks, the most prominent of which are the rough terrain that inhibits evacuation processes, geomorphology that restricts cellular and internet network connectivity in most of the regions, and fire danger due to the dense pine forest all over the area. Conversely, flooding is the major risk factor at the Archeological Site of Dion (Figure 1c), which apart from visitors’ safety causes problems to the site itself. Every few years, large portions of the site are covered with tons of sediment after a flood, which also damages the infrastructure (as a matter of fact, an internal bridge collapsed during a recent flood and one route of the site is currently blocked). The risk of fire is lower and confined in certain regions of the site, but it still exists and is important to monitor and manage due to a large number of visitors during the summer months and the organization of the Festival of Olympus in July and August. A more detailed description of the two sites is provided in Supplementary Materials.

The abovementioned test sites were selected to provide the necessary feedback and evaluation for optimally designing the Xenios system. In this context, all pilot operations are performed in close collaboration with the sites’ management bodies, which are the Samaria National Park Management Body in the case of Samaria Gorge and the Ephorate of Antiquities of Pieria in the case of the Archaeological Park of Dion. This interaction led to the design of a modular solution that operates at all levels of risk management from local to regional, exchanging information and dispatching status reports and real-time information.

3.2. User Requirements

For the efficient and need-driven design and development of the Xenios system and its components, the first and most crucial step was to identify and analyze the end-user needs. In this direction, user needs were carefully gathered via questionnaires targeting both operational users (including safety managers, incident commanders, first responders, and field personnel) and site visitors. The outcome of this analysis dictated the definition of the necessary services and their respective specifications, as well as the architecture of the proposed platform.

More specifically, different questionnaires were designed to capture all types of needs and from different levels and perspectives, so that the Xenios partners have the complete picture:

• Cultural and touristic site stakeholders (representatives with a high level of operational experience from operators and managers of cultural and touristic places, as well as civil protection departments), which were grouped into two subcategories:
  • Managers (users of the Xenios central platform): The respective questionnaire content was focused on the operational details of the specific site, access information (entrance, exits, access control systems, ticketing systems, etc.), information for the personnel, visitor information (volume per day/hour/season), dissemination/marketing campaigns, natural hazard analysis, legacy sensors and systems (e.g., meteorological, CCTV), communication systems (e.g., Wi-Fi, 3G/4G), and Xenios-related requirements.
  • First responders/field operators (users of the Xenios mobile component): The respective questionnaire aimed to collect information regarding the capability of the responders on technological use, their role in the field, the local site characteristics, and the services offered towards the visitors.
• Cultural and touristic site visitors: The third questionnaire aimed at understanding the profile of the visitors, their familiarization with mobile device usage, the type of their mobile, information and details on the Xenios mobile application and its capabilities (e.g., alert capability, touristic information provision, evacuation route guidance).

Based on the feedback of all user categories, a qualitative and quantitative analysis was conducted, leading to the end-user needs and requirements. These needs were used as the driving force to design the Xenios architecture and its components. A detailed description of the identified needs is provided in Supplementary Materials.

3.3. Design Principles

Xenios was launched as a system for supporting tourist sites within—but not limited to—the European Union (EU) and, as such, must comply with the General Data Protection Regulation (GDPR) [28] for any processing of personal data. According to the latter, personal data collected by the system must be processed with legality, objectivity, and transparency (principle of legality), for the legitimate and explicit purposes that are collected (limitation of purpose), to be appropriate, relevant and limited to what is absolutely necessary for the fulfillment of the purposes (principle of proportionality or principle of minimization), be accurate and true (principle of accuracy), be maintained for the time absolutely necessary to achieve the purpose of processing (limitation of the purpose of processing) and ensure security, integrity, confidentiality and their availability.

GDPR’s restrictions unavoidably drive the design principles followed in Xenios’ design. Personal data allowing the identification of data subjects are only kept for the event of a visitor contacting the Xenios’ administrator for an emergency, using the embedded panic button in the Xenios mobile application. In accordance with the principle of data minimization (“I do not hold more data than I need for my processing”), the platform implements a specific data retention policy, which is implemented by the base-source of the platform, i.e., from its backend, where all its data are stored. More specifically, this is implemented in the Xenios system through:

• The system does not store the media access control (MAC) addresses of the visitors, which is a private datum that can uniquely identify the mobile app’s user. Instead, MAC addresses are only used for storing the number of visitors currently served by a specific Wi-Fi router/repeater, in order to know the visitors’ dispersion on the site.
• The auto-display tour (i.e., automatic provision of information of a landmark when the visitor approaches it) does not store Global Positioning System (GPS) track data, neither at the client-side nor at the server-side. The Xenios system does not need the track data, but just the visitor’s last position.
• All data are deleted at the end of the day, keeping only anonymized summary records for non-personal data-related statistical purposes (e.g., number of visitors per day, most popular PoIs, average time to complete visit).
• No username is required for using the mobile app nor names or other personal data are stored during or after the visit, whereas using the Xenios mobile app is not mandatory for entering the site.

On a technical level, Xenios’ design follows a loosely coupled event-driven architecture (EDA), which is implemented on an Enterprise Messaging Bus and by different web service technologies to allow subsystems to communicate with each other. Using the message bus for most communication allows all data requests and responses to be sent to the message bus without knowing which element will handle the data. Therefore, components can be easily exchanged, updated, or added to the system without updating existing components. Additional principles that have driven the system’s design were the need for the frontend applications to be multilingual, the requirement for the architecture to be modular since not all sites have the same needs (e.g., a ticketing system is not always present, or some sites have negligible risk for floods), and strong security guarantees embedded within every component of the system.

3.4. System Architecture

Based on the operational and technical needs derived from the analysis of the users’ requirements (Section 3.2) and the design principles (Section 3.3), a Business Process Model (BPM) was developed that describes the way each system component is used, respecting legal, ethical, and societal constraints. The BPM led to the formulation of specific use cases and the definition of interconnected and interrelated components, also defining the methods, processes, interfaces, and flow of information between them.

Figure 2 present a schematic overview of the Xenios system’s architecture. It comprises three main layers: (a) the layer of pluggable components, which includes all modules providing the information that is handled by the platform, (b) the backend layer, which coordinates all information flow from the pluggable components layer to the frontend one, and (c) the frontend layer, which conveys all information to the users. Each of these layers comprises several subsystems/components, which are detailed in the following subsections.

3.5. Pluggable Components

3.5.1. Extreme Weather Forecasting

Forecasting extreme meteorological phenomena is arguably useful for any outdoor site. Xenios’ extreme weather forecasting component is based on established weather prediction models, which are, however, downscaled to increase their spatial resolution. Two types of forecasts are provided. The first one is short-term forecasts (48 h ahead), provided at hourly intervals. The second one is seasonal forecasts, provided once for a 6-month period ahead. Both types of forecasts are intended for the Xenios web platform users (i.e., site administrators), rather than for visitors.

The short- and long-term meteorological predictions needed for the calculation of the different risk indices are provided by the atmospheric mesoscale Weather Research and Forecasting (WRF) numerical model and, more specifically, the Advanced Research WRF (WRF-ARF; version 3.6.1) [29]. The WRF model has been extensively evaluated and validated against ground observations [30,31,32]. The model is set up to perform simulations of dynamical downscaling using as input two different datasets from: (a) the Global Forecast System (GFS) [33] and (b) the Climate Forecast System (CFS) [34], produced by the National Centers for Environmental Prediction (NCEP).

Meteorological forecasts for 48 h ahead are provided by the WRF model on an hourly basis using the GFS data. The model is configured to downscale, in a one-way nested approach, the GFS data from the European domain (d01, 432 × 432 cells, 15 km horizontal resolution) to the domain of Greece (d02) of 3 km spatial resolution and then to the inner domains of Samaria (d03, 76 × 76 cells) and Dion (d04, 61 × 61 cells) both at 1 km resolution. Seasonal prediction data from the CFS are downscaled, in a one-way nested approach, from the European domain (265 × 200 grid cells with 20 km horizontal resolution) to the domain of Greece (185 × 185 cells with 5 km horizontal resolution), to provide at a 6-h basis seasonal prediction for 6-months ahead.

In both cases, the model outputs 20 atmospheric variables and indicators for specific geographical locations selected in each test site. The atmospheric variables comprise air temperature, wind speed and direction, precipitation height and rate of height, snow height, cloud coverage percentage, visibility, relative humidity, and mean pressure level at sea level. The indicators contain thresholds on selected variables (e.g., air temperature higher than 35 °C or lower than 0 °C, wind speed exceeding 18 m/s, rate of precipitation and snow height exceeding 5 mm/h and 2 mm/h, respectively), as well as aggregate indicators (e.g., heat or chill indices). The predictions are fed into the Xenios system via a File Transmission Protocol (FTP) connection once a day (early in the morning) and are subsequently homogenized and stored in the internal database for use with the other services (i.e., risks alerts, visualization, as well as inputs to other risk prediction modules).

3.5.2. Fire Danger Forecasting

Reliable fire danger forecast constitutes one of the most significant components of integrated forest fire management [35] and it is highly dependent on a variety of factors affecting fire ignition and/or spread. Fire danger cannot be assessed univocally, as its definition depends on the danger component emphasized (ignition versus spread or both), temporal resolution (e.g., short-term, midterm, or seasonal), and primary source of information (meteorological predictions versus remote sensing imagery). To address these issues, Xenios incorporates three different fire danger forecasting modules that approach the danger forecast differently and combinedly provide comprehensive information to the end-user: (a) a seasonal fire danger prediction module using meteorological forecasts, (b) a midterm (updated every eight days) one using earth observation (EO) data and ancillary thematic layers, and (c) a short-term (1–2 days ahead) forecasts using a combination of EO data and meteorological forecasts.

For the seasonal fire danger predictions, the seasonal meteorological forecast data (produced every six months, but with a six-hour step; see Section 3.5.1) at 5 km spatial resolution are used as inputs to the Canadian FWI system [36,37]. Air temperature, relative humidity, and wind speed at 12:00 UTC, as well as 24-h cumulative precipitation, are used to estimate intermediate parameters of FWI daily and for the whole fire season (1 May to 30 September in Greece) [38,39]. These daily predictions are then aggregated to derive fortnightly and monthly maps of seasonal fire danger indices. Three indices are produced: season severity rating (SSR), fire weather index (FWI), and drought code (BC). Combinedly, they provide a coarse estimate of the forthcoming season’s expected severeness in terms of fire danger, so that the site managers can prepare more efficiently (e.g., intensifying fuel treatments). The methodology has recently been presented in [39], where the evolution of FWI’s spatial and temporal distribution due to climate change was studied.

The midterm fire danger index (MFDI) is provided in 8-day periods and tries to quantify the probability for a fire to start from a specific location. It is based on a previously published contribution [40]. The primary source of information related to vegetation moisture content is derived from time-series of satellite data from the Moderate Imaging Spectrometer (MODIS) and, more specifically, the 8-day composite surface reflectance product MOD09A1 (Version 6) [41]. The analysis is based on a spectral index generated by the MOD09A1 product, namely, the normalized difference infrared index—band 6 (NDIIb6) [42]. A time-series of NDIIb6 images spanning ten years before the current date range MFDI is calculated for is constructed, out of which dryness anomalies of the current 8-day period (standardized NDIIb6 deviations from the history’s average values) are identified. This is then used to derive the so-called dry fuel connectivity (DFC) measure [43], which quantifies the observed anomalies (i.e., vegetation dryer or more wet than historic mean) and also encompasses the spatial dimension (i.e., danger increases if neighboring areas are also dry). DFC is then combined with several static (or, more precisely, slowly changing or yearly updated) variables. These comprise fuel type categories derived from Sentinel-2 satellite imagery [44], topographic features (elevation, slope, and aspect) derived from ALOS Global Digital Surface Model “ALOS World 3D—30m (AW3D30)” [45] (provided free of charge by the Japan Aerospace Exploration Agency), and distances from land cover with increased danger for a fire to start (road network, urban areas, and agricultural fields) calculated from available thematic layers. MFDI is finally derived as the weighted average of all variables following a systematic empirical approach and ranges from one (low/no danger) to four (high danger). More details on MFDI’s formulation can be found in [40]. On a technical note, the official MOD09A1 products are distributed at least two days after the 8-day period has passed. Hence, Xenios’ MFDI relies on its near-real-time (NRT) variant MOD09A1N [46], created by the MODIS Land Science Team and distributed by NASA’s Land, Atmosphere Near real-time Capability for EOS (LANCE).

Finally, Xenios’ short-term fire danger module provides fire danger forecasts for one to two days ahead, fusing meteorological predictions, information derived from EO data, statistics, and expert knowledge. The index is currently under development, but the basic idea is to use the short-term meteorological predictions of wind speed, air temperature, and relative humidity (see Section 3.5.1), the fuel type map used in MFDI, vegetation senescence information for highly flammable fuels (e.g., grasses) through time-series of Sentinel-2 imagery, MFDI’s DFC component for estimating vegetation water status, precipitation of previous days, and statistics (e.g., historic ignition probabilities). These data sources will be fused through an empirical framework, influenced by Rothermel’s surface fire spread model [47], fire behavior modeling systems such as BehavePlus [19], and multi-decade academic and practical experience obtained by estimating fire danger indices in Greece.

All three fire danger indices/modules will be provided via the Xenios web platform to the relevant stakeholders (site managers, according to the categorization provided in Section 3.2), having fully explained to them the limitations and advantages of each index.

3.5.3. Fire Behavior Simulations

Fire behavior simulation is an invaluable tool not only for real-time response planning, but also for wildfire risk assessment and for designing fuel management projects [48]. Xenios incorporates the G.FMIS fire simulator for fire behavior modeling, which is a proprietary software [49] based on the ubiquitously used Rothermel’s equations [47] for the estimation of fire behavior, and on the appropriately improved Dijkstra’s shortest path algorithm for the simulation of fire propagation [49,50], whereas it also integrates the NUATMOS wind field algorithm [51]. The simulator can be applied at a local/regional scale (10-100 m spatial resolution). For the execution of the simulator’s core module, topography (in particular, a digital terrain model) and fuel maps of the area are taken under consideration, as well as the wind field (wind speed and direction) and fuel moisture content at the time of simulation. The final outputs are maps of fireline intensity, flame length, and rate of spread, simulated at each point (grid cell), together with the timestep of the simulated fire.

Xenios’ objective is not to provide a fully operational, real-time fire behavior simulation system. Such a system is useful for the fire service or the civil protection agencies, but makes little sense for a tourist site manager, who cannot control the fire suppression mechanism in any way. Instead, it is provided as a tool supporting the design of efficient mitigation measures (e.g., adapting fuel treatment practices). To this end, a preliminary study is conducted in each site, identifying the most probable fire ignition locations based on the area’s fuels and topography. For each ignition location, a comprehensive set of weather scenarios is considered and a fire behavior simulation is performed for each such scenario, leading to the development of a fire behavior and propagation scenarios’ database. Given a set of weather parameters, the fire behavior scenario selected is the one developed with the best matching weather scenario, using the short-term meteorological predictions incorporated into the system (Section 3.5.1). Alternatively, the user is also allowed to manually insert a date, time of the day, temperature, and relative humidity, and the system then automatically estimates the proper weather scenario to use. An example of such simulations is depicted in Figure 3 for the Samaria site, showcasing the timestep of the simulated fire (with a colormap ranging from yellow to dark orange) from three potential fire ignition points in the Samaria Gorge, under a certain scenario of weather conditions. Similar views (with different colormaps) are provided for fireline intensity, flame length, and rate of spread.

3.5.4. Flood Danger Forecasting

Flood forecasting is necessarily tied to the characteristics of the area for which the prediction is made because the associated elements (quantity and rate of rainfall, topography, soils, vegetation cover, type of flood) vary greatly. For example, flood forecasting at Dion required the development of a specific module, tailored to the conditions of the area and the management needs of the archaeological site. The approach taken was to collect all available data (past floods, meteorological observations from nearby stations and predictions from the WRF-ARF system, geological, hydrological, and vegetative characteristics of the catchment) and to map the water catchment area feeding the torrent Ourlias and its tributaries, which are the main contributors to the flooding of the archaeological site. The behavior of the catchment was analyzed using an established hydrological model, the HEC-HMS (Hydrologic Engineering Center—Hydrologic Modeling System) [52,53] of the U.S. Army Corps of Engineers Hydrologic Engineering Center (HEC). Finally, we simulated the behavior of the catchment as a function of the meteorological measurements and predictions and determined alert thresholds for the meteorological predictions obtained from the WRF-ARF system (see Section 3.5.1). Given the availability of mainly qualitative data regarding past floods, the study became an exercise to determine the thresholds combining all types of available information. Additionally, it was determined to install an OTT HydroMet Radar Level Sensor (see Section 4.2) and a meteorological station at one of the bridges within the archaeological site, to obtain reliable measurements allowing better testing of the flood forecasting thresholds.

Regarding flooding at the Samaria site, the module developed is quite different, as the problem has very different characteristics compared to that of Dion. At the Samaria Gorge, flooding takes place very quickly (flash flood) as the rocky soil substrate can infiltrate very little water, the karstic environment creates conditions where water appears and disappears in relatively close distances, and almost 50% of the main trail’s length is within or adjacent to streams, thus making visitors exposed to immediate and grave danger. As a result, the managers have decided to keep the site closed to visitors from fall to early spring, when the probability of heavy rain triggering a flooding event is commonly very high. Nevertheless, a flooding event is a matter of constant consideration during the rest of the operational period (April to October), since the weather conditions on the mountain range can change suddenly. Currently, emphasis has been put on the use of general weather forecasts and observation of real-time measurements from meteorological stations within and around the Gorge. However, Xenios offers a better level of prediction, since site-specific high-resolution weather forecasts are produced (see Section 3.5.1), which are combined with real-time measurements from meteorological stations to issue alerts.

3.5.5. Ticketing System

Xenios interconnects with legacy ticketing systems, in sites where an open architecture ticketing system is available or, at least, if the system can export visitor entry–exit data in real- or semi-real-time. In both Xenios pilot areas, no electronic ticketing system was available, so Xenios was equipped with a submodule that counts visitors in entrance(s) and exit(s) using a barcode scanner attached to a portable Raspberry. The Xenios Ticketing Systems reports in real-time the visitors’ count and displays it on the management interface.

3.5.6. Visitor Dispersion Modules

An important feature of Xenios is its ability to monitor the visitor’s dispersion on the site. This is achieved by three subsystems, which—if seen under a hierarchical scheme—provide an increasing accuracy of visitors’ location determination. On a first level, the ticketing system provides the real-time count of the total number of visitors currently within the site, thus triggering the base alert (i.e., evacuation is required) in case of an emergency. On a second level, the Xenios system logs in real-time the number of visitors that are connected to each Wi-Fi router or repeater installed on the site. As noted in Section 3.3, only the total number of visitors served by each Wi-Fi router/repeater is stored in the system and not the individual MAC addresses, to avoid complications with private data handling. Effectively, this subsystem can identify the distribution of the visitors in subareas of the site (as defined by the Wi-Fi repeaters coverage), at least for those visitors that are connected to the site’s Wi-Fi network (see Section 4.2 for an illustrative example).

On the third and more precise level, Xenios supports the ability to monitor the dispersion of visitors to the site through UAVs, in case of an emergency event (e.g., wildfire or flood). Communication between the site manager and the UAV operator is offered via the Alerter module (see Figure 2), whereby the former informs the latter on the need for UAV support. Implementation-wise, this is achieved through the UAV support request submodule, which is a special function of the Alerter. Supportive information is provided by the site manager to the UAV pilot, such as the time, area of interest, incident type, and any additional notes creating a mission request. In turn, the pilot accepts the mission subject to the meteorological conditions and other flight prerequisites. The UAV then flies over the point or region of interest, providing real-time monitoring and situational awareness (with automatic people detection) from the field (Figure 4). The video-analytics-processed video is then streamed to the Xenios management interface, along with a generated alert regarding the presence of endangered people in the field. This is considered as a triggering point for further actions that (among others) are foreseen by the site’s emergency/evacuation action plans. The UAV dispersion module’s functionality aims to facilitate the search and rescue efforts, focusing on specific locations that were preliminarily identified by the other two—coarser—Xenios dispersion subsystems.

3.5.7. Visitor Informational Content

Multimedia content is used within the Xenios system to provide some information (e.g., historical, navigation-related, meteorological, points of interest) towards those interested in the outdoor touristic sites. The content is stored within the Xenios’ cloud storage facilities and served to the visitors through the dedicated mobile application (see Section 3.7.2). All informational content can be uploaded by the site’s administrator, through the interface of the Xenios web platform (see Section 3.7.1). Multimedia content supported by Xenios include:

• Textual description of PoIs.
• Navigation plans or guided e-tours.
• Emergency response plans, the access to which is nevertheless restricted to the site’s manager and authorized public authorities only.
• Meteorological conditions and forecasts.
• Photogrammetric products, such as orthophoto maps, 3D models, and panoramic images, collected through handheld cameras and UAVs.

Regarding the last category, the content created was optimized for the specific use case of the Xenios mobile app. In this context, the content’s resolution was adapted to best suit the data transmission limitations imposed by the environmental conditions and wireless network capacity in the pilot areas (Figure 5).

3.6. Backend Layer

The backend layer (see Figure 2) coordinates all information flow from the pluggable components layer to the frontend one, serving as the platform’s kernel. At its heart lies the Xenios Core (XC), a data provider to which all components are connected through the Web Services Provider and Communication Middleware (WSPCM). This provider can be accessible to other Xenios components or other third-party and legacy applications that may provide or retrieve data following the same connection path if they were authenticated by the Security Middleware. The WSPCM provides the means to connect to the XC and, upon request, the latter responds. Requests/calls can be made via web service requests, either following a representational state transfer (REST) architecture or the Simple Object Access Protocol (SOAP) protocol, or after opening a WebSocket. When data are requested from the XC, the latter responds by providing a dataset in JavaScript Object Notation (JSON) or Extensible Markup Language (XML) format. No information request can be passed to the XC unless it passes the Security Middleware. This middleware can validate the request via a username/password pair, static Internet Protocol (IP) addresses, or certificates provided by the caller.

The Xenios Storage is a hybrid storage system in which high-availability databases or file systems host the data required by the various components. The Xenios Storage holds information such as PoIs, emergency plans, 3D models, and other file-based data. Access to the storage is performed only by the XC and the accompanying components supporting its role.

The Forecaster Orchestrator is the Xenios component that handles pulling, storage, and presentation of forecasts provided by the natural dangers forecasting modules. This involves retrieving the data from the different forecasting services, transforming them into a predefined homogeneous format, attaching to them web services attributes, and storing them to the database (Xenios Storage). In addition, it implements the scheduling mechanism needed for retrieving the data as required by each forecast service (e.g., daily, hourly, weekly, and so on). When a new natural hazard forecasting module needs to be connected to Xenios, a dedicated submodule must be implemented within the Forecast Orchestrator and then the new module can emit alerts, as any other preexisting module.

The Alerter is the Xenios component monitoring procedures and creating alerts with an importance tag, which are then provided to the Xenios’ user or any external agencies (e.g., the fire service). Xenios is based on the realization that all danger from natural phenomena have some (possibly graded) alert issuance conditions, usually in the form of threshold rules. The Alerter keeps a database of these conditions and just issues an alert with the appropriate tag/description. The message issued provides information such as timestamp, site and location, type of the alert (e.g., fire, flood, panic button pressed by a visitor), and importance (low, medium, or high).

The Reporter is the subsystem that oversees spreading the information to the appropriate recipients, as registered into the Xenios system. The Reporter incorporates the alert dataset created by the Alerter and transmits its data through popup windows on the platform’s interface and through email. It is also the component providing datasets to external agencies requesting information and provides anonymized statistical data. Emergency response units can consume data that adhere to the Emergency Data Exchange Language (EDXL) specifications, generated automatically by the Reporter. EDXL is a family of XML-based messaging standards that facilitate emergency information sharing between government entities and the full range of emergency-related organizations [54]. It comprises a comprehensive and flexible set of standards that address emergency information sharing and data exchange across various actors involved in the process of disaster management [55].

In an analogy to the logging frameworks used in programming languages, the Alerter is the logger (the mechanism that creates the alerts) and the Reporter is the handler (the mechanism that transmits the message). Such an architecture provides great flexibility in the information flow of the system. For example, multiple authorities can be informed of an event simply by attaching multiple handlers into the same logger and even with different means (e.g., the site manager via the web platform and a competent national agency via email), filters can be applied to each handler individually (e.g., inform the site manager on all alerts, but some other agency only on medium- or high-importance events), or even not log an event that is below a lower threshold of importance (although this is rather unlikely in Xenios, considering its use cases).

Xenios also provides a voice over IP (VoIP) private branch exchange (PBX) module, which is built on an Asterisk (https://www.asterisk.org/, accessed on 2 May 2021) core and allows voice communication between the Xenios users, internal or external. The Xenios PBX is also equipped with Session Initiation Protocol (SIP) trunks, which provide access to landlines and enable the Xenios users to respond to external calls. The Xenios web platform includes a field/widget, where the site manager can click and communicate with the caller hands-free through the computer’s headphones.

Finally, the Translation Middleware was also incorporated into Xenios’ backend layer, offering a multilingual interface to the applications/modules and the content provided to all users.

The XC, WSPCM, and Security Middleware subsystems are connected in a so-called onion architecture (Figure 6), together with the management interface (described in the next section). In a multilayer system, the onion architecture of middleware dictates that an outer middleware handles any request before any action is taken by the core. If the user or component authentication fails (authentication middleware) the request does not pass to the next layer (role middleware) and, therefore, does not reach the application’s core. In the Xenios’ specific implementation, the XC (blue disk in Figure 6) is protected by the Security Middleware (red ring), which intercepts any request (arrows) made by the management interface (yellow and orange rings) to the XC.

3.7. Frontend Layer

3.7.1. Management Interface

The Xenios management interface is the web graphical user interface (GUI) of the Xenios system, intended for the site managers. Through it, the authenticated users receive all information provided by the various pluggable components and they can manage and update the information provided to the site visitors, as well as control all information flow. To avoid the spread of panic, no alerts/messages are communicated to the site visitors unless the site manager permits such action via the management interface. Depending on user rights, users can only view or edit information related to the site they manage. In addition, the Xenios management interface is a data fusion site map, presenting data taken from other subsystems and providing an operational picture of the site. Users can access the natural hazard forecasting modules and alerts reporting, while they are able to communicate with each other or external callers through the integrated VoIP PBX. The visitors’ dispersion is displayed on the map, providing an estimate of the situation if needed. Example snapshots of the platform are showcased in Section 4.3.

3.7.2. Mobile Application

The Xenios mobile application aims to establish a communication link between the site managers and visitors for sending alarms, but at the same time also serves the latter with useful tourist information, so that they are encouraged to download and use the app (Figure 7). In normal (not dangerous) circumstances, the mobile app provides free informational material with rich tourist content (see Section 3.5.7), related to the sights and other characteristic PoIs of the routes that are being visited. The characteristics of this functionality are enhanced if the user permits the app to use the mobile phone’s GPS position. In that case, the application highlights the PoIs that are closest to his/her current location. During high-risk situations, the mobile device serves as a tracker that transmits the location of the user to the site manager (using the management interface) and allows emergency calling to request any kind of help.

4. Results

4.1. User Requirements Questionnaires

As mentioned in Section 3.2, Xenios’ development sprung from the requirements of its potential end-users, collected via questionnaires targeting both tourist site stakeholders (site managers as well as field operators/first responders) and site visitors. We collected feedback from 21 tourist site stakeholders and 53 site visitors. The results were very encouraging, as all provisioned services described in Section 3.5 received positive feedback (more than 80% of the respondents assigned grades greater than three on a five-valued scale) from all user categories. Moreover, the visitors’ dispersion monitoring capabilities were highlighted as a very important feature by the field operators, who ranked it as the most urgent issue that needs to be addressed for their site, followed by establishing concrete procedures for evacuating the visitors in case of an emergency.

Figure 8 presents the aggregate responses from the site visitors for some services and use cases that were initially considered for Xenios but were ultimately excluded. Mixed to negative/indifferent views were expressed for providing announcements/news of the site or information on events nearby (Figure 8a). On privacy-related questions, the site visitors were generally favorable to the provision of automatic alerts with tourist information as they approach a PoI (Figure 8a) and would be willing to allow access to their current location via their mobile phone’s GPS for this purpose, but would not permit maintaining the history of the route they are following in the site (Figure 8b). Hence, this feature was implemented in Xenios as a list of nearby PoIs, rather than an actual alert as the visitor first approaches a PoI (that would require determining the direction of the visitor’s movement and, hence, storing—even temporarily—the actual route he/she is following). On questions related to potential sources of revenue for Xenios, promoting local businesses in the surrounding area received rather negative feedback. Although not shown in the figure, the responses of the site managers to the same question yielded similar results. Moreover, most visitors would install a dedicated mobile app designed for the specific site but would not be willing to pay for it. Finally, when the site managers were asked if they would be willing to pay for the Xenios platform (not shown in Figure 8), only one-third answered positively, with those responding negatively citing lack of adequate resources for such purposes. This was because most site managers that completed the questionnaire were representatives from public organizations (natural parks, ephorates of antiquities, civil protection agencies, etc.), the funding of which is typically very limited.

4.2. Pilot Areas’ Setup

As mentioned in Section 3.1 and Section 3.5.4, flooding is a major risk at the Dion study area, with a high frequency of occurrence that causes problems to the site itself. Therefore, we were required to develop a specific module, tailored to the conditions of the area and the management needs of the archaeological site. In order to obtain reliable measurements of the Ourlias torrent’s water level (that directly affects the site) as well as meteorological data, we installed an OTT HydroMet Radar Level Sensor and a meteorological station at one of the bridges within the archaeological site (Figure 9). The instruments have been continuously sending measurements to the Xenios system since their installation. These measurements will be used to define alert thresholds for the meteorological predictions obtained from the WRF-ARF system (Section 3.5.1), since the peak of the floods at Dion is usually delayed from the onset of rain and flooding does not have the characteristics of a flash flood.

Wi-Fi coverage was also a challenge in both study areas. Even at the Archaeological Park of Dion—which is generally flat—Wi-Fi coverage was limited to a small area around the main entrance, where the main Wi-Fi router was installed. Therefore, additional Wi-Fi repeaters were installed all over the site. Their optimal location was selected through a field study, whereby a random path was chosen on the visitors’ main route at the site, making small stops near points of interest and using mobile devices to simulate a visitor’s track around the area. Along the way, several disconnection–reconnect tests were performed on the Xenios Wi-Fi network, as many mobile devices are known to disconnect from wireless networks during a phone call (indicatively, the reconnection to the Xenios network from a mobile device running Android 10.9 takes place in less than 6 s). During the tests, the weather was mild and rainy. Stability and quality of coverage were not affected. Eventually, the optimal location of the available Wi-Fi repeaters was determined as the one that covered most of the main visitors’ route, as shown in Figure 10a. A study was conducted subsequently to determine the additional equipment required for covering the entire site in the future (Figure 10b). Figure 10b is also illustrative of how the Wi-Fi-based visitor dispersion subsystem (Section 3.5.6) works. Effectively, each Wi-Fi router/repeater defines an area it can cover (polygons in Figure 10b), based on proximity and as limited by natural obstacles (e.g., dense trees). In overlapping areas, any of the antennas involved could serve a visitor, but only one. Xenios updates the number of visitors served by each repeater/rooter in real-time, so the approximate area the visitors are located can be determined.

The Samaria Gorge study area is even more challenging with respect to Wi-Fi coverage. A preliminary field study was also conducted, crossing the gorge and testing along the way the signal strength. After the first 500 m from the entrance, there is no cellular network coverage from any mobile phone provider, except some very specific and isolated points. GPS signal coverage (at least from a smartphone’s GPS receiver) does not exist anywhere inside the gorge as well. The current plan is to install Wi-Fi repeaters at the start of the gorge’s route covering approximately the first 2 km of the route, for the purposes of the demonstration. More viable alternatives are being sought for the future, including satellite phone coverage, since permanent infrastructure installations are difficult to be implemented in the area, due to the restrictions set by the Samaria Gorge National Park being a NATURA 2000 network site.

4.3. First Results

Demonstration activities at both study areas (Samaria Gorge National Park and Archaeological Park of Dion) were originally planned for the summer period of 2020. Unfortunately, the COVID-19 disrupted these plans and the full-scale demonstrations were rescheduled for the summer of 2021. Nevertheless, most of the platform’s subsystems and functionality were implemented and we tested different simulated scenarios, i.e., how the Xenios platform would respond under different risk alerts.

Weather forecasts are served to the Xenios platform users (site administrators) for each site-specific 1 × 1 km grid cell of the WRF-ARF model (see Section 3.5.1), as shown in Figure 11. Binary thresholds are also enforced for alerting on extreme weather conditions forecasted in the next 48 h. In the example of Figure 11a, an alert of extreme coldness alert was activated (red button on top of the right sidebar) on 20 February 2021 due to the weather system “Medea” that affected Greece during that period. Note that the platform’s interface is under active development, with some visual elements (e.g., labels, charts) requiring fine-tuning, whereas the translation is not full yet.

Risk alerts are shown as notifications in the Xenios platform, as depicted in Figure 12a. The natural hazard forecast within Xenios aims to timely inform field operators regarding the possible occurrence of phenomena that could cause disasters and endanger site visitors and staff. As such, these alerts are initially provided only to the platform users, i.e., the site administrators, through which they can continuously monitor the development of the risk in real-time. If they decide it is necessary to do so, they can then activate the emergency alerting of visitors via the mobile app (Figure 7d) and/or mobilize the emergency response mechanism (e.g., civil protection authorities, fire brigade, police). As mentioned in Section 3.6, automated reports adhering to the EDXL specifications are provided by the Xenios system for the latter purpose, although this would require the necessary arrangements to be performed in advance with the competent authorities. The Xenios system can—in principle—determine the location of the visitor in the space, at least if the latter has allowed it through the mobile application settings. This allows site management executives to monitor the flow and the densities of visitors (Figure 12b), while utilizing a software toolcase to manage security issues, e.g., dispatching extra security and assistance staff where needed. At the same time, Xenios offers a call center function, through which two-way communication with visitors is ensured. Visitors are able, with the push of a button on the application screen (distress signal), to call for help due to an urgent personal issue (e.g., medical). In the event of insufficient access to the internet while being on-site, the visitor can always call the landline of the Xenios management center and talk to a representative.

As mobile phone ownership is widespread nowadays, this device is an obvious way to ensure communication between site administrators and visitors. Thus, Xenios offers a mobile phone application for this purpose, which at the same time enhances the visibility of the site to visitors. If a visitor installs the free application and allows the use of location, then the Xenios system provides free informational material (digital tour, photos, videos, etc.) with rich media content, which concerns the sights and other characteristic PoIs of the routes that are being visited (texts, photos, videos, etc.). The site managers can design the routes and upload all informational material through a dedicated interface of the Xenios platform (Figure 13).

5. Discussion

Prevention and response to natural disasters in Greece are regulated through legal tools with hierarchical structure and participation of numerous public services. Particularly in dealing with natural disasters such as fires and floods, public services engaged could be the civil protection agency, the fire service, the regional authorities, the municipalities and local community councils, the forest service, the management bodies of protected areas, the police, the coast guard, volunteer organizations, etc. The General Secretariat of Civil Protection, through the so-called National Crisis and Hazard Management Mechanism (NCHMM), holds the general coordination of actions targeted at the prevention, preparedness, and protection of human lives and the environment and it is configured in central, regional, and local level. At each level, these multiple agencies with different types of jurisdictional authorities and levels of decision-making are taking part through dedicated coordination bodies. NCHMM takes actions to ensure the proper coordination of different agencies. Nevertheless, issues of time-consuming or even delayed decision-making processes due to the multi-stakeholder scheme could arise. These issues—which are not by any means unique to Greece, e.g., see [56,57,58]—could pose a serious risk in natural disaster incident management where time is a key factor [56]. Xenios could constitute a bridge of direct briefing to the appropriate levels and officials in order to achieve faster decision making, proper structure activation, and priority measures per incident, thus becoming a common denominator in the entire mechanism. The capability of automated reports that follow the EDXL specifications within Xenios (see Section 3.6) serves exactly this purpose, since EDXL is a flexible and comprehensive set of standards that address emergency information sharing and data exchange across various actors involved in the process of disaster management. For example, the Hellenic Fire Service already supports receiving EDXL-formed emergency messages. This is an important provision of the Xenios system, because, in most places of public interest such as archaeological sites and natural parks, government-level organizations have the sole responsibility of appropriately evacuating the site in case of an emergency event.

Xenios fosters a modular architecture, allowing virtually any natural hazard forecasting service to be easily integrated as a pluggable component. As a matter of fact, the Samaria Gorge has been considered as a test site since Xenios’ inception, but the Archaeological Park of Dion was selected later, during the users’ requirements framework formulation. The latter identified the need for managing flood risks, which were not considered during the preliminary Xenios design. Nevertheless, a flood risk module was implemented and seamlessly integrated into Xenios, including the necessary real-time water level meter and in situ meteorological stations. As explained in Section 3.6, this was achieved on a technical level by just implementing the appropriate data retrieval/transformation submodule in the Forecast Orchestrator, registering the new type of risk in the alerts tagging system, and defining the alert thresholds in the Alerter. As such, other types of natural risks can be incorporated in the future into the system, such as thunderstorms, avalanche warnings, and snowstorms.

A technical problem we faced during the deployment to the study areas was the limited network connectivity. Even extending the Wi-Fi coverage at the Archaeological Park of Dion—which is generally flat—proved challenging (see Section 4.2), due to the dense high vegetation and the lack of visual contact between points (either because of vegetation or because of soil unevenness). Location information from cellular network providers seems as a viable alternative and can be readily incorporated into Xenios, but there are legal restrictions on their use (or prohibition) in many countries, including Greece (at least presently). The provision of relevant informational content to the visitors via the Xenios mobile app also serves as a motivation to use the app, so that at least their approximate location can be monitored via the Wi-Fi dispersion module, subject to their approval of course.

Early in Xenios’ design phase, we internally debated whether site visitors’ data should be used for further analysis, to support a business-to-consumer (B2C) business model. A comprehensive legal framework analysis was conducted related to personal data handling restrictions and obligations, which highlighted the potential disadvantages of such an approach. More specifically, user profiling is needed for efficiently implementing a B2C model featuring personalized recommendations, which increases both the risk for a data breach and, therefore, the cost for increased data protection mechanisms and procedures. Additionally, a data protection officer (DPO) would be required (further increasing the costs), whereas some users might even be discouraged to use the application. As a result, Xenios’ design was based on the principles of Privacy by Design and Privacy by Default, avoiding any unnecessary personal data interaction and bookkeeping only aggregate anonymized statistical metrics (see Section 3.3).

A viable business plan is currently under active development within Xenios. Although this is an ongoing process, it has already become clear that a business-to-business (B2B) model should be pursued, targeting at creating revenue from the provision of Xenios in a platform-as-a-service (PaaS) mode to sites, rather than from a mobile app subscription model. As reported in Section 4.1, both tourists and site personnel were generally negatively inclined in advertising nearby local businesses, which could constitute an alternative means of revenue (although, arguably, with at least questionable revenue potential). Most importantly, there is fierce competition in the domain of mobile apps/platforms that provide solely tourist information, which renders this approach virtually impossible. Still, informational content provision to site visitors via the mobile app is an important part of Xenios, because otherwise, the casual visitors of an outdoor site would be highly unlikely to be interested to download and install another mobile app just to be able to communicate with the site managers in case of an emergency. After all, tourists or visitors of recreational facilities are more interested in the sightseeing they visit or the activity they will participate in and usually have little concern about security, which they take for granted. Hence, Xenios is oriented towards following the B2B model (providing the service free of charge to the visitors, but as PaaS to the sites), trying to reach out to national tourist attraction management authorities, museums, large hotel infrastructures, and other recreational facilities (such as golf courses, for example), although we continue to research upon covering other potential areas of application. Xenios’ modular architecture facilitates this endeavor, since not all such sites are threatened by all possible natural hazards. In addition, the handling of visitors’ informational content (Section 3.5.7) is also directly transferable in all such sites. For example, the different facilities of a large hotel infrastructure can be directly inserted into the platform as PoIs, along with a description and any multimedia content desired. Accordingly, the concept of guided tours can be directly employed for navigating the visitors around the site (consider, for example, the different recreational facilities of a large hotel complex), whereas the concept of emergency response plans can also be applied to indoor spaces (which many times have similar plans, such as structural fire response plans, earthquake response plans, evacuation plans, security plans).

6. Conclusions

The Xenios system presented in this paper fuses early warning and risk communication services with tourist informational content provision via web-based and mobile phone applications, specifically designed to meet the needs of visitors and stakeholders in sites of cultural and tourist interest. The system is built around a modular architecture that permits different subsystems to be included or not, depending on the site’s actual needs and limitations. This is primarily achieved by realizing that all danger from natural phenomena has some (possibly graded) alert issuance conditions, usually in the form of threshold rules. Hence, new risk forecasting modules can be added, without changing the system’s core. Modules for common natural hazards (extreme weather phenomena, wildfires, and floods), visitor dispersion monitoring, two-way communication between visitors and site managers, as well as automated reporting to emergency authorities are supported out of the box.

Xenios’ innovation does not lie in the individual services it incorporates. There are many operating systems for natural risk forecasting and even more for tourist information provision. Rather, its novelty lies in the consolidation of the different users’ needs, providing a comprehensive risk management decision support tool to the site managers on the one hand and attracting the site visitors to use it on the other hand. This was partially confirmed and validated by the results of the first field tests in the two pilot areas and will be further explored and evaluated in the following period, during which the site managers will have a hands-on experience and demonstration. With natural disasters being a major concern in modern societies at an increasing frequency, solutions such as Xenios can help in increasing a site’s visibility, provisioning a sustainable tourist product, making the lives of the site’s personnel easier, and—above all—fostering safer tourism.

In the immediate future, we will finalize the Xenios’ platform elements (visual improvements, full translation, etc.) and fine-tune the danger forecast workflows where needed. We are also scheduling physical demonstrations of the system in the study areas during the 2021 summer period (hoping that the situation of the COVID-19 pandemic will improve and allow such an endeavor), so that we can showcase the full Xenios’ capabilities, including the ticketing system and the visitors’ dispersion monitoring functionality (ticketing system, Wi-Fi connections, and UAV support request features).