wiki:Event/2012/GSoC/CAPBroker

Version 13 (modified by g0wda, 12 years ago) ( diff )

--

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

Component Stage
Data model for CAP alerts implemented: to be reviewed
  • the models are at modules/eden/cap.py
Component Stage Expected
CAP alert creation interface Started Thursday, 21 June

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 28 June
  • Plan: modify s3import and s3export, XSLTs for CAP messages.
Component Stage Expected
CAP template creation interface Not started 1 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.

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:
  • Mentor information:
    • Name: Nuwan Waidyanatha
    • IRC handle: gnewy
  • Weekly meetings:
    • Tuesdays 10:00 UTC (skype: shashig0wda)
Note: See TracWiki for help on using the wiki.