DEV Community: SimpleMeteo

How barometer.today draws its isobars

SimpleMeteo — Mon, 07 Sep 2026 22:47:02 +0000

barometer.today shows air pressure for any city: the reading now, the change since yesterday, and the week ahead. It also has a world isobar map, animated hour by hour from a day back to four days ahead.

This post explains what isobars are and the algorithms that we use to draw them. The code is Python with numpy, scipy, contourpy and shapely, and anyone drawing contour maps from gridded data will meet the same problems.

What an isobar is

Air pressure varies from place to place, and a weather map shows this with isobars - lines joining points of equal pressure. Where lines crowd together pressure changes fast over a short distance and the wind is usually strong. Where they spread out the air is calmer. The rings close around centers of high pressure marked H and low pressure, marked L. A deep low with tight rings is a storm. A broad high with loose rings is settled weather.

The pressure on such a map is sea-level pressure. A barometer in Denver reads about 835 hPa because it sits 1,600 m up, which says nothing about the weather. So the reading is converted to what it would be at sea level, and the map becomes comparable everywhere. With one exception, covered below.

The data

The map is drawn from the ECMWF global forecast. It arrives as a grid of sea-level pressure values every 0.25 degrees, about 28 km, for the whole planet. The model's own time step is three hours; Open-Meteo interpolates that to hourly values. We fetch it from Open-Meteo, which we run on our own server for all SimpleMeteo.com sites. uvi.today and pollen.today use the same instance.

The model updates four times a day. After each update a job produces one frame per hour, about 120 in total.

Smoothing

A raw model grid is jagged cell to cell, so lines traced straight from it wobble. We use a Gaussian blur with a sigma of one cell, 28 km. Wider blurs give calmer lines but flatten the extremes: with a 110 km blur, a hurricane with a 936 hPa core comes out as a mild 993 hPa low. It could produce a map that looks fine and is wrong.

The blur has to know about mountains. Over a high plateau sea-level pressure is a calculation about air that does not exist, and it usually comes out several hPa too high. A plain Gaussian would spread those inflated values into the real field around the plateau. Along the Himalayan front this moves lowland values by more than an isobar interval.

The fix is a normalized convolution. Blur the field with the plateau cells set to zero, blur a mask of ones and zeros the same way, and divide one by the other. Each output cell is then the weighted mean of only the valid cells nearby. Two lines of scipy:

num = gaussian_filter(np.where(valid, z, 0.0), sigma)
den = gaussian_filter(valid.astype(float), sigma)
smoothed = np.where(valid, num / den, z)

The same trick handles a missing value: instead of a single null spreading into a 9 by 9 hole after blurring, it contributes nothing and stays a one-cell gap.

Where the mask is

The mask is ground above 2,500 m. It comes from a digital elevation model, smoothed to 55 km so that a single peak does not count, then only massifs of at least 265,000 km² are kept. Four regions qualify: the Andes, the Tibetan plateau with the Himalaya and the Pamir, the Greenland ice sheet and Antarctica.

Over the mask the isobars are still drawn, but dashed. The map stays continuous and the reader is not left with a hole in Asia, while the dashes say the values here are extrapolated. Each line segment is tested against the mask individually, so an isobar crossing the Andes is dashed for exactly the part over high ground.

Tracing the lines

Contours are traced with marching squares, the standard algorithm that matplotlib uses. Each grid cell has a value at its four corners. For a given level, say 1012 hPa, the algorithm marks each corner as above or below, which gives 16 possible patterns, and each pattern says where the line enters and leaves the cell. The crossing point along an edge is found by linear interpolation between the corner values. Done for every cell, the pieces join into continuous lines. Done for every level, you have the map.

A world map adds a twist: longitude wraps around. The algorithm sees a rectangle with left and right edges and would stop every line at 180 degrees. So the grid is padded with two degrees of columns copied from the opposite edge, contoured, and the lines clipped back to the world. They then cross the Pacific date line without a seam.

