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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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.