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?
- 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.
- 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 (link no longer active) 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.