pad = int(math.ceil(2.0 / res))
zp = np.hstack([z[:, -pad:], z, z[:, :pad]])
xp = np.concatenate([lons[-pad:] - 360, lons, lons[:pad] + 360])
gen = contourpy.contour_generator(x=xp, y=lats, z=np.ma.array(zp, mask=mp))

Each line is then simplified with the Douglas-Peucker algorithm at 0.05 degrees. It removes points that lie within that distance of a straight line between their neighbours, so a nearly straight 900 km isobar collapses to three points while a tight ring around a storm keeps its shape. A frame ends up as a few hundred kilobytes of GeoJSON, under 100 KB compressed.

Finding the H and L

Centers are found on the smoothed field with min and max filters: a cell is a candidate if it is the extreme within a window of about 850 km. The window is built per band of latitude, so it is a real distance and not a cell count. A fixed cell count would cover only half the distance at 60 degrees north that it covers at the equator.

A candidate must also stand out. The field within the window must range by at least 3 hPa, or 5 hPa inside 20 degrees of the equator, where the tropical atmosphere has a natural twice-daily tide of 2 to 4 hPa that would otherwise put a letter at every ripple.

Two details matter in practice. The masked cells are filled with minus infinity for the max filter and plus infinity for the min filter, never NaN. Scipy's filters treat a NaN differently depending on where it falls in the window, and the result is that a real low on the Antarctic coast can silently vanish. And no letter is placed on ground above 1,000 m. In the tropics a high is also dropped when ground above 700 m lies within a degree of it, because the nightly cooling of a highland spills a fictitious high onto the coastal cells around it. Lows are exempt: the Afar heat low sits near sea level inside a ring of highlands and is real.

z_hi = np.where(mask, -np.inf, z)   # for maximum_filter
z_lo = np.where(mask,  np.inf, z)   # for minimum_filter

The final step is the one that matters most. Each surviving candidate is refined on the raw, unsmoothed grid: the printed value and position are the true extreme within one degree of the candidate. Smoothing is right for the lines and wrong for the extremes. This way the L over a hurricane carries the model's own minimum, even when the core is only a few cells wide.

Keeping the animation steady

A center must also appear in the neighbouring hour, within 800 km, in either the frame before or the frame after. A letter that exists for a single frame is noise at the threshold, and dropping it keeps the animation calm. The rule is deliberately loose: a deep Atlantic low can move 500 km in a few hours, and a stricter test took its letter away while the rings were plainly there.

In the browser, the map is Leaflet. The image layers are created once and only swap their source between frames, and the lines are redrawn on a single canvas. A frame is shown only when its lines and fill have fully decoded. And the number labels on the lines stay in place as long as the same isobar still runs under them, so you can scrub through five days of weather on a phone and the numbers do not jump.

The map is at barometer.today/pressure-map. barometer.today is part of the SimpleMeteo family with uvi.today (UV index), pollen.today (pollen), airindex.today (air quality) and weatherjourney.com (climate history since 1940). All are free, with no accounts, cookies or ads.

Why we self-hosted Open-Meteo: AI crawlers, rate limits, and 100 ms we didn't expect to win

SimpleMeteo — Tue, 28 Apr 2026 17:35:05 +0000

TL;DR — We run uvi.today (UV index), pollen.today (pollen forecast) and airindex.today (air quality). All three pull from Open-Meteo. AI crawlers pushed us past the free tier, the paid tier worked but still wasn't a fit for crawler-heavy traffic, so we ended up self-hosting Open-Meteo on a single VPS. Disk: ~50 GB. Latency: 90–100 ms faster per request. Cost: less than the paid plan.

This is a short write-up of how we got there, what the migration actually looked like, and a couple of things we'd flag for anyone thinking about doing the same.

The setup

The three sites are simple Next.js apps. Each city page renders server-side and calls Open-Meteo for two datasets:

The forecast API for temperature, weather code, humidity, etc.
The CAMS air quality API for UV index, AQI components, and pollen.

We cache responses in an LRU on the Node side (coord-keyed, 60 min TTL) and that's it. No queue, no warm cache jobs, no background workers.

For the first months, the free public Open-Meteo API was perfect. The free tier is generous:

