As usual, the folks at the National Weather Service have made our job pretty easy. You can take a look at what they’ve given us to work with here. Each observation stations get its own web page containing an Xml document (updated hourly) describing the current weather conditions. The URL for the page containing the current conditions for each weather station is formed by appending the station’s identification string to the base URL for current observations. So for example to get the current conditions for Smithfield, Rhode Island the URL would look like this:

http://www.weather.gov/xml/current_obs/KSFZ.xml

So now the puzzle comes down to how do we find the ID for the reporting station closest to the spot for which we want the current conditions? We’ve got a few choices, but all of them start with this document, the index of reporting stations. It contains an entry for every reporting station, formatted just like this excerpt for our Smithfield station:

<station>
  <station_id>KSFZ</station_id> 
  <state>RI</state> 
  <station_name>Smithfield</station_name> 
  <latitude>41.91</latitude> 
  <longitude>-71.4</longitude> 
  <html_url>http://weather.noaa.gov/weather/current/KSFZ.html</html_url> 
  <rss_url>http://weather.gov/xml/current_obs/KSFZ.rss</rss_url> 
  <xml_url>http://weather.gov/xml/current_obs/KSFZ.xml</xml_url> 
</station>
 

The key pieces here are the station_name, state and station_id. We’re also going to find the latitude and longitude useful a bit later. Since this is a reasonably large document (900kb) and we want to play really nice with the NWS folks so they’ll let us continue to use their toys (and we want our app to be responsive), we’ll download it once (using a BackgroundWorker) and cache a copy in IsolatedStorage (along with an option to refresh our cache when needed).

So armed with the list of all the reporting stations, there are a couple of routes we could take. On the one hand we could simply mimic what the NWS does on their current conditions web page:

1. Show the user a list of all the states and ask them to pick one.
2. Based on their selection, show them a list of all the observation stations in that state and ask them to pick one.
3. From their selection, compose the URL for the current conditions page and submit a web request.

The TestFromStateStation sample application (available for download at the end of this post) implements this approach.

The other approach is to:

1. Ask the user for the Zip Code for their location.
2. Query the NDFD web service for a location (latitude, longitude) associated with the zip code.
3. Compute the distance between the zip location and the location of each observation station in the reporting stations index (see above) to find the closest station.
4. Use the station Id from the closest station to compose the URL for the current conditions page and submit a web request.

This technique relies on being able to determine the distance between two points on the earth’s surface. There are a number of techniques we can use – you can read a really good description of your options thanks to the folks at movable-type. For our purposes, the spherical law of cosines is good enough (see ObservationStations.GetDistance() in the NationalWeatherServiceLibrary project in the attached solution). The TestFromZip sample (see below) implements this approach.

So there you have it, the ability to get the current weather conditions using either state/station or zip code. As promised, here are the downloads: TestFromStateStation.exe, TestFromZip.exe and the complete VS2008 solution.

At this point we’re done with the web service pieces of the project; we know how to get forecasts and current conditions for anywhere in the US. Next it’s time to create the UI.

But before I jump into that, I’m going to take a small detour and talk about custom painting a TreeView. This is motivated by the fact that the NDFD Xml data is a bit hard to visually parse when displayed as raw Xml, so I thought I’d simplify my debugging a bit by pushing the data into a custom painted TreeView.

There are a couple approaches to custom painting in a managed TreeView. The simplest (OwnerDraw) is to set the TreeView.DrawMode property like this:

this.DrawMode = TreeViewDrawMode.OwnerDrawText;

or

this.DrawMode = TreeViewDrawMode.OwnerDrawAll;

Then you override OnDrawNode and do your painting. The big benefit with this approach is that the TreeView does most of the heavy lifting – it determines when a TreeNode needs redrawn as well as the bounding rectangle – all you need to do is draw the contents of a node when requested.

