From Open Accident Data to Location-Based Warnings: A Prototype for Thailand

Road traffic injuries remain a major public-health problem in Thailand. The WHO Global Status Report on Road Safety 2018 estimated 22,491 road-traffic deaths in Thailand, equivalent to 32.7 deaths per 100,000 population, with motorcycle-related fatalities representing a significant concern [1]. Previous research has identified driver perception and decision-making failures as important factors in motorcycle crashes [2]. Providing information about locations with historically high accident concentrations may help drivers recognize potential road risks. However, historical accident data indicate past patterns rather than predict when an accident will occur.

Several Thai government agencies collect accident information for different purposes and may use different definitions and reporting methods [3]. The Ministry of Transport publishes road-accident records as open data through the Information and Communication Technology Center of the Office of the Permanent Secretary [4]. These records include accident dates, times, geographic coordinates, road names, and other accident-related attributes. Although such data support analysis and policy planning, they are not necessarily delivered directly to drivers through location-based services.

This study addresses this gap by developing a prototype that transforms open accident data into location-based warnings through a mobile application. The prototype has three objectives:

1. Prepare publicly available accident records for geospatial analysis.
2. Identify accident-prone areas using the Getis-Ord Gi* hotspot statistic.
3. Develop a mobile application that generates a warning when a device enters a designated hotspot area.

The prototype uses accident records from Bangkok covering January 2019 to April 2021. Accident records are aggregated by road segment, and statistically significant hotspots are identified using GIS analysis. The resulting hotspot layer is published through ArcGIS Online and connected to an iOS application developed using ArcGIS AppStudio and geotrigger functionality.

The main contribution is an end-to-end prototype integrating open government accident data, spatial hotspot analysis, cloud GIS services, and mobile geofencing. The study focuses on the practical integration of existing technologies rather than developing a new hotspot-detection method. The resulting workflow can potentially be adapted to other geographical areas and location-based applications.

The remainder of this paper is organized as follows. Section II reviews related work. Section III describes the methodology and system development. Section IV presents the results and evaluation. Section V discusses the findings and limitations, and Section VI concludes the paper.

Several public services provide access to Thai road-accident information. Yak Data [5], developed by Opendream and partner organizations, compiles open accident data, primarily from compulsory-insurance claims, and presents area-level findings for community awareness and planning. It also allows users to explore accident-prone locations before traveling. Thai RSC [6], operated by the Road Accident Victims Protection Company, provides accident statistics at provincial, district, and sub-district levels, including information on fatalities and injuries.

Both services primarily present historical accident information for analysis, planning, and public awareness. However, they do not implement the specific location-triggered warning function developed in this project, which generates an alert when a mobile device enters a designated accident-prone area.

Hotspot analysis is widely used to identify spatial clusters in applications such as crime analysis, epidemiology, and road safety. An Esri study of Brevard County, Florida, aggregated crash records by road segment and applied the Getis-Ord Gi* statistic in ArcGIS Pro to identify statistically significant clusters of high crash rates [7].

While the cited study focuses on identifying and mapping accident hotspots, this project extends the workflow by connecting the resulting hotspot layer to a mobile application. The application uses geofencing to generate a warning when a device enters a designated hotspot area.

Table I compares the related services and the proposed prototype in terms of data sources, spatial analysis, risk-layer generation, and mobile warning functionality.

✓ = provided; P = partially provided; blank = not provided.
Pa = The case study reports descriptive crash patterns for its study area, including temporal patterns and crash counts by road segment, but does not represent a service that publishes accident statistics.
Pb = Yak Data does not provide a dedicated mobile application. Users can access risk locations through its LINE chatbot (@yakdata) and website, including searches for nearby locations or points along a planned route.

The Getis-Ord Gi* statistic [8], [9] is a local indicator of spatial association that identifies whether features with high (or low) values cluster spatially. For a set of n spatial units with attribute values xj and spatial weights wi,j, the statistic for unit i is

Gi* = ( Σj wi,j xj − X̄ Σj wi,j ) / ( S · U ) (1)
U = √[ ( n Σj wi,j² − ( Σj wi,j )² ) / ( n − 1 ) ] (2)