Tier	Per minute	Per hour	Per day	Per month
Free	600	5,000	10,000	300,000
Standard	unlimited	unlimited	unlimited	1,000,000

Source: open-meteo.com/en/pricing. The free tier is non-commercial; the Standard plan is what you upgrade to once you put ads on the site.

Then the crawlers showed up

Search Console traffic was modest. Logs were not. Once the sites started ranking on long-tail queries, every AI crawler on the planet decided that a city-by-locale URL grid was an irresistible buffet.

In our access logs we kept seeing the same User-Agents on tight loops:

GPTBot
ClaudeBot
Bytespider
Amazonbot
Meta-ExternalAgent

The peak we measured before blocking them was around 15,000 requests per hour from a single bot. On a sister project that took longer to get blocking right, we saw bursts close to 200k/day. None of these bots respect any kind of "please slow down". They either get a 200, a 429, or a 403 — pick one.

We picked 403, eventually. But before we did, the public Open-Meteo API started returning 429s during peaks, and our pages started erroring out for real users.

The math is brutal: 100 cities × 9 locales = 900 cacheable URLs. With a 60 minute cache TTL that's 900 origin requests per hour worst case for our own users. Add a single misbehaving crawler that ignores cache headers and asks for ?lat=…&lon=… with random rounding, and the cache hit rate collapses. We were burning through 10,000 calls/day in a few hours.

We tried the paid tier first

The Standard plan removes the per-minute, per-hour and per-day caps and gives you 1,000,000 calls per month on a customer-api.open-meteo.com host. Switching is one env var:

# .env
OPENMETEO_API_KEY=...

// src/lib/uv-api.ts (excerpt)
const omHost = process.env.OPENMETEO_HOST;
const apiKey = !omHost ? process.env.OPENMETEO_API_KEY : undefined;

const CAMS_BASE = omHost
  ? `${omHost}/v1/air-quality`
  : apiKey
    ? 'https://customer-air-quality-api.open-meteo.com/v1/air-quality'
    : 'https://air-quality-api.open-meteo.com/v1/air-quality';

Open-Meteo are upfront in their FAQ that monthly limits aren't being enforced yet — they're still building the usage portal — so in practice the Standard plan is "soft 1M/month, dedicated servers, commercial use OK". This solved the rate-limit problem immediately.

It did not solve two other things:

Crawler load is wasteful spend. Even if the limit isn't enforced, paying for traffic that produces no revenue (and no useful index entry on most platforms) is irritating.
Latency. Every page render fans out to two API hosts in another datacenter. We were measuring p50 around 180–220 ms per upstream call from our box. CAMS pollen + forecast = two of those, mostly serial.

Self-hosting Open-Meteo

This is the part that surprised us: it is genuinely easy.

Open-Meteo publishes a single Docker image (ghcr.io/open-meteo/open-meteo) that does both jobs:

serve — runs the API on port 8080. Same query syntax as the public API.
sync <model> <variables> — pulls the latest model run from the upstream provider (DWD, NOAA, ECMWF, MET Norway, …) and writes it to a shared volume.

You run one serve and as many sync workers as you have models you care about. Each sync job re-runs on an interval (--repeat-interval 5 = every 5 minutes) and stores the last N days of past data (--past-days 3).

For us, the relevant compose file looks roughly like this:

services:
  open-meteo:
    image: ghcr.io/open-meteo/open-meteo
    volumes: [open-meteo-data:/app/data]
    expose: ["8080"]
    command: ["serve"]

  sync-dwd:
    image: ghcr.io/open-meteo/open-meteo
    volumes: [open-meteo-data:/app/data]
    command:
      - sync
      - dwd_icon,dwd_icon_eu,dwd_icon_d2
      - temperature_2m,relative_humidity_2m,weather_code,cloud_cover,precipitation,shortwave_radiation
      - --past-days=3
      - --repeat-interval=5

  sync-cams:
    image: ghcr.io/open-meteo/open-meteo
    volumes: [open-meteo-data:/app/data]
    command:
      - sync
      - cams_global,cams_europe
      - uv_index,uv_index_clear_sky,pm10,pm2_5,ozone,alder_pollen,birch_pollen,grass_pollen,ragweed_pollen
      - --past-days=3
      - --repeat-interval=5

