Natural Disaster Information System (NDIS) for RPAS Mission Planning

Highlights

What are the main findings?

• A lightweight, modular information system was developed to support RPAS (drone) mission planning for geohazard contexts.
• The framework integrates hazard type, hazard stage, and sensor–drone compatibility using a structured, rule-based approach.

What is the implication of the main finding?

• NDIS enables rapid and informed decision-making and planning of drone missions for hazard monitoring and disaster response.
• The system can be adapted across different disaster types and operational needs to support mitigation strategies globally.

Abstract

Today’s rapidly increasing number and performance of Remotely Piloted Aircraft Systems (RPASs) and sensors allows for an innovative approach in monitoring, mitigating, and responding to natural disasters and risks. At present, there are 100s of different RPAS platforms and smaller and more affordable payload sensors. As natural disasters pose ever increasing risks to society and the environment, it is imperative that these RPASs are utilized effectively. In order to exploit these advances, this study presents the development and validation of a Natural Disaster Information System (NDIS), a geospatial decision-support framework for RPAS-based natural hazard missions. The system integrates a global geohazard database with specifications of geophysical sensors and RPAS platforms to automate mission planning in a generalized form. NDIS v1.0 uses decision tree algorithms to select suitable sensors and platforms based on hazard type, distance to infrastructure, and survey feasibility. NDIS v2.0 introduces a Random Forest method and a Critical Path Method (CPM) to further optimize task sequencing and mission timing. The latest version, NDIS v3.8.3, implements a staggered decision workflow that sequentially maps hazard type and disaster stage to appropriate survey methods, sensor payloads, and compatible RPAS using rule-based and threshold-based filtering. RPAS selection considers payload capacity and range thresholds, adjusted dynamically by proximity, and ranks candidate platforms using hazard- and sensor-specific endurance criteria. The system is implemented using ArcGIS Pro 3.4.0, ArcGIS Experience Builder (2025 cloud release), and Azure Web App Services (Python 3.10 runtime). NDIS supports both batch processing and interactive real-time queries through a web-based user interface. Additional features include a statistical overview dashboard to help users interpret dataset distribution, and a crowdsourced input module that enables community-contributed hazard data via ArcGIS Survey123. NDIS is presented and validated in, for example, applications related to volcanic hazards in Indonesia. These capabilities make NDIS a scalable, adaptable, and operationally meaningful tool for multi-hazard monitoring and remote sensing mission planning.

1. Introduction

Remotely Piloted Aircraft Systems (RPASs) have become increasingly prevalent in environmental monitoring, emergency response, and hazard assessment [1]. Their mobility, high spatial resolution, and ability to operate in challenging terrain make them effective tools for surveying natural disasters [2]. In recent years, the growing diversity of RPAS platforms and lightweight geophysical and remote sensing sensors has expanded the potential for autonomous or semi-autonomous survey planning in both urban and remote environments [3].

Despite these technological advances, mission planning for RPAS-based hazard monitoring remains largely manual [4]. Operators must match geohazard characteristics to appropriate platforms/drones and sensors, often under tight time constraints and with limited contextual data. Furthermore, existing geospatial tools offer limited integration between hazard databases and drone-specific operational parameters such as payload capacity, communication range, and endurance [5]. As a result, RPAS missions are often constrained by trial-and-error workflows or reliance on expert judgment, which is not always available for such time-critical missions.

Previous studies have highlighted the use of uncrewed aerial systems in disaster mapping and emergency response [1,2,3]. However, few have attempted to unify hazard intelligence with platform-sensor compatibility in a structured decision framework. However, few have attempted to unify hazard intelligence with platform–sensor compatibility in a structured decision framework. While decision support systems (DSS) have been developed for natural hazard applications, including those used by national agencies such as the United States Geological Survey (USGS), their scope is typically limited to hazard assessment, mapping, or resource prioritization [6,7]. Broader reviews of hazard-focused DSS indicate a focus on flood forecasting, landslide susceptibility, and community resilience evaluation [7,8], rather than integrated mission planning or platform–sensor pairing. In practice, sensor and platform selection remains highly dependent on manual workflows or domain-specific expertise, with no standardized logic across hazard types or operational settings. This limitation is further compounded by the fragmented nature of geohazard data, which are maintained separately across different institutions: volcanic data by the Smithsonian Institution, earthquake records by the International Seismological Centre (ISC) and USGS, tsunami databases by NOAA’s National Centers for Environmental Information (NCEI), landslide inventories by NASA’s Global Landslide Catalog, and fault data by the GEM Foundation. These sources are rarely interoperable and are not directly linked to RPAS deployment requirements or survey logistics.

Examples of existing decision support systems include the Copernicus Emergency Management Service (EMS), which provides satellite-derived mapping products for flood, wildfire, and other hazards across Europe [9,10]; RiskScape, developed by GNS Science and NIWA, which supports multi-hazard loss modeling in New Zealand [11,12]; and InaSAFE, a scenario-based tool designed to assess the impact of hazard events on populations and infrastructure in Southeast Asia [13]. While these systems support situational awareness and impact estimation, they do not include operational decision logic for drone-based survey coordination. Similarly, earthquake response tools such as ShakeMap and PAGER from the USGS provide impact visualization and casualty estimation [14,15,16], but are not designed to support platform–sensor pairing or automated RPAS mission planning. To date, no operational system has combined hazard-specific databases with drone and sensor configuration logic in a unified, modular structure.

This study introduces the Natural Disaster Information System (NDIS), a modular decision-support framework for RPAS mission planning in geohazard contexts. NDIS integrates a spatial hazard database with a catalogue of RPAS platforms and sensor payloads, employing both rule-based logic and machine learning algorithms to identify suitable configurations. The system addresses essential mission parameters such as hazard type, distance from infrastructure for take-off and landing, and survey feasibility. By incorporating sequential decision logic, NDIS enables platform and sensor selection based on disaster stage, survey method, and operational constraints.

The system implements a five-stage, rule-based decision structure that guides users toward suitable platform-sensor combinations. The framework supports standardized mission planning and demonstrates how structured logic can be applied to real-world hazard response contexts. Therefore, NDIS closely aligns with the objectives of the United Nations Sustainable Development Goals [17], particularly Goal 11 (for Resilient Urbanization) and Goal 17 (Empower Technology for Disaster Risk Reduction).

This manuscript is structured into 5 sections. Section 2 describes the data used for the database and the method to process the information. Section 3 shows the implementation of NDIS with example applications. Section 4 presents a discussion of the NDIS and its functionality, and Section 5 provides conclusions.

2. Data and Methods

This section outlines the datasets, preprocessing techniques, and decision logic used to implement the NDIS for RPAS-based hazard mission planning. The system integrates geohazard data from multiple sources, combining spatial geometry with hazard-specific parameters such as magnitude, Volcanic Explosivity Index (VEI), and reported human impacts, among others. Where direct economic loss data were unavailable, estimates were derived using severity indicators and casualty records, with dataset-specific procedures detailed in subsequent sections.

Data preprocessing involves a series of geospatial analysis techniques, including proximity analysis, zonal statistics, and spatial clipping to Exclusive Economic Zone (EEZ) boundaries, in order to constrain geohazard distribution to relevant maritime and territorial regions. These operations were performed using ArcGIS Pro, which also served as the primary environment for early-stage logic testing and scenario validation prior to backend deployment.

To support platform and sensor selection, a combination of scientometric review and rule-based decision logic was employed. Although supervised learning approaches such as decision trees and ensemble models were initially evaluated, their limited generalizability led to the adoption of a staggered decision workflow for final RPAS and sensor recommendations. Figure 1 provides an overview of the NDIS implementation pipeline, from data collection to sensor–drone mission recommendation. This schematic is referenced throughout the remainder of the section to contextualize the described methods.

2.1. Geohazard Dataset and Engineering

