Reset Application (All timestamps are displayed in UTC)
Hail Size:
LSR Buffer: km
Warning Buffer: degrees
Warning Type: TornadoSvr T'stormMarineFlash Flood (2008+)
LSR Type: TornadoWind DamageHailWind GustMarineFlash Flood (2008+)
When possible, verify SVR warnings against issuance WIND...HAIL tag App listing per-WFO tags
When possible, limit considered warnings to your hail/wind threshold

IEM Cow (NWS Storm Based Warning Verification)

IEM Cow API Access

Data presented here is unofficial and should be used for educational purposes only. This application allows you to view warnings and storm reports issued by a Weather Forecast Office (WFO) for a period of time of your choice. The application attempts to automatically provide verification numbers for the warnings issued.

This application works for dates after 8 June 2005.

Storm Based Warnings

On the first of October 2007, the National Weather Service began issuing warnings for tornados, severe weather, floods, and marine hazards on a storm by storm basis. Previously, the warnings were issued for an entire county. This application attempts to provide verification statistics for these storm based warnings.

Related links:

Verification Methodology

The map on the left illustrates some of the spatial statistics the Cow produces. The following is a brief description of these values.

API for IEM Cow Data

20 June 2018: The IEM is pleased to announce availability of an API for programatic access to IEM Cow data and statistics. At this time, the API is not considered stable and JSON schema should not be considered stable either. Hopefully in a week or two, with some friendly testing and feedback, both will stablize for an API level "1" that should not change going forward. The generated output statistics have not been fully tested yet either! This will be stabilzed as well in the coming days.

The JSON emitting service endpoint is:

This endpoint accepts a large number of CGI parameters via HTTP GET. None of the parameters are required.

callback=func not used This supports JSON-P style requests with the resulting JSON data begin encapsulated by a javascript function call. i.e. callback=gotdata
wfo=XXX All WFOs considered This specifies the three character WFO identifier that you wish to get statistics for. If none are specified, then you get the entire NWS. You can provide this parameter one or more times, i.e. wfo=XXX&wfo=YYY
Time Specification Option 1
Last 4 Hour Period This start time and end time sets the window to look for NWS Storm Based Warnings and Local Storm Reports. For the case of warnings, the warning must have been issued after the start time and have an expiration prior to the end time. The tricky issue issue is when warnings cross either the start or end time, this can lead to incomplete statistics (ie a storm report was actually covered by a warning, but that warning was outside your time domain. These timestamps are in UTC., i.e. begints=2018-06-18T12:00Z&endts=2018-06-19T12:00Z
Time Specification Option 2
syear=YYYY smonth=MM sday=DD shour=HH24
eyear=YYYY emonth=MM eday=DD ehour=HH24
Last 4 Hour Period Same time details above as with Option 1, but here you are just specifying manually each part of the date, i.e. syear=2018&smonth=6&sday=18&shour=12&eyear=2018&emonth=6&eday=19&ehour=12&
phenomena=XX All TO, SV, FF, MA These are the VTEC phenomena codes that you want the data and stats for. These are two character and the currently supported Storm Based Warning types are Tornado (TO), Severe Thunderstorm (SV), Flash Flood (FF), and Marine (MA). You can specify more than one phenomena, i.e. phenomena=TO&phenomena=SV
lsrtype=XX All TO, SV, FF, MA So like in the case of phenomena above, here you are specifying which category of Local Storm Reports to consider. This gets to be a bit difficult to fully explain. In general, the codes reflect with Local Storm Report types should be used that can potentially verify the warning. i.e. lsrtype=TO&lsrtype=SV
hailsize=SIZE_IN_INCHES 1.00 inches What hail size in inches should be considered when verifying the warnings. The present day standard is one inch, but previously it was 0.75 inches. This parameter only considers one value, i.e. hailsize=1.50
lsrbuffer=DIST_IN_KM 15 km IEM Cow attempts to provide an areal verification percentage within the polygons, this areal value is computed by buffering out the point LSR reports by the given radius in kilometers. The GIS operation is done in USGS Albers (EPSG:2163). example, lsrbuffer=15
warningbuffer=DIST_IN_KM 1 km So this is kind of a bug-a-boo and dirty little secret, but the NWS Storm Based Warnings are not necessarily exact in latitude/longitude space. The basic data provides polygon points with two places of decimal precision. Given political boundaries and other lame limitations, there are places in the country that would never receive a warning if not for allowing the polygons to buffer out slightly for folks implementing workflows with this data. So we default to buffer out the warning 1km, which is used in verification, but not in size calculations. example, warningbuffer=1
wind=SPEED_IN_MPH 58 MPH For wind Local Storm Reports, what minimum speed should be considered for verifying a warning. This value is not used in the case of Marine Warnings. example, wind=58
fcster=string Not considered With this enabled, resulting stats should not be used This will limit considered warnings to those signed by the exact string provided. This creates a problematic situation with all storm reports considered, but only a subset of warnings provided for verification. The actual verification of individual warnings will be accurate, but the bulk stats are not correct. example, fcster=forecaster10

Resulting JSON Schema.

This is very much a work-in-progress, with feedback needed and will change until this stablizes.

{"generated_at": "ISO9660",
 "params": {dictionary of how API was called},
 "stats": {dictionary of generated statistics},
 "events": GeoJSON-style object of warnings,
 "stormreports": GeoJSON-style object on LSRS