The problem with this approach is that as soon as your node content gets a bit complex, you start down a slippery slope of increasing complexity as you add hit test code for selection highlighting etc. And if your drawing code gets the least bit complex, you will start to notice redrawing flicker as you resize windows containing your custom painted TreeView. (It’s unfortunate, but the built-in double buffering does not work for OwnerDrawText or OwnerDrawAll. You can get some improvement in the flicker by overriding WndProc and eating all the WM_ERASEBKGND messages, but it doesn’t really fix the problem.) So, except for the simplest situations, I usually end up using the second approach which is to do all the painting myself (UserPaint). It’s a little complex the first time, but most of the complexity is boilerplate code that you can reuse (the attached code is a pretty good starting point).

You enable user painting by setting several of the ControlStyles bits for your TreeView like this:

this.SetStyle(ControlStyles.UserPaint, true);
this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
this.SetStyle(ControlStyles.OptimizedDoubleBuffer, true);

Now only OnPaint and OnPaintBackground get called (OnDrawNode is out of the loop), and this is where the fun begins.

For starters, you’ll want to override both OnPaint and OnPaintBackground. For OnPaintBackground, I find it’s usually most efficient to do nothing more than insure the base class OnPaintBackground isn’t called:

protected override void OnPaintBackground(PaintEventArgs pevent)
{
	// We can do a better job of predicting where nodes will paint the background
	// and what area is left, so just disable background painting.
	//base.OnPaintBackground(pevent);
}

This means in OnPaint, we need to paint not only the TreeNodes but the empty area where there are no TreeNodes as well. So OnPaint looks something like this:

protected override void OnPaint(PaintEventArgs e)
{
	// If we have nodes, then we have to draw them - and that means everything
	// about the node.
	if (this.Nodes.Count > 0)
	{
		// If we have nodes then there has to be a Nodes[0]. Use it to get the
		// height of one TreeNode - in a TreeView, all nodes are the same height
		// (unless you are using PInvoke to call TVM_SETITEM and set TV_ITEM 
		// iIntegral member for a specific node - which we are not doing!).
		int nodeHeight = this.Nodes[0].Bounds.Height;
 
		int curY = 0;
 
		// Walk down the client area, stepping by the height of one row, looking 
		// for nodes.
		while (curY <= this.ClientRectangle.Height)
		{
			// This probably isn't the most efficient way to do this, but
			// at least we aren't writing our own code to walk the tree...
			TreeNode node = this.GetNodeAt(0, curY);
 
			// If this rect does contain a node, draw the node.
			if (node != null)
			{
				DrawTreeNodeEventArgs args = new DrawTreeNodeEventArgs(
					e.Graphics,
					node,
					e.ClipRectangle,
					GetNodeStates(node)); // manufacture the proper TreeNodeStates
 
				DrawCustomNode(ref args);
			}
 
			// If this rect doesn't contain a node, we need to fill it with the 
			// background color.
			else
				e.Graphics.FillRectangle(
					_backBrush, 
					0, 
					curY, 
					this.ClientRectangle.Width, 
					nodeHeight);
 
			curY += nodeHeight;
		}
	}
 
	// If there are no nodes in the tree, we're going to have to paint the 
	// entire background.
	else
		e.Graphics.FillRectangle(_backBrush, this.ClientRectangle);
 
	// Don't need - in this case we can guarantee no one is listening...
	//base.OnPaint(e);
}

As you can see, our job is to just walk down the client area of the TreeView, one node height at a time, checking to see if there is a node there. (There is a lot of optimizing opportunity here.) If we have a node we draw it; if there isn’t, we draw background. That’s all there is to it – well almost. You probably noticed there are a couple of methods stuck in the middle of OnPaint that we haven’t talked about yet – and these can be a bit of a pickle.

The first problem we need to resolve is addressed by the GetNodeStates method which supplies the TreeNodeStates parameter for the DrawTreeNodeEventArgs constructor. The stock TreeView that you are familiar with has a curious behavior when it comes to highlighting selected TreeNodes. If you click on one node to select it, its background gets painted with SystemBrushes.Highlight and all is good. But if now you click-and-hold on a second node you will notice the first node loses its highlight and the second node is now highlighted – but it gets even more complex. If now (while still holding your mouse button down) you move your mouse a bit (say more than 15 pixels or so) the highlight reverts to the first node. This behavior is made possible by TreeNodeStates.Focused. It turns out that in a TreeView, node highlighting is indicated by Focused rather than Selected, so it’s the coming and going of Focused for the first and second nodes that is prompting the highlighting behavior we just saw. The problem is that we don’t actually have a way to directly test for the Focused state. If you are using OwnerDrawText or OwnerDrawAll you get the Focused state handed to you when your OnDrawNode override is called, but when doing our own drawing in OnPaint, we need to manufacture the Focused state and this is the purpose for GetNodeStates (this is the secret sauce):

