Rainy Day XML
The five weeks up to and including the middle of September were interesting (to say the least) here in sunny Florida. Depending on how you count, we had somewhere between three and five named tropical storms and hurricanes pummel our coastline and interior. We knew in advance the storms were coming, of course. We just didn't know when or exactly where.
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:
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.
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:
In this XML Tourist column, I'll briefly cover a couple of these alternatives.
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:
 |
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=amsterdamreturns 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!)
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.…
XML.com Copyright © 1998-2006 O'Reilly Media, Inc.