Rainy Day XML

At such times it's tempting to turn to instantly available, always-on media outlets, such as cable TV's Weather Channel, for regular weather updates. This knee-jerk "solution" to the information gap fails on at least two levels:

• For arguably noble and perhaps mercenary reasons, these outlets pay almost exclusive attention to the areas that, as events unfold, are going to be hardest hit. Camera crews, helicopters, and entire swaths of broadcast time never seem to be devoted to where you are or even anywhere near where you are.
• If you believe what you see on TV regarding an oncoming weather event, the news is always dire. But the worst news imaginable is not necessarily the only news you need to consider. If 60-foot trees surround your house, maybe it doesn't make any difference to you that the top wind speed might turn out to be 160 miles per hour; a twitchy 80-miles-per-hour will be plenty bad enough.

I'm not discounting the -- at least potential -- usefulness of emergency-broadcast radio stations, by the way. We've simply never been able to raise anything but static on those frequencies.

The ideal solution to these difficulties would give you targeted information, preferably down to the level of city (if not ZIP or other postal code within a city). The solution would be timely. It would be updated as conditions change. It would be delivered with a minimum of exclamation points (expressed or implied). In a perfect world, it wouldn't depend on your having reliable electricity at the time you most need the information. And -- especially if you live in a city -- it shouldn't require that some poor soul gallop from door to door on horseback, crying out the time, temperature, and barometric pressure, while ducking baseball-sized hail: it should be technically sophisticated.

Narrowing the Field

For what should be obvious reasons, I'm focusing here on XML solutions to the weather-forecasting problem. I won't be covering any solutions whose mechanisms are hidden behind a proprietary screen. (There are quite a few such solutions, though.)

As with many XML applications, XML-based weather data comes in numerous flavors, including:

1. Simple RSS feeds, suitable for consumption by RSS reader clients and RSS-smart web sites.
2. Data from the U.S. National Weather Service (NWS). In addition to a plain-old RSS feed, they also offer an experimental feed of data from the National Digital Forecast Database (NDFD). This comes in the form of a weather-specific Digital Weather Markup Language (DWML). Once you've got such a feed, of course, you can use XSLT to transform it into anything you'd like (including RSS).
3. Data from The Weather Channel itself. This isn't known by any particularly catchy name, as far as I've been able to determine; it's simply called "Weather XML." (Here is the DTD.). Two disadvantages to this approach: You must apply for a (free) weather.com license key; and you will be restricted in terms of how you use and display the data once retrieved. For example, you'll have to agree to use three links to weather.com. The upside is that this is a popular format, so you'll have lots of company if you need help understanding the ins and outs of processing the feed.
4. Weather alerts only -- that is, not ongoing forecasts but simply periodic announcements of some anticipated "big event." A potential source format for this information is the Common Alerting Protocol (CAP) published by OASIS. Note, though, that CAP is a generic "public alert" protocol; alerts can cover not just meteorological events, but also geological, national security, and so on. Also note that CAP feeder systems don't seem to be exactly thick on the ground right now. You can retrieve sample CAP feeds from the NWS site, for any state (but not, alas, any city) in the United States. CAP is intended to be a globally useful standard, by the way -- not restricted to use in the U.S.

In this XML Tourist column, I'll briefly cover a couple of these alternatives.

RSS-based Weather Data

A very simple source for this feed is the rssWeather.com site. As you'll see there, the default location for the feed is Las Vegas, Nev. To localize it for your own (or any other) city, use the search box at the top right. When it displays the appropriate city's results, obtain the URL for the feed from the orange XML button in the left-hand menu.

rssWeather.com isn't restricted to U.S. cities, by the way. However, in non-U.S. locations you'll need to know the International Civil Aviation Organization (ICAO) four-letter code for a local airport -- for example, ZBAA for Beijing or EHAM for Amsterdam. The site includes a step-by-step process to locate an appropriate ICAO code, starting here. You can also look up the code for a given city using the alphabetical index at the Airport Technology site.

Here's a screenshot of the FeedReader RSS client, currently "tuned" to Amsterdam:

Weather XML

This is a popular solution despite its drawbacks; at least it's free of hyperventilating, wind-blown and rain-soaked weathercasters.

To obtain the feed, you must first register with weather.com to obtain a license key. The registration is free but mandatory. Once you've registered, you'll receive a confirmation email and a link to the software developer's kit. Included in the kit is a comprehensive user's guide, numerous icons, and instructions (and restrictions) on use of The Weather Channel logos.

In general, in order to use Weather XML your application needs to be capable of sending and receiving queries and responses, respectively, to and from the weather.com XML server. Queries for forecasts -- simple URLs -- require use of a "location ID" for the desired city, airport, whatever; you can obtain this location ID using a query of this form:

http://xoap.weather.com/search/search?where=[common

