Choosing a Weather Service

I'm working on an iPhone app called Horizon that requires the use of a weather service. Horizon integrates the weather with your calendar to give you the most information about your upcoming appointments. It is not out yet, but you can follow @horizon_app on twitter to be kept up to date on its progress. This post is part of a series entitled "The Making of Horizon", where I discuss various topics involved in the making of Horizon. Without further ado, I present to you Part 1: Choosing a Weather Service.

I can honestly say that I have researched and used more weather weather services than I thought existed. Heres the thing: no matter where you look, you'll be hard-pressed to find one that suits your needs perfectly. The process I went through to find the right weather service for my app was painful and time intensive, I hope that this blog post will make it easier for you. First, let me note that my weather data needs are a little unusual and did have an effect on my opinion of these services. The right service for your product highly relates to what you need, so I will keep in mind the general use of these services when evaluating the different weather services. Let's jump right in.

The National Weather Service

The National Weather Service is part of the NOAA (National Oceanic and Atmospheric Administration), a scientific agency within the United States department of commerce. Keyword here is United States; the NWS only provides data in the US, which could be a deal breaker for many. The interesting thing about the NWS is that if you look at many other mainstream weather services (Accuweather,, etc.), you'll see that they get their data from the NWS. Huh? So do these sites actually do anything? It turns out that many weather services modify the NWS's data to try and produce more accurate results. The NWS API returns data in XML only and can be queried either through REST or SOAP. I didn't even consider using SOAP for my iPhone app, and I personally prefer JSON to XML. Then I checked out their documentation ( and was scared off, to say the least. Nevertheless, enamored by its price (or lack thereof), I replaced the service that I currently had integrated into Horizon (HAMWeather) with the NWS. This was a big mistake. Not only do I find their data structure completely moronic, the service was very unreliable. Sometimes it would load immediately and other times the request would take 5-10 seconds to return. I shortly switched back to HAMWeather (which I cover below). Even though implementing the NWS was a big pain in the ass, I did learn that the price of other services that offer quality, reliability, and ease of use may be more worth it than I thought.


After looking at the NWS's documentation, Wunderground's documentation was a pleasure to read. They had a clean, easy to navigate website and their API was quite easy to use. All you have to do is sign up for a developer account and you're good to go (for now). For what I need, batch requests are important. I need to be able to get several days of weather for multiple locations in one request. It's a tall order, and I didn't find it in Wunderground. They have batch requests, but only one location per batch. The rest of their API is really nice. I implemented it into my app quite easily. Their location parameter gives you many options, allowing you to input any of these: US state/city, US zipcode, country/city, latitude/longitude, airport code, and a few more. The biggest upset about Wunderground is their pricing. They have three different tiers based on what type of data you need, and then they have three more tiers based on how many requests you need. Just to give you an idea, to get a 10-day forecast and 1-day hourly at 5,000 calls per day will cost $150 per month. Need the hourly forecast for all 10 days? You're already up to $300 per month. Wunderground is a great weather API that comes with a clean, easy to navigate website. But it comes at a cost, and a relatively high one at that.

Not much to say about, only that after a little digging you'll find their prices are very high. 830 requests per day for 5 day weather data will run you about $350 per month. That's a hefty price to pay for weather data, especially compared to other services like Wunderground and HAMWeather.


Weatherbug is an interesting option. Their developer site is a little outdated, most posts haven't been updated for 2 years. However, you can send an email directly to Chris Sloop and he will reply very promptly. Weatherbug actually gives you 5000 free API calls per day, which would normally cost you $150 from Wunderground. Although you get 7 days out to Wunderground's 10, Weatherbug gives you hourly weather for the full 7 days. In addition, you can query up to 5 different locations at a time. Weatherbug is a pretty great API for a reasonable price. It seems to trump Wunderground in most areas (except for documentation). At this point, if I were choosing between the two, I'd go for Weatherbug.


