Version 61 (modified by 11 years ago) ( diff ) | ,
---|
CAP Code-fest
Common Alerting Protocol
SHOW UP if you are a PROGRAMMER or working in DISASTER MANAGEMENT (but not limited to, encourage all, free for anyone to attend)
Place: Orion IT City Park
Date: Thursday 19 June 2014 9AM onwards
Objectives
- Develop a Sahana (OData-like) S3XML data structure to CRUD pictographs used in alerting. The teams will determine the optimal set of CAP elements to build in to the HTTP RESTful Request APIs. Thereafter, the CAP Editor, Mobile CAP Tool, and ITU CAP Software will use the APIs to publish a message with the pictograph
- Establish a set of parameters for exchanging measurement data; first document the norms in the Sahana wiki; then enhance each of the CAP-enabled tools to use the parameter values to change the visualization (e.g. flash flood water height to display the inundation region on a map).
- Emulate a Google Alerthub test base for experimenting with RSS/Atom feeds for a Common Operating Picture; using the Sahana-Eden’s Crisis Map with spatial and temporal filtering capabilities.
We are applying a Goal Improvement HCI Methodology is to experiment with enhancing software components for interchanging various alerting message between the CAP-enabled software tools. For such we have identified the following
Software Tools
Software tool name | coding platform | team contact | documentation |
SAMBRO | Python/Web2Py/PostgreSQL | Nuwan Waidyanatha, Francis Boon , Dominic Konig | CAP Broker Blueprint |
CAP Editor | Java | Eliot Christian | documentation included |
Mobile publisher | HTML5/JS | Art Botterell | CAPTools on GitHub |
CAP ITU Software | Linux, Apache, MySQL, PHP (LAMP) | Isuru Ilangakoon | other documentation - based Single Language CAP Publisher and Subscriber |
Intended coding and related activities
(A) Pictographs database and APIs
(A.1) Introduce the teams to some of the identifies pictograph repositories: UNOCHA, NHS,
(A.2) Research the set of alert specific pictographs and relevant icons to create alerting pictographs for the hazards: volcano, flash floods, and cyclones
(A.3) Create the pictographs to be filtered by a limited set of enumerated CAP elements such as urgency, severity, certainty, response, and category; additionally, alerting pictographs would be further customized for event (types), headlines, and instructions.
(A.4) Build a MVC in Sahana Eden to CRUD the set of pictographs; then provide a RESTful API to request for a CAP message specific pictograph
(A.5) Each of the CAP-enabled tools would provide the HTML to display a frame with the pictograph received through the Sahana Eden RESTful API.
(B) Validating parameters carrying scientific data
(B.1) Identify 5 to 10 sets of, hazard event specific, commonly used scientific measures
(B.2) Develop a data structure for managing relationships between the various ordered encoding of scientific measures (e.g. wave-height would imply the ocean wave height; possibly modeled as a pair object-property; where object is the wave and property is height)
(B.3) Build the API for CAP publishers and subscribers to validate the scientific measures. The scientific measures are exchanged through CAP <parameter> elements.
(B.4) Programmers from the four CAP-enabled software tools would submit their <parameter> element data through the API to match with an existing object and property.
(B.5) The individual CAP-enabled software tools can exchange various CAP messages with <parameter> element values and the cross validated with the Sahana-Eden validation service.
(C) Emulating the Alerthub
(C) Emulating the Alerthub (C.1) Build an API in the Sahana-Eden CAP Broker that would allow for authorized users to register a CAP message contained Atom/RSS feed.
(C.2) Let the four other CAP-enabled software tools register their CAP RSS/Atom feeds
(C.3) Integrate the Crisis Mapping module (GSoC 2014) to enable visualization of the CAP messages received from the other four CAP-enabled software tools
(C.4) Offer the service in Sahana-Ede demo site as a tool for CAP implementers to use Sahana-Eden Alerthub Emulator for testing before directly integrating real-live feeds with Google’s Alerthub
Team Roles
A "team" comprises several members with varied skills and expertise. Essentially the participants will be a blend of Disaster Management (DM) and Emergency Communication experts. A few observes but with a vested interest in DM will be among the participants. When you REGISTER specify your anticipated role or the capacity in which you would like to contribute.
Each CAP-enabled software tool can be used by each team. We have identified several essential team roles that would help a team fulfill the coding activities.
Role | Description |
IRC | - each team must designate, at least, one person to communicate with members of other teams and the code-fest organizers through the IRC channel (#sahana-meeting). Any exchange of instructions, literature surveys, code snippets, or discussions will happen on the IRC channel. |
Wiki writers | Technical writer(s) who would contribute to documenting the Blueprints and User Guides |
QA Testers | |
Programmers | - Software programmers competent working with any of the source code in the CAP-enabled software tools are essential. They will communicate with Domain Experts and Code-fest Program Committee determine the solutions for the given objects. Some of you may be inclined to work on Quality Assurance with some testing. However, designating, at least, one member for testing would ensure bug free code for other teams to reliably adopt |
CAP Experts | - each team will have, at least, one person exposed to the CAP standard. Several members, participating in the CAP Jump Start and CAP Implementation Workshops will be participating in the Code-fest. They will contribute to the design and testing of the three objectives. |
DM Experts | - Disaster Management personnel can contribute to the design and testing. The main responsibility would be to determine the usability as well as provide inputs through online research or share their knowledge. |
Observers | - those who are not keen in taking on a team responsibility but are willing to share some labor and become a positively reinforcing lurker. |
Facilitators
- Francis Boon, SSF Product Development Committee Chair
- Dominic Konig, SSF Standards & Interoperability Program Committee Member
- Eliot Christian, CAP Program Committee Chair, WMO
- Elysa Jones, OASIS EM-TC Chair
- Nuwan Waidyanatha, SSF Standards & Interoperability Program Committee Chair
Footnotes
- Nuwan Waidyanatha, Sahana Software Foundation Standards & Interoperability Chair and LIRNEasia Senior Research Fellow