= !BluePrint: Crisis Mapping = [[TOC]] == Introduction == Sahana Eden can be used as a Crisis Mapping Platform to allow incidents and other information to be mapped during a crisis. Most of the building blocks for Crisis Mapping are already in place in Sahana Eden, and the goal of this project would be to bring these pieces together in a usable solution. This will allow Crisis Mapping to be integrated into other Sahana Eden solutions. The focus of this project is building an easy to use solution. This project will involve developing a custom [DeveloperGuidelines/Templates Template]: {{{CrisisMap}}} Michael Howden from the Sahana Community is able to help mentor this project. If you have any questions, please contact the [https://groups.google.com/group/sahana-eden Sahana Eden Mailing List] == Stakeholders == TBC Tip: Engage these stakeholders in the development of your !BluePrint. [[BR]][[BR]] CAP Broker's 5th -''receive CAP feeds'' and 6th - ''visualize CAP feeds'' ("common operating picture") are two [http://eden.sahanafoundation.org/wiki/BluePrint/CAPBroker#Missingfeatures: missing features] in the Sahana-Eden CAP Broker.The [http://eden.sahanafoundation.org/wiki/BluePrint/CAPBroker CAP Broker] is a stakeholder because the CAP Broker would simply reuse the "crisis map" functions in visualizing CAP feeds. A common practice is demarcating the polygon on an interactive map indicated by CAP information. Thereafter, further parse the information for efficient message filtering (e.g. selected set of enumerated CAP elements). Continue to read the [http://eden.sahanafoundation.org/wiki/BluePrint/CrisisMap#Requirements Requirements] section in this page. == User Stories == TBC * A person in the community wants to be able to report the impact of a disaster to get assistance * An emergency manager wants to be able to view the needs across the community * [http://eden.sahanafoundation.org/wiki/BluePrint/CAPBroker#Description CAP Broker user story; sepcifically the 5th - ... view the current situation ...] == Requirements == '''The audience of Crisis Map are divided into three categories :''' * Organisations : Situational awareness, Inventory management, catering to requests amongst other organizational operations * Public reporters : - tool for easy and quick reporting (pic upload, location marking on map) - the reporting tool should be designed such that the report should be automatically structured before sending to the database * Population : making requests, seeing resources on map, volunteering, local community communication ==== CAP Broker requirements ==== * The CAP Broker should reuse available code from the crisis mapping project to serve its purpose of offering [http://eden.sahanafoundation.org/wiki/BluePrint/CAPBroker#Description multi-agency situational-awareness features]. * To keep the situational-awareness simple, the CAP Broker must leverage certain interactive controls for [http://eden.sahanafoundation.org/wiki/BluePrint/CAPBroker#Visualization alert visual analytics] === Phase I === '''* Custom homepage & menu''' '''* Form to upload incidents to the map (using {{{event_incident_report}}})''' - Due to rise in role of mobile phones for incident reporting, there can be alternative intuitive template of the form for mobile phones. The user should have a way to report incident while he/she is on the move. Camera and GPS can be accessed using a browser and this will increase the accountability of the data. - When user is filling the incident for a particular location, recent reports for that location will be displayed on the side. User can select those ones which are reports for the same incident. Initially these connections can be just stored, and after analyzing them we can develop a module which clusters such incidents based on these connections. Research papers on topics like "Crisis Map Mash-ups" and "Emergence of Neogeographic practices for incident reporting" have mentioned the problems current crisis mapping tools face is inability to remove duplicate data. Most tools use number of incoming reports as a measure of incident seriousness, but that is not proving to be effective. This feature will help us in solving this problem. '''* Map showing incidents''' - Map will feature different layers for different incidents. User can select which layers he wants to deploy/view. - Simple functions will be made to create new layers or customize existing ones and add features to it as this will be the most used feature when deploying templates. The aim is to make inexperienced programmers use this template very easily for faster deployment. - On clicking a marker, the information displayed will depend on the user type, whether he is a volunteer looking places where his help maybe needed or a user looking for relief camps. The template will have functions to add user types and select which information should be displayed to which user type. - Various functions to give user full control over the customization of the template and map '''* Ability to select different icons (See: [wiki:DeveloperGuidelines/GIS])''' '''* Summary Pages for Incident reports & Charts ''' === Phase II === * Import feeds from different social media platforms (See: DeveloperGuidelines/Messaging) * Configure feeds to import * Create incidents from clicking on map points * Integrated form to allow easy creation of different types of resources (PoI, Resources, Requests, Tasks, Alerts) === Phase III === '''* Analyse Data Over Time''' * [wiki:BluePrint/GIS/TimePlay] * [wiki:BluePrint/TimePlot] '''* Allow "voting" to prioritize''' - Users can upvote or downvote a incident or it's report.The weightage of the vote will depend on the user type. The weight variable for each user can be set when defining user types during the implementation of template - This voting feature can also be used to classify the data from social networks. Most crisis tools report the problem that they pick data from social networks, and sometimes this data is misleading or obsolete. '''* Control voting by different permissions''' '''* Allow requests & tasks to be generated and linked from incidents''' '''New ideas by participants of the Sahana Barcamp @ IOTX 2014 :''' - There should be focus on improving usability to reduce training time - there should be inter organization communication. Every organization should be aware of other organization activities. This would help in better allocation and deployment of help/resources - time to time quick report generation for every volunteer in the field for situational awareness - decision making can be crowdsourced, which will help in quick decision making - people should be able to report by SMS also (or maybe tweet the situation through SMS) - the location data should also have data source ( GPS or wifi location or tower triangulation) which will help in separating accurate information. This will help in decision making for organizations as accurate data is high priority data. - the number of steps for reporting should be minimized. For mobile devices we can have a simple click UI where by few clicks user can report a situation (this will also have optional field of description in the end)It will also matter which questions are being asked by the user first. e.g. Asking for type of disaster and photos should come before asking for location. Such kind of click UI will also help in having a structured report. - Organizations should be update status for requests in bulk. e.g. by selecting all markers of a particular area by drawing a polygon or circle and then marking them complete. - The data on the map should be aggregated (e.g. heat maps). Aggregated data gives better situational awareness and can play a important role in deploying group of resources. '''Problems seen in crisis maps :''' - Data overload (can be solved by using AI or call center models) - Outdated data - No quick scalable solution for verification of data - multiple requests for same situation from different sources - there is confusion between implementers on the permission level for different types of users == Design == TBC - But having some wireframes for the solution would be useful === Data Model === (e.g. EER or class diagrams) === Workflows === === Site Map === === Wireframes === === Technologies === == Current Implementation == TBC <*a brief description of the implementation (date/time, name, design options chosen)> <*a link to the code> <*list of deployments of the implementation> <*links to case studies> <*short analysis of achievements/problems> == Planned Implementation == TBC [[BR]][[BR]] == CAP Code-fest 19 Jun 2014 Sri Lanka == The [http://eden.sahanafoundation.org/wiki/Event/2014/IOTX/cap-codefest-2014 CAP Code-fest], in Sri Lanka, part of the Indian Ocean Tsunami + 10 year anniversary commemoration events. One key activity in the CAP Code-fest will require a tool such as the Crisis Map. The intent is to provide other CAP message publishers to test their feeds by emulating an Alerthub. The Crisis Map will, simply parse the CAP XML to extract the necessary and sufficient information. Thereafter, style the display on the Crisis Map. Discussed approach: * a form for publishers to register their RSS/Atom feed in the Sahana-Eden Crisis Map * use the msg_rss_channel resource * schedule a Poll of these channels to monitor the feed for new content (e.g. like in NYC Prepared) * write a Parser (again NYC Prepared has a Parser for the incoming RSS feed, although that converts msg_rss posts to cms_post resources) * parse the data into a resource to configure onto the map * have a Folder called 'Alerts' & then each RSS feed would be a separate layer within that folder * the resource could be simple cms_post of type 'Alert' (which is what TL DRMP uses) * determine the POI values to display in the Crisis Map * [optional] create a new event_alert resource (this is planned at some point & can then have an integration built into CAP) == Future Extensions == == Outstanding Questions == == References == === Sahana Eden Wiki === * Similar Functionality is described here: BluePrint/SocialMedia === Other Crisis Mapping Software: === * [http://www.ushahidi.com Ushahidi] - A platform for crowdsource mapping and monitoring of realtime crisis reports from the general public - Technology: Ushahidi Engine with the ability to integrate plug-ins and extensions - Data choice: Reports from the public via mobile phone, e-mail, the web, Twitter, RSS feeds from official news sources * [http://www.oe-files.de/gmaps/eqmashup.html Live Earthquake] - Displays earthquakes over the previous 7 days or 24 hrs on map and timeline - Technology: Google Maps API, Simile Timeline widget - Data choice: U.S. Geological Survey, European- Mediterranean Seismological Centre, GFZ Potsdam * [http://www.oe-files.de/gmaps/eqmashup.html Live Earthquake] - Displays near realtime “fire” tweets in the LA area - Technology: Google Maps API, Twitter API - Data source: Tweets with “fire” geocoded within 100 mi radius of LA * 2009 Los Angeles Fires by LA Times - Displays warning and response information about the wildfire in near real time - Technology: Google Maps - Data source: Los Angeles Times reporters, InciWeb, USGS satellite images, viewers’comments * [http://www.mibazaar.com/nationundersiegeSea Level Rise on Coastal Cities in US] - Displays presentday and sea-level rise images for each of the 31 U.S. coastal cities - Technology: Google Maps, Google Earth - Data source: Images from the “Nation Under Siege” online report by Architecture 2030 === Articles === [http://www.crowdsourcing.org/document/if-all-you-have-is-a-hammer---how-useful-is-humanitarian-crowdsourcing/3533 "If all You Have is a Hammer" - How Useful is Humanitarian Crowdsourcing?] ---- BluePrint