The geohazard inventory compiled for the NDIS framework includes both site-based and event-based records. Sites are persistent features such as volcanoes or fault lines. Events are discrete occurrences, for instance earthquakes or tsunamis. These hazards differ in both physical mechanism and monitoring requirements. Volcanoes are surface expressions of subsurface magma movement. Landslides are mass movements of soil or rock, often triggered by rainfall or seismic activity. Tsunamis are water displacement events, often triggered by earthquakes or landslides. Faults represent mapped geological structures that may generate future earthquakes. Earthquakes are sudden releases of energy due to fault rupture. Although related, not all earthquakes occur on mapped faults, and not all faults exhibit current seismicity. Faults are spatially persistent geological features representing zones of structural weakness, whereas earthquakes are discrete seismic events originating along such faults or elsewhere. Within this study, fault features are treated as potential risk zones requiring proactive monitoring, while earthquakes represent past or ongoing episodic events.

In addition to natural geohazards, the NDIS includes human-made facilities susceptible to geological activity, such as nuclear power plants. Although not geohazards themselves, their inclusion supports planning in regions where geological events may pose operational risks (e.g., Fukushima, Japan [18]). Figure 2 summarizes the relative distribution of records by hazard type and spans the period from 1900 to 2023. Earthquake events comprise the majority of entries due to their high frequency and global data availability. Source details for each hazard are provided in their respective Section 2.1.1, Section 2.1.2, Section 2.1.3, Section 2.1.4, Section 2.1.5 and Section 2.1.6.

