Third-Gen CARS-CAP Concept of Operations Detailed Design ...4. TG -CAP alerts shall not be editable by CARS 4/5 operators.* 1 2.01.00 5. In each state, CAP 1.1 shall read two external

Third-Gen CARS-CAP

Concept of Operations

Detailed Design Requirements

System Design

Prepared by:

Castle Rock Associates

Prepared for: Minnesota Department of Transportation

Last update:

December 3, 2014

Document Version History

Final Third-Gen CARS-CAP System Design Document 17m_du (2).docx

Confidential. Limited Circulation Document. Listed Agencies Only

2

Version Author Date Change Notes

1 du 9/18/12 First Draft

2 kv 1/3/12 Continuing edit

3 sk 1/4/13 Updates per kv’s comments

4 Kv 1/5/13 Reviewing sk3; continuing edit.

5 Kv 2/21/13 Updating mockups in light of latest TG Web SDD;

preparing for review in Louisville on 2/26

6 du 2/22/13 Updates per kv comments

7 kv 2/21/13 Reviewing du6

8 du 2/25/13 Updating per kv comments

9 kv 2/26/13 Capturing notes during review with IN, IA, ID, LA, and

Sac

10 kv 2/27/13 Incorporating feedback from review meeting

11 Sk 3/5/13 Updates as per KV’s comments.

12 du 7/01/13 Updates to bring in line with TG Web developments

13 du 10/21/14 Updates for Minnesota

14 pd 10/22/14 Updates for Sacramento

15 kv 10/30/14 Preparing for Mn/DOT submission – Innovative Ideas

15s kv 11/3/2014 Submitting to Mn/DOT

16s du 11/5/14 Accepted tracked changes

17s du 12/3/14 Updated “build” column



3

Table of Contents

1. CONCEPT OF OPERATIONS .............................................................................................................................. 4

2. SYSTEM REQUIREMENTS ................................................................................................................................. 5

2.1 CAP IMPORTS ...................................................................................................................................................... 5 2.2 ALERT MANAGEMENT ......................................................................................................................................... 6 2.3 MAPPING ALERTS TO EVENTS .............................................................................................................................. 7 2.4 AREA EVENTS ...................................................................................................................................................... 7 2.5 ROADWAY EXTENT EVENTS ................................................................................................................................ 8 2.6 DISPLAYING EVENTS IN TG CARS-WEB AND CARS 4/5 .................................................................................... 8 2.7 ANNOUNCEMENT ON NG/TG-511 ....................................................................................................................... 9

3. SYSTEM DESIGN ................................................................................................................................................ 10

3.1 OVERVIEW ......................................................................................................................................................... 10 3.2 NWS PRACTICES ............................................................................................................................................... 10

3.2.1 Zones, Counties and Polygons .................................................................................................................. 10 3.2.2 NWS Products, Segments and Events ........................................................................................................ 11 3.2.3 CAP Index Message Polling ...................................................................................................................... 11 3.2.4 CAP Index Message Parsing ..................................................................................................................... 12 3.2.5 Non-compliant (unwanted) Index Entry .................................................................................................... 13 3.2.6 Compliant Index Entry .............................................................................................................................. 14 3.2.7 Mapping CAP Description to TMDD Web Free Text ............................................................................... 16

3.3 VTEC PARSING ................................................................................................................................................. 16 3.3.1 CARS Phrase Mapping ............................................................................................................................. 17 3.3.2 CARS Event IDs ........................................................................................................................................ 18 3.3.3 Consecutive P-VTEC strings in upgrades / downgrades / replacements .................................................. 18 3.3.4 Multiple P-VTEC Events each in its own Product Segment ...................................................................... 20 3.3.5 Multiple P-VTEC Events in a Single Segment ........................................................................................... 22 3.3.6 Closely Related VTEC Strings in an Area-Segmented Event .................................................................... 24 3.3.7 Timing Changes (Headline Editing) ......................................................................................................... 24 3.3.8 Follow-up Warning Products—Special and Severe Weather Statements ................................................. 25

3.4 CAP DETAILED MESSAGE PARSING .................................................................................................................. 27 3.5 VTEC PARSING EXAMPLES ............................................................................................................................... 29

3.5.1 Hurricane and Tropical Cyclone Warnings .............................................................................................. 29 3.5.2 Flash Flood Warnings ............................................................................................................................... 33

3.6 TG-CAP LEVEL 2 .............................................................................................................................................. 35 3.6.1 Flash Flood Polygons ............................................................................................................................... 35 3.6.2 Tornado Polygons ..................................................................................................................................... 35

3.7 TG-CAP EVENT DISPLAY .................................................................................................................................. 39 3.7.1 Display of CAP Events .............................................................................................................................. 39 3.7.2 Display of Area vs. Roadway CAP Events ................................................................................................ 41 3.7.3 CAP Events in the Album Viewer .............................................................................................................. 45



4

1. Concept of Operations

This Third-Gen CARS-CAP (TG-CAP) System Design Document addresses the TG-Web and CARS 4/5 functional component NWS Warnings. This version of CARS-CAP can also include selected NWS Advisories, initially in Sacramento only. NWS Warnings and Advisories is a reference to National Weather Service (NWS) Common Area Protocol (CAP) alerts. The Common Alerting Protocol (CAP) is an XML-based data format for exchanging public alerts and emergencies between alerting technologies. CAP allows an alert message to be disseminated simultaneously and consistently over multiple warning systems to many applications. A single CAP message can be used to trigger sirens, the Emergency Alert System, Weather Radios, telephone notification systems such as 511, state CARS-Web pages, and systems for people with special needs such as the deaf and hearing-impaired. TG-CAP takes zone- and area-based NWS weather alerts and maps them both to roadway extent and area events in TG CARS Web and CARS 4/5. CAP roadway-extent events are not shown on TG CARS-Web and CARS 4/5 maps (except when a list view is also opened), in order to reduce icon clutter. Instead, TG-CAP events are shown using shaded polygons, each with an icon near its centroid. Roadway extent alerts are created primarily for the 511 phone system and other text-based public-facing modules. They are also used in event lists on select screens in TG Web. This document references both “TG CAP Level 1” and “TG CAP Level 2.” TG CAP Level 1 covers the import of CAP 1.1 XML events into CARS. Level 2 – currently funded by Idaho, Sacramento, and Minnesota—expands CARS-CAP to include the tornado and flash flood polygons now being published by NWS. Level 2 also includes the experimental inclusion of selected advisories, initially for deployment in Sacramento only.



5

2. System Requirements

The software shall be tested against the following system requirements. In accordance with Federal Highway Administration policies, the software shall be required to satisfy 100% of critical requirements and at least 80% of other requirements.

# System Requirement Phase Build

1. TG-CAP Level 1 shall support the fully automated import of selected weather zone alerts received from NWS using CAP 1.1.*

1 2.01.00

2. TG-CAP shall receive weather alerts in a one-way data exchange from the state’s NWS’s CAP web pages.*

1 2.01.00

3. Warnings shall be imported from the external system via an automated XML interface.*

1 2.01.00

4. TG-CAP alerts shall not be editable by CARS 4/5 operators.* 1 2.01.00

5. In each state, CAP 1.1 shall read two external XML feed types published by NWS—a summary feed and individual alert feeds.

1 2.01.00

6. CAP alerts shall be able to be presented as county/zone area events in TG Web and CARS 4/5, with icons centered in the shaded polygons.

1 2.01.00

7. CAP flash flood and tornado polygons shall not have area events in the polygonal areas, instead showing roadway events only.

2

8. Warnings imported from the NWS CAP feed shall be able to be presented as roadway extent events in TG-Web and CARS 4/5.

1 2.01.00

9. TG-CAP county/weather zone events shall be announced as named area events in TG-511 metro/regional reports.

1 2.01.00

10. Except for polygons and flash floods, TG-CAP shall create both an area event and a set of similar events mapped to roadways.

2

11. TG-CAP level 1 event zone/area coverage will be determined directly from the areas included in NWS CAP 1.1 XML alert.

1 2.01.00

12. At Level 2, TG-CAP extent events shall be derived dynamically from Flash Flood and Tornado polygons.

2 2.01.00

2.1 CAP Imports

13. TG-CAP Level 1 shall import CAP XML index and selected alert-specific XML messages using CAP 1.1.* 1 2.01.00

14. In the future, TG-CAP may need to be upgraded to import CAP messages using CAP 1.2.

15. TG-CAP shall read CAP data published in XML Direct form.* 1 2.01.00

16. TG-CAP Level 1 shall poll the NWS CAP 1.1 index data feed at 10 second intervals (configurable). 1 2.01.00

17. TG-CAP shall not process the CAP 1.1 XML index page unless the page’s message timestamp has been updated. 1 2.01.00

18. TG-CAP Level 1 shall also read each alert’s VTEC message, a set of fixed-field codes embedded in an index message XML data element. 1 2.01.00

19. Using VTEC, TG-CAP Level 1 shall exclude Watches and (if possible) all Statements. Most Advisory and some Warning alerts shall also be excluded from further reading/processing.

1 2.01.00



6

20. TG-CAP shall attempt to exclude “severe” and “special” weather statements whose VTECs present them as if they are warnings. 1 2.01.00

21. For compliant alert types that have changed, TG-CAP Level 1 shall also read the CAP 1.1 detailed XML message. 1 2.01.00

22. If reading/processing the CAP 1.1 data feeds takes longer than the polling interval, polling shall resume once the current read cycle has completed.

1 2.01.00

23. The following “compliant” warning types shall be imported into TG-CAP:

Blizzard Warning

Flash Flood Warning

Hurricane Force Wind Warning

Ice Storm Warning

Heavy Sleet Warning

High Wind Warning

Severe Thunderstorm Warning

Tornado Warning

Winter Storm Warning

Gale Warning

Hurricane Warning

Tropical Storm Warning

Inland Hurricane Warning

Inland Tropical Storm Warning

Lake Effect Snow Warning

1 2.01.00

24. In addition, the following Advisories shall be added to TG-CAP Level 1:

Dense Fog Advisory

Freezing Fog Advisory

Freezing Rain Advisory

High Wind Advisory

Winter Weather Advisory.

1 2.01.00

25. In the future, TG-CAP may import additional types of NWS Warnings, including:

Dust Storm Warning

Storm Warning

Tsunami Warning

26. In the future, Flood Warning polygons may be imported, to be applied to specific stretches of roadway identified as being subject to frequent flooding.

27. In the future, Avalanche Warnings may be imported, to be applied to specific stretches of roadway identified as being subject to avalanches.

2.2 Alert Management

28. All compliant alerts (i.e., desired alerts whose NWS expiry time has not passed) listed in the index shall be imported by TG-CAP Level 1.*

1 2.01.00



7

29. Each compliant alert in the index shall comprise a separate TG-CAP Level 1 event.

1 2.01.00

30. In TG-CAP Level 1, all alert aggregation shall be handled by NWS. Separate alerts in the index message shall never be aggregated or split.

1 2.01.00

31. In TG-CAP Level 1, compliant alerts with effective time(s) in the future shall be mapped to CARS-Event as future CARS events.

1 2.01.00

32. Should the index contain two or more “now in effect” alerts of the same alert type affecting any given zone, both alerts shall be imported into CARS.

1 2.01.00

33. When a future alert’s effective time is reached, it shall automatically be displayed as a current alert, as for all other future CARS events.

1 2.01.00

34. If any previously existing alert is still shown in the index, it shall be displayed as a separate alert.

1 2.01.00

35. If an alert disappears from the index, or a current alert’s VTEC end time is reached, that alert shall be assumed to have expired.

1 2.01.00

36. When multiple compliant alerts are simultaneously in effect, each shall be represented by separate sets of roadway events plus an area event in CARS.

1 2.01.00

2.3 Mapping Alerts to Events

37. TG-CAP shall map each NWS alert of interest to both an area, plus roadway CARS events.*

1 2.01.00

38. TG-CAP shall map the NWS CAP event phrase to an identical CARS event phrase, using local TMDD event phrases where necessary. *

1 2.01.00

39. When a CAP alert of interest is created or changed, or expires or disappears, corresponding CARS events shall be created, updated or deleted.

1 2.01.00

40. CARS shall track each event committed to the CARS event database using a TG-CAP event ID derived from the VTEC event ID.

1 2.01.00

41. If two compliant alerts have the same VTEC event ID, but separate CAP 1.1 index message entries, they shall not be merged.

