1 / 11

Norm Paulsen (norm.paulsen@ec.gc) Meteorological Service of Canada (Toronto)

Workshop showcasing implementation of CAP files in alert scenarios, focusing on updating threat zones in real-time for effective communication. Discusses challenges and considerations for message originators.

michelleleonard
Download Presentation

Norm Paulsen (norm.paulsen@ec.gc) Meteorological Service of Canada (Toronto)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CAP – Demonstration of Practice(Implementation Workshop – Geneva, Switzerland 9-10 December 2008) Norm Paulsen (norm.paulsen@ec.gc.ca) Meteorological Service of Canada (Toronto) - Information Strategy Section December 9th, 2008

  2. Alerting Scenario • Imagine an event that is extremely critical (Tornado) • Imagine a message Originator having difficulty keeping up with the unfolding situation (Tornado outbreak) • Imagine the overall threat zone expanding in size (outbreak expanding to new areas) • Imagine the initial CAP file has already been transmitted some time ago • Let’s pick up the activity in progress….

  3. 6 p.m. local time (tornado outbreak)- <info>: Area 1 threat polygon (in this case it includes the area of concern over the <expires> time Sample

  4. 7 p.m. local time (numerous tornadoes reported)- <info>: new Area 2 threat polygon (again it includes the area of concern over the <expires> time Status

  5. 7 p.m. local time (what does the CAP file contain?)- <msgType>Update (summarize the whole event) ..or..- <msgType> Alert (focus on new threat area) AlertBlock?

  6. Message Originator… • May not want to bother with updating previous threat zone information when under pressure to issue information on the new threat zone • May have additional time constraints such as translation times and coordination issues with other jurisdictions • Real life might suggest <msgType>Alert be optional (or even standard) in this Scenario • No Area 1 referenced in the 7 p.m. CAP message

  7. Perspective? • If CAP is to be processed as designed (using XML philosophy and proper data theory principles) then… • <msgtype>alert should work fine for the 7 p.m. message • 6 p.m. message is still applicable • Taking a closer look at <msgType>update • <msgType> is an element of the <alert> block and Update implies that the information in all the containing <info> blocks is to supersede any previously <referenced> CAP file • In this case the <info> block details from the first CAP file at 6 p.m. would be replaced by information included in the new CAP file at 7 p.m. • So what does the <info> block for Area 1 contain?

  8. <msgType>Update • Is the 7 p.m. <info> block for area 1 auto-updated with new times for • <effective>, <onset>, <expires>, etc… • or are they left as is? • Issuer may not be comfortable with the results of auto-updated time information on the previous threat zone as it could impact the integrity of <description>, <headline>, etc… • However, if the <info> block is just repeated (all elements including time references), the presentation of the information should appear unchanged to the end client • Real life might suggest <msgType>Update include a total repeat of the earlier <info> block • Area 1 information in the 7 p.m. CAP message repeated and displays unchanged

  9. Originator Concerns with <msgType>=Update? • Is <urgency>, <severity> and <certainty> ok as they are? • Is the <description> element still relevant? • Are <effective>, <onset>, and <expires> times automatically updated or remain as they were? • Does the distributor display an “Updated at X:XX time” • Do they use <sent> or <effective>? • Can they handle <effective> and <onset> be in the past? • If <expires> occurs around the same time as the Update does the <info> block just disappear?

  10. Originator concerns with <msgType>=Alert? • Can a distributor accommodate multiple <info> blocks from different CAP files from different times • The <references> and <incidents> elements in CAP suggests they are expected to do so • Can two CAP message files combine and update into one file in a subsequent issue? • The <references> element in a CAP file suggests it can

  11. Conclusions • Originators may… • make use of <msgType>Alert in an threat zone expanding scenario • repeat an <info> block in <msgType>Update and not update any time references or <description> elements • Off topic but… • use <msgtype>Alert to solve “upgrading” and “downgrading” scenarios • keep all areas in separate messages (not advised) in order to use the <msgType>Cancel in a similar fashion

More Related