Each dataset was reviewed and processed to derive attributes (

Table 1. Attributes and engineered features used in RPAS mission planning, summarized by mission type. Variables include hazard distance, mission distance, travel time, monitoring time, setup buffer, and total CPM duration.

Mission Type	Mission Distance D	Travel Time ${\mathit{T}}_{\mathit{t}\mathit{r}\mathit{a}\mathit{v}\mathit{e}\mathit{l}}$	Monitor Time ${\mathit{T}}_{\mathit{m}\mathit{o}\mathit{n}\mathit{i}\mathit{t}\mathit{o}\mathit{r}}$	Setup Buffer ${\mathit{T}}_{\mathit{s}\mathit{e}\mathit{t}\mathit{u}\mathit{p}}$	CPM Total Time ${\mathit{T}}_{\mathit{C}\mathit{P}\mathit{M}}$
Delivery	$D=d$	${\displaystyle \frac{d}{v_{cruise}·60}}$	$t_{delivery}$	20 min	$T_{travel}+T_{monitor}+T_{setup}$
Mapping	$D= ⌈{\displaystyle \frac{W}{p}}⌉·L$ or $D= \pi d$ (LiDAR alternative)	${\displaystyle \frac{d}{v_{cruise}·60}}$	${\displaystyle \frac{D}{v_{sensor}·60}}$	40 min	$T_{travel}+T_{monitor}+T_{setup}$

Note: See Appendix A.3 for full notation key and parameter definitions.

) relevant to RPAS mission planning, including hazard type, distance to infrastructure, event intensity, and estimated economic loss (

Table 2. Harmonized derived attributes for each hazard type used in the NDIS framework. All hazard-specific intensity metrics (e.g., VEI for volcanoes, Soloviev–Imamura scale for tsunamis, magnitude and depth for earthquakes) were converted to a unified NDIS ordinal intensity scale (1–5). Duration and economic loss values were either obtained from source records or simulated using hazard-specific engineered equations and fallback logic. These attributes were not intended as predictive models but as internally consistent prioritization inputs for RPAS mission planning.

Hazard Type	Intensity	Duration (min)	Economic Loss (in M US$)
Volcanoes	$I=f\left(VEI\right)$, where $VEI=\left\{\begin{array}{c}Reported\\ Rand weighted\end{array}\right.$ See Table A1 for ordinal scale	$T=\left\{\begin{array}{c}{(t}_{end}-t_{start})·1440, if known\\ U\left[a,b\right], based on VEI\end{array}\right.$	$L=Reported \cup Descriptor \cup U\left[L_i,U_i\right]$
Landslides	$I=$0.7⋅S + 0.3⋅C $S=$$\mathrm{size}, C=scaled cassualties$	$T~U\left[a,b\right]$, based on I	$L=U\left[L_i,U_i\right]·\left({\displaystyle \frac{P}{{10}^6}}\right)+0.05·(fatalities+0.5·injuries)$
Tsunamis	$I=$f(TS_MT_II) or $I= {log}_2\left(\sqrt{2}·h\right)$ Eq. reference [19]. See Table A2 for ordinal scale	$T~U\left[a,b\right]$, based on I	$L=U\left[L_i,U_i\right]·\left({\displaystyle \frac{P}{{10}^6}}\right)+0.1·(fatalities+0.5·injuries)$
Faults	$I=0.3·{\displaystyle \frac{dip}{90}}++0.4·{\displaystyle \frac{slip}{100}}+0.3·{\displaystyle \frac{V_{sep}}{50}}$	$T~U\left[a,b\right]$, based on I	$L=U\left[L_i,U_i\right]·\left({\displaystyle \frac{P}{{10}^6}}\right)$
Earthquakes	$I=F\left(M\right)+ ∆D$ $∆D= \left\{\begin{array}{c}+1, if D<10 \mathrm{km}\\ 0, 10\le D<70 \mathrm{km}\\ -1, 70\le D<300 \mathrm{km}\\ -2, D\ge 300 \mathrm{km}\end{array}\right.$	$T~U\left[a,b\right]$, based on I	$L=U\left[L_i,U_i\right]·\left({\displaystyle \frac{P}{{10}^6}}\right)$
Nuclear Power Plants	$I=5$	$T=1440$	$L=11. 5·{Capacity}_{MW}$

Note: See Appendix A.3 for full notation key and parameter definitions.

). For tsunamis, the logarithmic intensity transformation shown in Table 2 follows the formulation introduced by Soloviev and Imamura [19]. Further feature engineering involved the calculation of critical path metrics (CPM) and hazard-specific risk factors. Three supplementary datasets were also integrated: global population raster (for 30 km zonal statistics), global road networks (for proximity analysis), and Exclusive Economic Zones (for spatial clipping). All datasets were verified and aligned to the WGS 1984 geodetic reference system.

The Critical Path Method (CPM) was used to estimate the total mission duration for each RPAS-based geohazard survey. It comprises three additive components: travel time from the nearest access point to the hazard location, on-site monitoring or data collection time, and a setup buffer accounting for pre-flight preparation. Travel time was calculated using the distance to the hazard and an average cruise speed of 16 m/s, which reflects the typical operational range for multirotor RPAS based on empirical studies and performance modeling [8,9]. This value was applied uniformly across all mission types in the absence of drone-specific cruise velocity data.

Monitoring time was determined based on the operational characteristics of the selected sensor. For mapping-type missions involving optical or LiDAR sensors, a mapping speed of 5 m/s was applied to account for moderate-altitude flight with overlap requirements [10,11,12]. Ground-penetrating radar (GPR) and thermal missions were assigned a slower speed of 3 m/s due to their typically lower altitude and finer spatial resolution [11,13]. Magnetometer surveys were assigned to a higher mapping speed of 10 m/s [14,15]. For point-based missions, such as seismic node delivery or bottom pressure recorder (BPR) deployment, a fixed monitoring duration of 3 min was used.

The setup buffer was defined based on the operational complexity of the mission. For delivery-type tasks, such as seismic node deployment or thermal spot checks, where the mission distance is equivalent to the hazard distance, a buffer of 20 min was assigned to account for equipment checks and ground control station initialization. Whereas mapping-type mission, such as those using LiDAR, camera, or GPR, were assigned a 40-min buffer to accommodate additional tasks such as setting ground control points (GCPs), calibrating sensors, and configuring flight paths. These durations were selected to represent typical field conditions and were applied uniformly within each mission category.

2.1.1. Volcanoes

The volcano dataset used in this study combines two authoritative sources. The primary spatial dataset was obtained from the Smithsonian Institution’s Global Volcanism Program (GVP) through the Volcanoes of the World (VOTW) Web Feature Service. This Holocene database contains georeferenced records for 1323 volcanoes, detailing eruption history, morphology, and volcano type from the Holocene epoch to the present [20]. To supplement this, eruption-specific attributes were integrated from the National Centers for Environmental Information (NCEI) Significant Volcanic Eruption Database, maintained by NOAA’s National Geophysical Data Center. This secondary dataset provides event-level data including eruption dates, explosivity indices, and human impact indicators such as fatalities, injuries, and damage estimates [21].

Mission-relevant variables were derived to support RPAS planning in NDIS. VEI values, where available, were mapped to the NDIS ordinal intensity scale (

Table A1. Mapping of Volcanic explosivity index (VEI) ranges to intensity categories used in the NDIS framework.

VEI Range	NDIS Ordinal Intensity	Label
0–1	1	Very Low
2	2	Low
3–4	3	Moderate
5–6	4	High
7–8	5	Extreme

in Appendix A.1). For missing VEI records, values were estimated from reported fatality counts or sampled probabilistically based on global eruption frequency (details in Appendix A.1). Eruption durations were calculated from reported start and end dates or simulated from VEI-class ranges (Appendix A.1). Economic loss was taken from reported values, converted from qualitative descriptors, or simulated using intensity-weighted population and casualty factors (Table 2; Appendix A.1). For each volcano, the longest recorded eruption was retained to represent maximum hazard persistence.

This harmonized dataset provides geospatial, physical, and socio-economic indicators for volcanic hazards within the NDIS framework.

2.1.2. Landslides

Landslide data were obtained from NASA’s Cooperative Open Online Landslide Repository (COOLR), which compiles globally reported events from both institutional and citizen sources [22,23]. The dataset includes essential attributes such as event coordinates, hazard classification, and size descriptors. Data were preprocessed to align with NDIS schema. The ev_id (event id) field was retained as HazardID, and geometric attributes were preserved for spatial analyses.

To estimate event intensity, landslide size classifications (ls_size) were first mapped to a five-level ordinal scale, ranging from small, medium, large, very large to catastrophic. Where available, fatality and injury counts were incorporated to refine intensity by a composite score. A normalized casualty factor was combined with size weights (70:30) to reflect both physical scale and human impact, consistent with approaches used in disaster impact modeling [24]. Duration estimates were assigned using landslide size categories, following empirical guidance from USGS reports that describe landslide events ranging from sudden movements over minutes to prolonged displacement lasting weeks or longer, depending on slide type and material properties [25].

2.1.3. Tsunamis

Tsunami data are derived from the Global Historical Tsunami Database curated by the National Centers for Environmental Information (NCEI). This database includes over 2400 tsunami events spanning from 2100 BCE to the present and provides attributes such as location, intensity, runup height, and impact summaries based on observational and sensor-based records [26].

Preprocessing of this dataset involved standardizing significant fields such as hazard identification field (HazardID), spatial coordinates, hazard classification, and aligning the structure with the NDIS database schema. Tsunami intensity, derived from the Soloviev–Imamura scale, may range from approximately –1 to +8—though typical global records fall between –0.5 and +6 [19,27]. To harmonize within the NDIS 1–5 ordinal framework, intensities are mapped to thresholds, with extremes capped at the top ordinal level. To ensure consistency across the NDIS multi-hazard framework, this continuous scale was harmonized to an ordinal 1–5 classification using defined thresholds as shown in

Table A2. Mapping of tsunami intensity values to the NDIS ordinal classification (1–5). Intensity values from TS_MT_II and TS_INTENSITY were rescaled using fixed thresholds, while fallback estimates from MAX_EVENT_RUNUP were computed using equation in Table 2.

NDIS Ordinal Intensity	TS_MT_II/TS_INTENSITY Range	h (m)
1	<1.0	h < 1.41
2	1.0–2.99	1.41 ≤ h < 5.66
3	3.0–4.49	5.66 ≤ h < 22.63
4	4.5–5.99	22.63 ≤ h < 64.00
5	≥ 6.0	h ≥ 64.00

(Appendix A.2). When unavailable, alternative fields were applied in sequence: Tsunami intensity (TS_INTENSITY, similarly rescaled), maximum event runup height (MAX_EVENT_RUNUP, interpreted as shoreline run-up height) using a logarithmic equation in Table 2 [19], and randomly assigned values using fixed probabilities based on observed distribution.

Estimated durations were mapped by tsunami intensity levels to empirically informed time ranges, where higher intensities correspond to longer durations (e.g., intensity 1 ≈ 15–30 min, intensity 5 ≈ 6–12 h). This approach reflects patterns described in historical tsunami impact records [19,27]. Where intensity values were unavailable, durations were entered using fallback values within a plausible range (e.g., 1–4 h), attempting for temporal consistency across all events.

Economic loss values were compiled from reported data if available or estimated using descriptive damage categories. In cases of missing information, final simulations were computed based on tsunami intensity, population exposure, and reported casualties. Previous studies, such as Jongman et al. (2012), have shown wide variability in modeled flood losses due to differences in inundated area, land use, and exposure [28]. In this study, simplified discrete ranges and proportional scaling are applied to approximate damage values, supporting the generation of varied mission planning scenarios without requiring fully empirical input.

2.1.4. Active Faults

The fault dataset utilized in this study was obtained from the GEM Global Active Faults Database (GAF-DB), which compiles fault records from national and regional catalogs [29]. To facilitate integration with point-based geohazard records, the original polyline geometry of fault traces was converted into evenly spaced point features at 5–10 km intervals. This spacing captures the segment-scale variability observed in fault evolution models [30].

Synthetic attributes were then engineered to support hazard assessment and drone mission prioritization. These include fault intensity, duration, and economic loss, derived using normalized geophysical parameters and fallback logic consistent with other hazards.

Because original features lacked unique IDs, a structured format was created by appending a reserved numeric prefix (177) and zero-padding applied to the original index. Multiple points from the same fault received hierarchical suffixes to ensure traceability and uniqueness within the broader hazard database.

Duration was estimated based on the assigned intensity. Faults are known to exhibit prolonged rupture behavior compared to rapid-onset hazards. Accordingly, a range of durations was simulated: from 1–3 h for minor events (Intensity 1) to up to 2 days for major events (Intensity 5). This range-based duration reflects generalized tectonic rupture timelines used in seismic fault modeling [31].

Economic loss, expressed in millions of USD, was simulated using a population-scaled multiplier mapped to the intensity class. Higher intensity levels were associated with broader economic impact ranges. A fallback population value of one million was assigned where data was missing, ensuring continuity of the simulation process.

2.1.5. Earthquakes

The earthquake dataset used in this study integrates multiple catalogs to ensure both temporal depth and parameter consistency. Historical events were sourced from the GEM Global Historical Earthquake Catalogue (GHEC) and the SHARE European Earthquake Catalogue (SHEEC), which provide macroseismic records from the years 1000 to 1903 and 1000 to 1899, respectively. These catalogs compile data from parametric sources and macroseismic intensity reports, with epicentral locations and magnitude estimates derived through cross-verification with regional and national earthquake bulletins [32,33,34,35]. Instrumental records from the modern era (1904–present) were incorporated from the ISC Bulletin [36] and the ISC-GEM Global Instrumental Earthquake Catalogue [37], which provide homogenized magnitude values and refined epicentral locations based on standardized seismological models such as ak135.

Event identifiers were standardized (as HazardID), and geospatial attributes such as epicenter coordinates and depth were retained for spatial analysis. In addition to magnitude, earthquake depth was utilized to refine ground-shaking intensity estimates. While magnitude represents the energy released at the source, depth is a proxy for surface impact [38]. Shallow earthquakes (<10 km) were assigned an intensity adjustment of +1 due to stronger surface shaking, whereas deeper events (>70 km) were scaled down accordingly. These adjustments were implemented using depth buckets, reflecting established empirical and seismological relationships between focal depth and surface shaking intensity [38,39,40]. This transformation enabled consistent integration of seismic hazard levels within the broader geohazard classification in NDIS framework.

To simulate potential economic losses for each earthquake event, a simplified intensity-based model was applied. Each intensity class (1 to 5) was assigned a synthetic range of potential loss values (in millions USD), reflecting plausible damage scales based on population exposure. A uniform random value within the designated range was then multiplied by the estimated population within a 30 km radius, normalized by millions. This method draws conceptually from prior global seismic risk models that relate ground shaking intensity and exposure to expected losses [41], but the exact numerical ranges used here are scenario-based assumptions intended for prioritization purposes only and not actual loss estimation. The values used herein can be changed, hence, the selected values do not limit the usability of the NDIS.

2.1.6. Nuclear Power Plants

Nuclear hazard data were sourced from the Global Nuclear Power Tracker by the Global Energy Monitor [42]. This spatial dataset includes plant names, coordinates, and capacity in megawatts (MW). This dataset does not represent historical disasters but serves as a record of potential high-impact facilities. While nuclear incidents are rare, their consequences can be extreme, justifying their inclusion within the geohazard framework despite the absence of a standard event-based catalogue such as those maintained for earthquakes or volcanoes [43].

As most fields serve as placeholders for mission planning and risk modeling, preprocessing focused on cleaning numeric attributes and assigning standardized parameters. A synthetic HazardID was generated by appending a numerical suffix of 111 to the GEM unit identifier. Hazard intensity was assigned a default high value of 5.0 to reflect the severity potential of nuclear emergencies. Likewise, an assumed event duration of 1440 min (24 h) and a standard monitor time of 120 min were applied across all records.

Economic loss was estimated based on facility capacity, using a multiplier of $11.5 million per megawatt. This figure approximates the replacement or decommissioning cost associated with nuclear infrastructure, scaled from an average of $11.5 billion per gigawatt [44]. This harmonized and enriched dataset was then integrated into the unified geohazard database to support multi-hazard risk analysis and geospatial mission planning. Note that the monitoring efforts are limited to the initial disaster, and not the long-term effects to the surrounding environment and society. This choice was made to make the nuclear hazard comparable to natural hazards. Long-term monitoring is also not urgent to warrant a fast response, which the NDIS focusses on.

2.1.7. Supporting Geospatial Layers and Preprocessing

To support hazard prioritization and mission feasibility analysis, three global datasets were integrated: Exclusive Economic Zones (EEZ), Global Roads Inventory Project (GRIP), and Gridded Population of the World.

Hazard points were spatially filtered (illustrated in Figure 3) using a union of Exclusive Economic Zones (EEZ) and national boundaries, based on the Maritime Boundaries dataset [45]. Points located outside EEZ limits were retained in a separate dataset for documentation but excluded from operational prioritization. These features are likely situated in remote oceanic zones such as mid-ocean ridges or deep-sea basins, where the nearest land-based access exceeds 200 km. Such distances fall well beyond the range of typical RPAS operations. As the current mission framework emphasizes deployability using commercially available platforms, these offshore records were flagged for exclusion from immediate survey consideration. Out of 1,938,335 total geohazard entries, approximately 83,322 (~4.3%) were located outside EEZ limits or in remote offshore regions (e.g., mid-ocean ridges). These records were excluded from mission prioritization but retained for documentation purposes.

While RPAS provide flexibility in operations on site, most systems do need to be deployed from access roads to avoid lengthy approaches which limit endurance. Hence, an access point was defined at the nearest road. The proximity to transportation infrastructure was calculated by performing an analysis between each clipped geohazard layer and the global road network (illustrated in Figure 3). Road segments were derived from the Global Roads Inventory Project (GRIP), which provides harmonized coverage of global road infrastructure at multiple administrative levels [46]. For each geohazard point, the geodesic distance to the nearest road segment was computed (see Figure 4 for distance category from the total of geohazard sites and events), and the resulting values were recorded as a distance field. This metric was later used for platform-sensor mission planning, particularly in estimating deployment feasibility. A sample output of this preprocessing is illustrated in Figure 5, showing distance-to-road computation for geohazard points in the Fukuoka region. While such static views are interpretable at a local scale, they become heavily cluttered when applied globally across multiple hazard types, spatial layers, and recommended sensor-platform combinations. This visualization constraint—along with the need for real-time interaction—motivated the development of the NDIS web application as a more scalable alternative.

Zonal statistics were used to estimate population exposure within a 30 km buffer surrounding each geohazard (Figure 6 represents the percentages of hazard events and sites within populated areas). Using the Gridded Population of the World v4.11 raster dataset [47], buffered geometries were analyzed in batches to derive population counts based on aggregated cell values. The population raster was preprocessed to remove extreme or missing values and converted to integer format to ensure numerical stability. All raster cells intersecting each buffer were included to avoid underestimation at boundary zones. Invalid or undefined outputs were excluded, and unusually high totals were flagged for manual review. This approach enabled scalable and consistent estimation of affected populations, while accounting for spatial irregularities and data sparsity.

Together, these three layers—EEZ-defined boundaries, global road network, and population data—served distinct roles in spatial preprocessing. Hazard points were first clipped to EEZ boundaries to define sovereign zones, which were then used to segment the global road and hazard datasets for proximity analysis. Within each zone, the geodesic distance from each hazard point to the nearest road was computed using the GRIP dataset. Separately, a 30 km buffer was applied around each hazard point to estimate local population exposure using gridded population data (snippet in Figure 7). The resulting attributes—road distance and buffered population—were then appended to the geohazard dataset to support downstream mission planning and prioritization.

2.1.8. RPAS Database Compilation and Classification

The RPAS database was compiled through manual data collection from publicly available sources. An initial list of manufacturers was obtained from Drone Industry In-sights’ market infographic [48], which included names and logos of commercial drone producers. As the infographic did not contain technical specifications, additional information was obtained from publicly available materials, including manufacturer websites, datasheets, brochures, and technical product documentation.

A total of 179 drone models were identified and compiled into a structured dataset. Each entry was associated with multiple attributes, including maximum payload capacity, endurance, maximum takeoff weight (MTOW), communication range, speed, distance range, operational temperature, regulatory category, default payload configuration, image reference, unit price, and source website, among other specifications. For the purposes of classification and platform filtering, payload capacity, communication range, and distance range were treated as the primary criteria, given their direct relevance to geophysical and remote sensing survey requirements.

Drones in the RPAS database were categorized by two operational constraints: communication range and payload capacity. Communication range refers to the maximum distance over which a drone can reliably maintain a connection with its ground control station, which directly influences how far the drone can travel from its launch site during a mission. Drones were grouped into five communication range categories (Figure 8): less than 1 km (1.7%), 1–5 km (20.7%), 5–20 km (26.3%), 20–50 km (8.9%), and greater than 50 km (8.4%). Drones without explicitly stated communication ranges but equipped with GSM or cellular modules (e.g., LTE, 4G, 5G) were conservatively classified into the >50 km category. This classification reflects their theoretical capability to operate over long distances, assuming continuous mobile network coverage. While actual performance de-pends on terrain, infrastructure, and regulatory constraints, cellular communication modules enable Beyond Visual Line-of-Sight (BVLOS) operations in many jurisdictions under supervised or experimental conditions.

The remaining drones, which lacked clear communication range specifications, were grouped into an “Unknown” category. Many of these models likely use general-purpose telemetry systems operating on unlicensed frequency bands such as 2.4 GHz or 5.8 GHz. These frequencies are commonly used in consumer and prosumer drones and generally support short- to mid-range operations, typically spanning 1 to 20 km under ideal conditions. However, range can vary significantly based on transmission power, antenna con-figuration, terrain, and line-of-sight conditions. In some cases—particularly with low-er-frequency systems (e.g., 900 MHz) or directional antennas—longer-distance performance may be possible, though not always guaranteed or documented.

Payload capacity, defined as the maximum weight a drone can carry, was used as a filtering parameter for assessing platform compatibility with sensor payloads. Among 161 drone records with available payload data, models were grouped into five categories (Figure 9): <500 g (25.2%), 500 g–1 kg (8.9%), 1–2 kg (3.9%), 2–5 kg (21.8%), and >5 kg (40.2%). This classification was designed to represent a range of sensor deployment requirements and to align with common operational and regulatory thresholds. These groupings were used in the NDIS staggered decision logic to constrain platform selection based on sensor weight.

The structured RPAS database is used within the NDIS drone-matching module to relate drone specifications to sensor parameters and operational constraints. This association informs deployment planning in both accessible and remote geohazard environments.

2.1.9. Geophysical and Remote Sensing Sensors

The sensor component of the NDIS database focuses on geophysical and remote sensing methods suitable for deployment with RPAS in geohazard monitoring contexts. To characterize current usage patterns, a literature-based review was conducted using a scientometric approach. Scientometric methods apply quantitative analysis to published literature to identify trends and associations across research domains [49]. In this study, a structured query was implemented via Elsevier’s Engineering Village platform [50], using controlled vocabulary filters related to geohazard types, geophysical methods, and remote sensing technologies. The resulting publication data were used to identify commonly applied sensor types in geohazard monitoring (Figure 10 and to inform the inclusion of representative sensor payloads within the NDIS.

Seismic methods were the most frequently cited in field-based geohazard monitoring, particularly in relation to earthquakes, faults, and landslides. Magnetic and electromagnetic (EM) sensors were also identified, primarily for subsurface investigations in volcanic and landslide-prone areas. Optical and thermal imaging systems were commonly associated with studies of volcanic activity, landslides, and fault zones, where surface-level observations are required. Synthetic aperture radar (SAR) appeared in publications related to ground deformation monitoring, though its application was typically limited to satellite or crewed aircraft platforms due to payload and power constraints.

While drone specifications were not used to guide the scientometric analysis directly, the results were later cross-referenced with the RPAS payload database to ensure that selected sensors were physically deployable via drones.

2.2. Methods

During the development of the NDIS decision engine, four approaches were evaluated to assign drone–sensor combinations for geohazard missions. These include: (i) independent decision tree for sensor and drone selection, (ii) a combined decision tree model, (iii) a random forest classifier trained on joint sensor–drone pairings, and (iv) the final staggered decision method. While the machine learning models (i–iii) yielded high accuracy scores, they were ultimately discarded due to limitations in generalizability, constraint handling, and practical mission planning. The final approach (iv)—a rule-based, modular decision framework—was selected for implementation due to its transparency, compatibility enforcement, and adaptability.

The initial approach (i) used separate decision trees for sensor and drone selection. These models were trained using hazard attributes and equipment specifications, producing interpretable classification outcomes. However, due to the limited variety of available sensors and drones, the models overfitted to dominant classes and failed to generalize. This resulted in repetitive recommendations and implausible pairings, particularly for underrepresented hazard types.

To address these shortcomings, a combined decision tree model (ii) was developed to jointly optimize sensor and drone assignment. While this model introduced payload constraints and distance-based filtering, it still suffered from output rigidity and failed to scale with new equipment entries. Its fixed structure also made it difficult to enforce scenario-adaptive logic or accommodate updates to sensor requirements, making it impractical for operational use.

Approach (iii) trained a random forest classifier on pre-labeled sensor–drone pairs derived from the existing hazard dataset. Although the ensemble model reported high classification accuracy, it exhibited class imbalance, overfitting to frequent pairings such as seismic sensors with long-range drones and lacked constraint awareness for payload compatibility. Despite these limitations, the random forest model served as a valuable diagnostic tool to validate patterns in the deterministic rulebase.

To address the limitations observed in classification models, a structured decision framework (iv) was developed to reflect practical field planning logic. Termed herein as the “Staggered Decision method”, this approach draws conceptually from hierarchical decision-making and operational modularity. Rather than treating drone-sensor selection as a flat classification problem, the staggered method decomposes the decision into ordered stages—mirroring how human operators prioritize requirements under mission constraints. This framework was designed to ensure interpretability, reproducibility, and flexibility in hazard-specific mission planning. The core logic follows a five-step workflow (Figure 11): (1) identification of the hazard type, (2) classification of the disaster phase (pre-event, active, post-event, or clean-up), (3) selection of the appropriate survey method (e.g., mapping, structural integrity, or perimeter monitoring), (4) assignment of the optimal sensor type based on geophysical methods, and (5) matching of a compatible drone platform based on payload, range, and mission constraints (evaluation summary presented in

Table 3. Evaluation Summary of Sensor–Drone Assignment Methods (DT = decision tree, RF = random forest).

Approach	Description	Interpretability	Adaptability	Constraint Handling	Outcome
(i) Independent DT	Separate trees for sensor & drone	High	Low	Weak	Discarded
(ii) Combined DT	Joint tree for sensor–drone	Medium	Low	Moderate	Discarded
(iii) RF Classifier	Ensemble classifier	Low	Low	Weak	Discarded
(iv) Staggered Decision	Modular logic-based system	High	High	Strong	Selected

).

Geohazards differ substantially in their physical characteristics, monitoring needs, and operational constraints. For example, volcanic activity during an eruption may require airborne thermal imaging to monitor vent temperature and ash plumes, while seismic sensors are commonly applied in fault and earthquake monitoring to characterize ground motion and stress conditions. Tsunami assessments frequently involve visual sensors for documenting post-impact conditions, and nuclear sites are typically surveyed using optical sensors at a distance. These variations in monitoring approaches reflect the need for hazard-specific decision logic, which may not be effectively represented by a single model or fixed rule base.

Table 4. Recommended geophysical survey methods based on hazard type and disaster stage. (Adapted from scientometric review; radar-based methods are substituted with LiDAR for payload harmonization.).

Hazard Type	Disaster Phase	Recommended Sensors
Volcano	Pre-Event	Magnetometers, Seismic, Camera
Volcano	During	Thermal Camera, Camera, LiDAR
Volcano	Post-Event	LiDAR, Camera, Seismic
Volcano	Clean-Up	LiDAR, Camera, Seismic
Earthquake	Pre-Event	Seismic, Magnetometers, Camera
Earthquake	During	Seismic, Camera, LiDAR
Earthquake	Post-Event	LiDAR, Camera, Seismic
Fault	Pre-Event	Seismic, Magnetometers, Camera
Fault	Post-Event	Seismic, Camera, LiDAR
Landslide	Pre-Event	LiDAR, GPR, Camera
Landslide	During	Camera, Thermal Camera, LiDAR
Landslide	Post-Event	LiDAR, Seismic, Camera
Landslide	Clean-Up	Camera, LiDAR, Seismic
Tsunami	During	BPR, Camera, Seismic
Tsunami	Post-Event	BPR, LiDAR, Camera
Tsunami	Clean-Up	Camera, LiDAR, Thermal Camera
Nuclear	Pre-Event	Thermal Camera, Camera, LiDAR
Nuclear	During	Thermal Camera, Camera, LiDAR
Nuclear	Post-Event	Camera, LiDAR, Gamma Spectrometer
Nuclear	Clean-Up	Camera, LiDAR, Gamma Spectrometer

which identified commonly reported sensor–hazard associations in the geohazard monitoring literature. Radar-based sensors mentioned in the reviewed publications were substituted with LiDAR in the current implementation to align with payload constraints and drone compatibility. Seismic sensors were typically associated with pre-event monitoring of earthquakes and faults, while LiDAR appeared more frequently in post-disaster applications involving surface or structural assessment. Table 4 presents the resulting sensor–hazard mapping used to guide subsequent stages of sensor and drone selection.

While gamma-ray spectrometry was included for nuclear post-event and clean-up stages due to its relevance in radiation detection, other specialized sensors—such as spectrometers and electromagnetic (EM) instruments—were not incorporated in the current system design, as these are more commonly deployed in geological or mineral surveys rather than time-sensitive RPAS-based hazard response [51,52]. Nonetheless, adding new sensors can easily be accomplished if sufficient examples have been reviewed and added to the database.

The staggered decision framework was implemented through a rule-based pipeline by assigning a top-three sensor list to each geohazard point, based on hazard type and disaster phase as defined in Table 4). Each sensor is then evaluated against the target area using predefined area templates and line spacing assumptions to estimate the required flight path length. For example, sensors like “LiDAR” or “Magnetometers” follow a line-grid coverage model where spacing is used to compute flight paths (e.g., number of swaths × area length), while seismic or BPR surveys simply match the point-to-point hazard distance. These computed distances are then compared against drone endurance and payload capacities.

Drone selection is conducted using a weighted scoring system that balances proximity (by distance binning), payload feasibility, overkill penalty (excess payload capacity), and tight-fit bonuses (minimal excess). A fallback mechanism ensures that even when no ideal drone is found, a deployable alternative is chosen from the closest available match in a flexible threshold bin. Distance and communication range constraints are dynamically adjusted depending on sensor type. For instance, “Seismic” requires communication bin matching, while “Camera” is exempt from payload thresholds as it is low-weight and a valuable addition to any mission.

The staggered decision method was implemented to enable modular updates and constraint-aware logic without requiring model retraining. Each stage of the rule base—such as sensor thresholds or platform specifications—can be independently adjusted as new data become available. Operational parameters including payload capacity, communication range, and fallback logic are directly encoded to support consistent filtering across diverse mission contexts.

The method produces outputs based on explicit rules, which facilitates interpretability and supports downstream processes such as Critical Path Method (CPM) scheduling and urgency scoring. It remains adaptable to revisions in hazard datasets and sensor inventories, while maintaining consistency through a predefined structure.

To address development considerations in the system design, the method was structured around four objectives: generalizability across hazard types and platforms; customizability for different operational phases; optimizability within mission constraints; and compatibility with validation needs. To support ongoing refinement, a contribution module allows users to provide or review hazard records, which are subject to verification prior to integration. The rule-based design is consistent with established practices in multi-criteria decision analysis (MCDA) and spatial decision support systems (SDSS) [53,54].

3. Results

This section demonstrates the implementation outcomes and examples of the NDIS framework. It highlights both outputs from the backend logic and deployment insights relevant to operational readiness and real-world use scenarios.

3.1. System Implementation and Deployment

The final version of the NDIS was deployed as a browser-accessible geospatial application. This version integrates a frontend interface developed using ArcGIS Experience Builder (ArcGIS Online, 2025 cloud-hosted release) with a backend inference engine implemented in FastAPI, a Python framework designed for building web-based application programming interfaces (APIs). An API refers to a structured set of rules that allows different software components to communicate—here, enabling the frontend to request and receive mission recommendations from the backend in real time.

The NDIS integrates three main data flows (Figure 12) to support both automated and user-driven mission planning. In the first flow (purple box in Figure 12), preprocessed geohazard records are evaluated using the staggered decision logic, with the resulting mission recommendations published as feature layers in ArcGIS Online and visualized in the ArcGIS Experience Builder (ExB) frontend. The second flow (blue box in Figure 12) enables user-defined mission planning in real time. This interactive component is powered by a FastAPI backend hosted on Microsoft Azure App Service (Python 3.10 runtime stack), using Oryx to automatically configure the Python runtime environment during deployment.

The backend includes the main application script (main.py), the core decision logic (logic.py), and supporting files such as the sensor and drone databases. These components are connected to a lightweight HTML interface embedded within ExB via a custom widget, enabling users to input coordinates and mission parameters directly through the frontend. A third flow (green box in Figure 12) supports crowdsourced data contributions. User-submitted hazard reports entered via ArcGIS Survey123 are stored in ArcGIS Online, reviewed for quality control, and optionally incorporated into the geohazard dataset for future mission planning. Together, these flows form a closed-loop system (yellow box in Figure 12) in a web application format that combines backend automation with user input and validation.

3.1.1. Deployment Procedure

The backend was deployed to Azure App Service, a lightweight cloud-based platform provided by Microsoft that enables Python-based web applications to be hosted without server maintenance. Deployment was developed for a Linux-based environment managed via KuduLite, a simplified container designed specifically for resource-constrained hosting. The application files were first compressed into a ZIP archive and uploaded through Azure’s Deployment Center, which handles the unpacking and environment setup.

To enable reproducibility, version control, and incremental updates, the backend folder was linked to a GitHub repository. This repository functions as both an archival record and the source for the backend logic, allowing others to examine the implementation and, if needed, replicate or adapt the system. The repository includes logic.py, main.py, configuration templates, and dependency files. Large datasets, including the geohazard and RPAS databases, are not included due to file size limitations and hosting constraints.

In addition, a Continuous Integration and Continuous Deployment (CI/CD) pipeline was configured using GitHub Actions. CI/CD is an automation process that ensures any new update (such as debugging/code corrections or logic enhancements) pushed to the GitHub repository is automatically detected by Azure, built, and redeployed without manual intervention. This mechanism reduces human error, accelerates iteration cycles, and preserves consistency across development environments.

3.1.2. System Integration

Once deployed e.g., at https://ndisv3-cmcpgaembbcafpby.canadacentral-01.azurewebsites.net/ (accessed on 16 October 2025), the FastAPI endpoint was integrated into the ArcGIS Experience Builder frontend through a custom widget. This widget allows end-users to interact with the system by either clicking directly on the map or entering location coordinates and mission parameters via form inputs. These inputs are transmitted to the backend, which processes them using the encoded logic and returns recommended sensors, drone configurations, and associated parameters, which are displayed to the user through the interface. This integration allows the NDIS to function as a lightweight, modular Software-as-a-Service (SaaS) platform.

3.2. Web Application Capabilities

The Natural Disaster Information System (NDIS) web application was developed to operationalize the mission planning logic described in this paper. It provides an interactive, map-based interface for exploring historical geohazard records, retrieving precomputed recommendations, and simulating user-defined drone–sensor missions. The application is publicly accessible at: https://experience.arcgis.com/experience/0f4b603be71d4039bda2fe92541422a6 (accessed on 16 October 2025).

The interface is organized into four sequentially structured pages. The first page (Figure 13) serves as a static landing page introducing the NDIS framework, its intended use, and access instructions. From this page, users can select the “NDIS App” tab or click the icon beneath the NDIS logo to open the main interactive interface.

The second page (Figure 14) provides the primary platform for mission planning. The right-hand side of the page displays geohazard points, each linked to preprocessed drone–sensor combinations. Selecting a point triggers a pop-up window (green box) containing mission-specific attributes, including hazard intensity, estimated economic loss, population exposure within a 30 km buffer, and distance to the nearest road. A legend menu on the left side of the map provides symbology references for easier interpretation. In the example shown in Figure 14, a tsunami event near Edvard Munch’s villa, approximately 34 km south of Oslo, Norway, displays a distance of approximately 1 km to the nearest road. The system subsequently recommends multirotor platforms (on a sidebar in purple box in Figure 14) suitable for short-range missions that require high maneuverability. The sidebar, which also displays default platform recommendations when no point is selected, includes drone specifications and paired sensor details.

On the left-hand side of the interface of page 2 (Figure 14 left side), users may define a custom mission by completing a parameter form (Figure 15). For instance, a simulated mission for a pre-event active fault survey using a GPR sensor, located 50 km from the nearest road with a 200 m × 200 m survey area and 20 m spacing, results in recommendations favoring fixed-wing drones more suited to long-range deployment. After submitting a mission, the system returns a mission summary, a top-ranked sensor–drone pair (Figure 15 right side), and two alternative drone options, as shown in Figure A1 in Appendix B.

To demonstrate both applicability and consistency, this functionality was tested on volcanic hazard scenarios in Indonesia, specifically the Merapi volcano (Figure 16). For this site, the system generated drone–sensor recommendations include the DJI Matrice 100 (max payload 1000 g, equipped with the Zenmuse X3 12.4 MP CMOS camera as the default payload), Skydio X2 (12.3 MP camera), and Atlas Aerospace AvalanchePRO (12.7 MP CMOS camera). These outputs correspond well to prior field deployments at Merapi that used DJI Phantom 3 and DJI Mavic Pro drones—both featuring 12 MP cameras [55] with comparable flight characteristics, despite their lower payload capacities. Although these historical deployments were not used as training data, the similarity in sensor resolution, flight behavior, and mission parameters reinforces the plausibility and operational validity of the NDIS recommendations, particularly for optical survey missions.

The third page of the application (Figure 17) presents a geohazard dashboard containing both dynamic (red box in Figure 17) and static statistics (green box in Figure 17) derived from the backend database. Dynamic views, such as hazard frequency over time in Nepal, allow for focused spatial-temporal exploration, while aggregate statistics at the bottom of the page summarize attributes of the full dataset. These include hazard distribution by type, proximity to infrastructure, drone’s communication range and drone’s weight distributions, which serve to contextualize the data and support interpretation by researchers, field operators, and policy planners.

The fourth page (Figure 18) integrates a public reporting tool developed using ArcGIS Survey123. This interface allows users to submit new geohazard observations or revise existing records. The form structure reflects the staggered decision logic, capturing inputs such as hazard type, stage, distance, and optional sensor overrides. Additional fields allow contributors to include references or supporting documentation, which can greatly assist in the verification process. For example, a user may define a mission near the San Andreas Fault, approximately 156 km east of San Diego, California, and specify survey attributes to generate a structured mission profile.

Submitted records are reviewed through a quality assurance and quality control (QA/QC) procedure prior to inclusion in the system. This involves checking for field completeness, consistency with existing data, and relevance of any attached references. Verified records may be appended to the database and included in future mission planning workflows at the discretion of the developers.

In addition to field-oriented and open-access environments, the system was tested against a hypothetical scenario set in a highly restricted jurisdiction. For example, a gamma spectrometry mission was simulated near a nuclear facility (Figure 19) in the Democratic People’s Republic of Korea (North Korea), where publicly available information indicates that drone operations are restricted to government-authorized agencies, with no provision for civilian or private use [56]. In this case, the system proceeded to generate platform recommendations assuming ideal conditions, such as a longer transmission range multirotor (DJI FlyCart 30 with a signal transmission of 20 km) capable of supporting radiation sensors. While speculative, this test illustrates the system’s ability to return technically feasible outputs even in contexts where legal deployment may be constrained or undefined.

The NDIS framework does not enforce country-specific aviation laws, but rather adheres to generalized parameters derived from technical profiles (e.g., takeoff weight, sensor payload, endurance). This design choice is consistent with broader international frameworks such as those outlined by the International Civil Aviation Organization (ICAO) and the Joint Authorities for Rulemaking on Unmanned Systems (JARUS), which provide technical categorization and operational guidance without prescribing enforcement at the national level [57]. Accordingly, responsibility for regulatory compliance rests with the end user or governing authority.

To improve readability and visual clarity, map products were styled using light-themed, colorblind-accessible palettes adapted from ColorBrewer and Paul Tol’s color schemes [58,59,60]. The layout emphasized consistency and legibility across components, with minimal visual noise to accommodate diverse user needs, including those with neurodivergent processing styles.

To ensure accessibility across different devices, the interface was configured using ArcGIS Experience Builder’s built-in display modes for desktop, tablet, and mobile environments. These responsive settings allow the application to scale appropriately across screen sizes and maintain functional integrity for both technical and non-technical users.

Drone images displayed in the NDIS interface are sourced via publicly available URLs provided by manufacturers or licensed third-party platforms. These images are not owned by the authors and are used solely for non-commercial, academic purposes to illustrate drone specifications within the decision-support system. All trademarks and brand assets remain the property of their respective rights holders, and hyperlinks within the platform direct users to the original source for full context.

A complementary ArcGIS StoryMap is also available at: https://storymaps.arcgis.com/stories/c5053d195bdd41539805a195d765467d (accessed on 16 October 2025). The StoryMap provides a narrative overview of the NDIS development process, including system rationale, conceptual design, and field trials. Although not integrated into the core application, it offers additional insight for outreach, education, and public engagement.

3.3. Distribution of Recommended Drone Models and Sensor Utilization Across Hazards

For large-scale processing of approximately 1.9 million geohazard records, the staggered decision logic was applied within ArcGIS Pro using a standalone script-based workflow. While the underlying logic mirrors the Python function used in the web API, this batch process was executed locally to leverage ArcGIS Pro’s more efficient handling of geospatial operations.

In the batch workflow, each geohazard record is processed independently using attributes such as geographic coordinates, hazard type, hazard stage, and distance. These parameters are passed through a rule-based decision logic that assigns up to three relevant sensors per record, depending on the operational requirements of the identified hazard. For each sensor, the system identifies suitable drone platforms by evaluating payload compatibility and communication range. The resulting output is a one-to-many table, where each input point may correspond to multiple platform–sensor configurations.

For example, expanding on the Merapi volcano scenario introduced earlier, the same batch logic was applied to all volcano records labeled as being in the pre-event stage (see Table 4). For each record, the system mapped sensor priorities—typically magnetometers, seismic sensors, and cameras—and identified compatible drones based on site-specific parameters such as distance and payload capacity. In the Merapi case, this resulted in recommendations like the ACSL AirTruck, DJI S900, and Draganfly Starling X.2, which support heavier payloads suitable for magnetometers such as the GEM GSMP-35U series that weigh about 805 grams [61]. This example illustrates how the system generates tailored mission outputs for diverse hazard types and sensor requirements, enabling users to retrieve these configurations directly by selecting any hazard point on the map, without requiring additional input or customization.

The implementation of NDIS version 3.8.3 reflects the intended design as outlined in Section 2.2. Integration with ArcGIS Experience Builder and Survey123 facilitates user interaction, data contribution, and the distribution of mission outputs. This approach allows newly added drones, sensors, or hazard records to be used in the inference process without requiring retraining or manual code modification.

4. Discussion

The NDIS serves as a structured application of rule-based logic for drone and sensor selection in geohazard monitoring. This section examines the outcomes observed during implementation, identifies current limitations, and considers the system’s relevance within broader geospatial decision support frameworks. These observations inform future directions for enhancing scalability, improving end-user adaptability, and facilitating integration with complementary planning tools.

4.1. Interpretation of Drone-Sensor Assignment Patterns

The distribution of recommended drone models across hazard types reflects both the structure of the staggered decision logic and the practical constraints embedded in the NDIS framework. Figure 20 presents fifteen most frequently assigned drone platforms, grouped by hazard type. These results illustrate recurring selection patterns that are consistent with the mission profiles associated with different hazards.

Several platforms, such as the Aerialtronics Altura Zenith ATX8, DJI Mavic Mini, and Parrot Anafi Ai, were recommended across multiple hazard types. These platforms are generally multirotor systems—such as quadcopters or octocopters—with moderate endurance and limited payload capacity. Their frequent selection corresponds to missions requiring high maneuverability, especially in contexts where manual flight or visual inspection is necessary. This is particularly relevant for during- or post-event phases involving optical or thermal sensors, where fixed flight paths (e.g., lawnmower grids used in mapping) are less suitable, and rapid deployment or operator control may be prioritized. Although spatial constraints such as airspace or built environment proximity were not explicitly encoded in the decision logic, the dominance of multirotor models aligns with the types of sensors assigned in many scenarios—such as cameras, thermal cameras, or seismic payloads—across volcanic, landslide, tsunami, and nuclear hazards.

In contrast, fixed-wing platforms such as the Aerosonde Mk 4.3 and AEE G10 were more frequently recommended for tsunami and fault hazards. These cases typically involve expansive or remote environments—such as coastal zones or inland fault systems—where longer flight ranges and larger coverage areas are operationally required. The assignments were based on estimated distance and flight path dimensions, using platform endurance values to identify models suitable for the spatial extent of each mission. Similarly, hybrid VTOL drones such as the JOUAV CW-15 were assigned in contexts where vertical takeoff and landing were necessary due to terrain constraints, while still enabling efficient fixed-wing travel for larger survey coverage.

Heavy-lift multirotor platforms such as the DJI S900, Acecore Noa H6 Hybrid, and EAMS E484MP were recommended primarily in volcano, earthquake, and fault hazards involving sensors with higher payload requirements. These platforms, typically configured as quadcopters or hexacopters with lift capacities exceeding 3 kg, are suitable for carrying geophysical instruments such as airborne GPR systems, magnetometers or for delivering deployable sensors like seismic nodes or BPR. Their vertical lift capabilities and flight stability support short-range missions that require precise payload handling, particularly in uneven or obstructed terrain.

An analysis of hazard assignments by drone model indicates that distribution patterns correspond to platform configuration and operational parameters. The Aerialtronics Altura Zenith ATX8 appeared across all six hazard types, likely due to its moderate payload capacity and multirotor configuration, which supports stable operation in varied environments. In contrast, platforms such as the Aerosonde Mk 4.3, JOUAV CW-15, AEE G10, and IDEAFLY Poseidon-480 Pro II were assigned to a narrower range of hazards. These platforms are primarily fixed-wing or hybrid types, designed for extended flight duration, and were selected in contexts requiring long-range or offshore coverage. This assessment does not mean that one RPAS type is better than another, but it demonstrates that the selections of the NDIS can be validated using scientific reasoning. As this reasoning is implemented in the NDIS, it gives users the ability to make RPAS and sensor selections without the need to query all previous missions and applications.

Platform selection was determined by technical fit rather than brand, as no single manufacturer appeared across all hazards. RPAS cost was included in the query results where available, based on unit price data compiled up to 2024 in U.S. dollars. Not all platforms had publicly available pricing, and values for some units were obtained through direct inquiry to manufacturers. These prices are provided for reference only and may not reflect current market conditions.

4.2. Advantages of the NDIS Framework

Table 5. Comparative Features of Selected Hazard Decision-Support Systems and NDIS.

Feature	ShakeMap	PAGER	Copernicus EMS	InaSAFE	NDIS
Hazard Input	Earthquake only	Earthquake only	Multiple	Multiple	Multiple
Data Source	USGS	USGS + Pop. Data	Satellite imagery	Local hazard layers	Global multisource
Mission Planning	✕	✕	✕	✕	✓
Sensor Matching	✕	✕	✕	✕	✓
Drone Matching	✕	✕	✕	✕	✓
Output Type	Maps, Alerts	Casualty Estimates	Thematic Maps	Impact Summary	Drone-Sensor Pair+CPM

presents a comparison between NDIS and several representative hazard-related decision-support systems, including ShakeMap, PAGER, Copernicus EMS, and InaSAFE. These systems primarily focus on impact estimation, alerting, or situational awareness and do not include operational logic for platform–sensor matching or mission configuration. By contrast, NDIS integrates multi-hazard inputs with constraint-aware recommendations for drone and sensor selection based on user-defined mission parameters such as hazard type, distance to road, survey area, and survey method. The output includes not only pre-processed combinations but also estimated deployment time and supporting specifications for planning.

While the NDIS framework falls within the broader category of decision-support systems (DSSs), it differs from traditional spatial DSSs (SDSSs) and multi-criteria decision analysis (MCDA) models in both structure and function. SDSS tools are often used for scenario modeling and spatial prioritization, while MCDA frameworks commonly apply weighted scoring across predefined criteria to rank alternatives. In contrast, NDIS uses a staged filtering approach based on technical constraints such as payload capacity, communication range, distance to road, and hazard-specific survey needs. Rather than optimizing across a weighted preference scale, the system narrows feasible combinations through conditional logic applied in sequence. The outputs are best interpreted as indicative planning tools, offering constraint-based recommendations to support mission configuration, rather than predictive models or statistical forecasts. This approach emphasizes interpretability, operational transparency, and alignment with real-world deployment considerations, particularly for RPAS-based missions where binary constraints (e.g., payload exceeds limit) are more relevant than preference-based rankings. The system’s outputs are generated from deterministic logic rather than probabilistic scoring, making them more suitable for environments where mission feasibility must be explicitly defined.

The system architecture relies on two integrated environments: an open-source backend built with FastAPI and a geospatial interface developed using Esri’s ArcGIS platform. This setup enables consistent data transfer between the processing logic and the user-interface, avoids additional translation layers, reduces maintenance overhead, and improves workflow stability.

4.3. Limitations and Trade-Offs

The rule-based architecture in NDIS introduces certain limitations. The deterministic logic aids transparency but limits flexibility in handling multi-hazard contexts (e.g., landslide and flood hazard), novel mission profiles (RPAS swarms), or emerging technologies not captured in the current threshold definitions (e.g., vibrometers, drone-deployable SAR). Several attributes within the geohazard database are synthetically derived or estimated to support consistent processing across hazard types. While appropriate for system prototyping and comparative analysis, these engineered values may deviate from ground-truth measurements and should be interpreted accordingly before the implementation of a mission.

The current implementation assumes ideal operating and regulatory conditions. Although parameters like takeoff weight are included to reflect typical licensing categories (e.g., 250 g–25 kg), jurisdiction-specific flight rules are not explicitly enforced. Some recommended platforms may require certified operators or special authorization. Furthermore, integration with Esri’s tools—such as ArcGIS Experience Builder or ArcGIS Online—depends on specific file structures and deployment environments. Adapting the system to other GIS platforms or cloud services may require additional configuration. The platform has not been tested under concurrent multi-user scenarios. Its current deployment, hosted on a student-tier Azure App Service using Kudu-Lite, may not meet the performance requirements of emergency response or institutional-scale operations. Additional performance details are provided in Appendix C.

4.4. Operational Implications

The NDIS framework able to link hazard characteristics with platform and sensor feasibility, facilitating standardized mission planning across different phases of the disaster management cycle. This includes pre-event risk assessment, during-event response, and post-event reconnaissance.

In time-sensitive situations, such as search and rescue operations, the real-time mission planner supports rapid drone–sensor pairing based on local hazard parameters and site accessibility. This enables faster deployment planning without requiring manual trial-and-error.

At the institutional level, NDIS may be used as a first step to coordinate survey logistics and hazard data collection. Its consistent rule structure helps ensure that platform assignments are reproducible and aligned with hazard-specific needs, supporting planning efforts across multiple regions and operational teams.

Integration with participatory tools such as ArcGIS Survey123 enables local stakeholders to contribute observations, photographs, and contextual details, which can inform data verification and refinement. This participatory input complements the system’s rule-based logic, allowing for more consistent data formatting while maintaining transparency in decision support. Rather than replacing expert input, the system serves as a preparatory aid—helping users to understand technical requirements and operational feasibility before deployment. While expert-based planning may offer more tailored recommendations, it often requires days or weeks. In contrast, NDIS produces indicative outputs within minutes and could be used as initial plans for experts and decision makers. It integrates existing knowledge from the databases into the decision-making process but still needs to be validated with human subject matter expertise.

In this context, NDIS functions as a bridge between hazard identification and actionable mitigation. Whether applied in early monitoring or post-disaster phases such as search and rescue (SAR), the system provides structured outputs to support situational understanding and logistical planning. These functions contribute to broader efforts in resilient urbanization and disaster risk reduction, as outlined in SDGs 11 and 17.

4.5. Future Work

Several opportunities remain for enhancing the functionality, resilience, and usability of the NDIS platform:

• Uncertainty modeling: The current rule-based system operates under deterministic assumptions. Incorporating probabilistic elements—such as wind variability, sensor reliability, or communication loss—could support the generation of robustness indicators or confidence levels for each mission recommendation.
• Flight path trajectory visualization: Present outputs include estimated distance and duration; however, visualizing projected flight paths could improve operational planning. Such features would support airspace coordination, obstacle avoidance, and endurance validation, especially in mission operations with terrain constraints.
• Workflow continuity: As NDIS operates within the Esri environment, future development could explore integration with ArcGIS Flight or equivalent modules. This would enable direct transfer of recommended flight parameters into established mission planning tools, facilitating smoother transitions from decision support to field implementation.
• Integration with real-time data feeds: The current system uses static input layers. Future versions may incorporate live feeds through standard-compliant interfaces such as Web Feature Services (WFS). For example, volcano monitoring data from the Smithsonian Global Volcanism Program (GVP) is accessible via OGC-compatible endpoints (GeoJSON, CSV, Shapefile). Extending this capability to other sources, such as the ISC Bulletin or national warning systems, would support more timely and adaptive mission planning.

Note: The current system (NDIS v3.8.3) was developed using the standard edition of ArcGIS Experience Builder, which requires manual coordinate input due to decoupled map–widget architecture. An internal developer edition is under active development to implement native map integration, allowing direct coordinate capture. This enhancement is not fully described in the present manuscript to maintain scope clarity and avoid replication.

5. Conclusions

The Natural Disaster Information System provides a flexible and scalable framework for drone-based geohazard monitoring by integrating spatial data processing, decision logic, and sensor–platform assignment into a unified geospatial system. Developed using a modular architecture across the Esri ecosystem, FastAPI, and Azure App Service, NDIS supports both real-time queries and batch mission planning across diverse hazard types.

By applying a rule-based decision approach rather than machine learning models, NDIS maintains transparency and consistency in its recommendations. This improves traceability—an important consideration in disaster response operations where decision accountability is required.

Technical and regulatory constraints—such as payload limits, communication range, and platform weight classes—are encoded into the decision workflow, enabling mission planning to proceed as a structured reasoning task within a spatial context. The platform incorporates both institutional datasets and user-contributed inputs, allowing use across multiple spatial and organizational scales. Integration with Esri-based tools enables interoperability between backend processing and geospatial interfaces. Through its staggered logic, hazard-stage awareness, and support for participatory data, NDIS produces automated recommendations that reflect practical deployment conditions. As geohazard datasets grow and RPAS usage expands, such systems may support more timely, repeatable, and spatially targeted decision-making. Of note is that NDIS supports natural hazard response teams but is not suited to replace human expertise.