|Version 12 (modified by 10 years ago) ( diff ),|
This page has details related to the CAP Broker implementation GSoC project.
- Development branch: http://github.com/shashi/eden/tree/cap
- Demo instance http://184.108.40.206: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.
|Data model for CAP alerts||implemented: to be reviewed|
- the models are at modules/eden/cap.py
|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
|CAP Alert import/export||Not started||Thursday 28 June|
- Plan: modify s3import and s3export, XSLTs for CAP messages.
|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.
|CAP Profile creation interface||Not started||10 July|
- Plan: notes are in the data model spreadsheet
|Subscription and Delivery||Not started||July 25th|
- Plan: auth_user level for subscription, completely use s3msg here.
This is the received feedback:
Error message not going away Alerts are alpha-sorted
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 b) <identifier> - typical format is prefix + dateTime + timezone + sequence + postfix; e.g. scdmc-20120626T19:30:00+8:00-005-220.127.116.11.144.2. The prefix = "scdmc-", postfix="-18.104.22.168.144.2", and sequence="005" (we may issue more than one alert in one day). 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
d) <Reference> - if <reference> is empty, then <reference> = <identifier>; else leave whatever it already is. 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:
- Name: Shashi Gowda
- Email: firstname.lastname@example.org
- IRC handle: g0wda
- Mentor information:
- Name: Nuwan Waidyanatha
- IRC handle: gnewy
- Weekly meetings:
- Tuesdays 10:00 UTC (skype: shashig0wda)