private TreeNodeStates GetNodeStates(TreeNode node)
{
	TreeNodeStates states = 0;
 
	// If mouse button is not down, then normal rules apply - if a node is
	// selected, then it also has focus. We set _mouseDownNode in our
	// OnMouseDown override and clear it in our OnMouseUp override.
	if (_mouseDownNode == null)
	{
		if (node.IsSelected)
			states = TreeNodeStates.Selected | TreeNodeStates.Focused;
	}
 
	// But if a mouse button has been clicked on a node, then we need to check
	// to see if that node is currently drop-highlighted.
	else if (node != _mouseDownNode)
	{
		// If this is the currently selected node, but a mouse button has been
		// clicked-and-held on another node and that node is currently showing 
		// the drop-highlight, then we don't show selection highlighting for this
		// node.
 
		if (!IsDropHighlighted(_mouseDownNode) && node.IsSelected)
			states = TreeNodeStates.Selected | TreeNodeStates.Focused;
	}
 
	// Othewise if this is the node that has been clicked-and-held and if
	// this node is currently showing drop-highlighting, then show it. We 
	// still need to check to see if drop-highlighting is being shown for 
	// this node because if the user clicked-and-held on this node, but
	// then started to move the mouse, drop-highlighting is removed by
	// the underlying Win32 tree control.
	else if (node == _mouseDownNode)
	{
		if (IsDropHighlighted(node))
			states = TreeNodeStates.Focused;
	}
 
	return states;
}

The final pieces here are a couple of calls to the underlying Win32 tree control to get the state of the nodes in question from which we can determine if a particular node is drop-highlighted:

private bool IsDropHighlighted(TreeNode node)
{
	const int MASK = NativeMethods.TVIF_STATE | NativeMethods.TVIF_HANDLE;
 
	// TV_ITEM stateMask doesn't seem to matter when reading state - we get
	// all the state bits anyway (Windows7).
	const int STATEMASK = NativeMethods.TVIS_DROPHILITED;
 
	NativeMethods.TV_ITEM lParam = 
		new NativeMethods.TV_ITEM { 
			hItem = node.Handle, 
			mask = MASK, 
			stateMask = STATEMASK };
 
	UnsafeNativeMethods.SendMessage(
		new HandleRef(this, this.Handle), 
		NativeMethods.TVM_GETITEMW, 
		0, 
		ref lParam);
 
	return (lParam.state & NativeMethods.TVIS_DROPHILITED) != 0;
}

(The definitions for the various Win32 methods, structures and constants can be found in the attached sample.)

The second method we haven’t talked about is DrawCustomNode – this is where I actually get around to drawing the TreeNodes. Since my goal for this project was to create a simple view of an XmlDocument, the code just implements the stylized drawing to do that – and this is where you would put your code to draw a BarGraphTreeNode or whatever. In my case, since I am “syntax coloring” Xml, there is quite a bit going on to insure various segments of the colored text line up correctly – but that’s another story.

The attached sample (executable, source) contains a fully working test app using the NDFD web service to get weather forecasts for specific ZIP codes. It pushes the Xml forecast data into our new XmlTreeView. I hope you enjoy.

National Weather Service to the rescue. They have a nice web site where you can get your local 7-day forecast (updated hourly). But what’s even more interesting, if you click around on the map you can get a forecast for anywhere in the US, even for places that aren’t even close to a NWS field office (this keeps getting better and better) and all this data is available from a SOAP-based web service, the National Digital Forecast Database (NDFD). So it looks like there is a way to get weather forecasts– and I don’t have to wait for the “News at 5″. And I can stick them in a desktop Gadget, in a Word document or on a PowerPoint slide.

