How it works — a plain-language tour

This page explains the platform without assuming any technical background. If you want the engineering details, every section links to them — but you can understand the whole system from this page alone.

What this platform does

Weather models, satellites, radars, observation stations and hydrological sensors all produce data about the atmosphere and rivers. This platform collects that data and turns it into maps and figures that any application can request — a web viewer, a mobile app, an expert tool — using open, standardised requests ("give me the temperature map over Europe at 6 pm, at flight level 300").

flowchart LR
    A[Data producers<br/>models · satellites · stations · radars] --> B[The platform]
    B --> C[Any application<br/>web maps · expert tools · scripts]
    C -- "one standard language (OGC)" --> B

Hold "Alt" / "Option" to enable pan & zoom

The key word is standard: applications don't need to know anything about our internals, and we can change our internals without breaking them.

The restaurant analogy

Think of the platform as a restaurant:

• The pantry — all the data lives in two places: a database (facts and figures: observations, catalogs, indexes) and an object store (big files: satellite and model images). Nothing valuable is ever stored inside a server itself.
• The kitchen — GeoServer is the chef: when an application orders "temperature map, Europe, 6 pm", it fetches the right ingredients from the pantry and cooks the image on the spot.
• Several identical kitchens — we run several copies of GeoServer behind a single entrance. If one breaks, the others keep serving; on busy days we simply add more. They are identical and disposable: any of them can be thrown away and replaced in under a minute, because nothing is stored inside them (the proof).
• The pass-through counter — maps that were already cooked are kept in a shared cache: the second person asking for the same map gets it instantly, whichever kitchen originally cooked it (the proof).

flowchart TB
    subgraph Entrance["One entrance"]
        LB[Requests arrive]
    end
    LB --> K1[GeoServer copy 1]
    LB --> K2[GeoServer copy 2]
    LB --> K3[GeoServer copy N]
    K1 & K2 & K3 --> DB[(Database<br/>facts, catalogs, indexes)]
    K1 & K2 & K3 --> S3[(Object store<br/>big image files)]
    K1 & K2 & K3 --> C[(Shared map cache)]

Hold "Alt" / "Option" to enable pan & zoom

How new data appears — with nobody doing anything

When a new model run or satellite image arrives, an ingestion service converts it to an efficient open format, drops the file into the object store, and adds one row to an index in the database — "this file covers Europe, 6 pm, flight level 300, temperature, in kelvin".

That's all. Every GeoServer copy consults the index live, so the new data is immediately visible to every application, with no restart, no deployment, no manual step (the proof). The same goes for observations: the decoder writes rows, the maps update.

Time, altitude and units

• Every piece of data carries its date, and where relevant its altitude level and model run: applications can rewind, compare runs, and browse levels — the platform answers "at what times/levels do you have data?" as a standard question.
• Every measurement carries its unit. Sources disagree (aviation reports temperature in Celsius, models in kelvin): the platform converts everything to one canonical unit on the way in and never loses track of the original (why this matters).

Why it stays simple over time

• Nobody configures servers by hand. The entire server setup is written down as short text files; servers configure themselves from those files at start-up. Adding a data layer is a one-line change, reviewed like code. There is no "the person who clicked the right buttons has left" risk.
• Everything is rebuildable. From an empty computer cluster, the whole platform can be reconstructed from the repository — and each chapter of this documentation ends with a test that proves its part still works.
• Every decision is written down with its reasons and the options we rejected (the decision log) — thirteen so far.
• Failures are loud. When something is missing or broken, the component says so explicitly and stops, instead of limping along silently. Problems are found in seconds, not discovered weeks later.

What runs where

The platform runs on Kubernetes, a system that supervises applications on a computer cluster: it restarts what crashes, spreads the load, and lets us say "run three GeoServers" as a wish that it continuously enforces. The database and the object store are services the platform uses but doesn't manage — they can be provided by any infrastructure team.

Want the full picture? Start with the Vision, then the architecture and the step-by-step guides.