Storage and Manifests
This page documents the persistent runtime layout behind datasets, jobs, cache state, and generated outputs.
Storage Structure Diagram
Persistent Layout
The service uses DATA_ROOT, which defaults to /data, as the root for persisted runtime state.
Important subpaths:
| Path | Purpose |
|---|---|
/data/uploads | uploaded source files |
/data/extents | generated extent GeoJSON files |
/data/terrain | terrain RGB outputs |
/data/mago-input | intermediate Mago input assets |
/data/mago-terrain | generated Mago terrain outputs |
/data/thumbnails | thumbnail cache when disk mode is enabled |
Manifest Files
| File | Purpose |
|---|---|
/data/datasets.json | dataset registry |
/data/terrain_datasets.json | terrain registry |
/data/jobs.json | job history and latest results |
/data/jobs_deleted.json | deleted job archive |
/data/server_config.json | persisted runtime configuration |
Manifest Interaction Diagram
Startup Behavior
At application startup the service:
- ensures required storage directories exist
- loads persisted config into memory
- refreshes auth and access rules
- refreshes MapCache config
- prunes dataset records whose backing files are missing
- regenerates extent footprints when needed
Operational Implication
This means file-level state matters. If manifests are edited manually or a backing file disappears, the next startup can change visible state significantly. Treat the contents of DATA_ROOT as application state that should be backed up and managed deliberately.
Practical Reading Order
- Use C4 Architecture for the high-level structural model.
- Use Workflow Diagrams for operator and data lifecycle views.
- Use this page when you need to know exactly where persistent state lives and how manifests interact.