Lastly, I discovered HAMWeather. HAMWeather offers a variety of solutions for your company or product involving weather. One of these products is the Aeris API. Aeris is a robust, full featured weather service that I had somehow never noticed until now. The documentation is very clear, and they offer a variety of different plans for your rates and usage. Also, their customer service is superb. After submitting a question, you will most always get a response within 24 hours. The Aeris API has a batch request feature that allows you to batch up to 10 requests into one. An important thing to note is that this doesn't condense your 10 requests into one API call, you are still charged with making all 10 API calls. It is purely for convenience and speed. Although this seems like it only offers a minor advantage over making multiple calls, the batch requests are still very useful and made my code much cleaner. For programs that need to make several requests at a time (like Horizon), this feature is a life saver. However, you will find that it quickly eats up your API calls. That leads us to pricing. The lowest plan, Basic, starts at $25 per month for 5k calls per day. This is not bad, however if you want any hourly details, you will need to upgrade to the Plus Plan, which currently doesn't offer any hourly data but will in the next update (which should be coming out in December of 2012). This puts you at a minimum of $130 per month at 35k calls per day. This is a lot better than Wunderground's $150 per month for 5,000 calls per day; and HAMWeather will give you 15 days of forecast to Wunderground's 10. 

In the end, I decided to use HAMWeather for Horizon. It's flexible plans, batch requests, and superb customer service lead me to pick it over the others. It seems clear that there is no one service that is the best, but that you need to evaluate all of them and choose which one works best for you and your product. Hopefully this blog post will help make the decision more clear for you.

Join the discussion on Hacker News:

If you liked this post, please follow me on twitter: @krosenbluth or @krosenbluth.

Fonts, they're more useful than you might think.

I was recently introduced to Symbolset, a company that creates "semantic symbol fonts". What this means is that you can type keywords (or unicode characters) to produce glyphs or other icons. At first, I didn't see what the big deal was. Why would you want a whole font when you could just import a .png of the icon? It wasn't until I started using them that I realized how awesome they are.


I first used symbolsets for a new iPhone app that I am working on. I had previously been struggling with finding the right set of glyphs to use. Finding the right size and color is a pain in the ass with a .png or even a vector. With a vector you have to open up Illustrator (or some vector graphics editor), resize, and then reimport into your app. I installed the symbolset font once, and I never had to leave the code again. It really is pretty cool. Open up a new document in a text editor, and watch as your keywords magically turn into icons. I had a slight hiccup when the keywords weren't working with iOS and did some research to find out how symbolsets actually work. 

Basically, symbolsets use ligatures to turn keywords into icons.

Li•ga•ture | ligəCHər | noun - a character consisting of two or more joined letters, e.g. æ, fl.

Their font consists of keywords where typing 'delete' is a ligature for an X. Ligatures aren't enabled in UIKit, however you can enable them in core text by setting 


to a value of 2. This enables all ligatures in a font, which is necessary to use symbolsets. However, I wasn't ready to dive into core text, which has many things that I don't need. So, I decided to use unicode. Yes, symbolsets also work with unicode values. This makes using them a little bit more difficult, but it is still a lot easier than using .png's. Now I can resize and change color on the fly! Because it is so easy, symbolsets allow me to explore my creativity with colors and sizing of an icon, something which I previously would not have done.

Another great example of an icon set that utilizes fonts are Climacons. Climacons are "a climatically categorized typeface for web and user interface designers". Essentially, they are a set of weather icons packed into a font. Unlike symbolsets, they do not use ligatures for their symbols. Instead, they have different characters represent a different icon. This is a bit harder to use, as I have to keep referencing their key, but it still provides a much better interface to use than downloading their png's.


More people are starting to create other uses for fonts besides text, and I have a feeling you will start to see a lot more unconventional fonts hit the market soon. I find them very helpful to use as glyphs or icons and can only imagine the other possible uses of fonts. What do you think of fonts and their evolving role? Answer in the comments below, join the discussion on Hacker News, or send an email to:

Follow me on twitter @krosenbluth or @krosenbluth