1 2.01.00

42. At Level 2, TG-CAP events shall be tracked in the CARS 4 event history.

2 2.01.00

2.4 Area Events

43. Each compliant CAP alert (i.e., each CAP index entry of interest to CAP) shall be mapped to a single area event in CARS.

1 2.01.00

44. At Level 1, severe thunderstorm and tornado warnings shall be mapped to county areas.

1 2.01.00

45. At Level 1, all other compliant alerts shall be mapped to weather zone areas.

1 2.01.00

46. At Level 2, TG-CAP shall map Flash Flood, Tornado and Severe Thunderstorm warnings to storm polygons instead of to counties.

2 2.01.00

47. Each compliant alert in the CAP 1.1 Index shall comprise a separate area event in CARS.

1 2.01.00

48. Zone/county/parish areas may be added to or removed from any predefined area event whenever an alert is updated.

1 2.01.00

49. Updates may cause area events to merge or split. The resulting area 1 2.01.00



8

event ID(s) shall now be derived from VTEC.

50. At Level 2, dynamic areas polygons may change at every alert update. 2 2.01.00

2.5 Roadway Extent Events

51. At Level 1, TG-CAP shall also map the desired CAP alert types to pre-defined CARS-Location roadway segments.

1 2.01.00

52. At Level 2, TG-CAP shall map Flash Flood, Tornado and Severe Thunderstorm warnings to dynamic CARS-Location roadway segments.

2 2.01.00

53. TG-CAP Level 1 shall create an extent event on each stretch of roadway that crosses each single CAP 1.1 alert’s coverage area.

1 2.01.00

54. Each geographically separate stretch of roadway with a given alert shall comprise a separate extent event in CARS.

1 2.01.00

55. The extent of CAP roadway events may change whenever an alert is updated.

1 2.01.00

56. Updates may cause separate extent events to merge or split. The ID of the resulting extent event(s) shall be derived from the VTEC area event ID and the highway’s route designator.

1 2.01.00

2.6 Displaying Events in TG CARS-Web and CARS 4/5

57. TG Web shall include CAP events in its “All Reports” menu; i.e., there shall be no separate NWS or Weather main menu item where they are indexed.

1 2.01.00

58. On its initial map views, TG Web and CARS 4/5 shall display only TG CAP area events; roadway CAP events shall be suppressed.

1 2.01.00

59. TG-CAP roadway events shall appear in TG Web and CARS 4/5 Road Reports event lists.

1 2.01.00

60. Each TG-CAP area event shall initially be shown on TG Web and CARS 4/5 maps using a single icon near the approximate centroid of that part of the area visible in the current map view.

1 2.01.00

61. Each TG-CAP area event shall also be displayed using a translucent polygon appearing over the contiguous affected zones.

1 2.01.00

62. Mousing-over a TG-CAP county/zone event icon shall cause its associated polygon and border to become highlighted.

1 2.01.00

63. If more than five predefined areas are included in an area event, the event description shall state the number of zones/counties/parishes rather than listing all their names.

1 2.01.00

64. Each TG-CAP area event description shall include a hyperlink to the alert’s NWS URL.

1 2.01.00

65. Each TG-CAP area event’s web free text comment shall include event attribution to the appropriate NWS office.

1 2.01.00

66. Each event description shall provide the most recent update time, or (if later) the event’s start time, as detected via the CAP feed.

1 2.01.00

67. Selecting a TG-CAP county/zone area event icon on the map shall open an individual area event report.

1 2.01.00

68. The individual county/zone area event report shall display the area event description.

1 2.01.00

69. Clicking on a CAP roadway event shall open the details of that particular CAP roadway event.

1 2.01.00



9

2.7 Announcement on NG/TG-511

70. TG-CAP area events shall be announced as part of 511 city/regional reports on NG/TG-511 (where deployed).

1 2.01.00

71. States shall specify up to five counties to be included in each county-based 511 regional (city) report.

1 2.01.00

72. States shall also specify up to five NWS zones to be included in each zone-based 511 regional (city) report.

1 2.01.00

73. Areas included in the event but not specified in NG/TG-511 city report configurations shall not be named in 511 regional reports.

1 2.01.00

74. In each report, the alert type (e.g., Tornado Warning) shall be announced once, followed by a list of the areas affected by the alert.

1 2.01.00

75. If all the specified 511 regional/metro report zones are affected by the alert, the event announcement shall say “affecting the area,” instead of listing them.

1 2.01.00

76. CAP roadway extent events shall not be announced as part of NG/TG-511 regional/metro reports.

1 2.01.00



10

3. System Design

In accordance with FHWA’s Systems Engineering Process, this GUI design section is illustrative, rather than definitive. The concepts described below may not all be supported in the final system. The final system may satisfy the functional requirements (Section 2 of this document) in other ways. Module testing and acceptance are based on meeting the functional requirements, rather than deploying the particular concepts and initial ideas of this section.

3.1 Overview

NWS publishes each state’s CAP 1.1 weather alerts at a defined URL, which comprises a new alerts index page. TG-CAP shall poll the index page once every 10 seconds (configurable). TG-CAP shall parse the index message header and use the message timestamp to determine if the CAP 1.1 XML index page has been updated. If the XML has been updated, TG-CAP shall parse each index <entry>’s VTEC field, importing CAP 1.1 detailed alert messages of interest and adding, updating or removing CARS events to match the latest data.

Alerts that disappear from the index feed shall be immediately deleted in CARS. Although CAP 1.1 contains some CANcelled and EXPired NWS alerts, these manual messages are not used consistently, and they shall therefore be ignored.

The default cycle time in TG-CAP Level 1 shall be 10 seconds. If the CAP 1.1 XML index has not changed since the previous poll, TG-CAP Level 1 shall stop parsing, wait for the next polling instant, and repeat the process. That is, TG-CAP Level 1 shall check the index page’s time stamp every 10 seconds (configurable), unless it is still busy with the previous update. This vastly improved cycle time is required so that tornado warnings can be identified almost immediately.

Appendix A to earlier drafts of this SDD provided documentation of the CAP 1.1 data standard and XML schema.

3.2 NWS Practices

3.2.1 Zones, Counties and Polygons

The old, NWS CAP 1.0 feed confused zones and counties, by conveying county FIPs codes instead of the NWS zone codes required for many NWS warning products. The CAP 1.1 index message still has this problem. However, the problem has been fixed in the CAP 1.1 detailed message by CAP 1.1 including the “correct” UGCs—a list of either county weather zone codes, according to event type. TG-CAP Level 1 shall use the detailed CAP 1.1 warning or advisory message, rather than the index, to determine the UGC (i.e., the event’s location). All the other required data is in the index message. The table below says that NWS uses zones for winter weather and flash flood alerts, but counties for severe thunderstorms and tornadoes. In reality, however, the examples in the appendices to this SDD show that NWS is using counties for flash flood locations, as well as for severe thunderstorms and tornadoes.



11

NWS makes it clear that neither counties nor zones ought to be used for short-duration, high impact events. Location-specific storm polygons ought to be used instead of counties for flash flood, tornado and severe thunderstorm warnings. This key feature will be included for states that deploy TG-CAP Level 2.

3.2.2 NWS Products, Segments and Events

NWS Winter Weather Warning products are collections of alerts that fully describe a weather hazard. Each product may include a variety of events, such as a Blizzard Warning, a Freezing Rain Advisory, and a Winter Storm Watch, all in a single product issuance. Also, if each event is for a different geographic area, then the Winter Weather product is issued in multiple segments, each describing a specific event for a specific area. There may also be multiple segments within a single product which cover the same event, each for a different area. The reason for the multiple segments might be different storm timing or forecast accumulations in the different areas. The multiple segments of a single event such as a Blizzard Warning may all share the same NWS Event Tracking Number (ETN).

The general approach proposed to be followed in TG-CAP Level 1 is to focus on NWS events such as WS.W (Winter Storm Warning), rather than on NWS products and segments. However, NWS segments may also be significant in defining CARS events, if an event occurs at multiple locations (i.e., in NWS terminology, has multiple segments) or is geographically spread across time (e.g., as a winter storm progressively sweeps across a state).

3.2.3 CAP Index Message Polling

In TG-CAP Level 1, the polling rate of the statewide CAP URL (which now contains the statewide CAP index message) will be increased from once every five minutes (as currently implemented) or from once every minute (as CAP 1.0 was designed) to once every 10 seconds. This is made possible by the much smaller size of the index message in CAP 1.1, due to the elimination of most CAP 1.0 redundancy. This polling rate will not be changed without design team approval. The high frequency is required for immediate response to tornado warnings, where time is especially critical. Each state’s NWS CAP 1.1 index page begins with the header information provided below (defined by the CAP 1.1 standard). The blue text (and not the gray text) will be used by TG-CAP Level 1. The CAP 1.1 XML index messages presented below can be viewed in earlier drafts of this SDD in their entirety.

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>

<?xml-stylesheet href='http://alerts.weather.gov/cap/capatom.xsl'

type='text/xsl'?>



<feed

xmlns = 'http://www.w3.org/2005/Atom'



12

xmlns:cap = 'urn:oasis:names:tc:emergency:cap:1.1'

xmlns:ha = 'http://www.alerting.net/namespace/index_1.0'

>



<id>http://alerts.weather.gov/cap/al.atom</id>

<logo>http://alerts.weather.gov/images/xml_logo.gif</logo>

<generator>NWS CAP Server</generator>

<updated>2011-04-27T20:37:00-05:00</updated>

<author>

<name>[email protected]</name>

</author>

<title>Current Watches, Warnings and Advisories for Idaho Issued by the

National Weather Service</title>

<link href='http://alerts.weather.gov/cap/id.atom'/>

The feed field shall be checked to ensure that the index message is CAP 1.1. If xmlns:cap does not specify CAP 1.1, the software shall stop importing CAP messages, and a comprehensible and clear error message shall be written to the software operations log.

The statewide index’s updated field shall be checked to determine whether the index message has been updated since its last scan, usually 10 seconds ago. If the difference between this time and the current CARS system time is more than 5 minutes, a comprehensible and clear error message shall be written to the software operations log. The updated type xsd:dateTime represents a specific local date and time in the format CCYY-MM-DDThh:mm:ss.sss—a concatenation of xsd:date and xsd:time, separated by a literal letter "T". All of the XML rules that apply to the xsd:date and xsd:time types apply to xsd:dateTime as well. NWS adds an optional time zone expression at the end of the value, representing the local time difference from Coordinated Universal Time (-hh:mm). These values range from -10:00 to -4:00 in the U.S. For example, US Eastern Standard Time, which is five hours behind UTC, is represented as -05:00. Note that CAP 1.1 has changed from CAP 1.0 in that XML date/time fields are now defined in local time with a UTC offset, rather than being in UTC (as was the case for CAP 1.0 messages). In the case of Idaho, NWS messages originating in Boise, Poctatello and Missoula are in Mountain Time, messages from the Spokane weather office are in Pacific Time. The default time zone of Idaho CARS is Mountain. TG-CAP Level 1 must handle all the time zone conversions for message checking, and for the correct display of CAP 1.1 event data in CARS. If the XML index message’s updated time is the same as it was on the last read, the rest of the index page shall not be processed. If the timestamp has altered, then every entry on the state’s NWS CAP 1.1 index page must be read and processed. The remainder of the introductory header (grey text) will not be used by TG-CAP Level 1. In the future, TG-CAP may be integrated with CARS-Log and will log error messages there as well.

3.2.4 CAP Index Message Parsing

When TG-CAP is reading a CAP 1.1 XML index file after a restart, or if the file has changed since the previous poll of the index message, TG-CAP shall parse the entire contents of the index message file. Each <entry> in the index message refers to an NWS alert currently active in the state.

http://alerts.weather.gov/cap/id.atom



13

In TG-CAP, there shall be a one-to-one correspondence between “compliant” index entries (desired by CARS) and CARS events.

The CAP 1.1 XML index for the first entry of a sample index page is as follows. The blue text will be used by TG-CAP Level 1. The first index entry below is a non-compliant Warning—i.e., a warning of a type not wanted by TG-CAP Level 1.

3.2.5 Non-compliant (unwanted) Index Entry

<entry>

<id>http://alerts.weather.gov/cap/wwacapget.php?x=ID20110430194400FreezeWarni