identifier]

Substitute a city name or U.S. postal (ZIP) code for [common identifier]. U.S. postal codes always identify a single locale, so no further action on your part is necessary to obtain the forecast. If you use a city name, though, your application needs to be prepared to prompt the user to select from among various matches. For instance, the query string:

http://xoap.weather.com/search/search?where=amsterdam

returns a result like this:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!--This document is intended only for use by authorized

licensees of The Weather Channel. Unauthorized use is

prohibited. Copyright 1995-2004, The Weather Channel

Enterprises, Inc. All Rights Reserved.-->

<search ver="2.0">

  <loc id="NLXX0002" type="1">Amsterdam,

Netherlands</loc>

  <loc id="USMO0017" type="1">Amsterdam,

MO</loc>

  <loc id="USNY0035" type="1">Amsterdam,

NY</loc>

  <loc id="USOH0023" type="1">Amsterdam,

OH</loc>

</search>

The next step is to build a query for the weather itself, for the given location ID. Again, this is a simple URL, of this general form:

http://xoap.weather.com/weather/local/[locid]

Replace the [locid], of course, with the location ID obtained in the previous step. Appended to this URL is a mix of other parameters, some required and some optional. A typical example might be:

http://xoap.weather.com/weather/local/NLXX0002?cc=*&dayf=5

&prod=xoap&par=[partner id]&key=[license key]

The values of the [partner id] and [license key] parameters are sent to you in the email confirming your registration with weather.com.

This requests that weather.com return a Weather XML document for Amsterdam, Netherlands, including the current conditions and a five-day forecast. The result looks like the following (ellipses indicate omissions for brevity's sake):

<?xml version="1.0" encoding="ISO-8859-1"?>

<!--This document is intended only for use by authorized

licensees of The Weather Channel. Unauthorized use is

prohibited. Copyright 1995-2004, The Weather Channel

Enterprises, Inc. All Rights Reserved.-->

<weather ver="2.0">

  <head>

    <locale>en_US</locale>

    <form>MEDIUM</form>

    <ut>F</ut>

    <ud>mi</ud>

    <us>mph</us>

    <up>in</up>

    <ur>in</ur>

  </head>

  <loc id="NLXX0002">

    <dnam>Amsterdam, Netherlands</dnam>

    <tm>11:32 PM</tm>

    <lat>52.3</lat>

    <lon>4.77</lon>

    <sunr>7:29 AM</sunr>

    <suns>7:37 PM</suns>

    <zone>2</zone>

  </loc>

  <cc>

    <lsup>9/23/04 11:25 PM Local Time</lsup>

    <obst>Amsterdam, Netherlands</obst>

    <tmp>54</tmp>

    <flik>54</flik>

    <t>Partly Cloudy</t>

    <icon>29</icon>

    <bar>

      <r>29.77</r>

      <d>steady</d>

    </bar>

    <wind>

      <s>17</s>

      <gust>N/A</gust>

      <d>310</d>

      <t>NW</t>

    </wind>

    <hmid>88</hmid>

    <vis>6.2</vis>

    <uv>

      <i>0</i>

      <t>Low</t>

    </uv>

    <dewp>50</dewp>

  </cc>

  <dayf>

    <lsup>9/23/04 8:42 PM Local Time</lsup>

    <day d="0" t="Thursday" dt="Sep 23">

    <hi>N/A</hi>

    <low>51</low>

    <sunr>7:29 AM</sunr>

    <suns>7:37 PM</suns>

    <part p="d">

    <icon>-</icon>

    <t>N/A</t>

    <wind>

      <s>N/A</s>

      <gust>N/A</gust>

      <d>N/A</d>

      <t>N/A</t>

    </wind>

    [...]

</dayf>

</weather>

The information included in this document can be easily processed with any XML-aware application software: Java, C++, Visual Basic, and so on -- not excepting XSLT. For instance, you could simply insert the following line into the document returned:

<?xml-stylesheet type="text/xsl"

href="myweatherdisplay.xsl" ?>

and then feed the document, otherwise unchanged, to the user's browser. (Assuming, of course, that myweatherdisplay.xsl transforms the raw Weather XML to (X)HTML!)

The Next Step

One problem with any of the solutions discussed above is that getting the weather update still depends on electrical power -- via a battery or generator, if necessary -- in order to access an ISP. Maybe the most elegant fix to this final dilemma would be the ability to receive XML-based updates via a cell phone or similar device. Whenever we lost power, we were still connected to the outside world by cell phone.

Not surprisingly, I'm not the first person to have thought of this. A nifty demonstration of the possibilities is provided at the CapeScience web site. This approach makes use of the CapeScience AirportWeather or GlobalWeather Web service to return to the client a SOAP response (example) suitable for display on the target medium.

Now if I could just figure out how to use XML to handle all these sandbags.