| Version 28 (modified by , 11 years ago) ( diff ) |
|---|
BluePrint: Augmented Reality
Table of Contents
Introduction
Our augmented reality will serve as a method of finding and recovering of people stranded, injured or in need of immediate assistance. It will serve as a real-time "map" of sorts that takes advantage of the onboard camera in smartphones/tablets. As the image is on screen it will overlay the exact location, severity and specifics of people in need. Augmented reality will mitigate the difficulties emergency managers have in finding the exact location of people in need. Augmented reality will take it a step further by giving the emergency responder exact details about the person(s) in need so that they can evaluate and prioritize based on extending factors. This will give Sahana the ability to quickly and more efficiently reach out to people in danger in the wake of a natural or man made disaster. Solutions similar to this do exist but for different purposes, spanning across education, gaming, sports/entertainment and navigation.
Stakeholders
Emergency personnel and people in or near a crisis zone. Statistics reporting and missing persons agencies will be able to more easily report on people using the app. This should simplify some aspects of rescue operations and news propagation of crises to affected peoples in modern areas.
User Stories
<http://en.wikipedia.org/wiki/User_story> <A good User Story should answer the following questions:> <* Who the user is> <* What they want the solution to do for them?> <* Why they want it to do that? (goal)> <eg. A <type of user> wants the solution to <do something for them> so that <can achieve a goal>.>
User Story 1: Search and rescue teams want to see if there are any people they might have missed in an area. They want some way for people who have working mobile phones to be able to contact them and let them know where they are. This would make their job much easier and quicker.\
User Story 2: Something something families and disasters
Requirements
<Group requirements in subsections, e.g. etc.> <http://en.wikipedia.org/wiki/Requirements_analysis requirements> <Identify different types of requirements:>
Functional
Mobile Application for personal and emergency management personnel usage. Map overlay for locations and details of emergency events.
Non-functional
This program should be able to be used as an alternative or supplement to existing emergency response services.
This program should be able to be used quickly and easily by both emergency respondents and people in an emergency situation.
Interoperability
This should be able to be integrated into existing emergency response systems such as 911 so that even if emergency personnel on-site are unable to check they can have off-site assistance in locating trouble spots.
Standards
System Constraints
Design
Timeline :
Data Model
Each situtaion that will appear in the augmented reality will be referred to as an event. Each even will contain four four categories - meta data, threat level, a photo and a brief description. The meta data will include the latitude and longitude that can be taken from the device used to update the database through the onboard sensors. Optionally, it will include the altitude (such as 4th floor, under rubble, etc) entered manually. In case of an event API. Similarly the general location can be entered for remote locations where neither a street address or latitude and longitude can be entered (such as between "x" river and "y" river). The threat level will be entered on a scale of 1 to 100 with 1 being events that need to be addressed but not urgently and 100 being events that are severely urgent and need to be addressed immediately. On the augmented reality UI the severity will be represented on the map as a color ranging from red(highest need) to green to blue(lowest need) with darker shades meaning a higher rating and lighter shades meaning a lower rating. Also, a photo should be included that shows the location of the event to give the responder a more visual notion of the location of the event. Finally, a brief description is to be included to verbal state the event. The description is to be as concise as possible (such as "broken leg, bleeding out" or "open and dirty cut, bleeding slowly").
Workflows
<Diagrams or Pseudocode>
Site Map
<for User Interface solutions>
Wireframes
<for User Interface solutions>
Technologies
Current Implementation
Under Construction.
Planned Implementation
Under Construction.
Future Extensions
Under Construction.
Outstanding Questions
How to ensure that all self reports by impacted people are real reports and not false. (Prank calls to 911 for instance)
Afterthoughts
The main implementation of this project will be on mobile devices. As an emergency responder, any use for a laptop would be to access the database and that could be done by remote connection to the database. Conversely, if a victim had access to a computer and internet access through it they would not be the time of events we are seeking to mitigate. We feel as if a website would be overkill and, frankly, a waste of resources.