where X̄ is the global mean and S the global standard deviation of the attribute. The statistic is a z-score: a large positive value indicates a statistically significant cluster of high values (a hotspot), a large negative value a cold spot, and values near zero indicate no significant clustering. In this project the attribute is the number of accidents aggregated to a spatial unit, and the spatial units with a Gi* z-score significant at the 90%, 95%, and 99% confidence levels are retained as the accident-risk layer. The statistic is implemented in the Hot Spot Analysis tool of ArcGIS [10], which also reports a p-value and a confidence-level bin (Gi_Bin) for each feature. Because individual accident points all carry the same value, incident data must first be aggregated, for example by counting points per road segment. Esri recommends at least 30 features and a fixed distance band wide enough that every feature has at least one neighbour, about eight when the attribute is skewed [10].

The system was designed to satisfy four requirements:

1. Use publicly available accident data.
2. Identify accident-prone road segments using statistical hotspot analysis.
3. Provide location-based warnings through a smartphone using cloud-hosted GIS services.
4. Generate warnings when a device enters a designated accident hotspot.

As shown in Fig. 1, the system comprises three main components: (1) data preparation, (2) hotspot analysis and layer publication, and (3) mobile application development. Python and ArcGIS Pro are used to prepare and analyze the accident data. The resulting hotspot layer is published through ArcGIS Online and accessed by the mobile application, which uses geofencing to generate location-based warnings.

Accident records for Thailand’s national road network from January 2019 to April 2021 were obtained from the Ministry of Transport open-data service [4]. The three annual Excel files were merged into a single CSV table using Python in a Jupyter Notebook, resulting in 60,495 accident records.

The records were converted into point features using the XY Table to Point tool in ArcGIS Pro, based on their longitude and latitude fields and the WGS 84 geographic coordinate system (EPSG:4326). The accident points were clipped to the Bangkok administrative boundary, retaining 4,301 points. Subsequent spatial processing and hotspot analysis used the WGS 1984 Web Mercator projection (EPSG:3857).

A publicly available road-network layer in KML format was imported using the KML to Layer tool and clipped to the same Bangkok boundary. The resulting road-network features served as the spatial units of analysis.

Road segments were used as the spatial units of analysis so that the resulting hotspot layer corresponded to the road network. Accident points were snapped to the nearest road line, and the Spatial Join tool aggregated accident counts and related attributes for each road segment.
The accident count per segment was then used as the input variable for the Hot Spot Analysis (Getis-Ord Gi*) tool. The analysis included 13,966 road segments, using the Zone of Indifference conceptualization, Euclidean distance, a critical distance of 1,234 m, and False Discovery Rate (FDR) correction.

Segments with Gi_Bin greater than zero, representing statistically significant hotspots at the 90%, 95%, or 99% confidence levels, were selected as the accident-prone road layer (Fig. 2). The Gi_Bin values were used to distinguish the confidence levels through different colours.

The selected layer was exported as a shapefile and uploaded to ArcGIS Online as a hosted feature layer for access by the mobile application.

The iOS application, named Accident Hotspots Alert, was developed using ArcGIS AppStudio based on the Location Driven Geotriggers sample. The QML code was customized using Qt Creator [11].

A geotrigger is a location-based rule evaluated by ArcGIS Runtime that generates an event when a monitored location enters or exits a defined geofence. In this application, the geofences represent accident-prone road areas published as a hosted feature layer in ArcGIS Online, while the monitored location is the device's position.

At startup, the application loads the basemap and hosted hotspot layer from ArcGIS Online, sets an initial map viewpoint, and displays the user's current location. Users can switch between the ArcGIS Topographic and ArcGIS Streets Night basemaps, return to the home view, and recenter the map on their current position. When the device enters a hotspot geofence, the geotrigger generates an event, and the application displays a warning identifying the hotspot area, as illustrated in Fig. 3.

The device position can be obtained through GPS or a simulated route represented by a sequence of latitude and longitude coordinates. The simulated route enabled the warning functionality to be tested without requiring physical travel. The completed application was deployed to test devices using the ArcGIS AppStudio development workflow. During integration testing, the hotspot layer was displayed correctly in the application, but no warnings were generated. Investigation revealed that the geotrigger implementation required polygon features as geofences, whereas the initial hotspot layer consisted of line features. Consequently, the location-containment test could not be triggered using the original line layer.

