OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EMERGENCY-16) Support CAP event location and movement


    [ https://issues.oasis-open.org/browse/EMERGENCY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41845#comment-41845 ] 

Norm Paulsen commented on EMERGENCY-16:
---------------------------------------

My prefence is to leave the elements <description>, <instruction>, and <headline> alone (i.e. no constraints beyond the obvious minimal few that there are) . So for those that want to include event information within these elements, they are free to do so oin their own way. For those that feel that event information is useful, optional elements like <onset> can exist or new ones can be made to exist.

Right now, Env. Can. does not put in event information but we do forecast by event. Warnings for these vents aren't 1 to 1 so however many <info> blocks are needed to divide the warning up;  by <instruction>, <urgency> , <severity> or whatever, we have the option to do so and we use it often. But in the end we keep getting asked to include event details that automated systems can process. Event location and motion are highly desired details. So if elements were to exist to that end, and we had the info, we would use them.

But we would not want the <discussion> to be constrained to anything for this use (content or format) as that is not what we feel the <discussion> was intended for. So we would rather create a <parameter> and house that information there or if CAP 2.0 had an optional element we would use that.<discussion> should be for the alert.

But it all comes down to how best to input extra info that people want. Since the event and the alert are two separate objects, the info that goes with those objects should be grouped separately so that elements can coupled without having to be qualifed to the same object (CAP uses no qualifers). 

An additonal consideration goes to what an issuing authority uses CAP for. If it is for primarily public alerts, then no need for all the event info spliced out. If it is used  for Situational Awareness then I can see how event info could easily be included.

As it is Env Can. uses CAP more for situational awareness rather than public alerting but what we actually do is use it to create situation awarenss about the alert (not the event). In other words we often describe the Alert all in one CAP file (with its many divisions - primarily based on <instruction>).

This allows us to solve another problem we, and the NWS, refer to as bifurcation. A secondary benefit is the "continuity" problem that also gets solved - especially with large moving storms. Those two are another discussion, but the point is that we use CAP for situational awareness a lot. So extending CAP to include situational awareness information on the event itself is rather easy for us (if and when we collect such info and should a schema for elements comes along). If one doesn't come along, we can easily create some <parameters> to do so. 

Finally, for those that want to use CAP purely for public Alerts - understand that we create our CAP so that channel specific customizations can easily be built by selectively taking the necessary information out of what we consider to be, our more comprehensive CAP. The NWS works off a different model where their alerts are more Public Alert like than ours. It makes our two relationships with LMD's quite different. 

So back to the topic....Event Location and Motion information is secondary to us, but when we do get that stuff collected (not way far off), we will be able to include it without to much trouble, given our approach, and theoretically without "bifurcation" and "continuity" issues there too. But in the end, its not a critcal piece for us - what's critical is the mechanism that we end up setttling on for adding any ancillary information, regardless of what it is about. 











> Support CAP event location and movement
> ---------------------------------------
>
>                 Key: EMERGENCY-16
>                 URL: https://issues.oasis-open.org/browse/EMERGENCY-16
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Tony Mancuso
>              Labels: CAP
>
> Should a new CAP element be added that describes the current event location, speed and direction of movement?
> Also: Is there a need for describing motion? Ideas include multiple info blocks with own effective time/location or a new movingArea structure. Scenarios? Specifics?



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]