A weather model is an essential input, but it is not automatically the finished forecast for a particular place. The work that follows a model run helps connect its representation of the atmosphere with the conditions that matter to someone in a valley, on a mountain, at a farm or beside the coast.
Bringing different model outputs together
Forecast providers receive simulations from global and regional models with different grid spacing, terrain representations, update schedules and forecast horizons. Their performance also varies by location, weather variable and atmospheric situation. Several models can consequently produce different forecasts for the same place and time. Our weather-model guides explain these foundations in Part 1 and Part 2.
Before the outputs can be compared or combined, their meaning must be consistent. This involves checking coordinates, units, time intervals, measurement heights and variable definitions. Wind speed and wind gusts, for example, describe different quantities. A temperature value generally applies to a particular time, whereas precipitation describes an accumulation over a period.
For example, a three-hour precipitation total ending at 12:00 represents the water accumulated between 09:00 and 12:00 – not the amount falling at noon. To compare it with hourly precipitation, the different accumulation periods have to be taken into account. The original three-hour value also does not show exactly when within that period the rain occurred.
This preparation may be invisible to users, but it prevents differences in data format or definitions from being mistaken for genuine differences in the weather forecast.
Why a grid cell is not the same as a location
Numerical models represent the atmosphere and the surface on grids. A grid cell may cover a mixture of slopes, buildings, vegetation and water, while its modelled elevation differs from the height of the requested location. Smaller terrain features can be smoothed out, particularly in coarser models.
Consider a valley town and a nearby summit within the same coarse grid cell. Their proximity does not mean they share the same temperature, wind exposure or precipitation conditions. The first task is therefore to connect the requested coordinates with relevant surrounding model information, rather than simply treating one grid value as the answer.
For example, the meteoblue Forecast API produces point forecasts using surrounding model data, terrain information and post-processing. Users can specify the location’s elevation above sea level; otherwise, the API determines it from an 80-metre-resolution digital elevation model. Elevation adjustments affect several variables, including temperature and pressure.
However, an 80-metre terrain dataset does not mean the atmosphere has been simulated on an 80-metre grid. Local adjustment improves the relevance of a point forecast, but cannot recover every unresolved feature, such as airflow around an individual building or a very small scale shower. Native model resolution and local post-processing remain different things.
Deciding which models should contribute
Having several forecasts does not automatically identify the most useful one. A simple average can retain errors shared by multiple models, while always choosing the same model ignores changes in performance across locations and conditions.
The meteoblue Learning MultiModel (mLM) uses information about previous forecast performance to determine a suitable model combination for a specific location, typically considering performance over the previous 60 days.
This process can involve different forms of post-processing. Selection identifies a suitable model input, weighting determines how strongly different models contribute, blending
combines information from several forecasts, and correction addresses systematic errors. For example, choosing a model with a lower average error is different from adjusting a recurring bias, even though both can improve the final forecast. Where suitable measurements are available, they can also help identify and correct local forecast biases.
For meteoblue station-specific service, measurements from recent months can be used to adapt the model combination to local conditions. This helps account for site-specific performance differences that may not be visible in broader model comparisons.
mLM does not replace numerical weather models. It builds on them, using their forecasts in a way that reflects how well they perform for a given location and variable. At present, mLM is implemented and validated for air temperature, dew point temperature and wind speed. Other variables, including precipitation, cloud cover and radiation, rely on different data sources and processing approaches, so the same method should not be assumed across the entire forecast.
Adding the latest observations
For the next few hours, observations can reveal developments that an earlier model run has not captured accurately. Radar may show a precipitation band arriving sooner than expected. Stations can identify a local temperature difference, while satellite imagery provides information about clouds and their movement. Lightning observations can add context about active thunderstorms.
Observation-based short-range prediction is known as nowcasting. At meteoblue, it uses frequently updated station, radar or satellite information. Its contribution depends on the variable and available coverage: a radar image can help refine precipitation timing, but does not directly measure air temperature at a weather station.
These methods are particularly valuable in the immediate forecast range. Their usefulness decreases as weather features develop, weaken or change direction, so numerical models become essential farther ahead.
Making processed data usable
The processed forecast must then be presented in a form people and software can use. Depending on the product, this includes temperature, precipitation, wind, gusts, cloud cover and other variables, delivered as time series, diagrams or structured API data. Hourly values support detailed planning, while daily summaries provide a broader overview.
A single forecast value should also be accompanied by context about uncertainty. The meteoblue predictability indicator describes estimated forecast certainty, while precipitation probability concerns the likelihood of precipitation. They answer different questions: confidence in the overall forecast is not the same as the chance of rain.
The final point forecast is therefore not always the direct output of a single model. It combines available information into one best estimate while still reflecting the uncertainty that remains.
Why forecasts change between updates
A forecast is continually revised as new information becomes available. New model runs can change the expected development, mLM may update the preferred model combination, and recent observations can influence the short-range forecast.
For users, this may mean a change in when rain is expected to begin or an updated temperature for tomorrow afternoon. A forecast change does not automatically mean the earlier version was poor. It reflects the fact that newer information has been added, and its value can only be judged by comparing the forecast with what actually happened.
Checking the result against reality
The processing chain needs a way to establish whether it adds value. Forecast verification compares predictions with suitable observations across many locations and times. meteoblue monthly Forecast Accuracy Reports evaluate mLM against quality-controlled weather-station data and compare its performance with global models for temperature, dew point and wind speed.
A fair comparison must account for the weather variable, valid time and forecast horizon. The prediction issued several days before an event is a different test from an update made shortly before it. Hourly verification also captures timing errors that can disappear when only daily values are assessed.
Different metrics reveal different weaknesses. Mean Absolute Error (MAE) describes the average size of errors, Mean Error (ME) identifies systematic over- or underestimation, and Root Mean Square Error (RMSE) gives greater weight to larger misses. Used together, they help show whether a forecast performs consistently rather than being accurate only occasionally.
Verification also creates feedback for further development. A processing method may work well for one region or season but less well elsewhere. Repeated evaluation helps identify those differences and check whether changes improve performance over time. meteoblue Forecast Accuracy Reports provide a way to follow that evidence.
The forecast continues after the model run
The quality of a weather service depends on both its model inputs and how those inputs are processed. Making datasets comparable, adapting them to a location, learning from previous errors and incorporating suitable observations all help transform a model simulation into a usable forecast.
For meteoblue, these functions work together to produce locally relevant information. Continuous verification then tests the result. A forecast may look simple on the screen, but a lot of processing has happened before that final value is shown.
Have a question or an idea to share? Join the meteoblue Community Forum and continue the conversation with other weather enthusiasts.
