This page has details related to the CAP Broker implementation GSoC project.

• BluePrint/CAPBroker
• Development branch: ​http://github.com/shashi/eden/tree/cap
• Demo instance ​http://106.187.91.158:8000/
• Weekly meetings:
  • Meeting on 21st May 2012: ​http://logs.sahanafoundation.org/sahana-eden/2012-05-21.txt
• Project plan:
  • The project plan is now different from the one in the proposal in that, I will be implementing CAP Alert creation then CAP template and then CAP profile (simply reversing the order of the objects). This would allow for a validated CAP message to be created; core of the module.

Component	Stage
Data model for CAP alerts	completed

• the models are at modules/eden/cap.py

Component	Stage	Expected
CAP alert creation interface	Started	Under review

The data model is in place. I am now creating the various UI widgets necessary for the same, namely:

• KeyValue widget: for cap fileds such as Codes and Parameters: this is a widget will help in input of key-value pair data.
• CAP alert selection widget: for selecting a previous CAP alert (for referencing in a new one)
• CAP multiple info widget: for input of multiple <info> sections.
• CAPResourceWidget: for uploading one or more files for distribution in the CAP alert, or pick a resource previously uploaded (tabbed view)
• CAP Area selection widget: This will be for selection of a polygon from the map and encoding it in wkt and WGS84 formats

Other enhancements are listed in the things-currently-on-the-table document here: ​https://workflowy.com/#/af3d663a-c904-1442-fd88-380d487c0a05

Component	Stage	Expected
CAP Alert import/export	Not started	Thursday 1 June

• Plan: modify s3import and s3export, XSLTs for CAP messages.

Component	Stage	Expected
CAP template creation interface	Not started	5 July

• Plan: set a flag in the alert table and all the children (alert has a (which has a)) tables to denote a row belongs to a template.

Component	Stage	Expected
CAP Profile creation interface	Not started	10 July

• Plan: notes are in the data model spreadsheet

Component	Stage	Expected
Subscription and Delivery	Not started	July 25th

• Plan: auth_user level for subscription, completely use s3msg here.

Feedback

This is the received feedback:

Fran:

• Error message not going away
• Alerts are alpha-sorted

Nuwan:

Hi Shashi et al,

Final Deliverable should be a set of forms with appropriate work flows to create a CAP message and then produce an XML file. Thereafter, we would validate that XML file with Googl.org's CAP validator. Trying to build one that can handle multiple languages may be too ambitious, therefore, we'll restrict it to English for now. However, we should still assume we'll need multiple <info> segments that can be populated in English. If we are to deliver a CAP-enabled alerting module that can be utilized, then we would need the Profile and Template components to work.

First, some comments on the Create CAP Alert form 1) <Alert> segment = Create CAP Alert a) Given that CAP already contains the word Alert in it we can possibly simply call it "Create Alert" or "Create Message", where CAP is simply the underlying data structure -- Seems very apt! CAP Templates and Profiles retain CAP though. b) <identifier> - typical format is prefix + dateTime + timezone + sequence + postfix; e.g. scdmc-20120626T19:30:00+8:00-005-2.49.0.1.144.2. The prefix = "scdmc-", postfix="-2.49.0.1.144.2", and sequence="005" (we may issue more than one alert in one day).

-- Here prefix is configurable, defaults to domainname, sequence is the potential alert id, postfix is configurable defaults to "".

c) <scope> - need to build in the logic for each of the values: Public, Private, Restricted.

If "Public", then control(<Restriction> && <Recipients>) = disabled If "Restricted", then control(<Restriction>)=enabled && control( <Recipients>)=disabled If "Private", then control(<Restriction>)=disabled && control( <Recipients>)=enabled -- Done but these things are optional and not disabled as per CAP, correct?

d) <Reference> - if <reference> is empty, then <reference> = <identifier>; else leave whatever it already is.

-- which identifier? :/ isn't reference supposed to refer to other alerts which are these if the field is empty? (shashi)

e) <incidents> should be related to the same incidents list in the IRS module. Example: a mass movement that causes an accident, then incidents would be ="rock slide", "train derailment". I believe "rock slide" and "train derailment" may be archetypes of "mass movement" and "accident", respectively.

--- err. I just copy-pasted the irs categories. This should be fixed as in they should share these things, can we find the EDXL standard incidents?

Work flow you need is discussed in this ticket: http://eden.sahanafoundation.org/ticket/1026#no1 . Read the Attachments section and the Change History. For the create CAP Alert; specifically refer to the paragraphs beginning with Scrn03_CAP_Msg.png. Disregard the images added by Nostraa , you may get confused.

-->

Some notes on Scrn03_CAP_Msg.png

Scrn03_CAP_Msg.png: the image shows the <info> segment given at the bottom. One option would be to create tabs in the Create CAP Alert form. Put the <Alert> segment attributes in the first tab and the <Info> segment attributes in the second tab. Since there is a 1-to-many relationship between the <Alert> segment and the <Info> segments, in the image: Scrn03_CAP_Msg.png, the related <info> records are displayed in a table. The table shows only a selected set of elements to guide the user to enter in to that particular <info> block. The instances that create multiple <info> segments are Language and Updates.

Example: The Met depart may detect a cyclone developing in the Bay of Bengal. The Tamil Nadu DMC would issue an alert in English, French, Hindi, and Tamil, that's 4 <info> segments. Then every six hours they would issue an update of the same alert but with the new position, wind-speed, trajectory, etc. These updates would need to be issued in the 4 languages. Assuming there are 5 updates before it hits land, then that particular message would have 20 <info> segments.

We'll discuss the subsequent developments such as the <info> segment logic and layout when you get to that point; i.e. Scrn031_CAP_msg_Info.png, etc.

• Student information:
  • Name: Shashi Gowda
  • Email: ​connect2shashi@gmail.com
  • IRC handle: g0wda
• Mentor information:
  • Name: Nuwan Waidyanatha
  • IRC handle: gnewy

• Weekly meetings:
  • Tuesdays 10:00 UTC (skype: shashig0wda)