ng20110501150000ID.PIHNPWPIH.b7c258257d5dafd832c156791eb5da4a</id>


<published>2011-04-30T13:44:00-06:00</published>

<author>


</author>

<title>Freeze Warning issued April 30 at 1:44PM MDT expiring May 01 at 9:00AM

MDT by NWS Pocatello http://www.wrh.noaa.gov/Pocatello/</title>

<link

href="http://alerts.weather.gov/cap/wwacapget.php?x=ID20110430194400FreezeWar

ning20110501150000ID.PIHNPWPIH.b7c258257d5dafd832c156791eb5da4a"/>

<summary>...FREEZE WARNING IN EFFECT FROM 1 AM TO 9 AM MDT SUNDAY... THE

NATIONAL WEATHER SERVICE IN POCATELLO HAS ISSUED A FREEZE WARNING...WHICH IS

IN EFFECT FROM 1 AM TO 9 AM MDT SUNDAY. * TEMPERATURES: 25 TO 30. * TIMING:

FALLING BELOW 30 AFTER MIDNIGHT. * LOCATIONS INCLUDE:

POCATELLO...BLACKFOOT...MASSACRE ROCKS...</summary>

<cap:effective>2011-04-30T13:44:00-06:00</cap:effective>

<cap:expires>2011-05-01T09:00:00-06:00</cap:expires>

<cap:status>Actual</cap:status>

<cap:msgType>Alert</cap:msgType>

<cap:category>Met</cap:category>

<cap:urgency>Expected</cap:urgency>

<cap:severity>Moderate</cap:severity>

<cap:certainty>Likely</cap:certainty>

<cap:areaDesc>Eastern Magic Valley; Lower Snake River Plain; Upper Snake

River Plain</cap:areaDesc>

<cap:geocode>

<valueName>FIPS6</valueName>

<value>016005 016011 016013 016019 016023 016031 016051 016063 016065 016067

016077</value>

</cap:geocode>

<cap:parameter>

<valueName>VTEC</valueName>

<value>/O.NEW.KPIH.FZ.W.0002.110501T0700Z-110501T1500Z/</value>

</cap:parameter>

</entry>

The CAP 1.1 index message consists of a series of <entry> </entry>. The information initially required by TG-CAP Level 1 to determine event compliance is the type of alert. The initial question to be answered is whether or not this a Warning (W) or Advisory (Y) of a type required by TG-CAP Level 1 (e.g., Blizzard Warning). Unfortunately, this information is given in free text that it appears the NWS forecaster can edit, e.g., <title>Freeze Warning … NWS has now given forecasters the ability to manually edit the event’s headline, to read (for example), to the hard-to-parse WINTER STORM WARNING UPGRADED TO BLIZZARD WARNING ... We are not completely sure how that



14

authorization applies to the new <title> field of CAP 1.1, as no “live” examples have been found, but we prefer to be cautious about the expected contents of <title>. Inside each XML index <entry> is one or more embedded VTEC messages containing NWS alert (warning, advisory, ...) type codes. This VTEC value will therefore be parsed. The value field consists of one or more VTEC “messages”, each of which starts and ends with “/”. VTEC messages of interest are called P-VTEC messages, and always start with an “O” (for “operational”). Each P-VTEC message contains seven data elements, separated by six dots “.”. Each operational P-VTEC message must be checked to see if the 5th data element (“W” above) is “W” for warning or “Y” for advisory. If it is not “W” or “Y” (say, “S” or “A”), the P-VTEC message does not relate to an NWS Warning or Advisory and can be ignored. If none of the entry’s VTEC values are “O” (operational), or none contain “W” or “Y” in position #5, then the entire XML index <entry> can be ignored. Above, the P-VTEC message contains “W” for warning, which is of potential interest. In this case, the fourth VTEC data element must be compared with a list of alert type codes, to see if this is a Warning of interest to TG-CAP Level 1. The code “FZ” indicates a freeze warning, which is not required by TG-CAP. Therefore, this alert shall not be processed further by TG-CAP Level 1.

3.2.6 Compliant Index Entry

The CAP 1.1 XML index for the entry of the first Warning on the sample of the CAP 1.1 index message shown in earlier SDD versions is extracted below. The data were gathered during the 2010 winter, when the NWS feed was still in Beta. There are minor differences in the URLs that were used when the feed was Beta, but in other respects it appears not to have changed in going live.

<entry>

<id>http://www.weather.gov/alerts-

beta/wwacapget.php?x=ID20101127200800OTXWinterStormWarningOTX20101128000000ID

</id>


<published>2010-11-27T12:08:00-08:00</published>

<author>


</author>

<title>Winter Storm Warning issued November 27 at 12:08PM PST expiring

November 27 at 4:00PM PST by NWS Spokane

http://www.wrh.noaa.gov/Spokane</title>

<link href="http://www.weather.gov/alerts-

beta/wwacapget.php?x=ID20101127200800OTXWinterStormWarningOTX20101128000000ID

"/>

The alert type will be determined from VTEC fields below, and not initially from the title field above. However, for alerts of interest (such as this WS.W) we next need to check that the title text contains the equivalent text string somewhere (in this case, “Winter Storm Warning”). The reasons why this double check is required are explained in the next few pages. If the text string is found, the title text shall be copied into the TG-CAP event’s public free text (public comments) field, omitting the URL:



15

Winter Storm Warning issued November 27 at 12:08PM PST expiring November 27 at 4:00PM PST by NWS Spokane

The “link href” will be used in TG-CAP Level 1 to take TG Web and CARS 4/5 users to the detailed CAP 1.1 message. (As noted previously, the feed is no longer in beta format, as it had been in the example above). The NWS’s XML style sheet will make the message readable in most browser versions. The detailed message’s source XML will also need to be parsed, in order to obtain the UGC, as explained in later sections. <summary>...PERIODS OF SNOW TO CONTINUE TODAY AND TONIGHT... ...WINTER STORM

WARNING REMAINS IN EFFECT UNTIL 4 PM PST THIS AFTERNOON... A WINTER STORM

WARNING REMAINS IN EFFECT UNTIL 4 PM PST THIS AFTERNOON. * SNOW

ACCUMULATIONS: AN ADDITIONAL 1 TO 2 INCHES FOR THE SPOKANE</summary>

<cap:effective>2010-11-27T12:08:00-08:00</cap:effective>

<cap:expires>2010-11-27T16:00:00-08:00</cap:expires>

<cap:status>Actual</cap:status>

<cap:msgType>Alert</cap:msgType>

<cap:category>Met</cap:category>

<cap:urgency>Expected</cap:urgency>

<cap:severity>Moderate</cap:severity>

<cap:certainty>Likely</cap:certainty>

<cap:areaDesc>Bonner; Boundary; Coeur d'Alene Area; Fremont; Kootenai;

Northern Panhandle</cap:areaDesc>

<cap:geocode>


<value>016017 016021 016043 016055</value>

</cap:geocode>

<cap:parameter>


<value>/O.CON.KOTX.WS.W.0009.000000T0000Z-101128T0000Z/</value>

</cap:parameter>

</entry>

VTEC parsing again starts by looking for “O” in VTEC field #1. If “O” is found, VTEC field #5 which must checked to see if it is “W” or “Y” for Warning or Advisory. If “W” or “Y” is found, then VTEC fields #4 and #5 are checked for any of the desired TG-CAP alert types, in this case “WS.W”. The title field is finally searched for the specific string implied by the VTEC alert type (in this case, “Winter Storm Warning”). All these tests must be passed before CARS will import an area event from the CAP 1.1 index <entry>. For NWS events required by CARS, the <title> (except for the URL) and part of the <summary> shall be copied into the CARS web text field, up to and including summary’s fourth elipsis or period. To implement this, count every period that isn’t followed by a period, and truncate the string after the fourth counted period. The CARS event update time and the event end time shall be set to the NWS updated and cap:expires times, after any required time zone corrections. If the cap:expires time comprises a string of zeros (which will be the case for Hurricanes and related alerts), the CARS event has no end time, being valid until further notice. In TG-CAP Level 1, XML local times will be used in preference to the



16

VTEC UTC event start and end times because NWS leaves the VTEC times blank in several circumstances (see NWS VTEC Directive).

3.2.7 Mapping CAP Description to TMDD Web Free Text

The text of the CAP XML index message’s <title> field (excluding the weather office URL, which always comes at the end) shall be copied into the CARS web free text field. The URL will be omitted to help avoid URL clutter. Only one URL shall be present in each event description, linking to the style sheet version of the detailed XML message. <title>Winter Storm Warning issued November 27 at 12:08PM PST expiring

November 27 at 4:00PM PST by NWS Spokane

http://www.wrh.noaa.gov/Spokane</title>

A blank line shall follow the <title> text. Then, the first part of the index message’s <summary> field shall be mapped to CARS TMDD web free text, excluding any text that follows the fourth elipsis “… ” or period “.” Should the forecaster type “..” or “....”, this also comprises a single count. The rule is to count all periods that are not followed by a period. If four instances of “…” or “.” are not found, then all the <summary> text shall be included in CARS TMDD web free text.

3.3 VTEC Parsing

