Question 1

Why does the Open-Meteo status page not load and show ERR_BLOCKED_BY_CLIENT errors?

Accepted Answer

The ERR_BLOCKED_BY_CLIENT errors indicate that a browser extension (like an ad blocker) is blocking resources from app.statuscake.com. To fix, temporarily disable your ad blocker or add status.open-meteo.com to its allowlist. Alternatively, try opening the page in an incognito window with extensions disabled.

Question 2

Why is the Open-Meteo meteofrance_currents (SMOC) model stuck on an old run and not updating?

Accepted Answer

This is usually caused by an upstream data delay at Copernicus Marine, not by Open-Meteo itself. The `meteofrance_currents` downloader ingests both sea level and current data together, so when the Copernicus MOL sea-level dataset (`cmems_mod_glo_phy_anfc_merged-sl_PT1H-i`) is delayed due to unavailable upstream files, the ingestion of SMOC currents is blocked as well. To diagnose: 1) Check the model's last run at `https://marine-api.open-meteo.com/data/meteofrance_currents/static/meta.json` (`last_run_initialisation_time`). 2) Check the Copernicus Marine notification service for product `GLOBAL_ANALYSISFORECAST_PHY_001_024` for outage/delay announcements. 3) Wait for the upstream issue to be resolved; updates resume automatically once Copernicus publishes again. Note: forecast requests keep returning the last available run with `null` values beyond its `data_end_time`. Missing runs during the outage gap cannot be recovered or backfilled, because Copernicus no longer offers past runs for download, so the update jumps to the newest available run.

Question 3

How to reduce Open-Meteo self-hosted mirror storage by syncing only one region or country?

Accepted Answer

Use the regional sync option added in PR #2201: run `openmeteo-api sync --bbox lat1,lon1,lat2,lon2` to keep only data chunks inside your bounding box. Chunks outside the box are written as NaN, so the files remain fully compatible with the current Open-Meteo API and readers. Example results from a Japan-only mirror: 7 TB full-world database shrank to 292 GB, and a full fill from zero takes about 1 h 45 min. Reads are planned from each file's lookup table and merged, so sync costs only a few dozen to a few hundred range requests per file. A `--region area.geojson` polygon option and a `--mask-mode absent` mode (drops unused chunks entirely, ~44 GB for Japan but requires om-file-format changes) were proposed as follow-ups.

Question 4

How to obtain raw AROME-HD wind data for paragliding without elevation-based adjustments?

Accepted Answer

To get exact wind vectors from the nearest grid cell without any topographic statistical correction, use `elevation=nan` in your API request. This disables the default 90m DEM downscaling and prevents the system from selecting a different cell based on terrain height. For a 4‑day forecast with pure AROME‑HD during the first 48 hours and a smooth fallback to a lower‑resolution model afterwards, explicitly chain the models:
`&models=meteofrance_arome_hd,meteofrance_arpege_europe` (or `meteofrance_arome_france` for France‑only). The API selects the first model that covers each time step; when both cover the same period, the first listed model takes priority. This ensures high‑resolution AROME‑HD data for its maximum runtime, then a seamless transition to the global model without any blending that could dilute the 1.3 km resolution.

Question 5

Why is ncep_nam_conus wind direction wrong or mirrored in the Open-Meteo historical forecast API?

Accepted Answer

This is a suspected data bug: NAM CONUS wind direction appears mirrored, likely due to swapped u/v components or grid-relative winds not rotated to earth-relative. It affects `wind_direction_10m` and `wind_direction_80m` (wind speed is unaffected). Validation against METARs at KBDU/KBJC (~7,200 hours) showed NAM direction within 45° of observations only 24% of the time, versus 79% for `ncep_hrrr_conus`. Time-shifting does not help. Workaround: for wind direction over the CONUS domain, request `ncep_hrrr_conus` instead of `ncep_nam_conus` (e.g. `models=ncep_hrrr_conus&hourly=wind_direction_10m`). A partial mirror correction (`corrected ≈ 65° − reported_direction`) raises NAM agreement to ~57% but is not reliable for production use. Until the bug is fixed upstream, treat NAM CONUS wind direction from the historical forecast API as unusable.

open-meteo

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects