WMO, wis2box and pygeoapi: institutional data exchange
Explain how wis2box combines ingestion, storage, pygeoapi and notifications, and what a generic OGC API still needs for institutional exchange.
Editorial review: 2026-09-23
wis2box is a concrete institutional example of open components supporting data publication, discovery and exchange. Its value as evidence is the division of responsibilities across standards and services. It does not establish that WMO has no Esri software elsewhere or that a municipality can deploy the same system without domain-specific work.
The wis2box 1.2.0 architecture reference identifies message brokers, storage, data management, a pygeoapi API and a web application. WMO's API training exercise demonstrates collection-based discovery and query. These sources support the component roles below; they are not a GeoSAT delivery claim.
Follow a data product through the system
Observation file -> validation/transformation -> published data object
-> discovery metadata
-> notification
Consumer -> notification/discovery -> data access/API -> usable observation
This simplified reading of the architecture separates three things often confused in a portal: the data itself, metadata that helps find and interpret it, and a notification that something is available. A notification should not be mistaken for the full data payload or a guarantee that every consumer has processed it.
| Responsibility | Documented component family | Design question for an adopter |
|---|---|---|
| Store and retrieve data | Object/data storage | Stable URL, retention and recovery |
| Publish notifications | MQTT message brokers | Topic, access, replay and duplicate behavior |
| Transform observations | Domain processing tools | Units, station IDs, time and validation |
| Discover/query | pygeoapi and OGC APIs | Collections, metadata, identifiers and filters |
| Present to a person | Web application | Visibility of freshness and source |
Why a single map endpoint is insufficient
A reader needs to know what was measured, where, when, in which units, with what quality and under which usage conditions. A map image may visualize a value while losing the details needed for scientific or operational reuse. Publishing a feature API helps programmatic access but does not invent missing metadata.
A weather or water observation also has more than one relevant time: phenomenon time, ingestion time and publication time may differ. Late arrivals and corrections must be identifiable. If a station relocates or an instrument changes, a stable station identifier alone may not describe the full measurement context.
These are domain modeling issues. Copying a Docker composition from a weather exchange platform into a cadastral project does not create a suitable cadastral data model. Borrow the separation of concerns, then use the domain's own authoritative identifiers, metadata and validation.
A LATAM adaptation for environmental reporting
Consider a regional institution publishing synthetic air- or water-quality observations for training. Define station ID, timestamp with timezone, variable, unit, value, quality flag and source revision. Create a file or table with explicit missing values and a separate station description. Decide which records may be public and which remain preliminary.
Use an API for bounded queries and a bulk file for complete analysis. If timeliness requires notifications, publish messages that point to stable resources and document duplicate/late-event behavior. If updates happen monthly, a scheduled publication and clear metadata may be simpler than operating a broker.
| Requirement | Minimal implementation to test | Failure example |
|---|---|---|
| Discover dataset | Described collection with license and extent | API exists but users cannot interpret it |
| Retrieve known observation | Stable ID and timestamp | Same ID returns a different observation after reload |
| Filter a period | Defined temporal field and timezone | Local time treated as UTC |
| Correct a value | Revision/update policy | Consumer cannot distinguish corrected data |
| Recover publication | Restore source, metadata and configuration | Files return but collection links break |
| Notify consumers | Explicit event/reference contract | Duplicate event triggers duplicate processing |
Build a bounded proof with pygeoapi
Start with the two-station tutorial. It proves only a simple point-feature API, not WIS2 compliance or a complete observational exchange. Add the domain fields and expected query cases in a separate fixture, then test missing observations, invalid dates, unit consistency and corrected records.
Use the official WMO training material when implementing wis2box itself; registration and operational requirements belong to that ecosystem. Do not label a generic pygeoapi deployment as a WIS2 node merely because one of its components matches.
Operating responsibilities and costs
Someone must review source quality, update metadata, maintain the broker/API/storage, monitor freshness, handle failed ingestion and restore service. A managed platform can help, but the data owner still needs to define what a valid observation means. Include those hours and support arrangements in the cost model.
The lesson for an ArcGIS-to-open strategy is practical: standards can divide a complex exchange into replaceable responsibilities. Evaluate that design against a specific workload, then use the production pygeoapi guide for the API portion. A recognizable institutional example is useful context; your own acceptance tests remain the evidence for your deployment.