A few years ago I published a number of articles around using the National Weather Service NDFD web service to get current weather conditions and forecasts. Unfortunately a few months ago quite a few folks started mentioning the example applications had stopped working. I finally got time to look at the problem and have updated both the original articles and download examples. Just to tidy things up – and so folks won’t have to wait next time, I thought I would describe how I got everything working again. I’ll walk through the simplest example (the one from the “Consuming NDFD Web Services from a C# Client” post, but the debugging process and changes apply to all the examples that access the NDFD web service.
1. First I ran the original NdfdTest-Application example from the post. Yes, things weren’t looking so good.
2. So I downloaded and built the original project – and there were errors:
Clearly the service reference for the NDFD web service was not getting created.
3. Visual Studio can update service references if you ask so I right-clicked on the NdfdServiceReference and selected “Update Service Reference” from the shortcut menu and built the project again:
Ah ha! [Change 1] They changed the signature of the method used to get forecasts! To see what’s happened, double click on the NdfdServiceReference from the Solution Explorer in Visual Studio then expand the NdfdTest.NdfdServiceReference node in the Object Browser and click on the ndfdXMLPortType interface. It turns out they changed the signatures for all the methods, adding the ability to specify whether you want results in English (unitType.e) or Metric (unitType.m) units. So I modified the NDFDgetByDay function, adding a unitType.e parameter and ran the application – and we are still getting an Invalid Zip Code error. But now you can see in the output window we are getting a protocol exception:
4. This is good information, but not enough. So in Visual Studio I enabled breaking on any thrown Common Language Runtime Exception. I ran the application again, entered a zip code and bang!
What the heck is going on? We asked for for text/xml and we are getting text/html.
[Change 2] Somebody moved our web service – now it’s a web page instead!
5. I admit at this point, as soon as I updated the service reference, I should have gone to the app.config file and looked at what was generated for me. Well, never too late… Low and behold, there is a new address for the NDFD web service:
When I wrote this series of posts, the NDFD web service was at http://www.weather.gov. Now it’s at http://graphical.weather.gov instead.
6. So finally, replace the address on our original ndfdXMLPort endpoint with the address from the newly generated ndfdXMLPort1 endpoint. Everything is working again.
Great post!
I wrote a program in C# like this to consume weather feeds for my own use because I could never find one already written that had things just like I wanted. It shows current conditions, forcasts, but also will show any alerts put out for the monitored area. I can see any current weather warnings, fire hazards or what ever the NWS puts out for my area. One thing I did differently: I wasn’t confortable consuming the data from web reference because I wanted something a bit more portable and less tied to their web services. My program consumes the RSS data feeds and parses the XML documents returned. A bit more generic I believed at the time because I could then use it to parse data from any service that returned XML documents with only slight code changes. I eventually wrote the program to only consume from NOAA and the NWS because being a government service, it’s public domain and “free”. My tax dollars help maintain the site so through my application at least I’m getting something back. My program isn’t perfect but it works pretty good for me. Thanks for the post.