VTEC parsing will allow some other information required by TG-CAP Level 1 to be extracted from the CAP 1.1 Index message. As explained above, without the use of VTEC, the CAP 1.1 index message does not contain all the information required to determine if each index entry is relevant to TG-CAP (without parsing <title> free text, whose “headline” NWS operators are now allowed to change). Not all VTEC strings need be parsed. For example, where present, the H-VTEC string below shall be totally ignored, as shall certain P-VTEC strings. H-VTEC strings always begin with 5 characters before the first “.”, and follow a P-VTEC, whereas P-VTECs of interest always begin with a single “O” character followed by the separator “.”, i.e., “O.”. P-VTEC strings can follow one another, as explained later. P-VTEC strings starting with T, E or X shall always be ignored, as shall P-VTEC strings containing action codes (aaa—field #2) of UPG, CAN, EXP, and ROU1. Finally, if the VTEC <value> field is empty (as is often the case for “Special Weather Statements”), then the index <entry> is not of interest to TG-CAP.

The action field aaa (#2) tells TG-CAP Level 1 whether to create a new event (“NEW”) with a CARS update number of 1, to update an existing event (“CON, EXT, EXA, EXB, COR”), incrementing the CARS event’s update counter, or whether to end an event (“CAN, EXP”), or change the alert type, causing it to be counted as a new alert in NWS practice (“UPG”). Ending or greatly changing an old event to a new event type is not of direct interest to TG CARS-CAP, which can focus on the immediate future, letting the old events be superseded automatically. Thus, P-VTECs containing UPG, CAN, EXP and ROU can be ignored by TG-CAP Level 1.

1 The action ROU should never occur in a P-VTEC of interest to TG-CAP, but if it does, this P-VTEC string shall be ignored and an error message written to the TG-CAP operations log.



17

To recap: P-VTEC strings of interest always begin with “O.” (signifying an operational message) and contain action codes of NEW, CON, EXT, EXA, or EXB. All other VTEC strings (including empty strings containing no VTEC message) shall be ignored.

3.3.1 CARS Phrase Mapping

Using the fourth (#4) VTEC field, Phenomena (pp), and the fifth (#5) field, Significance (s), each phenomenon of significance to TG-CAP shall be mapped to a CARS event phrase. The specific phrase mapping of the Phenomena and Significance fields is defined in a table, later in this SDD. CARS phrases used in TG-CAP shall match NWS <title> text exactly. The table below defines how VTEC phrases shall be mapped to CARS TMDD categories and phrases. Only the CAP alerts listed in the table below shall be mapped to CARS events. All other CAP alerts shall be ignored.

VTEC alert Phenomena Significance TMDD Event Phrase

Blizzard BZ W Blizzard Warning

Extreme Wind EW W Extreme Wind Warning

Flash Flood FF W Flash Flood Warning

Dense Fog FG Y Dense Fog Advisory

Gale GL W Gale Warning

Heavy Snow HS W Heavy Snow Warning

Hurricane Force Wind HF W Hurricane Force Wind Warning

Inland Hurricane HI W Inland Hurricane Warning

Hurricane HU W Hurricane Warning

Ice Storm IS W Ice Storm Warning

High Wind HW W High Wind Warning



18

Lake Effect Snow LE W Lake Effect Snow Warning

Severe Thunderstorm SV W Severe Thunderstorm Warning

Inland Tropical Storm TI W Inland Tropical Storm Warning

Tornado Warning TO W Tornado Warning

Tropical Storm TR W Tropical Storm Warning

Winter Storm WS W Winter Storm Warning

Freezing Fog ZF Y Freezing Fog Advisory

Freezing Rain ZR Y Freezing Rain Advisory

3.3.2 CARS Event IDs

NWS assigns ETNs (event tracking numbers) sequentially each year by NWS weather office, for each combination of unique event phenomenon and significance (i.e., each event type).2 A new ETN is assigned only when the VTEC action code is NEW. The last three characters of the Weather Office ID cccc shall be used in conjunction with the phenomena and significance fields, the year of the event’s creation followed by a hyphen, and then its ETN ####, plus one additional letter x assigned by CARS (a through z), to create a unique event identifier: cccPPSYYYY-####x. The event ID cccPPS2011-#### has been found to be unique in every CAP 1.1 example tested, with one exception. The exception (for which the a, b, c, ... letters are required) is discussed in later subsections, below. In Louisiana, tropical cyclone warnings will normally use a mix of nationally and locally generated ETNs for a given tropical cyclone. Not every nationally generated ETN will be used in Louisiana in any given season. Certain warning types will use national ETNs, and others, local. TG-CAP will assume that NWS has created procedures inside AWIPS (the NWS forecasters’ equivalent of CARS) that prevent nationally developed ETN codes from being duplicated as local codes. Many more details are given in NWS VTEC Directive (Appendix C to earlier versions of this SDD), though no definite answer has been found on how (or whether) this works. If NWS event codes actually conflict, then some update sequences may become scrambled; however, the basic pattern of events displayed in CARS at any instant should still be correct, even if linkages between them were to go wrong. Note also that Heavy Snow Warnings (HS.W) were to be included in the TG-CAP Level 1 warning list, but they (along with some other event types) have been discontinued by NWS (see Appendix M of earlier versions of this SDD). Heavy snow is now handled as a Winter Storm Warning (WS.W).

3.3.3 Consecutive P-VTEC strings in upgrades / downgrades / replacements

NWS uses two sequential P-VTEC strings in products such as WS.W (Winter Storm Warning) when an event for the same area is (1) upgraded/downgraded to a different significance level (e.g., an advisory is being upgraded to a warning, or a warning is being downgraded to an advisory) or (2) replaced by a different but environmentally similar event, e.g., a Winter Storm Warning is being replaced by an Ice Storm Warning. Below, a Tropical Storm Warning is upgraded to a Hurricane Warning. /O.UPG.KLCH.TR.W.0002.000000T0000Z-000000T0000Z/

2 If a backup weather office issues an alert for another office’s area, the NWS four-letter identifier should indicate the

NWS office with the primary responsibility for the event’s location.



19

/O.NEW.KLCH.HU.W.0001.070913T0607Z-000000T0000Z/ The old alert is cancelled, and a new alert ID is created. It seems that the /old/new/ linkage is needed by NWS to track certain types of major event edits because of the fact that it numbers its own events sequentially (in order of their creation) separately for every alert type. Because the event type changes, the NWS-based event ID must change from lchTRW20111-0002 to lchHUW2011-0001. The backwards-linkage above is apparently intended to allow event histories to be tracked through the change of event ID—though only by building a special database to store and trace multiple former event IDs. CARS, on the other hand, is able to maintain event IDs consistent across all kinds of updates—whether to event descriptions, event times, or locations—by using a single sequence of event IDs in each state, allowing any of these variables (including the headline phrase type or headline phrase itself) to be changed without messing up the event ID. In this case, though, we want to make CARS follow NWS practices as far as is reasonably possible, so a CARS event ID at least partly based on the NWS model is desired. Below, NWS Boise has done (in data captured live by CR) something different from that of the example above, but with a similar effect to that described in the VTEC Directive: <value>/O.CAN.KBOI.WW.Y.0044.000000T0000Z-101128T1200Z/ /O.NEW.KBOI.WW.Y.0046.101127T2200Z-101128T1200Z/</value> Boise cancels a WW.Y NWS event (0044) and replaces it with a WW.Y having a new NWS event number (0046). We have no clear idea why NWS does this, given that the stated purpose of ETN is to allow events to be tracked across updates. It looks as if Boise changed the event ID merely because the event’s end time changed. As we don’t have the previous event details, we cannot be sure what else was changed. In other examples, though, this does not happen, and the event is updated without being renumbered. Above, the old alert is cancelled and a new alert (with a new ETN) begins. We propose that CARS will follow NWS event numbering, adopting a new event number when NWS does, and not worrying about the old/new linkage being traced in the examples above. Uses of event histories in CARS are relatively limited, and a major new development would be needed to track the VTEC backwards links such as those above. Instead, TG-CAP shall continue to focus on what’s starting, allowing ending events to end because they have been changed to EXP status, or have disappeared from the feed. This means that TG-CAP can ignore the CANcelled and UPGraded VTECs in the two examples above, and use only the continuing NEW events. In this case, it happens that Boise’s WW.Y (Winter Weather Advisory) is not a compliant TG-CAP Level 1 event, anyway; but the same principles should apply to warnings and advisories of interest to TG-CAP.



20

The table above shows that in these examples, the first P-VTEC string—the action code UPG or CAN—shall be used to identify and then ignore the old event being upgraded or downgraded/replaced. In the second P-VTEC string, the action code NEW is used to start a brand new NWS event, or an action code EXA, EXB, or EXT is used to add to an already existing NWS event. Or, if a correction is required for an upgrade, downgrade, or replacement, the COR action code may replace just the NEW, EXA, EXB, or EXT, and not the CAN or UPG action code. TG-CAP Level 1 will handle all of these situations by ignoring all P-VTEC strings whose action codes are UPG or CAN. The old CARS event that NWS just upgraded or cancelled need not be explicitly deleted; the fact that it no longer exists with a continuing action code in the statewide index message will be sufficient to cause it to end in CARS. TG-CAP Level 1 will instead process P-VTEC strings containing NEW, EXA, EXB, EXT and COR. This will cause many messages containing two P-VTEC strings to be simplified to one P-VTEC string, which focuses on the new situation rather than on the old one.

3.3.4 Multiple P-VTEC Events each in its own Product Segment

Review of actual data and NWS operational directives shows that most event-driven NWS products or product segments will contain one P-VTEC. A few will contain two P-VTEC strings in which the first can be ignored, as outlined above. This still leaves open a few cases in which a single NWS event includes multiple VTECs. In some observed cases, these are each in their own event “segments” (similar to CARS event elements). It appears that the NWS CAP 1.1 team usually delivers NWS phrase-based “events” rather than compound “products”, and separates geographically segmented events into separate index <entries>. Below, NWS Spokane weather forecast office (WFO) segments a Winter Storm Warning (WS.W) product into three geographical index entries, each product segment having its own expiry time. The three index entries all share the same WFO code, ETN, and alert phrase, but end at different



21

times as the storm moves south. It is this circumstance that requires TG-CAP event IDs to use a letter “x” at the end, so as to distinguish between these geographic event “segments”. The equivalent concept in CARS would be a multi-element event with a single ID and unique element numbers. In this case, however, we propose to handle the geographic “segments” as three separate CARS events (see Appendix B of earlier drafts of this SDD for full XML index <entry>s): Segment 1 (IDC 017, 021, 043 and 055) <title>Winter Storm Warning 12:08-4:00pm PST <valueName>FIPS6</valueName> <value>016017 016021 016043 016055</value> <valueName>VTEC</valueName> <value>/O.CON.KOTX.WS.W.0009.000000T0000Z-101128T0000Z/</value> The CARS event ID for the above shall be otxWSW2011-0009a Segment 2 (IDC 009, 057, 069) <title>Winter Storm Warning 12:08-7:00pm PST <valueName>FIPS6</valueName> <value>016009 016057 016069</value> <valueName>VTEC</valueName> <value>/O.CON.KOTX.WS.W.0009.000000T0000Z-101128T0300Z/</value> The CARS event ID for the above shall be otxWSW2011-0009b Segment 3 (IDC 009, 055, 057, 079) [Note that 3 of these four counties also occur above]3 <title>Winter Storm Warning 12:08-10:00pm PST <valueName>FIPS6</valueName> <value>016009 016055 016057 016079</value> <valueName>VTEC</valueName> <value>/O.CON.KOTX.WS.W.0009.000000T0000Z-101128T0600Z/</value> CARS event ID for the above shall be otxWSW2011-0009c Having had TG-CAP assign codes a, b, and c to identify duplicate event IDs found in a single instance of an NWS index message, when NWS fails to provide any means of numbering the event “segments” (event elements), the question arises: when any update occurs to the index message, how do we decide which new, similar-looking <entry> is now a, which is b and which is c? At Level 1, for speed and simplicity, TG-CAP shall simply assign a, b, c again in the sequential order in which these events appear in the NWS CAP 1.1 index message, without trying to track any one CARS event to its successor event. Thus, locations of any specific event may jump around. When Level 2 is implemented, TG-CAP may use the following algorithm to resolve this.

3 My guess is that this apparent blunder happened because the forecaster chose discrete zones for each event “segment”/”element”, but AWIPs then wrongly mapped the zones to counties. As most Idaho counties are split across multiple weather zones, the counties appear to be duplicated. In Idaho County 055, as a result, the storm ends at both 4 pm and again at 10 pm. Really, it was expected to end at 4 pm in part of the county, and at 10 pm in another part that happens to be in a different weather zone. Notice that NWS is still making this mistake in its index messages. Only the detailed message contains the information required to identify the affected areas clearly.



22

1. As TG-CAP processes the new index instance, it shall identify all the new duplicate segment instances sharing a given CARS event ID such as otxWSW2011-0009. (There may be more than one event ID having multiple segments, and if so they shall be processed sequentially.) 2. The UGCs in each updated event (say a´, b´, c´—although the number of duplicate segments may have increased or decreased) of the new index message shall be tested against the UGCs of a, b and c, forming a triangular matrix of scores. One point is scored in each pairwise comparison for every UGC that matches. 3. The new segment having the highest pairwise matching score is assigned to its corresponding old segment (say, b´ becomes the former segment a, b or c, having the highest overall matching score). 4. If multiple pairs have equal highest matching scores, preference shall be given to the first listed segments in the (1) the old, and then (2) the new, index instances. 5. Having matched one new segment, matching is repeated for the remaining old and new segments until any new segments remaining have matching scores with all old segments of zero. 5. These unmatched new segments becomes segment d, e, f, etc. (the next unused alphabetic segment identifier). 6. Any old segments that were not matched simply disappear. Given that segments are created manually, we believe that there will never be large numbers of segments in a given event in any state at any one time.

3.3.5 Multiple P-VTEC Events in a Single Segment

Given that the NWS VTEC team asserts that more than one P-VTEC may coexist in a single unsegmented product or product segment, we need to address this possibility. Examples have been found with two P-VTECs, one of which is compliant (wanted by TG-CAP). In principle, both P-VTECs could have been compliant. In all products containing the VTEC, NWS states that the P-VTEC strings will be sorted by the following criteria: a. First, by P-VTEC action code in the following order: CAN, EXP, UPG, NEW, EXB, EXA, EXT, CON. (The ROU action code appears only in Flood Warnings for Forecast Points [in H-VTEC?], and when it does, it will be by itself.)4 b. If two or more P-VTEC strings contain the same action code, then they are sorted by significance level (in the order W, Y, A, S). For example, WS.W (winter storm warning) would come in front of ZR.Y (freezing rain).

4 An exception (already discussed in the previous section) is made for upgrade and downgrade/replacement situations, where the P-VTEC strings containing the UPG and either NEW, EXA, EXB, or EXT (for upgrade) or the CAN and either NEW, EXA, EXB, or EXT (for downgrade or replacement) action codes will appear together, regardless of any other P-VTEC strings which appear in that segment. Note, however, that the UPG and CAN P-VTEC actions are ignored by TG-CAP, thereby resolving this specific issue.



23

c. If two or more P-VTEC strings contain the same action code and significance level, then they shall appear in chronological order by Event Beginning Time. d. If two or more P-VTEC strings contain the same action code, significance level, and Event Beginning Time, then they shall be sorted by phenomenon code (in alphabetical order). To parse these cases, should they occur, the rule to be used in TG-CAP Level 1 is as follows. Should two or more P-VTECs of interest (such as WS.W plus FG.Y, or WS.W plus ZF.Y—a winter storm warning plus a dense or freezing fog advisory) be discovered in a single index <entry>, then a CARS event containing both (or all of the) phrases shall be created, using the same phrase (P-VTEC) sequence as that adopted by NWS. Appendix G to earlier drafts of this SDD includes the following “live” example of two P-VTECs in a single event, but the second (wind chill warning) is not imported into TG-CAP.

<value>/O.CON.KBOI.BZ.W.0001.000000T0000Z-101124T0000Z/

/O.CON.KBOI.WC.W.0002.101124T0400Z-101124T1700Z/</value>

Unfortunately, this particular NWS Blizzard Warning duplicates the one above it in two counties, and contradicts it in terms of expected end time. This may have been a forecaster’s mistake, or an artifact of AWIPS alert editing, and cannot be totally prevented from being published by TG-CAP without risk of also filtering out valid messages. However, the <title> field of this event is not really consistent with the TG-CAP import, so by having TG-CAP Level 1 search for the presence of the correct VTEC title string (in this case, “Blizzard Warning”) in the <title> field, before accepting a VTEC event into CARS, we can filter out the second occurrence: <title>Wind Chill Warning issued November 23 at 10:20AM MST expiring November

24 at 10:00AM MST by NWS Boise http://www.wrh.noaa.gov/Boise/</title>

TG-CAP will create the assumed <title> string from the BZ.W (etc.) codes, such as “Blizzard Warning”, based on the VTEC string parsing described herein. It will then search for “Blizzard Warning” in the <title> string, accepting the alert into CARS only if the appropriate characters appear somewhere in the title—not necessarily right at the start. This should allow the following example of alert editing to pass into CARS, while preventing alerts titled Wind Chill Warning, etc., from being accepted:

WINTER STORM WARNING UPGRADED TO BLIZZARD WARNING ... The general form of headline edits recommended in Appendix K to earlier drafts of this SDD is

…[HAZARD NAME] UPGRADED TO [HAZARD NAME]… or …[HAZARD NAME] REPLACED BY [HAZARD NAME]…

Note that since CAP 1.1 was introduced, the UPPER CASE headlines have been replaced by Title Case <title>s. NWS directives have not been reissued, so we are guessing that the old rules still may apply.

http://www.wrh.noaa.gov/Boise/%3c/title



24

Both of these standard forms recommended above should pass the <title> string check approach proposed here, with the VTEC-generated string in the second place. Of course, any manual edit opens up the possibility that the critical string will contain a typo, but unfortunately this can’t be helped. We guess that these computer-generated strings will more often be cut, pasted or deleted rather than re-typed, and if we lose an occasional miss-spelled alert, this is perhaps less serious than sending out a Wind Chill Warning as if it were a Winter Storm Warning. If a TG-CAP event is ever created using two phrases, only the first (headline) phrase shall be checked against the NWS <title> field. This will ensure that the NWS <title> is at least somewhat similar to the CARS event headline phrase.

3.3.6 Closely Related VTEC Strings in an Area-Segmented Event

A further example below is taken from Appendix C to earlier drafts of this SDD. It shows how two zones (the first NWS segment) were added to an existing warning5 (the second segment below) by creating near-identical P-VTEC strings, one using the EXA action and the other using CON. (segment 1 of 2 within RFW product - expanded portion of warning) FLZ058-302300- (UGC)

/O.EXA.KMLB.FW.W.0038.070430T1700Z-070430T2300Z/ (P-VTEC) (segment 2 of 2 within RFW product - original portion of warning) FLZ041-044>046-053-144-302300- (UGC)

/O.CON.KMLB.FW.W.0038.070430T1700Z-070430T2300Z/ (P-VTEC) Both P-VTECs contain the same information (that we’ll assume to be) of interest to CARS, so there is a case for aggregating the two events (if the affected areas and times all matched) such that TG-CAP would handle the two VTEC strings as if they were just one. The affected area is the aggregate of the two predefined area lists. However, rather than start grouping and ungrouping NWS areas, TG-CAP will stick to its policy of adopting the same aggregation as does the CAP 1.1 index message. Should the index look like the example above, then there are two events (with event IDs ending in a, b ...6); or if the CAP 1.1 feed combines them, then there is just one. Thus, the forecasters’ groupings will be used, whether they seem to be sufficiently aggregated or not. Each index entry will create a CARS event containing all the valid VTEC phrases to be carried by TG-CAP; and the CARS key phrase (based on VTEC alert type) will be checked to confirm that it exists somewhere in the NWS <title>.

3.3.7 Timing Changes (Headline Editing)

This next example of possible complexity/inconsistency issues to be addressed—multiple phrases in a single <entry>—is taken from Appendix K to earlier drafts of this SDD. In some cases, changing the valid time of a hazard can create confusing multiple headlines. For example, if a forecaster

5 It happens that this is a “Red Flag” (Fire) warning of type not required by TG-CAP, but the process may be similar for warnings of interest to TG-CAP. 6 Note: while we think that NWS event “segments” in time or space are similar to CARS event “elements”, we are NOT proposing that multi-element events be created in CARS. Each “segment” or “element” will be mapped to a separate CARS event, whose event ID will end in a, b ...



25

changes the valid times in a case where a wind advisory follows a high wind warning, and both are valid in the first three hours, the following headlines are created (P-VTEC included for reference): /O.NEW.Kyyy.HW.W.0015.061121T1900Z061121T2100Z/ /O.EXT.Kyyy.WI.Y.0008.061121T2100Z-061122T0200Z/ ...HIGH WIND WARNING IN EFFECT UNTIL 1 PM PST THIS AFTERNOON... ...WIND ADVISORY NOW IN EFFECT UNTIL 6 PM PST THIS AFTERNOON... NWS states that the preferred headlines (to be manually created) are: HIGH WIND WARNING IN EFFECT UNTIL 1 PM PST THIS AFTERNOON... ...WIND... ADVISORY IN EFFECT FROM 1 PM UNTIL 6 PM PST THIS AFTERNOON... Now, in this specific case, TG-CAP Level 2 will (for the first time) be interested in the wind advisory. It is also possible that other combinations of phrases could be created, both of which would be relevant to TG-CAP Level 1. It seems likely that CAP 1.1 would serve these events up as two separate index <entry> items, in order to convey their different start and end times; but as no example has been found, we cannot be sure. To recap, in TG-CAP Level 1, should two or more P-VTECs of interest be discovered in a single index <entry>, then a CARS event containing both (or all of the) phrases shall be created, using the phrase/P-VTEC sequence adopted by NWS. And, the CARS key phrase such as Blizzard Warning (generated from VTEC BZ.W) shall be checked to see that this string exists, somewhere in the NWS CAP 1.1 index message’s <title> field, as it does in the 1960s telex-style “HEADLINE” up above.

3.3.8 Follow-up Warning Products—Special and Severe Weather Statements

“Follow up” warning products include “Special” (SPS) and “Severe” (SVS) weather statements. Their function seems to be to duplicate the information carried in certain, serious NWS Warnings. This is problematic for TG-CAP as we don’t want to create duplicate events in CARS, describing the same alert twice. Appendix C to earlier drafts of this SDD states that Significance in VTEC identifies the level of importance (e.g., watch, warning, advisory, etc.) of the weather or non-weather occurrence. One of the Significance options is S, Statement. Where NWS uses S for Statement in a VTEC, TG-CAP Level 1 can easily filter it out and ignore its duplicative, redundant information. Unfortunately, NWS directives now prevent that from happening, as detailed below. It may be that Statements once had a function. Perhaps before computerization, once the desperate scramble of getting out a Tornado Warning was over, maybe the forecaster had time to sit back and issue a more carefully crafted statement about what was going one. Perhaps the Statement would be more accurate, more complete, or would in some way add value to what had already been done. In most instances (apparently in all instances?), this is no longer the case. Statements such as SVS are now generated automatically by the forecaster’s AWIPS software and are published at the same instance as the warning which they “follow-up.” The information they contain is identical, word for word, letter for letter, except where the title is changed from Warning to Statement.



26

Worse, in Appendix C to earlier drafts of this SDD, NWS directs that when a follow-up statement is issued to update, cancel, or announce expiration of a previously issued event, the event significance code used in the updated, cancelled, or expired P-VTEC string will be the same as the corresponding significance code used in the original product, even if the product was issued under a different communications identifier. For example, the P-VTEC string in a Severe Weather Statement issued to follow-up a Severe Thunderstorm Warning must use the same W (for warning) significance level of the initial warning product. It doesn’t stop there. Section 3.3.2 of Appendix C to earlier drafts of this SDD says that “the SVS product is used to provide follow-up information to a TOR, SVR, or EWW ... The SVS and MWS use the phenomenon, significance, ETN, and event ending time from the original warning.” We can indeed see in the MS Word document compare above that the AWIPS software stamps out two of everything serious, instantly following up every changing only the title trimmings and the message ID (which, like the FEU message number, is never repeated in CAP 1.1 and therefore serves no major purpose). Sometimes the follow-up even precedes the alert itself in the CAP 1.1 sequence. The problem faced by TG-CAP is how to eliminate these confusing and redundant computer-generated Statements that instantly “follow up” every warning by saying every word a second time, with only the heading changed.



27

3.4 CAP Detailed Message Parsing

The detailed CAP 1.1 Alert message, in this case at http://www.weather.gov/alerts-beta/wwacapget.php?x=ID20101127200800OTXWinterStormWarningOTX20101128000000ID, shall now be parsed. Of course, the new feed is no longer in beta, so the URL will have changed. Every time TG-CAP finds a valid index message (VTEC Warning or Advisory) of a relevant type for TG-CAP Level 1, the hyperlink to the detailed XML message shall be used to access the event’s location, as follows: <?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?> <?xml-stylesheet href='http://www.weather.gov/alerts-beta/capatomproduct.xsl' type='text/xsl'?> <alert xmlns = 'urn:oasis:names:tc:emergency:cap:1.1'>  <identifier>NOAA-NWS-ALERTS-ID20101127200800OTXWinterStormWarningOTX20101128000000ID</identifier> <sender>[email protected]</sender> <sent>2010-11-27T12:08:00-08:00</sent> <status>Actual</status> <msgType>Alert</msgType> <scope>Public</scope> <note>Alert for Bonner; Boundary; Coeur d'Alene Area; Fremont; Kootenai; Northern Panhandle (Idaho) Issued by the National Weather Service</note> <references></references> Firstly, the parser shall confirm that this is a CAP 1.1 message. Then the actual information used to build the CARS event shall be imported: <info> <category>Met</category> <event>Winter Storm Warning</event> <urgency>Expected</urgency> <severity>Moderate</severity> <certainty>Likely</certainty> <eventCode> <valueName>SAME</valueName> <value>WSW</value> </eventCode> <effective>2010-11-27T12:08:00-08:00</effective> <expires>2010-11-27T16:00:00-08:00</expires> <senderName>NWS Spokane (Eastern Washington and Northern Idaho)</senderName> <headline>Winter Storm Warning issued November 27 at 12:08PM PST expiring November 27 at 4:00PM PST by NWS Spokane</headline> <description>...PERIODS OF SNOW TO CONTINUE TODAY AND TONIGHT... ...WINTER STORM WARNING REMAINS IN EFFECT UNTIL 4 PM PST THIS AFTERNOON... A WINTER STORM WARNING REMAINS IN EFFECT UNTIL 4 PM PST THIS AFTERNOON. * SNOW ACCUMULATIONS: AN ADDITIONAL 1 TO 2 INCHES FOR THE SPOKANE

http://www.weather.gov/alerts-beta/wwacapget.php?x=ID20101127200800OTXWinterStormWarningOTX20101128000000ID

http://www.weather.gov/alerts-beta/wwacapget.php?x=ID20101127200800OTXWinterStormWarningOTX20101128000000ID



28

AND COEUR D`ALENE AREA. AN ADDITIONAL 2 TO 4 INCHES FOR DEER PARK...NEWPORT...AND SANDPOINT. POINTS FARTHER NORTH... LIKE COLVILLE...NORTHPORT...AND METALINE FALLS WILL ONLY RECEIVE AN ADDITIONAL 1 TO 2 INCHES. * TIMING: SNOW WILL BE THE HEAVIEST EARLY THIS AFTERNOON. SNOW WILL DECREASE FROM NORTH TO SOUTH THIS AFTERNOON. * LOCATIONS INCLUDE: COEUR D`ALENE...POST FALLS...HAYDEN... WORLEY...SANDPOINT...RATHDRUM...BONNERS FERRY... PRIEST RIVER...SCHWEITZER MOUNTAIN ROAD...DEER PARK... NEWPORT... SPRINGDALE-HUNTERS ROAD...FLOWERY TRAIL ROAD... SPOKANE... CHENEY...DAVENPORT...ROCKFORD * WINDS: VARIABLE 5 TO 10 MPH. * IMPACTS: TRAVEL WILL BE DIFFICULT OVER THE THANKSGIVING HOLIDAY WEEKEND AS ROADS BECOME INCREASINGLY SNOW COVERED.</description> <instruction>A WINTER STORM WARNING FOR HEAVY SNOW MEANS SIGNIFICANT AMOUNTS OF SNOW ARE EXPECTED OR OCCURRING. SNOW ACCUMULATIONS WILL MAKE TRAVEL VERY HAZARDOUS OR IMPOSSIBLE.</instruction> <parameter> <valueName>WMOHEADER</valueName> <value></value> </parameter> <parameter> <valueName>UGC</valueName> <value>IDZ001-002-WAZ036-037</value> </parameter> <parameter> <valueName>VTEC</valueName> <value>/O.CON.KOTX.WS.W.0009.000000T0000Z-101128T0000Z/</value> </parameter> <parameter> <valueName>TIME...MOT...LOC</valueName> <value></value> </parameter> <area> <areaDesc>Bonner; Boundary; Coeur d'Alene Area; Fremont; Kootenai; Northern Panhandle</areaDesc> <polygon></polygon> <geocode> <valueName>FIPS6</valueName> <value>016017</value> </geocode> <geocode> <valueName>FIPS6</valueName> <value>016021</value> </geocode> <geocode> <valueName>FIPS6</valueName> <value>016043</value>



29

</geocode> <geocode> <valueName>FIPS6</valueName> <value>016055</value> </geocode> The FIPS codes above shall never be utilized. County areas will only be utilized for Tornado and Severe Thunderstorm Warnings, and these shall be obtained from the UGC below. The UGC <value> for these event types should be <value>IDC001<\value>, as will be shown in later examples. For all other kinds of events (including this one), the zone codes shown below are expected to appear in the UGC. In all cases, the UGC format used by NWS (xxG or xxC) shall be followed in TG-CAP Level 1. <geocode> <valueName>UGC</valueName> <value>IDZ001</value> </geocode> <geocode> <valueName>UGC</valueName> <value>IDZ002</value> </geocode> </area> </info> </alert>

3.5 VTEC Parsing Examples

3.5.1 Hurricane and Tropical Cyclone Warnings

These warnings are of critical significance in Louisiana. One additional filter is required in TG-CAP Level 1 so that they can be handled efficiently. In particular, it appears as if duplicate warnings may be issued by the National Hurricane Center and by NWS local weather offices. Although it is not clear that both would be present in the Louisiana state CAP 1.1 feed (as we have no CAP 1.1 hurricane examples) the filter defined below is intended to prevent the duplication of Hurricane and Tropical Cyclone warnings in CARS. The National Hurricane Center (NHC) issues tropical cyclone warnings for the immediate coastal land zones in the Contiguous U.S., Puerto Rico and the U.S. Virgin Islands. Tropical-related warnings for adjacent marine zones and non-Tropical Cyclone land zones are the responsibility of the local NWS weather offices, and are issued (along with warnings for the NHC’s land zones) in Hurricane Local Statement (HLS) products. Because the local weather offices carry both National Hurricane Center and non-NHC information, they will be used in CARS in preference to the National Hurricane Center’s warnings. Local offices relay all the national information relevant to TG-CAP, so it is important not to carry duplicate information from both sources. P-VTEC strings containing “KNHC” as the forecast office originated at the National Hurricane Center. Therefore, any P-VTEC strings containing KNHC in position #3 shall be filtered out by TG-CAP Level 1.



30

The example below shows a Tropical Cyclone issuance from the National Hurricane Center, followed by the Hurricane Local Statements (HLS) from the NWS office in Lake Charles, Louisiana. The full example, shown in Appendix C to earlier drafts of this SDD, also gives warnings issued by the Houston/Galveston, Texas, NWS office, but in that case no Louisiana weather zones were impacted.

Example - National Hurricane Center and related Hurricane Local Statement products NWS Product 1 (NHC) Scenario: Existing Tropical Storm Warning Partially Upgraded to Hurricane Warning by the National Hurricane Center Issuing Office: Tropical Prediction Center/National Hurricane Center, Miami FL (KNHC) Current time: 0515 UTC on September 13, 2007 Events (Product): Tropical Storm Warning and Hurricane Warning (TCV) Product valid for: Louisiana Zones 51 and 52; Texas Zones 213 thru 215, 237, and 238 Product expiration time: 0900 UTC on September 13, 2007 Event Tracking Numbers: 9th Tropical System of the year for the Atlantic Basin (this one currently for a Tropical Storm Warning and Hurricane Warning issued by the National Hurricane Center) Segment 1 (not to be imported by TG-CAP, which uses local weather office alerts instead) Valid for: Louisiana Zone 51 and Texas Zone 215 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1500 UTC on September 12, 2007 and Until Further Notice (0515 UTC on September 13, 2007) Hurricane Warning: 0515 UTC on September 13, 2007 and Until Further Notice Segment 2 (Texas: not required by LA TG-CAP) Valid for: Texas Zones 213, 214, 237, and 238 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1500 UTC on September 12, 2007 and Until Further Notice Segment 3(not to be imported by TG-CAP, which uses local weather office alerts instead) Valid for: Louisiana Zone 52 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1500 UTC on September 12, 2007 and Until Further Notice P-VTEC Coding (segment 1 of 3 within the NHC product - upgraded warning for WFO Lake Charles area) LAZ051-TXZ215-130900- (UGC)

/O.CAN.KNHC.TR.W.1009.000000T0000Z-000000T0000Z/ (P-VTEC 1) /O.NEW.KNHC.HU.W.1009.070913T0515Z-000000T0000Z/ (P-VTEC 2)

(segment 2 of 3 within the NHC product - continued warning for WFO Houston/Galveston area) TXZ213-214-237-238-130900- (UGC)

/O.CON.KNHC.TR.W.1009.000000T0000Z-000000T0000Z/ (P-VTEC) (segment 3 of 3 within the NHC product - continued warning for WFO Lake Charles area) LAZ052-130900- (UGC)

/O.CON.KNHC.TR.W.1009.000000T0000Z-000000T0000Z/ (P-VTEC)



31

Explanation: A special advisory is issued by the National Hurricane Center as newly upgraded Hurricane Humberto, the ninth tropical cyclone of the year in the Atlantic basin (eighth named storm with one tropical depression), approaches the western Gulf coast. Some of the existing Tropical Storm Warnings issued by the National Hurricane Center have been upgraded to Hurricane Warnings, while the rest of the existing Tropical Storm Warnings continue. The Warning areas impact local weather offices in Houston/Galveston, Texas, and Lake Charles, Louisiana. The Tropical Cyclone product, which covers the coastal land zones, originates from the National Hurricane Center (using the office identifier KNHC). Since all such Warnings are open-ended, the event ending times are coded as zeros.

NWS Product 2: Lake Charles NWS Office Scenario: Weather Forecast Office Lake Charles updates their Hurricane Local Statement because of upgraded Tropical Storm Warnings. Issuing Office: WFO Lake Charles LA (KLCH) Current time: 0607 UTC on September 13, 2007 Events (Product): Hurricane Warning, Tropical Storm Warning, Hurricane Wind Warning and Tropical Storm Wind Warning (HLS) Product valid for: Louisiana Zones 41, 51, and 52; Texas Zones 215 and 216; and Gulf of Mexico Marine Zones 450, 452, 470, and 472 Product expiration time: 1100 UTC on September 13, 2007 Event Tracking Numbers: 9th Tropical System of the year for the Atlantic Basin; 1st Hurricane Warning, 1st Tropical Storm Warning, 1st Hurricane Wind Warning, and 1st Tropical Storm Wind Warning of the year issued by KLCH.

Segment 1 (not required by TG-CAP, as the marine zones are not used in CARS) Valid for: Gulf of Mexico Marine Zones 450 and 470 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1614 UTC on September 12, 2007 and Until Further Notice (0607 UTC on September 13, 2007) Hurricane Warning: 0607 UTC on September 13, 2007 and Until Further Notice

Segment 2 (LA zone imported by TG-CAP) Valid for: Louisiana Zone 51 and Texas Zone 215 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1614 UTC on September 12, 2007 and Until Further Notice (0607 UTC on September 13, 2007) Hurricane Warning: 0607 UTC on September 13, 2007 and Until Further Notice Segment 3 (not required by TG-CAP, as the marine zones are not used in CARS) Valid for: Gulf of Mexico Marine Zones 452 and 472 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1614 UTC on September 12, 2007 and Until Further Notice Segment 4 (imported by TG-CAP) Valid for: Louisiana Zone 52



32

Expected (or actual) Event Beginning and Ending times of the Tropical Storm Warning: 1614 UTC on September 12, 2007 and Until Further Notice Segment 5 (LA zone imported by TG-CAP) Valid for: Louisiana Zone 41 and Texas Zone 216 Expected (or actual) Event Beginning and Ending times of the Tropical Storm Wind Warning: 0356 UTC and 1500 UTC on September 13, 2007 P-VTEC Coding (segment 1 of 5 within HLS product - upgraded warning for marine zones) GMZ450-GMZ470-131100- (UGC)

/O.UPG.KLCH.TR.W.0001.000000T0000Z-000000T0000Z/ (P-VTEC 1)7 /O.NEW.KLCH.HU.W.0001.070913T0607Z-000000T0000Z/ (P-VTEC 2)

(segment 2 of 5 within HLS product - upgraded warning for coastal land zones) LAZ051-TXZ215-131100- (UGC)

/O.UPG.KLCH.TR.W.1009.000000T0000Z-000000T0000Z/ (P-VTEC 1) /O.NEW.KLCH.HU.W.1009.070913T0607Z-000000T0000Z/ (P-VTEC 2)

(segment 3 of 5 within HLS product - continued warning for marine zones) GMZ452-472-131100- (UGC)

/O.CON.KLCH.TR.W.0001.000000T0000Z-000000T0000Z/ (P-VTEC) (segment 4 of 5 within HLS product - continued warning for coastal land zones) LAZ052-131100- (UGC)

/O.CON.KLCH.TR.W.1009.000000T0000Z-000000T0000Z/ (P-VTEC) (segment 5 of 5 within HLS product - continued warning for inland zones) LAZ041-TXZ216-131100- (UGC)

/O.CON.KLCH.TI.W.0001.000000T0000Z-070913T1500Z/ (P-VTEC)

Explanation: Using the information from the National Hurricane Center, Lake Charles weather forecast office issues a Hurricane Local Statement (HLS) for the upgraded Tropical Storm Warning. The first two segments of the HLS product cover the land and marine areas included in the new Hurricane Warning (HU.W) area. The third and fourth segments cover the land and marine areas in the continued Tropical Storm Warning (TR.W). The fifth segment is for the inland area included in the continued Tropical Storm Wind Warning (TI.W). Note the differences in the ETNs between Segments 1 and 2 and between Segments 3 and 4. Segments 2 and 4 are for the coastal land parishes, and use the same ETN as the Tropical Cyclone product from the National Hurricane Center which includes those areas (shown above as Product 1). Segments 1 and 3 are for the marine zones, and the ETNs for these segments represent the number of Tropical Storm and Hurricane Warnings issued out of WFO Lake Charles so far this year. Segment 5 is for the inland areas, and the ETN represents the number of Tropical Storm Wind Warnings issued so far this year by the Lake Charles weather forecast office.

7 Ignored, because we always ignore UPGrades.



33

Since Humberto is the first tropical cyclone to affect WFO Lake Charles this year, Segments 1, 3, and 5 all have ETN 0001. The event beginning time for the new Hurricane Warning (in Segments 1 and 2) is the current time, even though the upgraded warning was issued at 0515 UTC by the TPC. All of the TR.W and HU.W events are in effect until further notice, while the TI.W event has an actual event ending time. In TG-CAP, “Marine” weather zones shall always be ignored. Currently we expect that this affects only Louisiana.

3.5.2 Flash Flood Warnings

This example is taken from NWS Appendix D, Section 8.2. Here in the main body of this SDD, we show only those NWS events required by TG-CAP Level 1. Other events such as watches are fully illustrated in Appendix C to earlier drafts of this SDD. Product 3 (First Flash Flood Warning)

Scenario: New Flash Flood Warning issued Issuing Office: WFO Salt Lake City UT (KSLC) Current time: 1651 UTC on September 22, 2007 Event (Product): Flash Flood Warning (FFW) Immediate Cause: Excessive Rainfall Product valid for: Utah Counties 21 and 53 Product expiration time: 2300 UTC on September 22, 2007 Event Tracking Number: 70th Flash Flood Warning of the year issued by KSLC Expected Flood Severity: None coded

Expected (or actual) Event Beginning, Crest, and Ending times of the Warning: 1651 UTC on September 22, 2007, crest time not included, and 2300 UTC on September 22, 2007

UTC021-053-222300- (UGC)

/O.NEW.KSLC.FF.W.0070.070922T1651Z-070922T2300Z/ (P-VTEC) /00000.0.ER.000000T0000Z.000000T0000Z.000000T0000Z.OO/ (H-VTEC)

Explanation: A new areal Flash Flood Warning is issued for portions of two southwestern Utah counties which are included in the zone-based Flash Flood Watch. The ETN for this warning is independent of the one used for the watch, which remains in effect. The beginning and ending event times in the P-VTEC string correspond to when the flooding is expected to begin (current time) and end. Because this is an aerial warning, the actual flood beginning, crest, and ending times are not coded in the H-VTEC string.

Product 4 (Second Flash Flood Warning)

Scenario: Second Flash Flood Warning issued Issuing Office: WFO Salt Lake City UT (KSLC) Current time: 1828 UTC on September 22, 2007 Event (Product): Flash Flood Warning (FFW) Immediate Cause: Excessive Rainfall Product valid for: Utah County 25 Product expiration time: 0030 UTC on September 23, 2007 Event Tracking Number: 71st Flash Flood Warning of the year issued by KSLC Expected Flood Severity: None coded



34


UTC025-230030- (UGC)

/O.NEW.KSLC.FF.W.0071.070922T1828Z-070923T0030Z/ (P-VTEC) /00000.0.ER.000000T0000Z.000000T0000Z.000000T0000Z.OO/ (H-VTEC)

Explanation: About an hour and a half later, at 1828 UTC, a second new Flash Flood Warning is issued for portions of another Utah county which is included in the zone-based Flash Flood Watch. Product 8 (First Flash Flood Warning)

Scenario: First Flash Flood Warning allowed to expire Issuing Office: WFO Salt Lake City UT (KSLC) Current time: 2253 UTC on September 22, 2007 Event (Product): Flash Flood Warning (FFS) Immediate Cause: Excessive Rainfall Product valid for: Utah Counties 21 and 53 Product expiration time: 2303 UTC on September 22, 2007 Event Tracking Number: 70th Flash Flood Warning of the year issued by KSLC Expected Flood Severity: None coded


UTC021-053-222303- (UGC)

/O.EXP.KSLC.FF.W.0070.000000T0000Z-070922T2300Z/ (P-VTEC) /00000.0.ER.000000T0000Z.000000T0000Z.000000T0000Z.OO/ (H-VTEC)

Explanation: Shortly before the first Flash Flood Warning (ETN 0070) was scheduled to end (at 2300 UTC) a follow-up FFS product is issued to say it will be allowed to expire. The only change from the previous follow-up (Product 6) is the use of the EXP action code in the P-VTEC string. The product expiration time (in the UGC) goes beyond the P-VTEC event ending time to allow dissemination of the message via NOAA Weather Radio and other outlets. Product 10 (Second Flash Flood Warning)

Scenario: Second Flash Flood Warning allowed to expire Issuing Office: WFO Salt Lake City UT (KSLC) Current time: 0028 UTC on September 23, 2007 Event (Product): Flash Flood Warning (FFS) Immediate Cause: Excessive Rainfall Product valid for: Utah County 25 Product expiration time: 0038 UTC on September 23, 2007 Event Tracking Number: 71st Flash Flood Warning of the year issued by KSLC Expected Flood Severity: None coded


UTC025-230038- (UGC)

/O.EXP.KSLC.FF.W.0071.000000T0000Z-070923T0030Z/ (P-VTEC) /00000.0.ER.000000T0000Z.000000T0000Z.000000T0000Z.OO/ (H-VTEC)



35

Explanation: At 0028 UTC, just before the second Flash Flood Warning (ETN 0071) was scheduled to end (at 0030 UTC), a follow-up FFS product is issued to say it will be allowed to expire. The contents are similar to the earlier expiration FFS (Product 8) issued for the other warning.

3.6 TG-CAP Level 2

3.6.1 Flash Flood Polygons

In TG-CAP Level 2 deployments, TG-CAP Level 2 shall use the polygon latitude/longitudes provided in the detailed message instead of the county/parish codes to draw the shaded area on CARS maps in which TG-CAP is active. In other words, when a flash flood polygon is available, TG CARS-CAP shall no longer render the flash flood warning at the county/parish polygon level. The more localized polygon shape published shall be rendered instead. <polygon>+34.35,-92.92 +34.39,-92.86 +34.42,-92.90 +34.44,-92.89 +34.44,-

92.85 +34.39,-92.82 +34.24,-92.93 +34.20,-92.98 +34.22,-93.01 +34.35,-

92.92</polygon>

TG-CAP Level 2 shall also use the polygon data to calculate the start and end points of the warning on each roadway segment, as shown below.

Figure 1: Flash Flood Polygon in Figure 2: Roadway event created on each CARS-

TG-CAP Level 2 Location highway crossing the polygon

3.6.2 Tornado Polygons

TG-CAP Level 2 deployments will also use the polygon latitude/longitudes provided in the detailed message instead of the county/parish codes to draw the Tornado corridor shaded area on CARS



36

maps in which TG-CAP is active. Again, when a tornado polygon is available, TG CARS-CAP shall no longer render the tornado warning at the county/parish area level. The more localized polygon shape published shall be rendered instead.

Figure 3: Tornado Polygon in TG-CAP Level 2

Figure 4: Roadway event created on each CARS-Location highway crossing the polygon

April 28, 2011: Index Entry <entry> <id>http://alerts.weather.gov/cap/wwacapget.php?x=NC20110428215500TornadoWarning20110428223000NC.MHXTORMHX.563fde900227ee93bc897faf67fae8b5</id> <updated>2011-04-28T17:55:00-04:00</updated>



37

<published>2011-04-28T17:55:00-04:00</published> <author> <name>[email protected]</name> </author> <title>Tornado Warning issued April 28 at 5:55PM EDT expiring April 28 at 6:30PM EDT by NWS Newport/Morehead City http://www.erh.noaa.gov/mhx/</title> <link href="http://alerts.weather.gov/cap/wwacapget.php?x=NC20110428215500TornadoWarning20110428223000NC.MHXTORMHX.563fde900227ee93bc897faf67fae8b5"/> <summary>THE NATIONAL WEATHER SERVICE IN NEWPORT HAS ISSUED A * TORNADO WARNING FOR... NORTHWESTERN TYRRELL COUNTY IN EASTERN NORTH CAROLINA WASHINGTON COUNTY IN EASTERN NORTH CAROLINA * UNTIL 630 PM EDT * AT 550 PM EDT...NATIONAL WEATHER SERVICE DOPPLER RADAR INDICATED A</summary> <cap:effective>2011-04-28T17:55:00-04:00</cap:effective> <cap:expires>2011-04-28T18:30:00-04:00</cap:expires> <cap:status>Actual</cap:status> <cap:msgType>Alert</cap:msgType> <cap:category>Met</cap:category> <cap:urgency>Immediate</cap:urgency> <cap:severity>Extreme</cap:severity> <cap:certainty>Observed</cap:certainty> <cap:areaDesc>Tyrrell; Washington</cap:areaDesc> <cap:geocode> <valueName>FIPS6</valueName> <value>037177 037187</value> </cap:geocode> <cap:parameter> <valueName>VTEC</valueName> <value>/O.NEW.KMHX.TO.W.0034.110428T2155Z-110428T2230Z/</value> </cap:parameter> </entry> Detailed message <?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?> <?xml-stylesheet href='http://alerts.weather.gov/cap/capatomproduct.xsl' type='text/xsl'?> <alert xmlns = 'urn:oasis:names:tc:emergency:cap:1.1'>  <identifier>NOAA-NWS-ALERTS-NC20110428215500TornadoWarning20110428223000NC.MHXTORMHX.563fde900227ee93bc897faf67fae8b5</identifier> <sender>[email protected]</sender> <sent>2011-04-28T17:57:52-04:00</sent> <status>Actual</status> <msgType>Alert</msgType> <scope>Public</scope> <note>Alert for Tyrrell; Washington (North Carolina) Issued by the National Weather Service</note>



38

<references></references> <info> <category>Met</category> <event>Tornado Warning</event> <urgency>Immediate</urgency> <severity>Extreme</severity> <certainty>Observed</certainty> <eventCode> <valueName>SAME</valueName> <value>TOR</value> </eventCode> <effective>2011-04-28T17:55:00-04:00</effective> <expires>2011-04-28T18:30:00-04:00</expires> <senderName>NWS Newport/Morehead City (Eastern North Carolina)</senderName> <headline>Tornado Warning issued April 28 at 5:55PM EDT expiring April 28 at 6:30PM EDT by NWS Newport/Morehead City</headline> <description>THE NATIONAL WEATHER SERVICE IN NEWPORT HAS ISSUED A * TORNADO WARNING FOR... NORTHWESTERN TYRRELL COUNTY IN EASTERN NORTH CAROLINA WASHINGTON COUNTY IN EASTERN NORTH CAROLINA * UNTIL 630 PM EDT * AT 550 PM EDT...NATIONAL WEATHER SERVICE DOPPLER RADAR INDICATED A TORNADO 5 MILES WEST OF CENTER OF PHELPS LAKE...OR 12 MILES SOUTHEAST OF PLYMOUTH...MOVING NORTHEAST AT 55 MPH. QUARTER SIZED HAIL AND DAMAGING WINDS IN EXCESS OF 58 MPH ARE ALSO LIKELY WITH THIS STORM. * LOCATIONS IMPACTED INCLUDE... CRESWELL...SCUPPERNONG... </description> <instruction>TAKE COVER NOW. MOVE TO AN INTERIOR ROOM ON THE LOWEST FLOOR OF A STURDY BUILDING. AVOID WINDOWS. IF IN A MOBILE HOME...VEHICLE OR OUTDOORS...MOVE TO THE CLOSEST SUBSTANTIAL SHELTER. IF NO SHELTER IS AVAILABLE LIE DOWN IN A LOW LYING AREA. PROTECT YOURSELF FROM FLYING DEBRIS. PLEASE REPORT SEVERE WEATHER TO THE NATIONAL WEATHER SERVICE BY CALLING...1...8 0 0...8 8 9...6 8 8 9 OR NOTIFY YOUR LOCAL LAW ENFORCEMENT AGENCY. A TORNADO WATCH REMAINS IN EFFECT UNTIL 900 PM EDT THURSDAY EVENING FOR EASTERN NORTH CAROLINA.</instruction> <parameter> <valueName>WMOHEADER</valueName> <value></value> </parameter> <parameter> <valueName>UGC</valueName> <value>NCC177-187</value> </parameter> <parameter> <valueName>VTEC</valueName> <value>/O.NEW.KMHX.TO.W.0034.110428T2155Z-110428T2230Z/</value> </parameter> <parameter>



39

<valueName>TIME...MOT...LOC</valueName> <value>2155Z 234DEG 47KT 3579 7652</value> </parameter> <area> <areaDesc>Tyrrell; Washington</areaDesc> <polygon>+35.98,-76.38 +35.94,-76.36 +35.95,-76.32 +35.96,-76.31 +35.98,-76.25 +35.70,-76.58 +35.80,-76.69 +35.99,-76.42 +35.99,-76.40 +35.98,-76.38</polygon> <geocode> <valueName>FIPS6</valueName> <value>037177</value> </geocode> <geocode> <valueName>FIPS6</valueName> <value>037187</value> </geocode> <geocode> <valueName>UGC</valueName> <value>NCC177</value> </geocode> <geocode> <valueName>UGC</valueName> <value>NCC187</value> </geocode> </area> </info> </alert>

3.7 TG-CAP Event Display

TG CARS-CAP shall parse the applicable XML fields in the NWS CAP index message and (for location fields) the NWS CAP detailed message, and map each compliant alert in the NWS index message to CARS events. CARS-CAP shall create two distinct types of events for each alert: area-based and roadway-based. In TG Web, NWS warnings will appear alongside other events in the “All Reports” menu option; i.e., there will be no separate “NWS” or “Weather” main menu option for it. However, users shall be able to switch the display of NWS/CAP events on and off using the “Layers” button, independently of the display of other types of Road Reports events.

3.7.1 Display of CAP Events

On the opening TG Web page, CAP events with a priority of 1-3 will appear on the main map as shaded-in polygons with a clickable icon at the center. Below is a CARS-CAP area event on the Indiana TG CARS-Web map, where the translucent shading indicates the area affected by the NWS report imported through TG CARS-CAP.



40

Figure 5: TG Web CAP area display for CAP area event.

The TG Web “layers” button shall enable users to switch on and off the rendering of NWS/CAP events in TG Web map and lists views, independently of the display of other types of Road Report events. When users do so, NWS/CAP events shall disappear from the maps and lists currently being viewed, and the NWS/CAP icon and label shall also be removed from the map legend. NWS/CAP events shall not be displayed in maps or lists again during this user session until the user switches them back on again using the “layers” button. Switching off NWS/CAP events in this fashion shall not cause any other Road Report event types to disappear from the map, lists, or legend. CAP zone or county alerts (according to alert type) shall be mapped to CARS area events using the algorithms described in earlier parts of this document. Area events will be rendered in the CARS 4/5 maps, TG Web maps, and -511 regional reports. TG CARS-CAP area events shall be displayed on the TG CARS-Web and CARS 4/5 maps as a translucent polygon covering the zones affected by the event, with a weather icon at the approximate visible area centroid. Each translucent TG CARS-CAP area event polygon shall be displayed behind all other CARS event icons in the same area. The boundaries of each county/parish/zone within the affected area are no longer distinguished by a thin, gray translucent line. This feature was removed from the initial CARS-CAP for performance reasons in certain browsers, and was not re-instated in CARS-CAP Level 1. It shall similarly be excluded from TG CARS-CAP.

As of the upgrade to CAP version 1.1 (as published by the NWS), identical alerts in geographically adjacent zones are no longer combined into a single CARS area event by CARS-CAP; CARS-CAP now only reads groupings pre-aggregated by NWS. Each compliant NWS index message alert will then be mapped as one CARS area event per NWS alert. The parts of the CARS-CAP 1.0 software that previously aggregated events have been deprecated and are no longer present in the software. All event weather zone grouping are now be determined by NWS.



41

Periodically, there may be overlapping CAP events on the TG Web map. This can occur when there are both county- and zone-based events in effect in a particular state. Additionally, there may be m multiple simultaneous alert types in affect. In those cases, a darker shade shall be used to convey the zones/counties where there are overlapping reports in effect, as illustrated in the mockup below.

Figure 6: TG-Web displaying two overlapping CARS-CAP events

In addition to area events, CAP alerts that affect CARS-CAP highways (Interstate, U.S., and state highways) shall also be mapped to roadway segments events, for all predefined CARS-CAP highway segments in each CAP county or zone (depending on the weather event type). For example, in Iowa, a CAP “tornado warning” event for Story County, Iowa, might be mapped to highway segments on US 30, US 65, US 69, and I-35. If no Interstate, U.S. or state highway segments cross the CAP county or zone, no corresponding CARS roadway events will be created. Identical events on adjacent highway segments shall be aggregated into a single CARS event per highway, as in CARS-Segment. The TG-CAP roadway events will be used by highway reports in CARS 4, Third-Gen CARS-Web (in event summary lists), and NG/TG-511.

3.7.2 Display of Area vs. Roadway CAP Events

Until the user either Zooms to a Place, Picks a route, Selects and Area, or Chooses a Roadway, the map shall continue to display the CAP event as an area only on the map, as illustrated in the following mockup. Roadway CAP events shall be suppressed until an event list is generated.



42

Figure 7: TG CARS-CAP events on “Choose a Roadway” Menu

Only after the user has selected a roadway with a current TG CARS-CAP event will the roadway-based events also appear on the map and in the list. The translucent area polygon shall continue to be displayed, along with the weather event icon at the approximate visible area centroid. Additionally, a second weather event icon shall be displayed within the roadway event’s (or events’) extent(s).

Figure 8: CAP Events on “Choose a Roadway” Results Page



43

Similarly, after a user views a route after choosing the “Pick a Route” feature, CAP events will appear as both polygons and roadway events with icons/extents along the selected route. In the event report list to the left of the map, only the CAP roadway event(s) shall appear. The area events shall not be listed.

Figure 9: CAP Events on “Pick a Route” Results Page

The same protocol shall be followed when the user selects a pre-defined area in which CAP events are currently in effect. Both roadway and area events shall appear on the resulting map page, while only roadway events shall appear in the event list to the left.



44

Figure 10: CAP Events on Pre-defined Area Results Page

Finally, the same approach shall be taken when the user “zooms to a place.” Both area events and roadway-based CAP events will appear on the map; only roadway-based events will appear in the list.

Figure 11: CAP Events on “Zoom to a Place” Results Page



45

3.7.3 CAP Events in the Album Viewer

The following screen details how the CAP area event details will appear when the user clicks on an event icon on the TG Web map. On icon mouseover, a dark translucent line shall appear around the border of the weather event area. When the event icon has been clicked, the CAP event will open in a TG Web “album view.” Chevron areas on either side of the album viewer shall enable the user to click back and forward through other events in the current domain, which will include other events currently visible on the map—i.e., not just CAP weather warnings. Album domains and the click-through ordering of the events in the album viewer are defined in the TG Web SDD.

3.7.3.1 Area event in album view

The following mockup shows how area CAP events appear in the album viewer. The header shall indicate the primary VTEC alert type (e.g., Winter Storm Warning), as mapped to a CARS event headline phrase. A dynamic Google map shall display the area polygon and Weather Warning icon.

Figure 12: TG CARS-CAP area event description in album viewer

In the event description area, the next line shall list the counties/parishes/zones affected by the event alphabetically, and will be followed by a blank line. If there are more than five counties/parishes/zones in the area event, the county/parish/zone line will read “Warning affects n counties” (or “n parishes” in Louisiana—for county-based weather events SV, TO and FF), “n zones” (for all other weather events), with “n” being the total number of counties, parishes, or zones being affected.



46

Below that, an excerpt of the NWS CAP text shall appear. Below that, a link to the full CAP alert on the NWS site shall appear, with the hyperlinked text reading “Full NWS Alert.” The line with the link to the NWS URL shall be followed by a blank line. The next line shall state the event’s most recent update date and time, which shall always be the most recent <update> time provided in the NWS CAP event feed. Some changes were made in CARS-CAP Level 1 when the transition to CAP version 1.1 was implemented; these changes are reflected in the TG designs: specifically, counties were replaced by weather zones for all event types other than severe thunderstorms, tornadoes, and flash floods. The repetition of the area names was also removed, by eliminating them from the title. The “Full NWS alert” hyperlink points to the detailed NWS CAP XML page for this specific index entry, which users typically view via the style sheet. The update time shall follow.

3.7.3.2 Roadway event in album view

If the user clicks on a roadway-based CAP event, then an album view shall render the details of the event as follows.

Figure 13: CAP Roadway Event in CARS Album Viewer

The dynamic Google map in the album viewer shall render only the selected roadway-based CAP event in roadway event album views. The header shall indicate the roadway on which the event is occurring, followed by the key phrase of the event. The next line shall provide the event location on the roadway “Between X and Y.” Roadway events will include the CAP text excerpt and NWS links in the same fashion as CAP area events, followed by the update time.



47

Appendix A: Dense Fog Advisory (Example)

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>

<?xml-stylesheet href='http://alerts.weather.gov/cap/capatomproduct.xsl'

type='text/xsl'?>



<alert xmlns = 'urn:oasis:names:tc:emergency:cap:1.1'>



<identifier>NOAA-NWS-ALERTS-

NE125172872BA4.DenseFogAdvisory.12517287E6C0NE.GIDNPWGID.100a4aa811e59af6949c

7926bba47964</identifier>

<sender>[email protected]</sender>

<sent>2014-10-23T06:21:00-05:00</sent>

<status>Actual</status>

<msgType>Alert</msgType>

<scope>Public</scope>

<note>Alert for Adams; Buffalo; Clay; Dawson; Franklin; Furnas; Gosper;

Greeley; Hall; Hamilton; Harlan; Howard; Kearney; Merrick; Nance; Nuckolls;

Phelps; Polk; Sherman; Valley; Webster (Nebraska) Issued by the National

Weather Service</note>

<info>

<category>Met</category>

<event>Dense Fog Advisory</event>

<urgency>Expected</urgency>

<severity>Minor</severity>

<certainty>Likely</certainty>

<eventCode>

<valueName>SAME</valueName>

<value></value>

</eventCode>

<effective>2014-10-23T06:21:00-05:00</effective>

<expires>2014-10-23T11:00:00-05:00</expires>

<senderName>NWS Hastings (North Central Kansas and South Central

Nebraska)</senderName>

<headline>Dense Fog Advisory issued October 23 at 6:21AM CDT until October 23

at 11:00AM CDT by NWS Hastings</headline>

<description>...DENSE FOG AFFECTING MUCH OF THE AREA THIS MORNING...

.DENSE FOG WILL PERSIST ACROSS THE MAJORITY OF SOUTH CENTRAL

NEBRASKA AND NORTH CENTRAL KANSAS THROUGH THE MID-TO-LATE MORNING

HOURS BEFORE GRADUALLY DISSIPATING.

...DENSE FOG ADVISORY REMAINS IN EFFECT UNTIL 11 AM CDT THIS

MORNING...

* VISIBILITY...A LARGE PORTION OF THE AREA WILL CONTINUE TO



48

OBSERVE...OR WILL YET OBSERVE VISIBILITY REDUCTIONS TO AROUND

1/4 MILE OR LOWER. IMPROVEMENTS WILL TAKE PLACE THROUGH THE MID-

TO-LATE MORNING HOURS...BUT TIMING WILL VARY AS SOME PLACES SEE

FOG DISSIPATE BEFORE OTHERS.

* IMPACTS...SIGNIFICANT VISIBILITY REDUCTIONS...ALONG WITH LARGE

FLUCTUATIONS IN VISIBILITY OVER SHORT DISTANCES...WILL PROMOTE

POTENTIALLY HAZARDOUS DRIVING CONDITIONS FOR THE MORNING

COMMUTE.</description>

<instruction>A DENSE FOG ADVISORY MEANS VISIBILITIES WILL FREQUENTLY BE

REDUCED TO LESS THAN ONE QUARTER MILE. IF DRIVING...SLOW DOWN...

USE YOUR HEADLIGHTS...AND LEAVE PLENTY OF DISTANCE AHEAD OF

YOU.</instruction>

<parameter>

<valueName>WMOHEADER</valueName>

<value></value>

</parameter>

<parameter>

<valueName>UGC</valueName>

<value>KSZ005-006-017-018-NEZ039>041-046>049-060>063-072>076-082>086</value>

</parameter>

<parameter>


<value>/O.CON.KGID.FG.Y.0006.000000T0000Z-141023T1600Z/</value>

</parameter>

<parameter>

<valueName>TIME...MOT...LOC</valueName>

<value></value>

</parameter>

<area>

<areaDesc>Adams; Buffalo; Clay; Dawson; Franklin; Furnas; Gosper; Greeley;

Hall; Hamilton; Harlan; Howard; Kearney; Merrick; Nance; Nuckolls; Phelps;

Polk; Sherman; Valley; Webster</areaDesc>

<polygon></polygon>

<geocode>


<value>031001</value>

</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



49



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>





50

</geocode>

<geocode>


<value>NEZ039</value>

</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



51



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

<geocode>



</geocode>

</area>

</info>

</alert>

Documents

Third-Gen CARS-CAP Concept of Operations Detailed Design ...4. TG -CAP alerts shall not be editable by CARS 4/5 operators.* 1 2.01.00 5. In each state, CAP 1.1 shall read two external