The NWS provides a WSDL document so you might think it would be a simple thing to add a Service Reference to your project, have a proxy automatically generated, and you’re ready to roll. But unfortunately there is a wrinkle. The app.config file that’s auto generated from the NDFD WSDL document specifies that we’re going to use the stock basicHttpBinding and every time you send a SOAP request to the service you see this:

System.ServiceModel.ProtocolException was unhandled. Message=”The content type text/xml; charset=ISO-8859-1 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly.

In this case, the problem really doesn’t have anything to do with correctly implementing IsContentTypeSupported. It’s caused by the fact that the NDFD service uses ISO-8859-1 encoding. However the MessageEncoder used by the basicHttpBinding only understands UTF-8, UTF-16 and Big-Endian Unicode… So finally there’s an excuse to create a custom binding. And the good news is that although this might be tedious, it’s not hard and there is a Microsoft sample that does exactly what we need. Instead of using the “optimized” XML reader and writer used by WCF, the sample uses a plain ole System.Xml.XmlReader and System.Xml.XmlWriter which do support ISO-8859-1. So aside from having to add a custom MessageEncoder, MessageEncoderFactory, MessageEncodingBindingElement and BindingElementExtensionElement to our project (just cut and paste from the Microsoft sample), things really aren’t too bad.

Once the custom MessageEncoder (and friends) are in place we still need to modify the auto-generated system.ServiceModel section of our app.config file (actually, in this case we’re going to just replace the whole section). Here is what it looks like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <bindings>
           <customBinding>
            <binding name="NdfdBinding">
              <StmEncoding messageVersion="Soap11" encoding="ISO-8859-1" />
              <httpTransport/>
            </binding>
          </customBinding>
        </bindings>
 
        <client>
          <endpoint address="http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php"
                    binding="customBinding"
                    bindingConfiguration="NdfdBinding"
                    contract="NdfdServiceReference.ndfdXMLPortType"
                    name="ndfdXMLPort" />
        </client>
 
        <extensions>
          <bindingElementExtensions>
            <add name="StmEncoding"
                 type="StmEncoderLibrary.StmEncoderBindingElementExtensionElement, StmEncoderLibrary"/>
          </bindingElementExtensions>
        </extensions>
 
    </system.serviceModel>
</configuration>

The first thing required is a new endpoint.

<client>
   <endpoint address="http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php"
             binding="customBinding"
             bindingConfiguration="NdfdBinding"
             contract="NdfdServiceReference.ndfdXMLPortType"
             name="ndfdXMLPort" />
</client>

The address and contract are the same ones that were auto-generated from the NDFD WSDL document, but instead of using a basicHttpBinding, we specify a customBinding which gives us complete control of the WCF messaging stack. The specific custom binding we’re going to use in this case is named “NdfdBinding”. The name of the endpoint is how we are going to reference this endpoint when we create the service proxy in our application.

The next piece is the customBinding.

<bindings>
   <customBinding>
     <binding name="NdfdBinding">
       <StmEncoding messageVersion="Soap11" encoding="ISO-8859-1" />
       <httpTransport/>
     </binding>
   </customBinding>
 </bindings>

You probably don’t recognize the StmEncoding element (neither does Visual Studio IntelliSense). It’s a custom element that references a binding extension – this is how our custom MessageEncoder implementation gets into the act. Note that StmEncoding has messageVersion and encoding attributes – this is where we specify now our encoder is going to work – they are the values that eventually get passed to our custom MessageEncoderFactory and then to our custom MessageEncoder constructor.

Finally the bindingExtension:

<extensions>
   <bindingElementExtensions>
     <add name="StmEncoding"
          type="StmEncoderLibrary.StmEncoderBindingElementExtensionElement, StmEncoderLibrary"/>
   </bindingElementExtensions>
</extensions>

This is where we specify the fully-qualified name of our class derived from BindingElementExtensionElement and the assembly containing the entire custom message encoder implementation.

Well, that’s it. Once you have the custom MessageEncoder that handles ISO-8859-1 and an appropriately constructed app.config file you should be able to talk to the NDFD web service and get a weather forecast whenever you want.

If you would like try out the code, here is a working version of a Windows Forms application and a dll containing a custom MessageEncoder, and here is the source code.

Next I think I’ll make the XML data a bit more readable.