Summary

While watching the NOAA radar page for my area, I realized that they offer NOAA,:::::.gov/aboutrss.html" rel="external">RSS feeds of the weather, watches, and alerts. Now this seems like a cool idea. Can I automate the announcement of watches for my home? Clearly I could just go out and purchase a NOAA,:::::.gov/nwr/nwrrcvr.htm" rel="external">weather alert radio. Honestly, I already own one, but radio? that's so last century. How about making it part of my home automation? That's the wave of the future.

Why is this important?

Many homes and nearly all offices do not have a way to receive timely weather updates. This service could be integrated into home based automation devices and corporate communications systems (e.g. IP PBX) to provide both visual and audible indication of dangerous weather conditions.

Research

XML

As I would expect from the government, the feed content and formats are somewhat useful but, IMHO, not well thought out. The whole purpose of something like XML is to make the data parsable by a machine without ambiguity. In NOAA's defense, it is fare to say that the data that must be unambiguously parsed is dependent upon how the data is used. For instance the NOAA,:::::.gov/products/spcwwrss.xml" rel="external">base RSS feed is just a headline service with title and a link. This is suitable for inclusion on a headline service, but not suitable for automating alerts. Automation of alerts will require at least the type of information included in the header of a NOAA,:::::.gov/directives/010/pd01017012b.pdf" rel="external">SAME broadcast on the emergency radio broadcast service.

I found a page that lists information by county. This feed is location specific, but an interface that allows a user to select the correct zone might be difficult depending upon how well the zones are defined. Ideally there would be an XML document somewhere on the NOAA or other governmental site that defines the zones. This format also does not specifically call out the event type so for instance giving different treatment to a warning vs. alert would require parsing ASCII coded fields in an undefined name space. This is an example of the title element from a tornado watch item within the channel:
Tornado Watch - Baxter (Arkansas)
Ideally NOAA feeds would use the NOAA,:::::.gov/directives/010/pd01017012b.pdf" rel="external">SAME coding defined for the emergency radio broadcasts.

CAP

Turns out that there is a somewhat coordinated effort to consolidate all of the efforts. The Common Alerting Protocol (CAP) is an XML based document definition that appears to have more well defined information elements. This is the ticket. The National Weather Service supports some version of CAP although the <geocode> element is not quite up to the current revision of the specification. The CAP feeds are separated into states. The index is http://www.weather.gov/alerts/. The county FIPS codes are included in the <geocode> element. The FIPS location codes can be found here NOAA,:::::.gov/geodata/catalog/wsom/html/cntyzone.htm" rel="external">http://www.nws.NOAA.gov/geodata/catalog/wsom/html/cntyzone.htm along with a link to the delimited dump file. I also found the <cap:event> coding http://www.weather.gov/alerts/product_list.txt. This information is all at the bottom of this page http://www.weather.gov/alerts/.