EM CAP SC

  • 1.  NWS items for CAP-SC

    Posted 07-25-2013 13:07
      |   view attached
    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 begin:vcard fn:Mike Gerber n:Gerber;Mike org:National Weather Service;Office of Climate, Water, and Weather Services title:Physical Scientist version:2.1 end:vcard

    Attachment(s)

    vcf
    Mike_Gerber.vcf   165 B 1 version


  • 2.  RE: [emergency-cap] NWS items for CAP-SC

    Posted 07-25-2013 14:20
    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