volumes:
  open-meteo-data:

We sync six model groups in total:

DWD ICON (11 km global, 7 km EU, 2 km Central EU)
NCEP (GFS 13 km global, HRRR 3 km CONUS)
ECMWF IFS 25 km — long-range
MET Norway / UKMO / BOM / CMC for regional accuracy
CAMS global + Europe — UV, AQI, pollen
A one-off copernicus_dem90 sync for elevation data (~10 GB, runs once)

Application-side change is one line: set OPENMETEO_HOST=http://open-meteo:8080 and the existing client code routes there instead of the public API. No query rewriting needed — that's the nice part of Open-Meteo's design.

What the box actually looks like

Real numbers from a single VPS (8 vCPU, 16 GB RAM, 150 GB disk) running everything — three sites, Caddy, an IP-geo service, monitoring, and the full Open-Meteo stack:

Disk used by Open-Meteo data: ~50 GB and stable. The DEM is the largest one-time cost (~10 GB). The rolling weather data stays bounded by --past-days.
open-meteo serve container at steady state: ~1.1 GiB RAM, ~4 % of one core. Model files are mmapped, so the kernel page cache does most of the work — it's why free -h shows ~13 GiB sitting in buff/cache.
Sync workers: burst CPU when a new model run lands (every 1–6 hours depending on model), idle the rest of the time.
Initial sync: 1–2 hours for the first run. This is the only painful step.

This is a quieter footprint than we expected. Open-Meteo's storage format (here's their write-up) is a custom layout designed for exactly this kind of mmap-friendly point lookups, and you can feel that in the metrics.

The latency win

We weren't optimising for this — we just wanted the rate limits gone — but it turned into the most visible result.

Measured per-call upstream latency from our app container to Open-Meteo:

Public API (api.open-meteo.com): ~100-110 ms
Customer API (customer-api.open-meteo.com): comparable, slightly more consistent
Local container (http://open-meteo:8080): ~10 ms

Per page render that's roughly 90–100 ms shaved off, twice (forecast + CAMS), most of it serial. For a server-rendered Next.js page that has to land HTML before the browser can paint, this is meaningful — we saw it directly in our TTFB numbers.

What we didn't migrate

Not everything makes sense to host yourself:

Geocoding (geocoding-api.open-meteo.com). It's a separate service with its own dataset; we kept it on the public API and put a 1-hour LRU cache in front of it.
Historical / climate / ensemble APIs. We don't use them. If you do, note that the Standard plan also doesn't include them — that's a Professional-tier thing.
Marine / flood APIs. Same — out of scope for us.

The gotchas

A few things to know before you copy the docker-compose:

Pick variables deliberately. Each sync command takes an explicit list of variables. Adding a variable later means re-syncing — don't be too minimal at first.
Disk growth is mostly the DEM. The rolling weather data stays small if --past-days is small. Set this honestly — we use 3.
There is no built-in API key / rate limit on the local instance. It binds to a private Docker network in our case; if you expose it to the internet, put a reverse proxy with auth or a rate limiter in front.
Crawlers will still hit your app. Self-hosting Open-Meteo doesn't solve the crawler problem — it just stops the crawler problem from cascading into a third-party rate-limit problem.
Attribution still applies. Open-Meteo's data is CC BY 4.0; you keep crediting the underlying data sources (DWD, NOAA, ECMWF, CAMS, …) regardless of how you host it.

Was it worth it?

For our shape of traffic — small site, three domains sharing the same upstream, lots of automated traffic — yes, comfortably:

Capacity: effectively unbounded for our scale. We can let crawlers through if we ever change our mind without watching a meter.
Latency: ~10 ms per upstream call, twice per render.
Cost: one VPS that we already had, instead of a per-domain subscription.
Operational risk: lower than expected. The image is one container, the syncs are independent, and a failed sync just means stale-but-still-served data for that model.

Written by the team behind uvi.today, pollen.today, SimpleMeteo and airindex.today. We post the engineering side on X — @SimpleMeteo.