8. Cross-cutting concepts¶
To be written together with sub-projects 2 to 6: configuration persistence (initialization code rather than REST), secret injection, health probes, JVM settings, logging and monitoring.
8.0 Data sources and secrets¶
flowchart TB
subgraph Secrets
A[(db-admin<br/>operator)]
B[(geoserver-db)]
C[(meteo-reader)]
end
A --> J[Initialization Jobs]
B --> J
C --> J
B --> GS[GeoServer ×N]
C --> GS
GS -- "JNDI jdbc/geoserver · R/W" --> S1[(geoserver schema)]
GS -- "JNDI jdbc/meteo · R" --> S2[(decoder schema)]
DEC[Decoding service] -- "its own account · W" --> S2
J -- "creates roles, schema, grants" --> S1
J -- "reader role" --> S2
Hold "Alt" / "Option" to enable pan & zoom
- One Secret per account; the admin Secret is only mounted in the Jobs.
- One JNDI resource per (URL, account) pair; GeoServer stores reference the JNDI name. Details: ADR-0004.
8.0 bis Configuration persistence and JVM¶
- The database is the single source of truth: catalog (JDBCConfig),
resources including
security/(JDBCStore), WPS statuses (status). A pod's data dir is ephemeral and regenerated at startup (ADR-0005). - Reproducible configuration through a Java plugin
GeoServerInitializer, idempotent, driven by the environment; REST/UI reserved for manual operations (ADR-0006). - JVM:
-XX:MaxRAMPercentage=70— the pod memory limit is the only value to tune;ExitOnOutOfMemoryErrorso that an OOM restarts the pod rather than leaving a zombie process behind.
8.1 Parameters, dimensions and granule index¶
Status
Model from ADR-0003, implemented in sub-project 5 for rasters (mosaic schema: parameter, parameter_code, level_type, model_granule, sat_granule, per-mosaic views). The observations part (OBSERVATION) is implemented in sub-project 6 (schema obs: station, observation hypertable, publication views — see guide 6).
Quantity reference table and granule index¶
erDiagram
PARAMETER ||--o{ PARAMETER_CODE : "known as"
PARAMETER ||--o{ MODEL_GRANULE : "quantity"
PARAMETER ||--o{ OBSERVATION : "quantity"
LEVEL_TYPE ||--o{ MODEL_GRANULE : "level type"
SAT_GRANULE }o--|| PARAMETER : "quantity"
PARAMETER {
text param_key PK "e.g. air_temperature"
text cf_standard_name
text canonical_unit "UCUM: K, Pa, m/s, %"
text label_fr
}
PARAMETER_CODE {
text param_key FK
text scheme "grib2 | eccodes | bufr | metar | iwxxm | cf"
text code "0-0-0 | t | 0 12 101 | M03 …"
text unit_in_scheme "K | K | K | Cel"
}
LEVEL_TYPE {
smallint code PK "GRIB2 table 4.5"
text name "surface, isobaric, height above ground…"
text unit "Pa, m"
}
MODEL_GRANULE {
int fid PK
geometry the_geom "footprint, EPSG:4326"
text location "s3://bucket/prefix/file.tif"
text model "arpege, arome, ifs…"
text param_key FK
timestamptz reference_time "model run → DIM_REFERENCE_TIME"
timestamptz time "validity → TIME"
numeric elevation "level value → ELEVATION"
smallint level_type FK
text level_label "e.g. FL300"
text source_unit "actual unit of the file"
timestamptz ingested_at
}
SAT_GRANULE {
int fid PK
geometry the_geom
text location
text satellite "OSCAR/Space, e.g. meteosat-12"
text instrument "e.g. fci"
text product "e.g. ir105, rgb-natural"
text param_key FK "e.g. brightness_temperature"
timestamptz time "→ TIME"
text source_unit
timestamptz ingested_at
}
OBSERVATION {
text station_id
timestamptz time "TimescaleDB hypertable"
text param_key FK
double value "in canonical unit"
text source_unit "K, Cel, kt, hPa…"
text message_type "SYNOP | METAR | SPECI | TAF"
}
Hold "Alt" / "Option" to enable pan & zoom
Rules¶
- One GeoServer layer = one quantity = one unit = one style. One
ImageMosaic per (model, quantity) pair or per (satellite, instrument,
product) triple, filtered by an SQL view over the granule table
(
UseExistingSchema=true,AdditionalDomainAttributesfor the model run). - Exposed dimensions:
TIME(forecast validity time or observation instant),DIM_REFERENCE_TIME(model run),ELEVATION(vertical level). Two different level types = two layers. - File naming: redundant with the table, never the source of truth (patterns in ADR-0003).
8.2 Units of measurement¶
Principle: a measurement always has a unit.
- Each quantity in the reference table carries a canonical unit (K, Pa, m/s…), chosen based on the CF standard names.
- The same quantity arrives in different units depending on the carrier
(kelvin in GRIB2 and BUFR, degrees Celsius in METAR, hectopascal for QNH,
knots for aeronautical wind): the ingestion converts to the canonical
unit and keeps the source unit (
source_unit) next to the value. - The unit of a layer is published in its metadata and its legend; service outputs (GetFeatureInfo, WFS, WCS, WPS) return values in the canonical unit. Exact mechanism to be validated in sub-projects 5 and 6.