Content uploaded by Vitalis G. Ozianyi
Author content
All content in this area was uploaded by Vitalis G. Ozianyi on Nov 12, 2015
Content may be subject to copyright.
A Mobile Solution for Road Accident Data
Collection
Kenga Mosoti Derdus
1
, Dr. Vitalis Gavole Ozianyi
2
(Member IEEE)
Faculty of Information Technology
Strathmore University
Email: mosoti.kenga@strathmore.edu
1
,vozianyi@strathmore.edu
2
Department of Information Technology
Strathmore University, Kenya.
Abstract - Road accidents are major cause of injuries
and death in developing countries. It is crucial to build a
road accident database and data retrieval system as a
fundamental resource in improving road safety. Since the
accident database needs to hold reliable data, accurate
methods for accident data collection must be used. This
study focuses on improving accident data collection by
using a Smartphone-based application. The application's
aim is to improve data collection, while supporting
mobility, ubiquity and accuracy.
The name of the application is CrashData; it has been
developed and tested in Kenya. Using the application data
are sent to a central database for storage and can be
retrieved by the same application. The type of information
collected is determined by the Model Minimum Uniform
Crash Criteria (MMUCC), National Institute of Statistics
(NIS) and other accident data sets. Location information
recording is supported and depends entirely on
Smartphone inbuilt GPS module and Google places API.
The application provides a web interface for office based
managers, who can use Google maps to identify accident
hotspots by mining location information from the
database.
Keywords: Accident Database, Accident Data Collection,
Accident data presentation, Android Smartphone Application,
Google APIs
I. INTRODUCTION
The increase in motor vehicles, especially in developing
countries, has resulted in an increase in the number of
accidents. In Kenya, for example, by 2007, registrations
showed that there were 2.7 vehicles per 100 people [6].
Accidents affect the economy as 75% of the road accident
casualties are economically productive adults [12]. The most
affected are passengers and pedestrians, who account for 80%
of the casualties. In Kenya, an average of 3000 people die
annually as a result of all types of road accidents. This
accounts for 3.6% of total deaths. This figure is expected to
rise to 4.9% by the year 2030 [6]. Ten times this number
remain seriously injured [7]. There are many measures that
have been put in place to curb road accidents as well as
minimize occurrences of injuries in case of an accident.
However, many of these attempts have failed to keep pace.
For example, the requirement to install seat belts in all
vehicles in Kenya, including Public Service Vehicles (PSV)
failed to due to poor administration and corrupt police.
On European roads, 30,000 deaths resulted from road
accidents, and over 25,000 people remained seriously injured
[3]. In the United States, 30,000 deaths were caused by
accidents, and 2.5 million people remained injured. Deaths
caused by road accidents are expected to overtake other
causes [10].
In Kenya, the traffic police department is responsible for
collecting accident data on-site. The police fill P41 forms,
which are presented to police headquarters, and finally to the
Ministry of Roads and Public Works for analysis and
planning [12]. A P41 form is a single paper form, which is
used by the police to record accident details. It is the basis of
police crash data system in Kenya because there is no
electronic accident database. The data held in the P41 forms is
occasionally summarized and presented in excel charts. In
Kenya, more often, the statistics given above are inaccurate
because follow-up examination on accident scenes and
hospital updates on accident casualties are not added to the
already held accident data.
In this paper, we propose a mobile solution based android
platform that can be used to quickly and accurately collect
accident data. This paper is organized as follows;
In section II, we present literature review, which covers
various technologies that will support the solution and other
related research in the area of accident databases. In section
III, we describe the design, implementation and testing of the
proposed solution. Section IV presents conclusions and
suggest areas of further research.
II. LITERATURE REVIEW
A.
Related Technologies
The solution presented in this paper depends on a number
of technologies that are already in place. Examples include
Global Positioning System (GPS), open Google Application
Programming Interfaces (APIs), Smart phone cameras and
Android’s speech to text API.
1) Global Positioning System (GPS): The use of GPS is
the fastest and most accurate method of recording an
accident’s location [15]. A GPS receiver is an electronic
device that receives signals from GPS satellites. Over time,
the size of GPS receivers has reduced and they are now
integrated in smart phones. Because of this, localization is
very common and personal navigation and location-based
services are widening the scope of mobile usage [9]. With
GPS receiver modules, mobile devices offer sufficient
location accuracy and can be used to collect accident data
[15]. The receiver receives a signal from at least three
satellites and extracts the current device coordinates.
2) Google APIs and Map Markers: Using the Google
places API, the coordinates can be presented using names of
places and close range landmarks [5]. The most common
Google Places API requests include place searches, place
details and place actions. The latter allows users to
supplement Google data by submitting data into Google
Places Database. With the use of Google maps, locations of
interest can embedded on maps using colour markers. The
details of such locations are shown when the markers are
clicked [17]. Figure 1 shows map markers with info window.
Figure 1: Map Markers with info window
3) Smart Phone Cameras: Modern Smart phones are
equipped with high resolution cameras. These cameras can
take detailed photos, which can be used for various uses. The
photos can be stored in phone memory or be sent to some
other location for storage. Road accident photographs shows
evidence of an accident, and the extent of damage because
they communicate more information that just text.
4) Android’s Speech to Text API:
The use of inbuilt
mouthpieces in android enabled mobile phones to understand
commands and automate some tasks. This feature can
significantly expedite data input. However, it is largely
depedent on clarity of voice input [11].
A.
Road safety databases
Presently, there are many available international road
safety databases whose aim is to
elaborate road accidents data
in compatible and homogenous formats using standard accident
datasets and to ease the work of researchers in collecting accident
statistics [
HYPERLINK \l "Jay09"
1
]. These databases show
that tremendous work has been done in collecting and storing
accident data.
1) International Road Traffic and Accident Database
(IRTAD): This is the largest safety database in the world,
which collects accident data from Organization for Economic
Co-operation and Development (OECD) member countries.
This database contains over 500 data items [16].
2) GLOBESAFE
:
this database shares road accidents
from only nine Association of Southeast Asian Nations
(ASEAN) member countries.
3) Road Accident sampling system-India (RASSI): the
accident database contains detailed crash data collected in
accident scenes and follow-up examination. The RASSI
database has over 500 data items. The advantage of RASSI is
that, on-site data collection and follow-up examination by
experts are linked.
A.
Related Work
Leelakajonjit proposes an accident database and insists
that the location of an accident by use of GPS is very crucial
[4]. The location data is used to identify accident hotspot.
Lobont, Filichi, & Popescu explain how Illinois State uses a
system fitted into a vehicle that goes around to record
accident locations [3]. The system uses an inbuilt GPS
module for marking accident locations. Jayan &
Ganeshkumar proposes a Geo-database, which can be used to
identify accident hotspots [14]. The main data item stored is
location. International Road Federation (IRF) presents a
system called RADaR (Road Accident Data Recorder), which
is an android application on tablets [2]. It uses GPS or GPRS
to record crash locations and then send data to a central
database. The application is also able to take photographs and
record video of the accident scene.
A.
Adopting a Common Accident Dataset
1) Model Minimum Uniform Crash Criteria (MMUCC): it
is a standard that defines how data must be collected and what
data pieces are to be collected so that it is easier to share data.
It categorises the data collected into crash data elements,
vehicle data elements, person data elements such as all
vehicle occupants, all drivers, non-occupants [8].
2) National Institute of Statistics (NIS): According to
NIS, traffic accident data contains a rich source of
information on the different circumstances in which the
accidents occurred: cause of the accident, traffic,
environmental and road conditions and many more. Every
NIS variable has a number of items associated with it and a
total of 572 different data attributes [18].
III. SOLUTION APPROACH AND DESIGN
In this section, we make assumptions and then describe
how we designed, implemented and tested our application.
Our solution is designed under the following assumptions;
-That the driver and vehicle database is in place
-For this study, dummy data will be used to represent
these systems
-That data is easily shared within these sub-systems
A.
System Architecture Overview
The accident database interacts and shares data with
driving license, driver penalty point, vehicle registration and
other related subsystems. Figure 2 shows this relationship.
The traffic accident subsystem, which is the interest of this
study, is isolated and shown in Fig. 3. It shows the
components involved in accidents data collection and
presentation.
Centralized client-server architecture has been chosen for
this system. However, the use of web services makes it
hybrid. The system has few users hence there was no need to
have it distributed. Only the traffic police department has
access to it plus a simple web interface that allows hospitals
to give updates on the hospitalized accident casualties.
Nevertheless, this architecture is determined by portability,
data sharing and distributed processing.
Accident data is collected from an accident scene and sent
to a central server over a 3G network. The 3G wireless
network is the mobile broadband internet connection of
choice. Data collection is done on a native mobile application.
GPS satellites offers location services by the help of the GPS
sensor on a mobile device such as a tablet or mobile phone.
On the other hand, the web service offers geo-location for
physical location name.
The central server offers storage and processing functions.
Certain processing needs are offered by external web servers.
For example, Google maps API offers accident data mapping.
The server also offers an interface for sharing data with other
related systems. Data received from the mobile application is
processed by PHP scripts and stored on MySQL database. An
apache HTTP web server application provides an interface for
smart phones to connect to the central server.
Figure 2: Proposed system architecture overview in relation to other
sub-systems
Figure 3: Proposed system architecture
B.
Context Diagram
A context diagram represents a level zero data flow
diagram. In this case it presents CrashData as a single high-
level process and then shows the relationship that the system
has with other external entities. It therefore shows the
relationship between external entities, and the systems as a
single process. Data flowing into and out of the system is
shown with the entities that produce and receive the data.
Figure 4 shows the CrashData context diagram and Table 1
shows the key to the context diagram.
Figure 4: CrashData Context Diagram
Table 1: Context Diagram key
No. Description No. Description
1 Analysis results 8 Shared data
2 Recommended safety measures 9 Accident analysis results
3 Accident details 10 User account details
4 Recommended safety measures 11 Reports
5 Accident details 12 Recom mended safety measures
6 Follow-up examination 13 Acciden t casualty details
7 Accident analysis results
The external entities of the system include:
Traffic police officer: the traffic police officer collects and
uploads accident data to the central server. The traffic police
officers can also add expert recommendations to the accident
data and view the accident data afterwards.
Analysis experts: the analysis expert adds analysis
recommendations and follow-up examination.
Administrator: the main role of the administrator is user
accounts management and report generation, but can also add
accident analysis recommendations, view user logs and add
emergency responder contacts.
Web Service: this is an internet service, specifically Google
APIs, which will offer geo-location for physical location
name, and map and map markers.
C.
Implementation
1) Implementation Environment: The mobile application is
implemented on the android platform. Thus, the source code
is written in java utilizing android classes. After development,
the application is compiled and tested using Software
Development Kit (SDK) emulator on windows and a
Samsung tablet. The software is optimized for android OS is
4.3 (API 18) but ha a backward compatibility with android 2.2
(API 8). Android was chosen for the client application due to
the flexible SDK, Android Development Tools (ADT) and
availability of support from a number of developer
communities online. The web interface is written in Hypertext
Preprocessor (PHP) together with HTML and JavaScript. The
Hospital
Injury
Information
system
Vehicle
registration
system
Driver
penalty
subsystem
Driving
school
subsystem
Traffic
information
subsystem
Traffic
accident
data
subsystem
Traffic
information
subsystem
Driving
license
subsystem
Integrated
system
Web
services
GPS satellites
Accident data
collection with
CrashData runn
ing on
Application
and database
server
Data
sharing to
other
subsystem
s
Web
services
Accident data storage,
processing and sharing
Presentatio
n
Accident data
presentation
3G
13
8
1
2
1
1
1
0
9
7
5
6
4
3
1
2
CrashData
System
Analysis expert
Related
subsystems
Administrator
Traffic
Police
Officer
web system is hosted on a live Apache HTTP server. The
main reason for choosing PHP as the server-side language is
portability, easy debugging is powerful and error resilience.
Support from a large online developer community is readily
available. The web system receives interfaces with the mobile
client to receive requests from end users, and it also provides
front-end for presenting accident data to administrators.
Accident data was stored in MySQL database. Storage of
accident information in a database is preferred because it
facilitates easy to retrieval of information. MySQL database
was chosen because it is open source and has full
compatibility with PHP. It should be noted that the database
also carries dummy data that was used to simulate other
subsystems e.g. vehicle registry that are required by the
accident data collection system.
2) Implementation Details
Functionality: The application is made up of a mobile and
web components. The android mobile application runs on a
tablet and its main purpose is to enable users, i.e. traffic police
officers, to collect accident data and then send it to the server.
The application also provides emergency numbers that can
dialled in an emergency. Data collected include text and
multimedia (voice, picture and video). The Smartphone
running the application requires an internet connection and an
onboard GPS module for registering accident location. The
application also has a feature that allows accident casualty
details to be added to the accident details. The casualty details
are then connected to the particular accident. In a nutshell, the
mobile application is aimed at collecting accident data,
recording accident casualty details and contacting emergence
responders. The web application retrieves and presents
accident information that is sent by the mobile client to the
database. It resides on the HTTP web server and is linked to
the database. In addition, user accounts are managed using the
web interface. Using the web interface, accident causalities
can be linked to a specific accident and reports can be
generated.
2.1 Mobile Application Component; The mobile
application starts with a splash screen, then to a login screen
and finally an options screen, where the user chooses the
action. This is shown in Fig. 5.
Figure 5: Splash, login and option dashboard screens
The ‘File New accident’ option allows the user to start
collecting accident details. Table 2 below summarises the
type of data that is collected by the application. Figure 7
shows sample application screens interfaces that were used to
collect vehicle details. The ‘Call Emergence’ option leads the
user to the interface shown in Fig. 6.
Variable Items
Location Coordinates, nearest town/city, nearest
landmark, region (initially known as province)
Time Time of accident, date of accident, date of
accident recording.
Movement Pre-crush events, crash configurations
Alcohol Driver alcohol test results
Vehicle factors Registration number, owner, vehicle type,
loading, defects (lights, tires, mirrors, road
worthiness), insurance policy, model
Casualty details Consequences (deaths and injuries), gender,
age group, names, nationality, eventual
consequence of hospitalised casualty.
Multimedia data Accident scene photos, witness videos,
Road factors Nearby road signs, road surface characteristics
Other accident
conditions general
conditions
Hit and run, number of vehicles involved,
accident severity, light
conditions/illuminations, possible cause of the
accident.
Whether
conditions
E.g. normal weather, fog, rainy etc.
Driver Name, licence number, consequences, alcohol
test results , gender
Other damages Property name, property description, property
category (private or public)
Table 2: Data variable and items collected by CrashData
Figure 6: Calling Emergence Responders
Figure 7: Vehicle/driver details screenshots
2.2) Web application component: The main role of
the web component is to allow access to the collected accident
data. With it, the following can be done;
1) Search accident by date and accident ID, to show the
details on map and map markers with info window as shown
in Fig. 8.
2) Add follow up examination and recommendation to a
selected accident
3) Add casualty details to a selected accident
4) Add emergence responder contact numbers
5) Generate tabular and graphical reports from the stored data
6) Give updates on the progress and condition of the
hospitalised causalities as shown in Fig. 11
The kinds of reports that are generated by CrashData
application include the following;
1) Graphical Accident Distribution per Region
2) Graphical Distribution of Injury Severity by Age Group as
shown in Fig. 9
3) Graphical Distribution of Accident by Vehicle Type
4) Tabular Distribution of Accidents by Cause
5) Yearly summery as shown in Fig. 10
Figure 8: Accident Search and Map Locations
Figure 9: Graphical Distribution of Injury Severity by Age Group
Hospital updates are very important because it updates
prevailing statistics, and reports from such updates can be
used to show the recovery rates of accident victims.
Figure 10: Yearly summery
D.
Testing
The process of evaluation entails comparing the
completed system with the design goals. Use case
requirements were used to check whether the goals were
reached. First, we set the measures, and then determined what
results were considered successful.
Figure 11: CrashData hospital updates
Before the experiments and results, we discuss how we
measured the functional and non-functional requirements and
how successful results were measured. We used 5 subjects for
4 sessions (assumed as 20 subjects).
A use case was used to present functional requirements of the
system. We checked whether the complete system had the
features that were promised in the use case. The test cases
were simulations on real-life scenario. The outputs from the
tests were then compared with what was expected.
There were two non-functional requirements that were
tested i.e. user interface and usability. A questionnaire was
used to measure usability satisfaction from the users. The test
questionnaire was presented to the users after they had used
the application.
Acceptance tests were done on the final system to find out
whether the system met functional requirements. One real life
case was used determine whether the mobile application and
the web system delivered its promised functionality. In this
case, users were located in Traffic Headquarters, Ruaraka,
Thika Road (lat, -1.256962; lng, 36.857001). 5 user accounts
were created in the web system and were used by 5 users to
submit accident data. Functional requirements were tested as
shown by a sample test case shown in Table 3. The last row
shows the value pass if the result is what was expected, or fail
if the result was not as expected.
Identifier 1
Test case Creating user accounts and logging in
Description
The administrator creates user accounts in the web
system and users login from the mobile application
into the system
Utilized
use case
Manage user accounts upload accident data.
Results Accounts were created and users were able to login
using the mobile application into the system
Pass/fail Pass
Table 3: Creating user accounts and login test case
IV. CONCLUSIONS
In this paper, we have successfully designed and
developed a mobile application that offers great benefits in
A
ccident
search
(By date or ID)
Map marker with info
window showing
accident location and
details
Years
accident data collection. These advantages include; 1)
increased mobility, 2) accuracy of data collection increased
access to accident, 3) better storage of accident data and 4)
increased speed of filling of data into the system. With
improved access to data and location mining, accident hot
spots can be shown on maps. However, the solution presented
in this paper can only be successful if it is backed up by the
government. With reagard to this, a number policy
recommendations to key stakeholders and the government are
suggested below.
1) There is need for a standard accident data set for
inclusion in accident reports and periodical audits to
evaluate police performance
2) The government should build a national accident
database based on the standard dataset identified above
3) The government should extend its efforts to ensure that
the accident database collected is easily accessible to key
stakeholders
4) Mapping of accident data per location to identify ‘black
spots’
5) Analytics should be perfomed on the accident data to
derive sensible statistical trends
6) Connecting accident database with other related
subsystems such as driver and vehicle databases and
driver penalty database
7) Designing more report formats to be drawn from accident
database, which can reflect the state of road
8) Training the police traffic department on the applications
of current technologies in road safety
9) Because some accidents are not reported, the government
can extend similar projects to enable the public contribute
in accident reporting
From the forgoing, we realize that accurate accident data
is an impotant resource in addressing road safety challenges.
This research is not final and the following areas need more
research.
1) There is need to do research on alternative positioning
technologies such as GSM
2) Research needs to be done on the use of GIS analysis for
mapping to complement use of external services such
Google maps
3) There is need for new ways of accident data coding for
easier analysis
4) There is need for more research on data analytics, which
will assist to extract sensible trends from the accident
database when there is enough data available
ACKNOWLEDGEMENT
We acknowledge the Kenyan Traffic Police Department
for the valuable support, in terms of infomation and accident
data collection processes.
REFERENCES
[1] K. Jayasudha and C . Chandrasekar, "AN OVERVIEW OF DATA
MINING IN ROAD TRAFFIC AND ACCIDENT ANALYSIS,"
Journal of Computer Applications, vol. 2, no. 4, 2009.
[2] Internation Road Federation [IRF]. (2013) Internation Road Federation.
[Online]. http://www.irfnet.ch/roadsafety.php?id=104
[3] Lucian Lobont, Adrian Cosmin Filichi, and Liliana Georgeta Popescu,
"IMPROVING TRAFFIC SAFETY USING MODERN METHODS
FOR ACCIDENT DATA COLLECTION," Fascicle of Management
and Technological Engineering, no. 1, 2013.
[4] Amornchai Leelakajonjit, Kunnawee Kanitpong, Ulrich Brannolte, and
Pawinee Iamtrakul, "Improvement of road accident database for
Thailand," Journal of Society for Transportation and Traffic Studies
(JSTS), vol. 4, no. 3, pp. 30-38, 2013.
[5] Google. (2013) Google. [Online].
https://developers.google.com/places/documentation/
[6] Abdulgafoor Bachani et al., "Road Traffic Injuries in Kenya: The Health
Burden and Risk Factors in Two Districts," 2012.
[7] G. Munala and K. Maina, "REST-STOPS AS A PLANNING
ENGINEERING OPTION TO FATIGUE," JAGST, vol. 14, no. 1, 2012.
[8] "Model Minimum Uniform Crash Criteria:Fourth Edition ," 2012.
[9] Soyoung Hwang and Donghui Yu, "GPS Localization Improvement of
Smartphones Using Built-in Sensors," International Journal of Smart
Home, vol. 6, no. 3, pp. 1-3, 2012.
[10]
Chris B aguley, "The importance of a road accident data system and its
utilisation," Transport Research Laboratory, Research Report 2011.
[11]
Johan Schalkwyk et al., "Google Search by Voice: A case study,"
Mountain View, CA, USA, 2011.
[12]
F Otsyeno, "EDITORIAL ROAD SAFETY IN KENYA," East African
Orthopaedic Journal, pp. 33-34, 2011.
[13]
GeoChalkboard. (2011) GeoChalkboard. [Online].
http://geochalkboard.wordpress.com/2009/03/11/density-mapping-in-
google-maps-with-heatmapapi/
[14]
Deepthi Jayan and B. Ganeshkumar, "Identification of Accident Hot
Spots: A GIS Based Implementation for Kannur District, Kerala,"
INTERNATIONAL JOURNAL OF GEOMATICS AND GEOSCIENCES,
vol. 1, no. 1, 2010.
[15]
Mikulik Josef, "Identification of Accident Location by Use of GPS and
Possibilities of its Application," in 4th IRTAD CONFERENCE, Seoul,
Korea, 2009, pp. 82-85.
[16]
Imad Abugessaisa, "Knowledge Discovery In Road Accidents Database
- Intergration of Visual and Automatic Data Mining Methods,"
International Journal of Public Information Systems, vol. 2008:1, pp.
59-85, 2008.
[17]
UmmassSafe, "Commercial Motor Vehicle Crash Location,"
Cambridge, USA, 2007.
[18]
Karolien Geurts, "Traffic Accidents Data Set," Limburgs Universitair
Centrum,.
