Den by default » Using the Google Weather API

Using the Google Weather API – pros and cons so far

For my latest project, WeatherBar, I had to pick a weather API. Basically, I needed to get the weather conditions for a specific location, as well as a short forecast. The choices I had were Yahoo Weather API, WeatherBug API and Google Weather API (yes,there is no mistake here – it is a direct API call, since Google doesn’t have an official page for this API). Probably there are more services offering a public weather API out there, but these caught my attention.

Once I started working with API documentation I have encountered some serious limitations. When using the Yahoo Weather API, I had to operate with location-specific codes. Those are called WOEIDs (Where on Earth IDs). This required extra coding just to get that code. To give an example, here is the WOEID for Mercer, NJ (shown in the Yahoo Weather sample): 2507854. What does it say to you? Unless you know the principles of how WOEIDs are build, this is a bit hard to operate with. The WeatherBug API was pretty good. If used for US-only weather, it is more than enough – the API calls can be based on ZIP codes, therefore by entering a five-digit zone code, the weather conditions can be obtained. But this didn’t work well for international locations. WeatherBug allows the developers to get the weather anywhere, but once the location passed is outside the US, no ZIP code is going to help – the geographical coordinates are needed. Getting those would involve another geolocation web service, and at this point I wanted to keep it simple.

There was Google Weather API left. And it wasn’t a bad choice after all. WeatherBar gets all the weather conditions through this API. So, what are the good and the not so good parts about this specific service?

Pros:

Accepted Parameters – To get the conditions, the developer doesn’t have to know the latitude, longitude or the location code for a city or town to get the weather. Google Weather API accepts city names and ZIP codes as parameters for an API call, therefore it makes it a bit more comfortable to work with.
Performance – At this point I am not comparing this API to any other, I am just pointing out the fact that the data is processed and returned to the application quite fast.
XML readability – Unlike many others, the XML response for Google Weather API calls is quite explicit. No need to figure out what a specific abbreviation means or whatever a code means to a developer. There is either a positive response (with conditions) or a response notifying of an error. Here is a sample request.

Cons:

Lack of documentation - Believe it or not, but there is not much documentation on the Internet for the Google Weather API. I found this document, and it helped me build the actual API request, but no details. What about a detailed list of weather conditions? Nope, nothing like that. I discovered a lot of conditions by actually using System.Diagnostics.Debug.Print to see, where a condition is lacking an icon (you can use those supplied by Google and you will basically get rid of this issue, but I wanted to use some icons that are bigger than the default ones). Once noticed, I introduced the value in the switch statement. I do believe there are still quite a few missing.If anyone is interested, here is my list of weather conditions for the Google Weather API that I have found so far. It will be updated as new ones will be “caught”.
No detailed conditions in response – All a developer can get as a response are the current conditions (including temperature and humidity) and the forecast for the next four days. Nothing more, nothing less. Can be useful for small projects like WeatherBar, but when it comes to larger projects that work with forecast, wind velocity at various times (you can only get the current one) and detailed forecasts, Google Weather API is not an option.

From the experience I’ve got, I can say that I would definitely recommend Google Weather API for small projects. It offers the basic set of features to determine the conditions and it is easy to use. For larger ones – you will have to work with additional geolocation services and do additional document parsing.

12 Comments to “Using the Google Weather API – pros and cons so far”

Skaggles 4 February 2010 at 2:02 am #

Nice post. I’m actually looking into using the Google Map API for a project of mine.
Silvermage 14 February 2010 at 3:28 pm #

I was searching for that conditions.xml. You definitely saved my hours man. Thanks!
Allan 15 February 2010 at 9:31 pm #

I’m with @Silvermage You saved my ass with the conditions list. Thanks!
Daily Digest for February 20th | More Than Scratch The Surface

[...] Shared Den by default » Using the Google Weather API – pros and cons so far. [...]
Grey 12 March 2010 at 5:46 am #

Wow thanks a lot man, I spent hours searching for the weather conditions.
Grey 12 March 2010 at 6:34 am #

Here´s one you missed I think: Partly Sunny
Dennis Delimarsky 12 March 2010 at 4:14 pm #

Thanks Grey! Added it to the XML file. Glad to see other people contributing to the list as well.
Adam 8 April 2010 at 6:08 pm #

One thing I’m looking for here is historical and future data.

I’d love to be able to pass a date into the API and get specific data back for that date.
daniphone 19 April 2010 at 9:36 pm #

Nice article. Have anyone of you tried free weather API by World Weather Online (http://www.worldweatheronline.com/free-weather-feed.aspx). I need some information as to how reliable it is and whether someone else is using it.
Dennis Delimarsky 1 May 2010 at 2:36 pm #

Never tried it, but I see that it offers no location search – only by ZIP code and geographical coordinates.
Lucas Randazzo 17 May 2010 at 4:59 pm #

Thank you. Google weather API has been my salvation. I hope they make it official.
Dennis Delimarsky 18 May 2010 at 4:48 pm #

You are welcome! Well, generally it is official, it is just poorly documented.