disaster aid
TRANSCRIPT
KATHMANDU UNIVERSITY
SCHOOL OF ENGINEERING
DEPARTMENT OF CIVIL AND GEOMATICS ENGINEERING
FINAL INDEPENDENT PROJECT REPORT
(GEOM 410)
DEVELOPMENT OF ANDROID AND WEB APPLICATION FOR DISASTER
RISK MANAGEMENT THROUGH CROWDSOURCING
In Partial Fulfillment of the requirements for the Bachelor’s Degree in Geomatics
Engineering
By:
Arun Bhandari
Nishanta Khanal
July 2014
ii
KATHMANDU UNIVERSITY
SCHOOL OF ENGINEERING
DEPARTMENT OF CIVIL AND GEOMATICS ENGINEERING
FINAL INDEPENDENT PROJECT REPORT
(GEOM 410)
DEVELOPMENT OF ANDROID AND WEB APPLICATION FOR DISASTER RISK
MANAGEMENT THROUGH CROWDSOURCING
In Partial Fulfillment of the requirements for the Bachelor’s Degree in Geomatics
Engineering
By:
Arun Bhandari
Nishanta Khanal
Supervisors:
Mr. Shashish Maharjan
Mr. Uma Shankar Panday
July 2014
iv
AUTHORIZATION
As the authors of the project report entitled “DEVELOPMENT OF ANDROID AND WEB
APPLICATION FOR DISASTER RISK MANAGEMENT THROUGH CROWDSOURCING”,
we authorize Kathmandu University to lend this report to other institutions or individuals only for the
purpose of scholarly research. Reproduction of this document by photocopying or electronic
replication is allowed provided that no alteration in the authorship or contents of the documents has
been made. Contents of the document can be used only with necessary citations.
___________________________________________
Arun Bhandari
___________________________________________
Nishanta Khanal
July, 2014
v
DISSERTATION EVALUATION
[“BUILDING AN ANDROID APPLICATION FOR DISASTER RISK
MANAGEMENT”] by
Arun Bhandari, Nishanta Khanal
This is to certify that we have examined the above Project report and have found that it is complete
and satisfactory in all respects, and that any and all revisions required by the Final Independent
Project (GEOM 410) examination committee have been made.
_________________________________________
Mr. Shashish Maharjan, Supervisor
_________________________________________
Mr. Uma Shankar Pandey, Co-Supervisor
_________________________________________
Er. Prachand Man Pradhan, Act. Head
Department of Civil and Geomatics Engineering
_________________________________________
External Examiner
28 July 2014
vi
ABSTRACT
Kathmandu Valley has faced some major earthquake occurrences in history with huge amount
of damage to lives and property and the risk still prevails with the possibility of more severe
loss than ever recorded before. The geographical situation and foundational soil type of the
valley confirms the threat of earthquakes and the scale of damage is magnified by the
unplanned settlements, poorly designed buildings and dense population.
Besides earthquake, other incidents causing damage to lives and property continue to occur in
the capital city. Emergency services are insufficient and inefficient. There has been no concrete
system to track the locations of the victims and rescue them if another major disaster occurs.
Therefore, a system comprising of several tools and components that help in disaster risk
reduction and management is necessary.
In this project, we have developed tools that use latest technology (Location Based Services)
targeting a wide base of Android users. This Android application extracts the GPS coordinates
from the smart phone of the user, sends the data along with additional information to the server
and the system can be managed by an administering agency.
The user can call for emergency service, view map, report any disaster s/he witnesses, view
reports of other people, confirm or decline the incidents reported by others, find routes to the
nearest hospitals and participate in the collaborative system of disaster risk management. These
services are also available in the web component. The complete system can be administered
through an admin-component in the web.
So, this is a new approach of managing post disaster hazards. We believe that this tool shall be
useful in the national strategy for disaster resilience.
vii
ACKNOWLEDGEMENT
There are several individuals and institutions that we are indebted to for the successful
completion of this project. We would like to express our gratitude towards ICIMOD
(International Centre for Integrated Mountain Development) whose technical and financial
support has been the backbone in this project. The initiatives of ICIMOD in the sector disaster
resilience have motivated us to join the cause.
Kathmandu University and Department of Civil and Geomatics Engineering in particular has
encouraged and guided us through this journey. The knowledge and motivation that we have
gained during our course of study in the University have been the primary factor behind this
project. We are indebted towards the department for its continuous support.
Kathmandu Living Labs has been an idealistic institution for us, due to its long term
engagement in building OpenStreetMaps of Kathmandu and developing Android Applications
incorporating Geospatial information. Mr. Nama Raj Budathoki has always been an
inspirational figure to us. All the staffs at KLL have been welcoming and supportive to us
whenever we knocked on their doors for technical direction.
Our supervisors Mr. Shashish Maharjan and Mr. Uma Shankar Pandey have guided us
throughout the project with their valuable suggestions and recommendations. Without their
guidance and support, we would not have been able to produce what we have produced now.
We would like to express immense gratitude to both of them.
We would also like to acknowledge all the faculty members of Geomatics Engineering Program
have directly or indirectly helped us in the project.
Mr. Poshan Niroula has always provided us with a lot of practical suggestions from the depth
of his expertise. His suggestions have helped us see the higher potentials in the project we have
done. Mr. Amrit Karmacharya has always motivated by his proficiency and supportiveness.
We are very thankful to both of our seniors.
Our colleagues in Geomatics Engineering batch 2010 have been encouraging not only
throughout the project but throughout the course. We would like to thank everyone in the batch.
Last but not the least, thanks to our families for creating environments where we could work
on whatever we intended to.
viii
Table of Contents
1. INTRODUCTION .......................................................................................................................... 1
1.1. Background ............................................................................................................................. 2
1.2. Problem Statement .................................................................................................................. 4
1.3. Objectives ............................................................................................................................... 5
1.4. Scope of Work ........................................................................................................................ 5
2. LITERATURE REVIEW ............................................................................................................... 8
3. METHODOLOGY ....................................................................................................................... 10
3.1. Planning ................................................................................................................................ 11
3.2. Research ................................................................................................................................ 11
3.3. System Development ............................................................................................................ 12
3.3.1. Database Creation ......................................................................................................... 12
3.3.2. Server Backend Development ....................................................................................... 12
3.3.3. Website Backend and Frontend Development .............................................................. 14
3.3.4. Android Application Backend and Frontend Development .......................................... 15
3.4. Testing and Debugging ......................................................................................................... 17
4. DISCUSSION ............................................................................................................................... 19
4.1. Results ................................................................................................................................... 20
4.1.1 Database ............................................................................................................................... 20
4.1.2. Server Backend ............................................................................................................. 23
4.1.3. Website Backend and Frontend Development .............................................................. 23
4.1.4. Android Application ..................................................................................................... 32
4.2. Future Potentials: .................................................................................................................... 6
5. Conclusion and Recommendation .................................................................................................. 7
5.1. Conclusion .............................................................................................................................. 7
5.2. Limitations .............................................................................................................................. 7
5.3. Recommendations ................................................................................................................... 8
6. REFERENCES ............................................................................................................................. 10
ix
List of Figures
Figure 1- Disaster Alert Home Page ........................................................................................................ 8
Figure 2- FEMA app home page .............................................................................................................. 9
Figure 3- Natural Disaster Monitor app home page ............................................................................. 10
Figure 4- Database “disaster_aid” schema deign ................................................................................. 20
Figure 5- The Working of Server backend ............................................................................................. 23
Figure 6- Flow diagram of home page of the website .......................................................................... 24
Figure 7- UI of the homepage ............................................................................................................... 25
Figure 8- UI of homepage: news feed box opened ............................................................................... 25
Figure 9- UI of homepage: UI shuffled .................................................................................................. 26
Figure 10- Flow diagram of admin page (1) .......................................................................................... 28
Figure 11- Flow diagram of admin page (2) .......................................................................................... 29
Figure 12- UI of admin page to view summary and manage report type ............................................. 30
Figure 13- UI of admin page to manage reports ................................................................................... 30
Figure 14- UI of admin page to manage users ...................................................................................... 31
Figure 15- UI of admin page to manage emergency reports ................................................................ 31
Figure 16- Flow of Activities in the Android Application ...................................................................... 32
Figure 17- Flow diagram of SplashScreen Activity ................................................................................ 33
Figure 18- UI of the SplashScreen ......................................................................................................... 34
Figure 19- Flow diagram of LoginActivity .............................................................................................. 35
Figure 20-UI if the LoginActivity ............................................................................................................ 35
Figure 21- Flow diagram of RegisterActivity ......................................................................................... 36
Figure 22- UI of the RegisterActivity ..................................................................................................... 37
Figure 23- Flow diagram of NewsFeed ................................................................................................. 38
Figure 24- UI of the NewsFeed (logged in) ........................................................................................... 38
Figure 25- UI of the NewsFeed (not logged in) ..................................................................................... 39
Figure 26- Flow diagram of MapScreen ................................................................................................ 40
Figure 27- UI of MapScreen .................................................................................................................. 41
Figure 28- Flow diagram of ReportScreen ............................................................................................ 42
Figure 29- UI of the ReportScreen ........................................................................................................ 43
Figure 30- Flow diagram of DetailScreen .............................................................................................. 44
Figure 31- UI of the DetailScreen (logged in) .......................................................................................... 2
Figure 32- UI of the DetailScreen (notlogged in) .................................................................................... 2
Figure 33- Flow diagram of Emergency .................................................................................................. 3
Figure 34- UI of the Emergency activity .................................................................................................. 4
Figure 35- Flow diagram of Widget ......................................................................................................... 5
Figure 36- UI of the android widget ........................................................................................................ 5
x
List of Abbreviations
ADT Android Development Toolkit
AJAX Asynchronous JavaScript and XML
API Application Programming Interface
CSS Cascading Style Sheets
GPS Global Positioning System
HTML Hypertext Markup Language
IDE Integrated Development Environment
JS JavaScript
JSON JavaScript Object Notation
LAT Latitude
LONG Longitude
PHP PHP Hypertext Preprocessor
SDK Software Development Kit
SLF4J Simple Logging Façade for Java
UI User Interface
XAMPP X Apache MySQL PHP Pear
1
1. INTRODUCTION Nepal is a country comprising of a lot of geographical variations. The Himalayan Region has
a difficult terrain with large number of glaciers and mountain peaks whereas the Hilly Region
contains steep hills and fast flowing rivers and the Terai Region is a plain extending in southern
Nepal with large rivers and dense forests. This variation is surely an asset for a country like
ours because it contains unique landscapes, vegetation and shelters some rare species of
animals and birds. The geography is suitable for a lot of purposes such as tourism, hydropower
and medical science.
But the darker aspect of having this unique geography is that it is prone to a lot of natural
disasters[1]. And to make the matter even more complex, different types of disasters occur in
different geographical regions[2]. Since human settlements are scattered in all the regions,
there is always a risk that every disaster occurring in the nation will cause damage not only to
the natural structure but also to human life and property. For instance, glacial lake eruption will
cause damage to hundreds of villages in the higher hills, landslides are likely to sweep away
villages in the hills, floods in the rivers will wash away villages in the Terai Region and
earthquakes are likely to change the larger cities like Kathmandu into debris[3].
Nepal is currently ranked as 11thamong the countries at risk to earthquake and 30thamong the
countries who are at most risk to floods and landslides[4]. Disasters in Nepal occur in different
forms in different regions. They cause damages in different scales. And they require different
measures of resilience to reduce the damages. Even though natural disasters cannot be totally
prevented, their damages can be minimized by proper preparedness and safety measures. So,
Nepal has to have a disaster resilience infrastructure designed with consideration to the
geographical regions, disaster types and the communities likely to be affected by the disasters
so that they can be dealt according to their nature and scale of damage they are likely to cause.
Earthquake, among all other disasters likely to occur in Nepal, is the most challenging threat
to a huge population[5]. Earthquake among all other disasters likely to occur in Nepal, is the
most challenging threat to a huge population. Nepal sits at the meeting point of the Eurasian
and Indian tectonic plates, and the same seismic power that long ago produced the Himalayan
mountain range continues to make the country an earthquake hotspot. Geologists have
2
identified the region as due soon for a major earthquake, putting millions of people in danger
and the nation’s fragile economy at further risk. Kathmandu sprawls over the soft sediment of
an ancient lakebed and is surrounded by mountains. This combination can magnify seismic
power by ten times. But the problem magnifies due to haphazard settlement in the valley and
lack of enough infrastructures to cope with the post-earthquake difficulties.
While working on disaster risk reduction in Nepal, considerable amount of effort must be put
on Kathmandu Valley because it is vulnerable as well as overpopulated. The post-earthquake
crisis in Kathmandu Valley is expected to be tragic as the capital city of country is at most risk
to major earthquake and also is compared to Haiti to its geographical vulnerability [6].
Quantitative estimates of potential losses that may be caused by future great earthquakes along
the Himalaya suggest that as many as 150,000 people may die, 300,000 may be injured and
typically 3,000 settlements will be affected in a single event. One of the major problem and
reasons to hundreds of deaths regarding these disasters is lack of proper coordinated activity of
relief and rescue services to disaster affected areas[7].
But the citizens living in the valley are not in risk of earthquake only, but other minor disasters
such as landslides, accidents and flash floods. In Nepal most lives have been claimed by
disasters that are localized and affect small area[8]. These disasters also have to be managed
irrespective of the scale of damage. In this project, we have worked on developing a system
that can help in coping with disasters likely to occur in Kathmandu Valley.
1.1. Background Kathmandu valley is prone to disasters of various kinds. Earthquake is the major threat to
civilians inhabiting in the valley. However, disasters such as landslides, flash floods and
accidents have also caused damages in the past. Regardless of the form of disaster, Kathmandu
Valley needs a system to respond immediately after a disaster. Preventive measures are
necessary, but since some disasters are not preventable, focus has to be on how to minimize
the risk, how to rescue victims, how to make people aware of the damages that can happen,
how to react when a disaster occurs and how to save their own lives. Undoubtedly, rescue
teams, emergency services and rehabilitation infrastructures have to be developed. But the real
problem that is faced immediately after a disaster occurs is that the service providers are not
able to assess the information about where the tragedy occurred, where the victims are trapped
and where the safe spots are.
3
Emergency services such as ambulances, fire brigades, police force and rescue team have to be
stand-by in case of any sort of disaster. Even though the physical damages caused by the
disasters can be mitigated by using some measures, the actual damage that needs to be reduced
is the loss of human life. So, during and after any sort of disaster, the primary focus should be
given to reducing human casualties, rescuing the trapped victims and providing medical aid
and basic life required to the displaced people. The tragedy with even well-to-to nations is that
the rescue services cannot reach the actual area where the victim is. So, we developed a concept
where this problem can be effectively solved. But this is relevant only when the emergency
services are well functioning and efficient.
As of February2014, the percentage of telephone users in Nepal has increased to 86.82% and
the internet users has increased to 30.70% [9]. The penetration of communication technologies
is getting stronger in Nepal platform is a widely used platform today because smart phones are
very popular and the user base is large. This is an open platform used by developers to develop
applications that are useful to not only themselves but to the whole community. Based on a
study conducted in Bangladesh about use of wireless mobile technologies in disaster
information system, it can be said that mobile technology can be used to disseminate warnings
prior to the disaster and disaster information and alerts later on which can be used to receive
information about relief needs and requirements[10]. A lot of applications have been developed
and used in smart phones and they have been useful enough to cope with daily life problems.
More than 43% percent of smart-phones now have android OS in them while another popular
mobile platform iOS falls behind only by a few with the statistics of being on one in every five
phone i.e. twenty percent[11]. From entertainment to education and from business to
humanitarian activities, the usefulness of android applications has been proved already. So, we
in this project have tried to use this platform for the purpose and hence reach a huge community
of android users.
Location Based Services (LBS) is a recent concept that denotes applications integrating
geographic location with the general notion of services. Extraction of location information of
users carrying GPS embedded cell phones and connected to the internet through GPRS or Wi-
Fi can be useful in providing users with numerous services that require their locations. Here,
we have worked on the development of such a location based service that assists in disaster
risk reduction, preparedness and management. The exploitation of location information of the
4
people (especially victims), a reliable map of the city and use of cellular services enabling
internet connection (gprs, wifi, etc.) can be integrated to produce a system enabling victims to
broadcast their position and call for help as well as the emergency service providers to reach
that spot through the shortest route. We also aim in enabling the trend of collaborative
information sharing for disaster management in the system. It means that instead of relying on
a single source and uploading data from a single source we aim to enable the mass to upload
data themselves confirm the uploaded data or dismiss it. We have named this system “Disaster
Aid”.
1.2. Problem Statement Disasters are problematic all around the globe. Since most of the disasters are inevitable and
out of control of humans, prevention of disaster occurrence is not the solution. Accepting
disasters as the part of life, we need to start thinking about how to solve the problems occurring
after a disaster, minimize the damage and stay safe.
Kathmandu Valley faces risks to disasters due to its geographical situation, unplanned
settlements and rapid urban growth. The problem while dealing with disasters such as
earthquakes in Kathmandu is that there is lack of sufficient and efficient emergency services.
Emergency services such as ambulances, fire brigades, first aid teams, rescue teams and police
force will not be enough to handle the damage caused by large scale disasters.
But even when these services are expanded, made efficient and enough, the next challenge will
be on how to reach the victims. The information regarding where the disaster occurred and
where the victims need rescue will be necessary in order to deliver emergency services.
The ongoing measures adopted by the government and other agencies working on the field of
disaster resilience are focused either on restructuring/ retrofitting the vulnerable buildings and
extending medical/ first-aid services or on making people aware of how to react when disasters
occur, how to be safe and how to minimize the risks. Even though these are essential
components in the process, a more concrete and reliable system that has been built by
considering the post-disaster scenario is a primary need.
Simply making people aware will not be sufficient, there will always be victims who have to
be rescued. They should be made familiar to all the tools and techniques that they will have to
use when they need emergency services.
We have developed a tool that assists in the post disaster scenario by providing the emergency
service providers with the information about where an incident has occurred and where they
need to reach. Hence, this application will fill the gap between victims and rescue providers.
5
But we also tend to develop a habit in people that makes them keep updated about disaster
occurrences and report about disasters they have witnessed. This means that by the use of this
application, a culture of taking part in disaster resilience as a collective mission will start. So
this application will not only be a technical tool providing user location but also a tool for
spreading awareness and enabling collaborative approach in disaster resilience.
Also, there are several types of disasters that cause damage to life and property every once in
a while inside the valley. Not only should the valley have a system of managing risk due to
earthquake, but it must plan something to reduce the damage due to other disasters as well.
This application can help in managing the risks caused by all sorts of disasters.
1.3. Objectives The main objective of this project is to develop a system of communication between victims
and rescue service operators/ non-victims in a post disaster scenario enabled with reporting and
notifying systems.
To achieve the above objective, we have worked on the following sub-objectives:
1. To design and develop a database to store relevant information (user information,
disaster details, hospital locations, etc.)
2. To create a system of communication with server containing database
3. To build a system enabling users to report, view map and call for emergency help
through their mobile devices
4. To design a user interfaces (android and web) for users to interact with the system
5. To design and implement a proper administrative component able to manage the
database, users and map visualization.
1.4. Scope of Work As mentioned in the objectives section, the objective of this project is to develop an android
application that serves as a means of communication between victims and rescue service
providers after a disaster strikes. Along with that, creating a platform for collaborative disaster
risk management is also what we have targeted. To meet these objectives in the allocated time
and resources, we have defined some scope of our work.
The application has been developed in the android platform meaning that it cannot be run in
other platforms. Mainly iOS users will need a separate version of the application. So, the scope
of our application is limited to android users only.
6
Another scope that has been defined beforehand is that we are working on disaster resilience
for Kathmandu Valley. So, the application is able to work properly only inside the valley. This
is because we have used the map data of the valley only and locations outside the valley will
not have map loaded in the mapview activity in the android application.
OpenStreetMaps has been used as the source of map. So, the details available in
OpenStreetMaps are only visible in the map of the application (along with the additional data
that the application visualizes by overlaying in the map).
The application intends to serve as the medium of communication and it must be understood
beforehand that it does not directly deploy emergency services to rescue victims. There is the
need of another system that actually uses the information that this application provides and
deploys the services.
Also, there are only some categories of disasters provided as options for the users while
reporting. But a new category can be added by the admin. And even though there is a
mechanism for validating the reports (by the votes of other users) the system is not controlled
by the admin. So, the reliability of the data has been left on the users themselves hence
encouraging a collaborative approach.
1.5. Report Outline This report consists of five chapters:
Chapter 1: Introduction
This chapter introduces the project. It also outlines the objectives of the project as well as its
scope of work.
Chapter 2: Literature Review
This chapter provides brief overviews of other project that could be considered similar to the
project either in its technical or philosophical or both aspects of the project. Existing projects
are compared and contrasted with our own project.
Chapter 3: Methodology
This chapter focuses on how the project was carried out and accomplished. It does so by
breaking down the overall methodology into multiple parts and explaining each for namely
planning, research, system development, and testing and debugging.
7
Chapter 4: Results and Discussion
This chapter shows the results that were obtained from our project. Results for each step and
each component are explained in detail. It also mentions various possibilities of the project
regarding its usage, expansion and other things under the title Future Potentials in section
4.2.
Chapter 5: Conclusion and Recommendations
The final chapter of this report outlines the conclusions drawn out from this project. It also
includes some recommendations for future works based on the methodologies, results,
limitations and conclusions of this project. This chapter also provides an insight to some
limitations of the project.
8
2. LITERATURE REVIEW
Study of similar projects that have been implemented in some countries was also done. Some
applications based on android platform were studied and their pros and cons were considered
while developing our own application. Some of the applications that we found and studied are:
Disaster Alert:
Developed by Pacific Disaster Centre, Disaster Alert is very useful, as the name suggests,
on receiving real time alerts if a disaster is about to occur. An interactive map with real
time alerts collected from authoritative sources with details such as potential threats to
people, property or assets have been included in this application. This application covers
global Earthquake, floods, Tsunami, Volcano, Storm, Marine and even human induced
disasters.[20]
FEMA:
Developed by Federal Emergency Management System (FEMA) under Department of
Homeland Security, United States, FEMA is an android application that has been useful for
the purpose of managing the crisis during and after disaster occurrences. It assists the
government on getting information regarding where and how severe disaster has occurred
Figure 1- Disaster Alert Home Page
9
so that emergency services can be deployed. Along with that, FEMA delivers tips on how
to stay safer during disasters, what to do when disaster strikes and how to prepare for the
worst. Emergency meeting locations are also provided by the application. Users can call
for help in the form of emergency, basic needs and security. People also can report about
disasters along with photos of the area so that the information reaches to a large number of
people. So, FEMA is a very successful disaster application in the United States..
Natural Disaster Monitor:
Natural Disaster Monitor was developed by Dominic925. It provides real-time updates on
global calamities such as earthquake, tsunami, cyclone, floods, and volcano eruptions.
These calamities are shown on Google earth map[20]. These disasters are categorized using
colors so that the intensity of calamity can be perceived. Also, they can be sorted according
to date, time, region of occurrence or type. The app makes use of the alerts published by
the Global Disaster Alert and Co-ordination System (GDACS), which is a joint initiative
of the United Nations Office for coordination if Humanitarian Affairs (OCHA) and the
European Commission[20].
Figure 2- FEMA app home page
10
The study of these applications helped us plan better about what a disaster risk management
application should have and what makes more useful. We have incorporated disaster
category, maps, reporting system, routing facility, emergency service request facility and
the system to validate the reports through crowd sourcing.
Limitation of Existing Systems
These systems are well developed and popular systems that are useful in their own aspects
and have been useful for people. However, they have some limitations of their own that we
hope to overcome with Disaster Aid.
a. These system are admin controlled rather than crowd-sourced which means that there
is a single entity behind the application that provides all the required updates to the
application.
b. These applications are mainly designed to provide information to public such that they
can help themselves rather than give means to public to request services or actions.
c. Most apps offer little to no level of user interaction or even provide a means for the
crowd to suggest any new incidents that have occurred.
Figure 3- Natural Disaster Monitor app home page
11
3. METHODOLOGY Our overall methodology consisted of following phases:
3.1. Planning Before conducting any sort of task or project it is essential to plan out a strategy in which to
proceed and what to include. We had to plan all the content in order to proceed to research. In
planning phase we determined the rough sketch and outline of the front and backend of the
system. We produced a solid idea of what our application and website would be like and what
would it be able to do. We also planned on how we were going to test our project and what sort
of devices we needed for those purposes.
Our initial plans of how the system would work was based on how the users would interact
with both android and web application. The plan was to create an android application and a
web application that users would interact to which would load map data from same dataset and
same server which would be backed by a database.
Figure 4- Activity Diagram
3.2. Research Research was done throughout the project duration. We have spent considerable amount of
time consulting the published documents so that we could get a proper direction for our project.
Research was done on different topics; disasters, rescue and management, ongoing practices,
similar projects, android platform, application development, designing, database, etc.
According to the nature of information required, we have referred to different types of
documents such as books, tutorials, videos and research papers. Newspapers and online news
portals have helped us decide what the requirement in the context of Nepal is.
12
During the development phase, we had to find suitable libraries that we could use as well as
recognize and fix bugs that arose during the development and testing of the system. Internet
has been the biggest help to us during this project. It has grown over the years to include almost
everything within its grasps. There is even a popular saying among internet users that goes as
‘If you can’t find something on the internet, then you didn’t look hard enough’. Despite all the
criticisms for any public and crowd sourced websites,www.stackoverflow.com proved to be
one of the most useful sites that provided information on development and debugging issues
and their solutions. Direct communication with knowledgeable people who are experts in the
field through telephone and over social media was another active method of research for
improvements of the system.
3.3. System Development Our System Development phase can be broken down further into following parts:
3.3.1. Database Creation
Among various other database management systems available in market such as MySQL,
SQLite, Microsoft SQL, Oracle, MS Access, PostgreSQL etc. we have used PostgreSQL in our
system. We are inclined towards the use PostgreSQL as it is free, has cross-platform support
and is widely supported by various programming languages[12]. In order to work with
PostgreSQL we choose PgAdmin III as our choice of the frontend. We obtained our copy of
PgAdmin III legally for free from www.pgadmin.org website. The database appropriate for our
system has been designed and developed using the above mentioned software. The tables were
created by writing SQL and using the PgAdmin III interface.
3.3.2. Server Backend Development
In order for the system to run a server is required. But, simply having a server is not enough.
We need a mechanism for the devices that are connected to the server to be able to
communicate with it. For this, we need to create a backend that provides us with the proper
functionality that we need.
Following freely available tools were used in this process:
13
1. XAMPP: XAMPP is a free application available to download at
https://www.apachefriends.org/ . It was used to run/emulate and configure APACHE
server on our pc which enabled us to supply files and services through the server.
2. Notepad++: Notepad++ is a text editor and source code editor for Windows. It is free
software and is available publicly for download at http://notepad-plus-plus.org/ .It was
used to write all of our scripts.
3. Google Chrome: It is a web browser by google. It was used to test and debug the scripts
that we were creating. It is also free and can be freely downloaded from the following
website https://www.google.com/intl/en/chrome/browser/ .
4. Mozilla Firefox: It is another web browser that was used for the same purpose. It is
also free and can be downloaded at https://www.firefox.en.softonic.com/download/ .
For the project an APACHE PHP server was used since coding was done in PHP language in
server side scripting. In order to run the server we used the application XAMPP. Once XAMPP
was installed we used Notepad++ to write scripts in PHP language. The written scripts were
then saved inside a folder within “htdocs” folder produced with XAMPP installation.
The server backend is designed to take in POST requests from clients and returns data in JSON
format or GEOJSON format. POST method was preferred over the GET method as it is more
secure. JSON string is a data definition language (DDL) that can easily depict objects and its
properties while being easy to understand. GEOJSON format could be called an extended
theme of JSON format where there are set fixed components that makes processing it easier. A
standard GEOJSON string looks like[13] :
{ "type": "FeatureCollection",
"features": [
{ "type": "Feature",
"geometry": {"type": "Point", "coordinates": [0.0, 0.0]},
"properties": {"name": "point1"}
},
{ "type": "Feature",
"geometry": {"type": "Point", "coordinates": [10.0, 10.0]},
"properties": {"name": "point2”
},
}
The clients call proper PHP script in the server and supply them with data using POST method.
The server side script then processes the request and then collects the data that is supplied by
14
the client along with the request. The script then as requested fetches desired data from the
PostgreSQL database. It does so by running a SQL to the database management system which
provides it with the data as resulted by the SQL query. Then, the data that is obtained from the
database is formatted into a JSON string or a GEOJSON string as required. The resulting string
is sent back to the client who made the request.
The web browsers, at this point, were used to supply dummy request and supply false data to
see if the proper response was obtained from the server backend.
3.3.3. Website Backend and Frontend Development
We have created a user-friendly website that focuses on the map and the information it conveys.
The frontend of a website is the interface provided by the website that users interact with
whereas the backend of the website is the core workings of the website that works in the
background to supply data to the frontend. Multiple files were for each components of the web
application to make the site more modular and easy to edit and update. External libraries, that
were used, were downloaded and referenced from the scripts. Graphics and icons were created
for the web application.
The website was written using following languages
PHP: PHP language was used to control server side processing of the website. For e.g. not
to supply admin privileges to general users, etc.
JS : JS was used to control client side processing of the website. For e.g. display reports
when corresponding button is clicked, etc.
CSS: CSS was used to write style definitions of the webpage. It defines the looks and styles
of the frontend of the website.
In order to develop the website the following software were used:
XAMPP
NOTEPAD++
Google Chrome
Mozilla Firefox
Photoshop CS6: Photoshop is an advanced image editor and creator software. It was used
to create icons logos and animated gifs for markers for the map. It was preferred to its
alternatives like Paint tool SAI, MS Paint, etc. because of the familiarity to the software
and its level of easiness in creating animated graphics.
In order to develop the website the following libraries were used
15
Bootstrap 3: Bootstrap is a free collection of tools for creating websites and web
applications. It is a free and open source project initiated by twitter. It basically provides
us with JS and CSS for various UI components that we could use simply by copying those
and tweaking them to our needs. Some components in our project were built using the
bootstrap 3 framework.
jQuery: jQuery is an open source JS library that simplifies the client-side scripting of
HTML. It allows us to dynamically insert and delete HTML components and also perform
AJAX requests.
AJAX: AJAX is a group of interrelated Web development techniques used on the client-
side to create asynchronous Web applications. With Ajax, web applications can send data
to, and retrieve data from, a server in the background without interfering with and/or
lagging the display and behavior of the existing page. This enables us to refresh contents
of a webpage without actually having to refresh the whole page or having to move to
another page.
Leaflet: Leaflet is an open source JS library for building web mapping applications. It is
the framework that we used to display map on the website.
Charts.js: Charts.js Is an open source JS library for building interactive charts and graphs with ease.
Mapbox API:Mapbox is a website that works gives us WMS as well as WPS to some extent.
In this website we have used Mapbox API to get both map tiles for leaflet as well as routing
services. It is free service and that helps us too.
Google geocoding : Google’s geocoding API was used to convert Latitude and Longitude
to its corresponding place name to display in report’s detail descriptions.
3.3.4. Android Application Backend and Frontend Development
As the main intention of the project we have created an Android Application for the project.
The frontend and the backend of the application are both centered on the location of the user
that is supplied to the phone via its sensors. Required external libraries were downloaded and
added to the build path. Multiple activities were created. The graphics and icons used on the
application were created and added to the resources. Offline hospitals data was acquired and
added to the resources. Offline map data was acquired and since its size is big it was made
available to download instead of bundle it with the application.
The application was written using following languages
16
1. JAVA: JAVA programming language was used for both frontend and backend of the
android application. While the backend completely relies on JAVA coding, it is only used
to make the UI dynamic in case of frontend.
2. XML: XML was used to define layout and properties for the android application. Static UI
were all defined using XML.
In order to develop the android application we used following software
1. Eclipse: Eclipse is an IDE that works well with JAVA programming language. It has
extensions available for android and even comes bundled with ADT. It is freely available
from www.eclipse.org/downloads . The major reason for our decision to use it among its
alternatives such as Netbeans is our familiarity towards the IDE and the fact that it came
bundled with ADT and SDK as well.
2. JAVA SD : JAVA SDK or simply JDK is required for developing any application using
JAVA programming language. And since android development uses JAVA language, the
SDK is a must. It is available freely at the web site
www.oracle.com/technetwork/java/javase/downloads/index.html .
3. Android SDK: The Android SDK contains core library files for the android application that
provides us with functions and classes for development purposes. It works with the ADT
extension in eclipse. Android SDK installation gives us with SDK manager from where we
can download the required packages. The packages that we require are Android SDK
platform tools, SDK platform for desired API level (the higher the better) and Google API.
Following external libraries were used to develop the android applciation
4. Mapsforge Library: It is an android mapping library that enables us to render and view
maps offline[14]. It uses a .map file to display a map. The Mapsforge library can be
downloaded from https://code.google.com/p/mapsforge/wiki/ . However this does require
for a .map file to be present in local drive to display the map. For the area we are using i.e.
Kathmandu,
5. Graphhopper Library: Graphhopper library is an android library that enables us to get
routes from one point to another without being online[15]. We can get the Graphhopper
library from https://github.com/graphhopper/graphhopper . However, it also requires a set
of files to be present inside a folder in the local drive of the device namely edges, geometry,
locationIndex, names nodes and properties in order to be able to display the route offline.
For our area the net size sums up to about 6mb.
6. SLF4J Library : SLF4J is a library for logging systems allowing the end-user to plug-
in the desired logging system at deployment time. It is used by most android external
17
libraries such as MapsForge and is required[16]. It can be downloaded from
http://www.slf4j.org/download.html .
The application consists of various activities for various purposes
1. SplashScreen: It is the screen which literally doesn’t do anything, it just waits for a tap
from user to proceed to the next screen. It is placed to keep the project’s introductory picture
2. LoginActivity: It is the screen that is used to login into a user account by the user.
3. RegisterActivity: New users can register in this screen.
4. NewsFeed : It is the screen where new reports close to a user are shown to the user.
5. MapScreen: It is the screen which shows map and reports along with hospitals on the map.
6. ReportScreen: It is the screen in which users can submit new reports.
7. DetailScreen: It is the screen which shows details of the report that was clicked by the user.
8. Emergency: This screen only opens/triggers when a user has submitted an emergency
request but the device’s GPS cannot get a location. It just waits until it gets a fix on the
device’s location.
The application also consists of other classes that were created to help in aiding the application
1. POI: This class was created to store location information of points to help in creation of
markers.
2. Receiver: This class was created to make sending HTTP requests to server simple and easy.
In order to make this action work in the background and not lag the user UI, this class
extends the ‘AsyncTask’ class and overrides its native ‘doInBackground’ and
‘onPostExecute’ methods.
3. WidgetProvider: This class was created to in order to configure the working of widgets of
the application.
3.4. Testing and Debugging Testing and debugging are integral part of any software development. In most cases testing and
debugging goes hand in hand with the development/coding process. In our case as well most
of our testing and debugging was done during development phase. However we also tested our
system after the development of the system was complete to ensure that no further bugs arose
and that the system could handle multiple requests.
Our testing of website was done on following browsers
1. Google Chrome 36
2. Mozilla Firefox 32
3. Internet Explorer 11
18
The debugging was done mostly using Google Chrome. Its console was most used to look at
errors by logging them and identifying what we were dealing with. After the identification of
the bug, we proceeded to research on the solution and then applying those solutions. Among
the tested browsers none of them produced any sort of bugs on running the completed system.
In case of android phone, we tested the application on multiple devices
1. Android Emulator (android 4.4.2)
2. Samsung Galaxy duos (android 4.2.2)
3. Samsung Tab 3 (android 4.1.2)
4. Samsung Note 2 (android 4.4.2)
5. Samsung Ace plus (android 2.3.6)
The debugging was mostly done using Samsung Galaxy Ace Plus and Android Emulator. The
eclipse LogCat was used in similar fashion to the Google Chrome console while debugging for
website. In order to do this however, we need to enable “Developer Options” on the device and
keep it connected via USB cable while debugging. On testing on the devices we didn’t find any
persisting errors. However on testing on the Samsung Note 2 which has latest android KitKat
(4.4.2) update there was a persistent error “UnsatisfiedLinkError” which hindered the
application while route was being displayed. But on doing research, we found out that the error
only existed on the particular model with particular version of android only. Since android
KitKat is fairly new, we don’t expect the error to be resolved by Samsung anytime soon. Other
than this particular device, there doesn’t seem to be other problem.
Further testing was done by trying to submit multiple reports at once using multiple devices.
The system fared well during the test and there were no visible errors.
19
4. RESULTS AND DISCUSSION The application that we developed has been incorporated with the features that we thought
were necessary for disaster risk management. Learning from similar applications used by
other nations, we have tried to make one for Nepal that is equally efficient and useful. We
have used maps; GPS coordinates to broadcast locations, one-button click for emergency
service request and crowd-sourced system for disaster risk mitigation. We have categorized
disasters and made system of validating reports from the crowd. Also, routes from one point
to another can be acquired from the application. Nearest hospital can be known just with a
single click in the application. Even so, there are many reforms that can brought in the
application and there are a lot of potentials that it holds. In this segment, we would like to
discuss about the results that we have achieved, how they are advantageous, what the future
potentials are and what can be done in future to make this application more useful as well as
what should be done in the disaster preparedness program.
20
4.1. Results
4.1.1 Database
The design of the schema prepared for Disaster Aid looks like:
Figure 5- Database “disaster_aid” schema deign
Table-1. user_auth:
This table stores all of the user’s information. It contains of five fields
a. username: This field stores the username of the users. It is primary key so there is
no way that there could be a duplicate username.
b. contact: This field stores the contact information i.e. phone number of the user
c. user_role: This field stores the role of user in the system i.e. 1 for admin and 2 for
general user.
d. email: This field stores the email address of the user
e. pass: This field stores the password of the user
21
A new entry in this table is created every time a user registers in the system. Each row
in this table represents a user and the information is used to check while user is logging
in. Admins can create/delete/edit users from admin page.
Table-2. report_types:
This table is used to store the types of report in the system. The reporting mechanism
uses this table’s data to determine the valid dataset while submitting and/or
categorizing the reports. It consists of just one field
a. types: This fields stores the types of reports
Admins can add the types of report from admin page or into the database directly.
Table-3. reports:
This table stores all the reports that users submit except for emergency reports. It
consists of following fields.
a. Id : This field stores the id number for the report. This makes each report unique
as it is the primary key of the table.
b. username: This field stores the username of the user who submitted the report.
c. report_type: This field stores the report type of the report submitted. It is a foreign
keyreferenced to the “types” field of the “report_types” table. So it can only have
one of the values present in that field. text NOT NULL,
d. disaster_level: This field stores the level of seriousness or severity of disaster
submittedaccording to user based on their judgment and knowledge of the situation.
e. description : This field stores the description of the incident supplied by the
user. It is addition information of the incident that the users deem notable.
f. report_x: This field stores the latitude of the report submitted.
g. report_y: This field stores the longitude of the report submitted.
h. report_date: This field stores the date of the report submitted. Considering the fact
that users have different time set on their devices, this field is populated with server
date rather than receiving a date from user.
i. report_time: This field stores the time of report. Similar to date, it stores server
time.
j. correct: This field stores the amount of users that has vouched for the report to be
true to what it suggests.
22
k. incorrect: This field stores the amount of users that has vouched for the report to
be false.
l. tot_search:This field adds the values of “username”, “description”, “report_date”
and “report_time”. This field is used in making search smoother and dynamic.
A row in this table represents a table. An entry is created each time a user submits a
report either from his/her android device or the web. Admins can create/delete/edit a
report from the admin page.
Table-4. likes:
This table stores the information of who has voted on a report and whether s/he has
voted the report as right or wrong. It contains following fields.
a. rep_id: This field stores the id of the report it is associated to. It is a foreign key of
the field “id” of the table “reports”.
b. rep_user: This field stores the username of the user who has voted for the report it
isassociated to. It is foreign key of the field “username” of the table “user_auth”.
The pairing “rep_id” and “rep_user” make a composite primary key. This means
that a user can only have one entry for a report. So, users can only vote once for
each report.
c. rep_right: This table stores whether the user has voted the report as right or wrong.
It stores the information with “y” for right and “n” for wrong.
Table-5. emergency:
Like table “reports” this table also reports the information of reports submitted but
it is for the emergency reports which we classify as reports that need urgent
attention. This table consists of following five fields.
a. id : This field stores the id for the emergency report. It is the primary key and thus
uniquely identifies an emergency report.
b. username: This field stores the username for the user who has submitted the
emergency report.
c. report_x: This field stores the latitude of the location from where the emergency
report was submitted.
d. report_y: This field stores the longitude of the location from where the emergency
report was submitted.
23
e. report_date: This field stores the date on which the emergency report was
submitted. Like the “report_date” field in “reports” table it stores server date.
f. report_time: This field stores the date on which the emergency report was
submitted. Like the “report_time” field in “reports” table it stores server time.
4.1.2. Server Backend
Here is how the server backend worked portrayed in a flowchart
Figure 6- The Working of Server backend
This server backend enables us to perform various functionalities such as logging in, registering
a user, submitting reports and even visualizing reports in maps.
4.1.3. Website Backend and Frontend Development
Our website has two parts depending on the role of the user
General Section
General Section is the section of website that is accessible by every user, although some parts
are selectively displayed depending on whether the user is admin or not. The complete
workings of the home page can be depicted by the following flowchart.
The flowchart show the various processes and options associated with the homepage within
rectangle with rounded corners-The arrow shows the flow of the program. Solid lines mean
that the flow remains within the page whereas the dashed arrow means that the content is being
pulled using AJAX request to the server and dotted lines mean that there is navigation to a
different web page
24
Figure 7- Flow diagram of home page of the website
The UI of the website is highly user-interactive as users will be able to open and close small
boxes that display details of reports, report feeds or form to submit a report.
The interface, as soon as the page loads completely, looks like this
25
Figure 8- UI of the homepage
This is the screenshot of the webpage when the user is logged in as “ban” who is an admin.
Here if s/he presses the “View Reports” button on the navigation bar then he opens a box with
latest reports in it. Here is how it looks
Figure 9- UI of homepage: news feed box opened
Similar happens when “Report New” is pressed, which greets user with a form to submit new
report. A detail box appears when a report from the list is clicked or any report icon or hospital
icon on the map is clicked. These boxes can be moved within the browser window as much as
desired. This gives users the freedom to view any information they want to view within the
window how they want. This can be seen on the figure following where the report box has been
moved from left side as in above figure to the right side.
26
Figure 10- UI of homepage: UI shuffled
Next, when the user presses on his/her username, which in this case is “ban”, he gets a
dropdown menu a list of options. Since “ban” in this case is an admin, he will get admin
options too which navigate away from current page to the admin page.
Admin Section
Admin Section is the section of website that is accessible only by admins. Admin section
consists of multiple pages.
1. Summary page: The summary page has a navigation page that is common to all four
pages that open their corresponding pages. Then there is an inner navigation pane that
helps us navigate within the page. In this case it links us to their corresponding section in
the main content section. There is an option to add/delete report type in the page from
where we can add new report type or add a new report type.
2. Manage Users Page: This page is for admins to manage the users of the systems. Here
people can delete or edit user information. First the page fetches users from the database
using AJAX request and then populates it in a list form. When a user item is pressed/
clicked, its corresponding information gets populated in the form that is in the main
window. The information can be updated or deleted from there
3. Manage Reports Page: This page is for admins to manage the reports of the systems.
Here people can delete or edit report information. First the page fetches reports from the
database using AJAX request and then populates it in a list form. When a report item is
pressed/ clicked, its corresponding information gets populated in the form that is in the
main window. The information can be updated or deleted from there
27
4. Manage Emergency page: This page works same as the above two pages by getting
emergency reports from the server and populating in a list. We can update or delete it as
well.
The complete workings of the admin pages can be depicted by the following flowcharts.
28
Figure 11- Flow diagram of admin page (1)
29
Figure 12- Flow diagram of admin page (2)
30
The interface for the four pages, looks like this
Figure 13- UI of admin page to view summary and manage report type
This page shows graphs of stats related to reports of the system. There is a side pane that is
common to all the four UI that works the same way for all the four pages. Then there is the
inner navigation pane that in this case lists a number of section with links that navigate users
to the section it is linked with. Here, an admin can add or remove a report type as well.
Figure 14- UI of admin page to manage reports
This page is for managing reports of the system. This page has the common navigation bar to
the left. Reports are listed in the inner navigation pane where one can search for a report as
well. Once an admin selects a report, the form in main section gets populated with information
31
along with chart that how many people have voted the report right and how many have voted
wrong. One can perform changes and update/delete the user.
Figure 15- UI of admin page to manage users
This page is for managing users of the system. This page also has the common navigation bar
to the left. Users are listed in the inner navigation pane where one can search for an user as
well. Once an admin selects a user, the form in main section gets populated with information
along with chart that shows his/her contribution to the system. One can perform changes and
update/delete the user.
Figure 16- UI of admin page to manage emergency reports
32
This page is for managing emergency reports of the system. This page also has the common
navigation bar to the left. Emergency reports are listed in the inner navigation pane where one
can search for an emergency report as well. Once an admin selects an emergency report, the
form in main section gets populated with information. One can perform changes and
update/delete the emergency report.
4.1.4. Android Application
The following chart shows us how the activities of the application move from one to another.
However the following flow diagram does not show how each activity flows within itself.
Figure 17- Flow of Activities in the Android Application
Each activity works differently and for different purposes. It can be seen below
33
SplashScreen
As mentioned before this activity does not do anything except for waiting for the user to interact
with the application. It is shown as soon as the user opens the application. It does however
checks if the user is logged in or not. If the user is logged in it sends the user directly to the
NewsFeed whereas if the user is not logged in then it sends the user to LoginActivity. If the
users press back button from here, they can exit the application.
The flow of the SplashScreen activity can be seen below
Figure 18- Flow diagram of SplashScreen Activity
The UI of the splash screen is simple and doesn’t contain of any buttons or require any complex
interaction from user.
34
Figure 19- UI of the SplashScreen
LoginActivity
It is the Screen that allows user to login to the system. It provides users with two boxes to input
their username and password and three buttons to login, login as guest or register. The logging
in occurs as the android application sends the information to server which check if the username
and password match. If they do, user gets logged in. Logging in as a user or a guest takes the
user to the NewsFeed whereas trying to register takes the user to the RegisterActivity. If user
presses back button from here, they can exit the application. Once user logs in in the android
app s/he doesn’t need to log in again till s/he logs out or clears data on android.
The flow of LoginActivity can be seen below
35
Figure 20- Flow diagram of LoginActivity
The UI of the LoginActivity consists of a form to input user’s username and password along
with buttons to login and register. There is also a button to login as guest if a user doesn’t have
an account and doesn’t not wish to register yet or if s/he simply wishes to login as a guest. The
UI is as below
Figure 21-UI if the LoginActivity
36
RegisterActivity
This is the screen where new users can get started with disaster aid by registering their own
personal accounts. It provides users with a form to fill for users that when submitted requests
the server to add a user to its listing.
Figure 22- Flow diagram of RegisterActivity
The UI of RegisterActivity, much similar to LoginActivity consists of a form to fill in by the
user and a Register button to complete the registration.
37
Figure 23- UI of the RegisterActivity
NewsFeed
It is the screen which is served to the user right after s/he logs in the android app. This screen
consists of a list where all the reports within 5km of the user location are fed to the user ordered
according to which one is most recent. It also displays the username of the user who is logged
in, his/her contact information and email at the top left and an option to logout right below it.
For users who logged in as guest, it just displays “guest”. There are three buttons on the right
side which take users to different screens. MapScreen. Report takes users to the ReportScreen.
Emergency takes users to the Emergency activity. Furthermore, clicking on any item on the list
takes users to the DetailScreen with corresponding information supplied. On clicking back
button on the device on this activity the user is greeted with a prompt of whether s/he’d really
like to exit the application. If the user presses yes, the application exits.
38
Figure 24- Flow diagram of NewsFeed
The UI of NewsFeed consists of two parts one upper area with user detail and buttons and the
other lower area with list that displays details of the reports from the server.
The UI of this activity on an android device looks like
Figure 25- UI of the NewsFeed (logged in)
39
Figure 26- UI of the NewsFeed (not logged in)
MapScreen
It is the screen where the whole screen area is covered by map. This activity focuses on
portrayal of reports on the map. The map is rendered offline using “Mapsforge” library which
uses the corresponding .map file to load the map data. It requests data about reports and
emergency reports from the server. The received data is shown into the map using their location
with markers. There is also a JSON file in the package that contains the information about
hospitals which is shown in the map as well. This activity takes user’s location and adds a
marker as well. In case that the activity receives two points as initial intent extras, Graphhopper
is used to get route between them which is added to the map in red colored line. One can press
the H button on the right to get the nearest hospital from him/her. Other than that pressing on
any of the markers except for the user marker takes the user to the DetailScreen where
information about what the user tapped on is displayed.
40
Figure 27- Flow diagram of MapScreen
The MapScreen activity has very minimalistic UI with almost no buttons at all the whole
activity is covered with map and it is what users will interact with. There is an exception
however, users have a button H to get the closest hospital to them. Here the bright red dots are
emergency reports. They are made bright red so that the icon contrasts with the map in the
background to attract focus of users to the emergency reports. Other incidents have similar
circular markers with letters within them and color-coded to fit them best.
41
Figure 28- UI of MapScreen
ReportScreen
It is a simple activity that is used to submit new reports by users. The activity provides users
with a form that users can fill in and submit. Users can manually give Lat Long to the field or
the activity simply listens to the GPS signals to update the Lat Long field itself. The form when
submitted sufficiently and correctly will submit a request to the server which in turn will add a
report to the database. After the report is successfully submitted, the activity sends users back
to the NewsFeed screen.
42
Figure 29- Flow diagram of ReportScreen
The report screen provides users with a form where they can fill out the fields according to the
incident. The latitude and longitude fields do not need to be filled manually as they fill
themselves when the device gets a location. The UI looks like this
43
Figure 30- UI of the ReportScreen
DetailScreen
It is the screen which shows details of the report that was clicked by the user. The information
about the report is extracted and displayed accordingly on the screen. It provides the option of
voting the report right or wrong to the users who are logged in. It first checks whether user has
already voted and if the user has already voted, it prompts the user if he would like to delete
the existing vote to cast a new one. After the existing vote has been deleted, user can vote again
to cast a new vote. There are also two direction options that send users back to MapScreen
requesting direction between two points. First button gives users direction from their location
to the incident, whereas the second gives users direction from the incident to the nearest
hospital.
44
Figure 31- Flow diagram of DetailScreen
The UI of the screen differs slightly on whether the user is logged in or not and also whether
the call is being made to display detail of reports or hospitals. Non-users won’t have the option
to vote while when viewing hospital detail, there won’t be a button to get direction to nearest
hospital.
2
Figure 32- UI of the DetailScreen (logged in)
Figure 33- UI of the DetailScreen (notlogged in)
Emergency
As mentioned before this screen only opens/triggers when a user has submitted an emergency
request but the device’s GPS cannot get a location. It just waits until it gets a fix on the device’s
location. Once it gets a fix on the device’s location it calls the server script that adds an
emergency report to the system using the location supplied by the device. This screen can be
opened from the widget as well as pressing the Emergency button on the news feed.
3
Figure 34- Flow diagram of Emergency
The UI of the Emergency activity is the most simple of all as it doesn’t demand any sort of
interaction at all and stops only if location is unavailable. So it just tells us to open our GPS.
4
Figure 35- UI of the Emergency activity
Widget
Besides the activities mentioned above another part of the application is the widget. A widget
is a mini application directly accessible on the home screen of the android device and that runs
all the time that it is added. The widget in our case consists of a button. The widget constantly
listens to the location provided to the devices and sends users to the Emergency activity one
users press the button on the widget. Then as mentioned under Emergency sub-section before,
the location is used in submitting an emergency report to the server. By any chance, if the
widget cannot supply the Emergency activity with location then there is nothing to worry as
the Emergency activity will itself wait for a location before submitting.
The flow of the widget can be shown as
5
Figure 36- Flow diagram of Widget
The UI of widget as mentioned before consists only of a button. It looks like
Figure 37- UI of the android widget
6
4.2. Future Potentials: As discussed before, the application that we have developed carries a lot of potentials. We have
tried to incorporate a simple yet sophisticated system, design easy to use interfaces and develop
a proper administering component that can manage reports and users, analyze them and deploy
the requested emergency services. There is a potential that a huge user community shall be
formed that will take part actively in handling the disaster induced risk management in its
geographical proximity. This community will be assisting the authorized agencies by providing
the most valuable resource: information.
Another potential of this application is that people will start taking part in managing disaster
hazards to some extent themselves. Our society comprises of all sorts of people, some skilled
and others non-skilled. No matter what, everyone can help in the collaborative effort to mitigate
the damage after disasters. People can start rescuing others if they can. If not, they will call for
help. Everyone is a volunteer during crisis. Voluntary groups, first-aid trainees as well as
people who want to help can use the information that the application disseminates and take
part. The mindset that only the responsible agencies should manage post disaster hazards will
slowly fade away, replaced by the collaborative mindset that everyone should help everyone.
Another potential that this application carries is that it can be used as a means of spreading
awareness. The dos and not-to-dos during disasters can be conveyed to the users, who can then
disseminate that message to others around them. Documents can be disseminated through the
application so that every user has them in their pockets which will ultimately spread out to
others who may not use the application.
The Android application “Disaster Aid” is capable of fulfilling the gap between victims and
non-victims/ rescue service providers after a disaster has occurred. It can serve as the bridge
between those who need help and those who want to help. It can provide the vital information
regarding the location of the victims to the emergency service providers so that efficient
service delivery to the right place is possible. Also, the use of this application tends to spread
awareness among the users that disasters are likely to occur anywhere and thus be prepared
with as much resources as possible.
7
5. Conclusion and Recommendation
5.1. Conclusion During the span of this project, we encountered some difficult situations and had to deal
them with patience and persistence. The force dragging us during those situations was the
feeling that we have been building something that can be of real use to the society. The
motive itself has been the greatest motivation for us. And we are glad that we have been
able to meet the initial target and build a system, efficient and reliable enough, to actually
contribute to the society.
The culture of taking part in the mission of disaster resilience is likely to be developed
when this application is used. The application builds a habit of checking the news related
to disasters, being updated about the nearby incidents and reporting about the disasters that
one has witnessed. Hence, every user will be a respondent in the system, everyone will be
supporting the system, and everyone will be helping everyone. A collaborative system of
disaster risk management is likely to emerge if this application is incorporated as an
element of the national disaster resilience system.
But we have always believed that this is not the completion of the mission, but a
milestone achieved. The mission is to build a system that can be integrated with the
national plan for disaster resilience so that communication with both the victims and the
rescue service providers is possible. This is possible only after a higher level of solidarity
among all the stakeholder agencies that have the mission of mitigating the damage due to
disasters. We look forward to being a part of that alignment for disaster resilience.
Considering all the future potentials that the output of this project bears, we are delighted
to have worked on such a project under such cooperating institutions and individuals. We
also express immense desire to work on similar projects in the days to come.
5.2. Limitations We have developed an android application that can help users call for emergency service,
get user reports regarding disaster occurrences and assist the administering agency in
deploying emergency services, analyzing the trends and statistics and hence planning
accordingly.
But there are some limitations in the application. First of all, it has been developed in the
android platform. This means, the application shall not run in any other platforms. Only
android device users will be able to report disasters or call for emergency rescue.
Secondly, the base map that we have used is OpenStreetMaps which is an open source map
developed using collaborative approach. This means, OpenStreetMaps relies on the mass
8
contributors for its completeness and reliability. The map can be incomplete and erroneous
in some parts. Thus, error in the map that this application renders will be the same as that
in OpenStreetMaps.
This application extracts the location of user from the GPS in-built in his/her phone. Since
there are several factors controlling the error in GPS coordinates, we do not assure accuracy
the coordinate. The coordinate of user will surely have some errors depending on the
environmental conditions and other factors inducing the GPS errors. Our application will
not alter the coordinate extracted from the phone GPS. The application will also use
network location in case GPS location is unavailable but it is even less accurate than GPS
under normal circumstances.
This application is a tool that can collect information regarding disasters so that hazard
reduction measures can be undertaken. But this doesn’t mean that we can assure the service
delivery as per emergency requests. This responsibility shall be handed over to an
administering agency (perhaps a stakeholder agency in disaster resilience) willing and
capable enough to respond to user requests and administer the reports and users. We do not
want to raise expectations by making people believe that the guarantee of their lives and
property is assured once they use this application.
This application will not be able to deploy services like ambulances, fire brigades and
police force because they are the services in control of the government or the private sector.
We have not incorporated the system of forwarding notifications to emergency services
leaving that responsibility to the above mentioned agency. The application will only send
reports, locations and other descriptions fed by users to the administering agency.
Since we have focused on the Kathmandu Valley for the project, we will be limited only
inside the valley. The map tiles of the valley will only be loaded, so the application will not
work outside the valley, partly because the map tiles have not been loaded or the
OpenStreetMaps is well developed outside Kathmandu.
5.3. Recommendations At the end of the project, we have accomplished the initially set objectives. But the project
itself will not be complete unless the application will be brought to use by some authorized
agency working on the field of disaster resilience. It will always be a privilege for us to
bring the application into use.
9
But bringing it into use may require some adaptive alterations in the application. We look
forward to cooperating with the stakeholders so that necessary additions can be
implemented.
Several features can be added to the application which we could not due to time bounds.
But there are lots of features that when incorporated into this application can make it more
useful. We ourselves want to work on adding those features, but interested agencies or
individuals can work in similar projects and contribute in the cause.
We also want to recommend that disaster resilience should not only be carried out by
spreading awareness or collecting data but working on how to mitigate the hazards. This
preparedness comprises of development of both infrastructures and system of assessing the
victims’ situations. Mere collection of data and analysis will only help in planning not on
actual hazard management. Mobilization of emergency service providers will help
10
6. REFERENCES
1. Network-Nepal, D.P., NEPAL DISASTER. 2. Dilley, M., Natural disaster hotspots: a global risk analysis. Vol. 5. 2005: World Bank
Publications. 3. Vuichard, D. and M. Zimmermann, The Langmoche flash-flood, Khumbu Himal, Nepal.
Mountain Research and Development, 1986: p. 90-94. 4. Risk, R.D., A Challenge for Development. United Nations Development Programme-Bureau
for Crisis Prevention and Recovery, New York, 2004. 5. Pandey, M., et al., Seismotectonics of the Nepal Himalaya from a local seismic network.
Journal of Asian Earth Sciences, 1999. 17(5): p. 703-712. 6. Bhattarai, K. and D. Conway, Urban vulnerabilities in the Kathmandu valley, Nepal:
visualizations of human/hazard interactions. Journal of Geographic Information System, 2010. 2(02): p. 63.
7. Fajardo, J.T.B. and C.M. Oppus, A mobile disaster management system using the android technology. WSEAS Transactions on Communications, 2010. 9(6): p. 343-353.
8. Aryal, K.R., The history of disaster incidents and impacts in Nepal 1900–2005. International Journal of Disaster Risk Science, 2012. 3(3): p. 147-154.
9. Bhandari, K. Mobile Penetration reaches 76.8% and Internet Penetration reaches 30.70%. 2014 [cited 2014 2nd June].
10. Kushchu, I., Prospects of Using m-Technologies for Disaster Information Management in Bangladesh and other LDCs.
11. Mahapatra, L. Android Vs. iOS: What’s The Most Popular Mobile Operating System In Your Country? 2013 [cited 2014 11th June]; Available from: http://www.ibtimes.com/android-vs-ios-whats-most-popular-mobile-operating-system-your-country-1464892.
12. Blasby, D., Building a spatial database in postgresql. Open Source Database Summit, 2001. 13. Howard Butler (Hobu Inc.), M.D.C., Allan Doyle (MIT), Sean Gillies (UNC-Chapel Hill), Tim
Schaub (OpenGeo), Christopher Schmidt (MetaCarta). GeoJSON Specification. 16 June 2008; Available from: http://geojson.org/geojson-spec.html.
14. team, M. mapsforge - free mapping and navigation tools - Google Project Hosting. [cited 2014 March]; Available from: https://code.google.com/p/mapsforge/.
15. graphhopper. graphhopper. Available from: https://github.com/graphhopper/graphhopper/. 16. team, S.J. SLF4J FAQ. Available from: http://www.slf4j.org/faq.html.