What FastAPI-mapserver Is Built To Do
FastAPI-mapserver is the service layer that ties together raster ingestion, OGC publishing, background processing, caching, terrain generation, and HySpex catalog workflows in one operational stack.
This project is not just a FastAPI wrapper around a few endpoints. It is the control plane around GeoTIFF datasets, MapServer and MapCache, Celery workers, Redis-backed job state, a built-in frontend, and terrain products that need to stay aligned across API, storage, and deployment.
At a high level, the stack is responsible for four kinds of work:
- ingesting or registering datasets and exposing them through OGC routes
- converting source products into GeoTIFF-backed outputs that the platform can serve consistently
- generating and publishing terrain artifacts for Cesium and related clients
- tracking long-running jobs, especially HySpex CSW parent campaigns that expand into many child jobs
The reason this repository matters operationally is that these features share the same manifests, cache directories, deployment files, and runtime assumptions. A small change in routing, config persistence, or cache generation can affect user-facing map behavior immediately.
That is also why the documentation effort now lives close to the code: operators need one place to understand how /datasets, /jobs, /mapcache, terrain generation, and HySpex-specific flows fit together.
In practice, the platform currently centers on these capabilities:
- GeoTIFF dataset upload, registration, metadata repair, and duplicate detection
- MapServer-backed WMS and related OGC service exposure
- MapCache config generation, cache cleanup, and optional seeding during ingestion
- Celery and Redis orchestration for asynchronous tasks and job introspection
- HySpex CSW ingestion, including resumable parent-batch execution and campaign status tracking
- terrain preparation for Mago and Cesium-oriented clients

Over the last two days, the focus has been tightening this operational surface: turning the docs site into project documentation, replacing scaffold content with real platform notes, expanding route-level test coverage, and separating smoke validation from the main unit path.
This blog is where that work is recorded in smaller, chronological slices.
