Inside Inverza

How Inverza sees the sky: eight data sources behind every forecast

· 8 min read · By Marcel Strelow
Infographic showing eight data sources arranged in a ring around a central forecast engine: Open-Meteo Forecast, Horizon Clouds, Air Quality, Marine API, Overpass / OpenStreetMap, METAR Live, High-Res Regional Model, and Previous Model Runs.
Eight independent data sources feed into a single Inverza forecast. Click to see full resolution.

Most weather apps query one model and call it a day. That gets you "will it rain on my walk to the train". Landscape photography needs more. You're trying to decide whether tomorrow's sunrise will be a flat grey lid or the kind of mid-cloud canvas that lights up neon for ninety seconds after the sun clears the ridge. One opinion isn't enough.

Every time Inverza refreshes the forecast for a spot, it makes eight network calls across four different providers, then merges everything into a single internal forecast object that the photo-condition detectors and the AI chat both consume. If any individual source fails, the forecast still works - the detectors just lose a small amount of nuance for that one slice. This post walks through what those eight sources are, what each one contributes, and why pulling them all together beats chasing a single "best" weather API.

1. Open-Meteo Forecast - the base layer

This is the foundation. One HTTP request to Open-Meteo returns the hourly and daily forecast for the spot: temperature, humidity, dew point, wind speed and direction at 10 m and at 700/500 hPa pressure levels, precipitation, weather code (the WMO 4677 standard table), and increasingly important for the dramatic-storm-clouds detector, CAPE (Convective Available Potential Energy) and Lifted Index. Cloud cover is returned broken into three altitude bands - low (0-2 km), mid (2-6 km), and high (6+ km) - which matters because each layer has a completely different photographic effect.

Open-Meteo aggregates several global models (ICON, GFS, ECMWF) into a unified API. The result is more robust than picking one model and trusting it absolutely. Every other source on this page is a refinement of, or cross-check against, this base layer.

2. Horizon Clouds - what's between you and the sun

Here's an early lesson in landscape photography: vivid sunrise colour depends on the sky between you and the horizon, sometimes 40 kilometres east of where you're standing. That distant strip is where the sun's light has to pass through on its way up to the clouds above you. If a thick low-cloud bank is sitting on that horizon, the rising sun never breaks free of it, and the interesting mid and high clouds overhead never receive the warm under-lighting that turns them pink and gold. They just stay flat and grey.

So for every forecast, Inverza fetches two additional cloud-cover queries: one ~40 km in the sunrise direction, one ~40 km in the sunset direction. This pair of "horizon offset" fetches uses Open-Meteo's lighter `cloud_cover_low/mid/high` endpoint and adds maybe 200 ms to the total fetch. The detectors for Colorful Dawn, Afterglow, and Golden Clouds check the local cloud canvas and the horizon clarity together. A glorious overhead deck plus a clear eastern horizon scores high; the same deck behind a horizon wall of grey scores low. Most apps cannot make this distinction, which is why their afterglow predictions feel like a coin flip.

3. Air Quality - the invisible variable

The Soft Light detector exists because of this source. Open-Meteo's air-quality API returns hourly aerosol optical depth (AOD), particulate matter (PM10, PM2.5), and a mineral dust value. When AOD is elevated - say, a Sahara dust plume drifting north over Europe, or wildfire smoke from a few states away - the golden hour produces a diffuse, particle-softened warmth that's photographically magical and meteorologically invisible to a normal cloud-cover forecast. The Soft Light detector reads air quality alongside sun altitude and surfaces this as its own condition.

Without air-quality data, "60% cloud, AOD 0.05" (flat overcast) and "60% cloud, AOD 0.4" (soft particle-lit gold) look identical to a model that only thinks about clouds. The photographic difference between them is enormous.

4. Marine API - what the water is doing

Fog physics depends heavily on water-temperature differentials. The Ground Fog detector has three distinct paths:

The first path needs no extra data. The second and third both need to know the water-surface temperature. Inverza pulls SST for coastal locations from Open-Meteo's Marine API (the ECMWF marine model). For inland lakes, where Marine isn't useful, the app instead fetches the last 7 days of air temperature and computes a lagged running mean as a SST proxy - shallow-to-medium water bodies track 2-5 day lagged air temp pretty closely. Either way, the detector now knows how the water and the air differ, which is the whole basis of the advection/steam distinction.

5. Overpass / OpenStreetMap - the geographic context

Two pieces of geographic data from OpenStreetMap via the Overpass API:

Nearby water bodies. An "is_in" plus "around:" query in a small radius around the spot. Returns lakes, rivers, sea/ocean polygons. Used by the fog detector above - it needs to know not just the SST but the size, distance, and type of water nearby, because a 50 m pond doesn't generate steam fog the way Lake Como does.

