At the end of 2021, Dark Sky’s weather API will finally be history. After Apple acquired the company in March 2020, the tech giant has gradually integrated all Dark Sky services. In July 2020, the app for Android was discontinued and now the end of the weather data interface also follows. The consequence: users of the Dark Sky API have to look for an alternative. Fortunately there are some good ones.
In the following, we present the 5 most important criteria to consider when choosing a suitable weather API.
1. Data scope: The more weather parameters the better
What parameters does the API include? Is the minimum standard enough for me? In which time steps – daily, hourly or quarter-hourly – do I want to retrieve the data? Do I need historical data or forecast data and for how many days in advance? These are questions every developer asks at the beginning of a project.
Simple weather APIs often only provide a forecast on a daily basis with the following eight parameters as a minimum standard: temperature (min, max, average), precipitation amount, probability of precipitation and wind speed.
Professional APIs also offer many other parameters: calendar (sunrise, sunset, day length), climate data (extreme values, deviation from the climate mean) or special parameters such as UV index, global radiation, ozone, fine dust or pollen load.
Tip: Promises like “We offer 30 days forecasts” should not be trusted much. This is no proof of quality, because no weather model can reliably determine the weather that far in advance.
2. Data quality: Regional models provide more precise data and quality has its price
Many providers promise high-quality weather data for the whole world, and often free of charge. But beware of such offers: High-quality data and forecasts require deep technical knowledge, model expertise and ongoing data preparation. Only very few can really do all this – and of course this comes at a price.
In addition, the models on which the weather data are based are extremely important. Global models such as the GFS model of the US climate authority NOAA are rather unsuitable for the German-speaking region, since their resolution is much too coarse. Consequently, the same weather data would be output for Berlin Grunewald and Berlin Alexanderplatz, even though the two locations are 13 kilometers apart. It is even more critical in exposed locations on the coast or at the edge of the Alps, where often only a few kilometers can make a big difference in the weather.
Tip: Good providers use regional models with particularly high spatial resolution. This makes the data much more precise.
3. Variant query options: Providing multiple options makes it easier for the user
Good weather APIs offer multiple query variants to help users find the right one for them, depending on their case or preferences. In the best case, weather data can be queried by geo-coordinate, city name, zip code, or some other geo-aggregation.
For example, if one wants to link customer data with weather data at the zip code level for an analysis, a zip code query function saves the detour via a matching table.
Furthermore, simple APIs only provide historical data in the form of measured weather station values. This is of little use since, for example, Munich Airport is known to be several kilometers away from the center of Munich. Good weather APIs therefore provide historical data from a forecast or grid archive.
Tip: The METEONOMIQS API even offers weather aggregation. This allows the weather to be output precisely to many geographical levels. Among these are postal codes, counties, Nielsen areas or even microgeographic units such as GfK City Districts or Microm areas. That saves a lot of data preparation.
4. Integration: Quick & Easy has the top priority
Tip: Suitable weather APIs have many different endpoints such as forecast, history, climate or air quality – this generates many queries and additional monitoring for the user.
5. Price: Don’t buy a pig in a poke and test it first
The first step should always be to test the API in detail via a free trial period. Sometimes this trial can be used for smaller applications such as a weather widget for a specific location.
Beyond the trial volume, the price depends on the data volume and query volume. Those who generate more queries or need hourly data as well as historical data will pay more. If you are not quite sure yet whether the weather API is the right one, you should first choose a small package and pay variably according to retrieval. The public prices are unit prices. However, if you only need individual data parameters, for example, but a high query volume, you should ask the respective provider directly for individual packages.