ADR-0002 — GeoServer workspace organization¶
Date: 2026-09-01 · Status: proposed (to be decided with sub-projects 6 and 7)
Context¶
The layers span three domains (meteorology, aeronautics, hydrology) and four
kinds of data (basemaps and static data, satellite imagery, multi-dimensional
weather models, time series in the database). In GeoServer, a workspace is at
once a namespace, a virtual service (/geoserver/<workspace>/wms), a
security boundary (per-workspace access rules) and a grouping of stores.
The chosen split therefore shapes URLs, permissions and operations.
Update 2026-09-02 — decision basis¶
The decision must be made against the real target inventory (GTS network and dedicated feeds): SYNOP, METAR, TAF, AIRMET/SIGMET/GAMET (area products with validity periods), satellite imagery, radar, lightning, NWP models and hydrology-dedicated layers — explicitly not against the layout of any small prior project. The candidate workspace sets below are to be re-examined with that inventory and the future rights model.
Options¶
| Option | Workspaces | Pros | Cons |
|---|---|---|---|
| A — by data nature | static, satellites, models, meteo (TimescaleDB time series) |
Homogeneous stores per workspace (same type, same dimensions, same ingestion pipeline); simple operations and automation | A business client (e.g. aeronautics) consumes several workspaces; per-domain permissions are harder |
| B — by business domain | meteorology, aeronautic, hydrology |
URLs and permissions aligned with the consumers; one virtual service per business domain | Heterogeneous stores in the same workspace; a single source (e.g. a weather model) useful to several domains would have to be duplicated or referenced |
| C — hybrid | Workspaces by nature (A) + layer groups or per-domain naming prefixes; or the reverse | Combines both axes | Two conventions to maintain |
Decision¶
Not taken. To be settled after the ingestion (sub-project 5), vector data (6) and basemap (7) prototypes, when the actual number of stores and the permission requirements are known.
Consequences (expected)¶
- Prototypes 1 to 5 use provisional workspace names and must not hard-code anything against them.
- The decision will be recorded as an update to this ADR (status "accepted").