TheRON/otivm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add RFC-TESSERA-3.0-PALEO-001: palaeoenvironmental sea level correction

Browse Source
This commit is contained in:
otivm
2026-04-26 14:04:06 +00:00
parent dfbc503ef5
commit a53f0df4a5
1 changed files with 448 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

448
docs/RFC-TESSERA-3.0-PALEO-001.md Normal file
View File

@@ -0,0 +1,448 @@
# RFC-TESSERA-3.0-PALEO-001
## Palaeoenvironmental Sea Level Correction
### Status: Draft v0.1
### Date: 2026-04-26
### Supersedes: nothing — first RFC in PALEO series
### Referenced by: RFC-TESSERA-3.0-OCC-001 Section 8, tesserav3 README
### Note: Canonical copy lives in tesserav3 ssot/docs/v3/. This is a reference copy.
---
## Abstract
TESSERA `elev_cm` values are referenced to modern mean sea level (MSL = 0),
sourced from GEBCO 2025 using the EGM2008 geoid as vertical datum. This is
physically correct and immutable. It must not be modified.
Sea level has not been constant. At the Last Glacial Maximum (~20,000 BCE)
global MSL was approximately 120m below present. At 8000 BCE (CIVICVS
simulation period) it was approximately 20–30m below present and rising
rapidly. At 0 CE (OTIVM Roman period) it was within ~1m of present.
This RFC specifies:
- A named epoch table with sea level offsets relative to TESSERA baseline
- The canonical query by which any consumer (OTIVM, CIVICVS, future systems)
derives land/sea classification at a given epoch without modifying the baseline
- The pipeline work required to validate the offset values against the
palaeoclimate literature
- The scope boundary between TESSERA (physical reality) and consumers
(interpretation and rendering)
The sea level offset is never stored in `otivm.sqlite3` or `tessera.db`.
It is applied at query time by the consumer. The baseline is inviolate.
---
## 1. Design Principles
### 1.1 The baseline is immutable
`elev_cm` in `tessera_cells` records the physical elevation of each H9 cell
centroid relative to modern MSL as measured by GEBCO 2025. It is not adjusted
for epoch, not corrected for isostatic rebound, not modified by any scenario.
It is a physical measurement. It does not change.
Any correction applied to it — for sea level, for isostasy, for sediment
accumulation — is an interpretation layer. Interpretation layers live in
consumer code, not in TESSERA.
### 1.2 The epoch table is the contract
The named epoch table defined in Section 3 is the shared contract between
TESSERA and its consumers. OTIVM reads it. CIVICVS reads it. Any future
system reads it. The offsets in this table are derived from the palaeoclimate
literature and are citable. When the literature is updated or refined, the
epoch table is updated — not the baseline data.
### 1.3 The offset is a threshold, not a transform
Sea level correction does not require modifying elevation values. It requires
shifting the threshold at which a cell is classified as land or sea:
```
land = elev_cm > sea_level_offset_cm
```
Where `sea_level_offset_cm` is negative (sea was lower in the past, so the
land/sea boundary moves downward — more cells become land). This is a
scalar comparison. No geometry is modified. No data is rewritten.
### 1.4 Isostatic rebound is deferred
Glacial isostatic adjustment (GIA) — the rebound of landmasses after ice
sheet removal — is spatially variable and adds significant complexity.
Scandinavia was depressed by ~200m under the Fennoscandian ice sheet;
the Mediterranean was largely unaffected. GIA correction requires a
spatially varying offset per H9 cell, not a single scalar.
GIA is acknowledged here and deferred to RFC-TESSERA-3.0-PALEO-002. For
OTIVM purposes (Mediterranean basin, Roman and Mesolithic periods), the
GIA effect is small relative to eustatic sea level change and can be
treated as zero in the initial implementation without material error.
For CIVICVS (Spree-Havel valley, 8000 BCE), GIA is more significant —
northern Germany experienced ~10–20m of rebound between 10,000 BCE and
6,000 BCE. This is noted but does not block OTIVM-II delivery.
### 1.5 Relative sea level is not global sea level
TESSERA records absolute elevation relative to a global geoid. Sea level
at any specific location is the global eustatic signal plus local isostatic
adjustment plus local sediment compaction. The epoch table in Section 3
provides eustatic offsets only — global average sea level change. Local
corrections require GIA data (deferred) and sediment models (future work).
For the Mediterranean, eustatic offsets alone are sufficient for a
defensible first approximation. For the North Sea and Baltic, they are not.
This distinction must be surfaced to the player when relevant.
---
## 2. Vertical Datum
`elev_cm` in TESSERA is referenced to:
- **Datum:** EGM2008 geoid (approximately equivalent to global MSL)
- **Source:** GEBCO 2025 Grid
- **Unit:** signed integer centimetres
- **Range:** approximately −11,000m to +8,850m (full Earth surface)
- **Zero:** modern mean sea level
GEBCO 2025 uses a unified global grid at 15 arc-second resolution (~460m),
resampled to H9 centroids (~180m) during TESSERA pipeline stage 00–01.
The resampling introduces sub-metre error in areas of high terrain gradient.
For coastline rendering this is acceptable at H7 and H5 resolution; at H9
resolution in steep coastal terrain (e.g. fjords, cliffs) visible artefacts
may occur.
This datum is consistent with the ICE-5G and ICE-6G palaeoclimate sea level
reconstructions, which express past sea levels as offsets from present-day
MSL. No datum conversion is required when applying offsets from Section 3.
---
## 3. Named Epoch Table
The canonical set of epochs, their sea level offsets relative to TESSERA
baseline (modern MSL = 0), confidence grades, and primary citations.
All offsets are **eustatic only** — global average, no isostatic correction.
Negative values = sea was lower = more land area than today.
| epoch_key | label | approx_date | sl_offset_cm | confidence | primary_citation |
|---|---|---|---|---|---|
| `present` | Present day | 2025 CE | 0 | measured | GEBCO 2025 |
| `roman_14bce` | Roman period, 14 BCE | ~14 BCE | −10 | indicated | Lambeck et al. 2004 |
| `subboreal_3000bce` | Sub-Boreal, 3000 BCE | ~3000 BCE | −200 | indicated | Lambeck et al. 2014 |
| `atlantic_6000bce` | Atlantic optimum, 6000 BCE | ~6000 BCE | −500 | indicated | Lambeck et al. 2014 |
| `mesolithic_8000bce` | Mesolithic, 8000 BCE | ~8000 BCE | −2500 | indicated | Lambeck et al. 2014 |
| `preboreal_10000bce` | Pre-Boreal, 10000 BCE | ~10000 BCE | −5000 | indicated | Lambeck et al. 2014 |
| `younger_dryas_11000bce` | Younger Dryas, 11000 BCE | ~11000 BCE | −7000 | inferred | Lambeck et al. 2014 |
| `lgm_20000bce` | Last Glacial Maximum, 20000 BCE | ~20000 BCE | −12000 | indicated | Clark et al. 2009 |
| `eem_125000bce` | Eemian interglacial, 125000 BCE | ~125000 BCE | +600 | inferred | Dutton & Lambeck 2012 |
**Note on `roman_14bce`:** Mediterranean relative sea level at the Roman
period was within ~0.1m of present. The −10cm offset is within measurement
uncertainty and may be treated as zero for rendering purposes. It is included
for completeness and to prevent consumers from assuming present-day MSL is
wrong for Roman-period content.
**Note on `mesolithic_8000bce`:** This is the primary epoch for CIVICVS.
At −25m, significant coastal areas are exposed relative to today — the
Adriatic was shallower, the Po Valley more extensive, parts of the Aegean
shelf were land. For the Mediterranean specifically, the effect is most
visible in the Adriatic, the Gulf of Gabes (Tunisia), and the Nile delta.
**Note on `lgm_20000bce`:** At −120m, the Mediterranean was dramatically
different. The Sicilian Channel was partially exposed. Cyprus was larger.
The Nile delta extended much further north. This epoch is included for
future use; it is not required for OTIVM-II or CIVICVS v1.
### 3.1 Interpolation between epochs
Consumers may interpolate linearly between adjacent epochs for animation
or continuous temporal regression. Linear interpolation is not physically
accurate — sea level rise was non-linear and punctuated by meltwater pulses
(notably Meltwater Pulse 1A at ~14,600 BCE, ~20m rise in ~500 years). For
game purposes, linear interpolation between the named epochs in Section 3
is sufficient and defensible as an approximation.
When CIVICVS requires higher temporal resolution (decadal or centennial),
RFC-TESSERA-3.0-PALEO-002 will specify a continuous curve derived from
the Lambeck et al. 2014 far-field reconstruction.
---
## 4. Canonical Consumer Query
Any consumer deriving land/sea classification for a given epoch queries
`tessera_cells` as follows. This query is normative — consumers must not
implement alternative logic.
```sql
-- Land/sea classification at a named epoch
-- :h5 = H3 res-5 integer ID of the waypoint hex
-- :sl_offset_cm = sea_level_offset_cm from the epoch table (Section 3)
-- negative = sea was lower = more land
SELECT
h9,
lat,
lon,
elev_cm,
CASE
WHEN elev_cm > :sl_offset_cm THEN 1 -- land at this epoch
ELSE 0 -- sea at this epoch
END AS is_land
FROM tessera_cells
WHERE h5 = :h5
AND status = 2
ORDER BY h9;
```
For coastline rendering at reduced resolution (H7 or H5), aggregate by
the parent cell and classify as land if the majority of H9 children are land:
```sql
-- H7-aggregated land/sea classification at a named epoch
SELECT
h7,
COUNT(*) AS h9_total,
SUM(CASE WHEN elev_cm > :sl_offset_cm THEN 1 ELSE 0 END) AS h9_land,
CASE
WHEN SUM(CASE WHEN elev_cm > :sl_offset_cm THEN 1 ELSE 0 END) * 2
> COUNT(*) THEN 1
ELSE 0
END AS is_land_majority
FROM tessera_cells
WHERE h5 = :h5
AND status = 2
GROUP BY h7;
```
The majority rule (>50% of H9 children are land → H7 cell is land) is the
default. Consumers may use a higher threshold (e.g. 75%) for a more
conservative coastline that errs toward sea. This is a rendering decision,
not a data decision, and is not specified here.
### 4.1 What consumers must not do
- Modify `elev_cm` values in the database
- Store derived land/sea classification in the database
- Cache epoch offsets inside the baseline schema
- Treat the epoch table as immutable — it will be updated as the literature
is refined, and consumers must read it fresh rather than hardcoding offsets
---
## 5. Epoch Table Storage
The epoch table in Section 3 is the authoritative record. It is stored in
two places:
**In `otivm.sqlite3`** — as a read-only lookup table `paleo_epochs`, created
by the schema script (`data/create_otivm_db.sql`). The OTIVM game server
reads this table to resolve named epochs to `sl_offset_cm` values at runtime.
**In this RFC** — as the normative definition. If the table in the database
diverges from the RFC, the RFC takes precedence and the database must be
corrected.
### 5.1 `paleo_epochs` table schema
```sql
CREATE TABLE paleo_epochs (
epoch_key TEXT PRIMARY KEY,
label TEXT NOT NULL,
approx_date_bce INTEGER NOT NULL, -- years BCE, positive; years CE, negative
sl_offset_cm INTEGER NOT NULL, -- offset from modern MSL, negative = lower
confidence INTEGER NOT NULL -- FK to confidence_grades(id)
REFERENCES confidence_grades(id),
primary_citation TEXT NOT NULL,
notes TEXT
);
```
This table is populated once at database creation and updated only when the
RFC is updated. It is not a pipeline output — it is authored data derived
from the palaeoclimate literature.
### 5.2 Work order for TESSERA assistant
The following SQL insert block is the work order. It populates `paleo_epochs`
in `otivm.sqlite3`. The TESSERA assistant must:
1. Verify the offset values against the cited literature before inserting
2. Add this INSERT block to `data/create_otivm_db.sql` in the OTIVM repo
3. Confirm that `confidence_grades` IDs match (1=measured, 2=indicated,
3=inferred, 4=no_data) as defined in `data/create_otivm_db.sql`
4. Commit to OTIVM `main` branch with message:
"Add paleo_epochs table to create_otivm_db.sql per RFC-TESSERA-3.0-PALEO-001"
```sql
INSERT INTO paleo_epochs
(epoch_key, label, approx_date_bce, sl_offset_cm, confidence, primary_citation, notes)
VALUES
('present',
'Present day',
-2025,
0,
1,
'GEBCO Compilation Group (2025) GEBCO 2025 Grid (doi:10.5285/a29c5465-b138-234d-e053-6c86abc0dc7f)',
'Baseline. EGM2008 geoid, modern MSL = 0. No correction applied.'),
('roman_14bce',
'Roman period, 14 BCE',
14,
-10,
2,
'Lambeck et al. (2004) Sea-level change through the last glacial cycle. Science 292(5517).',
'Mediterranean RSL within measurement uncertainty of present. Treat as 0 for rendering.'),
('subboreal_3000bce',
'Sub-Boreal, 3000 BCE',
3000,
-200,
2,
'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).',
NULL),
('atlantic_6000bce',
'Atlantic optimum, 6000 BCE',
6000,
-500,
2,
'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).',
NULL),
('mesolithic_8000bce',
'Mesolithic, 8000 BCE',
8000,
-2500,
2,
'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).',
'Primary epoch for CIVICVS simulation. Adriatic, Gulf of Gabes, Nile delta visibly affected.'),
('preboreal_10000bce',
'Pre-Boreal, 10000 BCE',
10000,
-5000,
2,
'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).',
NULL),
('younger_dryas_11000bce',
'Younger Dryas, 11000 BCE',
11000,
-7000,
3,
'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).',
'Rapid sea level fall during Younger Dryas stadial. Offset is approximate.'),
('lgm_20000bce',
'Last Glacial Maximum, 20000 BCE',
20000,
-12000,
2,
'Clark et al. (2009) The Last Glacial Maximum. Science 325(5941).',
'Sicilian Channel partially exposed. Cyprus enlarged. Reserved for future use.'),
('eem_125000bce',
'Eemian interglacial, 125000 BCE',
125000,
600,
3,
'Dutton & Lambeck (2012) Ice volume and sea level during the last interglacial. Science 337(6091).',
'Positive offset: sea was higher than today. Reserved for future use.');
```
---
## 6. OTIVM-Specific Requirements
This section is addressed to the OTIVM game development assistant and
documents the game-side requirements that drove this RFC.
### 6.1 Map rendering epochs
OTIVM-II (current) renders the Mediterranean at the modern epoch (`present`,
offset = 0). The coastline query uses the canonical SQL in Section 4.
For OTIVM-III and beyond, the map must support rendering at any named epoch.
The epoch is passed as a parameter; the SQL is unchanged. The UI does not
need to expose epoch selection to the player in early releases — the epoch
is set by the game narrative (Roman period = `roman_14bce`).
### 6.2 Fog-of-war cell classification
When a galley travels a route, H3 cells along the route are revealed. The
revealed cells must be classified as land or sea at the active epoch before
rendering. The canonical query in Section 4 produces this classification.
Cells classified as sea are rendered as water. Cells classified as land
are rendered with terrain colour derived from `elev_cm` (relative to the
epoch offset, not absolute).
### 6.3 Sea level as a game mechanic
In future releases, the player may observe the coastline changing as the
narrative moves through time. The epoch table in Section 3 provides the
anchor points. The game transitions between epochs by interpolating
`sl_offset_cm` and re-running the canonical query. No data changes — only
the threshold changes.
This is not a gimmick. A player who reaches Alexandria in the Roman period
and later encounters journal entries referencing the Mesolithic shore is
experiencing the same physical geography at two different sea levels,
derived from the same `elev_cm` data, with a scalar offset that is citable
to Lambeck et al. 2014.
---
## 7. What This RFC Does Not Cover
| Topic | Future RFC |
|---|---|
| Glacial isostatic adjustment (GIA) | RFC-TESSERA-3.0-PALEO-002 |
| Meltwater pulse events (non-linear SL change) | RFC-TESSERA-3.0-PALEO-002 |
| Palaeoclimate terrain correction (vegetation, river courses) | RFC-TESSERA-3.0-PALEO-003 |
| Hydrological restoration (palaeo-drainage networks) | RFC-TESSERA-3.0-HYD-001 |
| Simulation temporal regression state | CIVICVS RFC stack |
| Player-facing epoch UI | OTIVM game code |
---
## 8. Primary Literature
All offset values in Section 3 must be verified against these sources before
the epoch table is committed to `otivm.sqlite3`. This is the responsibility
of the TESSERA pipeline assistant.
- **Lambeck et al. 2014** — "Sea level and global ice volumes from the Last
Glacial Maximum to the Holocene." *PNAS* 111(43): 15296–15303.
doi:10.1073/pnas.1411762111. Far-field reconstruction, globally applicable,
primary source for Holocene offsets.
- **Lambeck et al. 2004** — "Sea-level change through the last glacial cycle."
*Science* 292(5517): 679–686. doi:10.1126/science.1059549. Mediterranean
regional reconstruction, primary source for Roman period.
- **Clark et al. 2009** — "The Last Glacial Maximum." *Science* 325(5941):
710–714. doi:10.1126/science.1172873. LGM sea level −120m, primary source
for `lgm_20000bce`.
- **Dutton & Lambeck 2012** — "Ice Volume and Sea Level During the Last
Interglacial." *Science* 337(6091): 216–219. doi:10.1126/science.1205749.
Eemian +6m, primary source for `eem_125000bce`.
- **GEBCO 2025** — doi:10.5285/a29c5465-b138-234d-e053-6c86abc0dc7f.
Vertical datum reference. CC-BY 4.0.
---
*RFC-TESSERA-3.0-PALEO-001 Draft v0.1 — 2026-04-26*
*Produced by: OTIVM game development assistant*
*Work order to: TESSERA pipeline assistant*
*Status: Draft — pending literature verification of offset values before
paleo_epochs INSERT is committed to data/create_otivm_db.sql*
*Next action: TESSERA assistant verifies Lambeck et al. 2014 offsets,
then adds paleo_epochs schema and INSERT to data/create_otivm_db.sql*