Landcover. A separate query returns the land-use classification at the spot's coordinates: forest, bare rock, alpine fell, glacier, grass, urban, agricultural. The Brocken Spectre detector uses this as a vegetation gate. A spectre forms when you stand above a cloud with the sun behind you and your shadow projects onto the cloud. If you're standing in a forest, two things kill the effect: trees block the low-angle sun, and trees break the clean projected outline. The detector penalises forest landcover heavily. Open rock and alpine terrain get full marks. Without this gate, Brocken Spectre would falsely trigger on flat-topped hill walks through dense pine.

Overpass data is cached on disk indefinitely because landcover doesn't change. The first lookup for a new spot takes a second or two; every subsequent forecast at that spot reads straight from cache.

6. METAR Live - actual measured weather

Every airport with an active aviation weather station broadcasts a structured weather report every hour: real cloud cover and altitudes, visibility, temperature, dew point, wind, precipitation type, all measured directly on the ground. There are over 9,000 stations worldwide. That's a global mesh of ground-truth observations available for the price of a single HTTP request.

Inverza finds the nearest station within 50 km, fetches its latest METAR, and uses it as a cross-check against the model prediction. Two scenarios:

That's the gap between "the algorithm thinks fog is likely" and "the airport eight kilometres from you reports active fog at this exact minute". Both inputs are useful, and the badge tells you at a glance which one is driving the prediction.

7. High-Res Regional Models - finer eyes

Open-Meteo's default forecast uses a global model with ~11 km resolution. For three regions, much higher-resolution models exist and Inverza queries them in parallel:

When you're in coverage of one of these, Inverza compares the high-res model's hourly forecast against the default model's. Hours where they disagree by more than 15% are flagged - these are the genuinely uncertain windows. The 15-minute data, where available, also powers a more granular "what's happening in the next 6 hours" view: useful for catching short-lived fog windows that hourly data would average out of existence.

8. Previous Model Runs - is the forecast stable?

A forecast that says "85% clear at sunrise tomorrow" feels confident. But what did the same model say about the same hour yesterday? If yesterday's run said "100% overcast", that's the same forecast model changing its mind by 85 percentage points in 24 hours - which means the underlying atmospheric setup is poorly constrained, and you should trust today's prediction less.

Inverza pulls Open-Meteo's "previous_runs" data, which returns the same forecast hours but from yesterday's model run and the run two days ago. A small analyser computes how much each future hour's prediction has shifted between runs, and the detector subtracts a confidence penalty (capped at 0.12) when shifts are large. The user-facing effect: badges read "Likely" instead of "Very Likely" when the model has been all over the place. The AI chat is also told about the instability so it can hedge its language ("yesterday's model still predicted overcast for this afternoon, but today's run has switched to mostly clear - promising, though it's a recent change").

METAR-confirmed detections are exempt from this penalty. If reality confirms the prediction, there's no point penalising it for past indecision.

The fail-silent principle

Eight sources across four providers means a lot of moving parts that could fail. Overpass can be slow. NOAA's METAR endpoint occasionally rate-limits. The Marine API has regional gaps. The high-res models have hard coverage boundaries.

The architecture treats only the base Open-Meteo fetch as mandatory. Every other source uses a "safe" wrapper that catches errors, logs them as warnings, and returns nil. The forecast object then carries optional fields for each enrichment - directionalClouds, airQuality, waterBody, landcover, groundObservation, modelStability, modelComparisons, minuteForecasts - and each detector gracefully handles nil by falling back to a simpler scoring path. A coastal fog detection with a missing Marine API still works; it just can't distinguish advection from steam fog as cleanly. A Brocken Spectre check with a missing Overpass response defers to a latitude-based tree-line estimate.

The trade-off, simply: every enrichment is optional. When all eight sources respond, the forecast scores conditions with high nuance and confidence. When some don't, detections still come through with slightly less specificity in the supporting language. The app never goes dark because one API hiccuped.

What it all produces

After everything is fetched and merged, the result is a single internal WeatherForecast object that the rest of the app consumes. Three downstream surfaces:

Why this matters

Most weather apps run on a single API call. The cost of choosing one model and trusting it absolutely is that you inherit that model's blind spots: no nuance about which clouds catch light, no awareness of atmospheric particles, no fog physics around water, no ground-truth check against actual measurements, no way to detect when the forecast is unstable. A photographer making a 4 a.m. decision needs all of that.

The eight-source architecture answers a frustration I had for years: I'd compare the same forecast in three different apps, get three different stories, drive to the coast anyway, and find a grey lid. Inverza exists to fix that.

Want to see all eight sources doing their job at your favourite spot? Inverza is on the App Store.

Download on the App Store