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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap message

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


Subject: RE: [emergency-cap] NWS items for CAP-SC


Hi Mike

I most definitely want to discuss these...

One of the reasons for wanting to meet with you is exactly the issue you
raise in Scenario 2. We have modelled the event location polygon with a
motion vector. The motion vector is defined as time: direction: speed
and it applies to the event location polygon. "time" is required as the
time of the event measurement may not be exactly the same as the time of
the CAP message coming out.

The threat location polygon, which is the <polygon> we use in CAP, is
the event polygon and motion vector applied over time to cover the area
that is affected for the time period we define as the meaningful to the
warning message (I realize the event shape may change so the above is
just a generalization but essentially it is a good starting point for
discussion).


As for Scenario 1: We consider the message to be stale internally at
some time X. We then make <expires> a value equal or greater than X for
every CAP message (but mostly greater). We teach our forecasters to
update the warning by time X otherwise it is considered stale. The
message however continues to play for a period after the stale time is
reached (until it <expires> or is replaced with a new message). That
period is not very long and it gives our forecasters a chance to send
out an update even if they miss time X. They know they have a small
buffer before it is expired out in Distributer land. This avoids gaps in
web sites if a forecaster misses time X which can happen but is rare.
<expires> is a distributer value and it is interpreted as "stop
distributing the information" so we factor that in to our model.

Norm




-----Original Message-----
From: emergency-cap@lists.oasis-open.org
[mailto:emergency-cap@lists.oasis-open.org] On Behalf Of Mike Gerber
Sent: July 25, 2013 9:07 AM
To: emergency-cap@lists.oasis-open.org
Subject: [emergency-cap] NWS items for CAP-SC

Gang,

Here are a few items we at NWS would like to see addressed on the
CAP-SC.

- Discuss meaning of <expires> time and add a new optional element
called <endTime>.  NWS use of <expires> reflects the time at which the
information in the message (about the subject event) has gone stale and
should no longer be used. It comes from the expired time (aka purge
time) in the UGC block of NWS alerts. We added an optional parameter
called <eventEndTime> to reflect the expected end time of the event.  
This comes from the NWS VTEC. Some events do not have an expected end
time, so we don't include the <eventEndTime> in those situations.

- There are a couple of ways <references> could be interpreted when
multiple extended message identifiers are included in the tag. Which is
allowed or are both allowed?

Scenario 1:  The identifiers serially refer to previous messages about
the event for the geocodes specified in the CAP message.

Scenario 2:  The CAP message would serve as a follow-up to multiple CAP
messages, each of which had different geocodes.  To illustrate this,
imagine the following.  A Flash Flood Watch is issued.  The Flash Flood
Watch is later expanded to include an additional geocode.  This results
in a new CAP message with <msgType> of Alert to reflect the new area in
the watch. Later on, the watch area is expanded again and another CAP
message with  <msgType> of Alert is issued to reflect the new area in
the watch.  Later, an Update CAP message is issued as a followup for the
entire watch area.  In this case, multiple identifiers would be used in
the <references> tag where each of the previous messages had different
geocodes.  Thus, there wouldn't be a serial relationship between all of
the CAP message referred to in the <references>.

- During an event, the subject of the event could have a location and
move around within the threat area.  This could be a storm, gunman,
hazardous materials on a train, etc.  For storms which can be pinpointed
to a current location, such as a tornado, the NWS will include a
parameter which describes the storm's location, direction of motion, and
speed.  Should an element be standardized in CAP which describes the
location, direction of motion, and speed of the subject within the
event?

Mike


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