• API Overview
  • API Reference
  • C Library
  • Web Application
  • Knowledge Base
  • Back to meteonorm.com
Meteonorm Climate
Meteonorm Observation
Meteonorm Forecast
Parameter Modelling
Data Sources
    Source Selection Process
powered by Zudoku
Data Sources

Source Selection Process

Most Meteonorm endpoints do not return their data from a single archive. A request is instead served by combining several data sources — satellite products, reanalyses, forecast models, and station-based products — each covering a different part of the globe, a different time period, and a different set of parameters.

This page gives a short overview of how those sources are chosen, queried, and combined into one consistent time series.

Overview

fetch-process-fig1 Figure 1: How a request is served: sources are selected by priority, checked, resampled and merged into one time series.

Priorities & Coverage

Every source declares its parameters, geographic coverage, time period relative to the present, and a priority level that determines selection precedence when multiple sources overlap.

Selection runs separately for each requested parameter:

  1. Sources that do not cover the requested coordinates are filtered out.
  2. The remaining sources are applied in order of descending priority: the highest-priority source covers as much of the time period as possible, and any remaining gaps are passed to the next source.

If no source covers the location, or if the available sources together cannot cover the whole requested time period, the request fails with an error rather than returning an incomplete series.

Quality Control & Automatic Fallback

In addition to the coverage-based selection above, the data fetched from each source is checked for completeness before it is used. If more than 20% of the requested data is missing, or if the source is temporarily unavailable, that source is skipped and the next source in priority order takes over. An error is returned only when no remaining source can supply the requested parameter.

Why request length matters

Because the threshold in the check above is relative to the requested period, a fallback to an alternative data source is more likely for shorter time series. For example: a brief delay in satellite data availability might be negligible across a 7-day request, but that same delay could leave more than 20% of a 3-hour request missing. As a result, the fallback applies and the next source in priority order is used instead.

Resampling & merging

The data from each source is converted to the requested output frequency and then merged into a single series per parameter, with higher-priority data taking precedence. At the boundary between two sources the values are faded from one into the other over a few hours, so transitions are gradual rather than abrupt.

Last modified on September 23, 2026
PV Production
On this page
  • Overview
  • Priorities & Coverage
  • Quality Control & Automatic Fallback
    • Why request length matters
  • Resampling & merging