To resolve this issue, the hotspot layer was retrieved from ArcGIS Online and reopened in ArcGIS Pro. The line features were converted into polygons using the Buffer tool, applying a planar buffer distance of 10 m on each side of the road with rounded ends. Overlapping buffers were then merged using the Dissolve Boundaries tool to prevent a single location from generating multiple alerts. The resulting polygon layer was exported as a shapefile and uploaded to ArcGIS Online to replace the original line layer. Subsequent testing confirmed that the warning functionality operated as intended.

The application was tested as a Windows desktop build during development and subsequently installed on an iPhone through ArcGIS Player. Testing confirmed that the basemaps and hosted hotspot layer loaded correctly and that positioning and warning functions operated on a real device.

The warning logic was verified using simulated routes through known hotspot segments in Bangkok. Warnings were generated and cleared as expected.

Three users evaluated ten application functions. All functions operated correctly, and no function was recommended for removal. Of the 30 user ratings, 22 rated functions as good, six suggested improvements, and two recommended further development. Improvement requests mainly concerned the location button and current-section display, including clearer risk-level information and warning presentation.

The same users evaluated five aspects of user satisfaction using a three-level scale. Users were generally satisfied with the application's appearance, map-type selection, ease of use, and ease of understanding. The current-section display received the most moderate and negative ratings and was identified as the main area for improvement.

The results demonstrate the technical feasibility of integrating open accident data, spatial hotspot analysis, cloud GIS services, and mobile geofencing. The prototype extends existing accident-information services, such as Thai RSC and Yak Data, by providing location-based warnings when a device enters a designated hotspot area.

User feedback identified several areas for improvement. First, some users interpreted the hotspot layer as representing real-time accidents, although it was generated from historical records collected between 2019 and 2021. The interface should therefore clearly indicate the data period and historical nature of the layer. Providing real-time information would require data-sharing cooperation among relevant agencies.

Second, the warning message “Enter” was not immediately understood. A more direct message, such as “Be careful,” could improve warning communication. The current-section display should also present risk levels more clearly. Users additionally reported a minor interface issue involving white text on the light-coloured basemap selector.

The evaluation was preliminary and involved only three users. Although it confirmed basic functionality and provided initial user feedback, it did not establish hotspot predictive accuracy, warning effectiveness, or accident-reduction outcomes. Validation using accident data from a later period remains future work. The results may also be affected by the completeness and positional accuracy of the source accident records.

The hotspot layer is static and must be regenerated when new data become available. The study was limited to Bangkok because of hardware constraints and evaluated only one hotspot-detection technique. Warning functionality was tested using simulated routes rather than real traffic; therefore, the effects of GPS accuracy, location-update frequency, and driving conditions were not examined.

Finally, the workflow depends on commercial ArcGIS software, which may limit reproducibility where institutional licences are unavailable. Open-source alternatives could support the general workflow, including QGIS for spatial processing, PySAL for Getis-Ord Gi* analysis, GeoServer or GeoJSON for layer delivery, and native mobile location services for geofencing.

This paper presented a prototype mobile application that provides location-based warnings when a device enters accident-prone areas in Bangkok. The proposed workflow integrates open accident data from Thailand’s Ministry of Transport, Getis-Ord Gi* hotspot analysis, ArcGIS Online, and an iOS application using geofencing.

Functional testing confirmed that the application operated on real devices and generated warnings when simulated locations entered hotspot areas. A preliminary evaluation with three users confirmed that the application’s functions operated correctly and identified the risk-area display as the main feature requiring improvement. These results demonstrate the technical feasibility of integrating spatial hotspot analysis with a mobile location-based warning system, but do not establish predictive accuracy, warning effectiveness, or accident-reduction outcomes.

Future work will focus on validating the hotspot layer using later accident data, comparing alternative hotspot-detection methods, extending the analysis beyond Bangkok, and improving warning messages and interface design. Reimplementing the workflow using open-source tools could improve reproducibility and reduce software licensing costs. The proposed approach could also be adapted to other location-based point-event applications, such as crime and wildfire monitoring.