wiki:BluePrint/CrisisMap

Version 44 (modified by Hemant Kumar Singh, 10 years ago) ( diff )

--

BluePrint: Crisis Mapping

Table of Contents

  1. Introduction
  2. Stakeholders
  3. User Stories
  4. Requirements
      1. CAP Broker requirements
    2. Phase I
    3. Phase II
    4. Phase III
  5. Design
    1. Data Model
    2. Workflows
    3. Site Map
    4. Wireframes
    5. Technologies
  6. Current Implementation
  7. Planned Implementation
  8. CAP Code-fest 19 Jun 2014 Sri Lanka
  9. Future Extensions
  10. Keypoints of Brainstorming session at Barcamp@IOTX 2014
  11. Outstanding Questions
  12. References

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 Template: CrisisMap

Michael Howden from the Sahana Community is able to help mentor this project. If you have any questions, please contact the ​Sahana Eden Mailing List

Stakeholders

TBC <Who will be the users of the solution?> <Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?> <How will stakeholders be affected?> Tip: Engage these stakeholders in the development of your BluePrint.

CAP Broker's 5th -receive CAP feeds and 6th - visualize CAP feeds ("common operating picture") are two missing features in the Sahana-Eden CAP Broker.The 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 <area> information. Thereafter, further parse the information for efficient message filtering (e.g. selected set of enumerated CAP elements). Continue to read the Requirements section in this page.

User Stories

TBC

Requirements

TBC

CAP Broker requirements

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: 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

* 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

Design

TBC - But having some wireframes for the solution would be useful <Where relevant include alternative design options>

Data Model

(e.g. EER or class diagrams)

Workflows

<Diagrams or Pseudocode>

Site Map

<for User Interface solutions>

Wireframes

<for User Interface solutions>

Technologies

Current Implementation

TBC <Leave open for a list of existing implementation of this solution in Sahana Eden:> <*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 <List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on>

CAP Code-fest 19 Jun 2014 Sri Lanka

The 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

<List of features which could be included, but are outside of the scope of this extension>

Keypoints of Brainstorming session at Barcamp@IOTX 2014

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

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

New ideas by participants of the barcamp:

  • 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.

Outstanding Questions

<Questions about the features or design that haven't been (and need to be) answered>

References

* Other Crisis Mapping Software:

  • ​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
  • ​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
  • ​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
  • ​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

BluePrint

Note: See TracWiki for help on using the wiki.