Frontend Operator UI
Route and Purpose
Two operator UIs are available:
| Path | Description |
|---|---|
/ui/ | Legacy plain-JS operator UI (served if frontend/ directory exists) |
/ui-react/ | React operator UI — built during the Docker image build from frontend-react/ |
Both UIs expose the same backend API surface. /ui-react/ is the actively maintained version.
The fastest way to inspect live service state without writing one-off curl commands is to open /ui-react/.
Main UI Areas
| Area | Purpose |
|---|---|
| Server config card | inspect and persist runtime configuration |
| Upload and ingestion actions | upload GeoTIFFs, submit Sentinel or HySpex CSW requests |
| Dataset table | browse, filter, inspect, and act on datasets |
| Duplicate and missing-variant tools | identify data hygiene problems |
| MapCache cleanup tools | inspect and remove cached tile state |
| Jobs panel | monitor async work and inspect results |
| HySpex campaign monitor | aggregate campaign progress across sequential batches |
| Mago terrain tools | generate and inspect Cesium terrain outputs |
Authentication Behavior
The UI supports login and stores the token client-side so it can call protected endpoints. If you are unauthenticated, read-only functionality still works where the underlying route is public.
HySpex Bulk Modal
The HySpex modal now supports three operating modes:
- build a one-off payload
- submit a single parent bulk batch
- start a sequential browser-driven campaign
The sequential campaign mode drives the same backend route family used by the helper script and keeps campaign status synchronized with the jobs panel.
Operational Caveats
- job and campaign panels are the most reliable live-state surfaces during heavy activity
- the dataset table can feel stale after many changes; a browser refresh remains a practical recovery step
- campaign stop is cooperative and stops after the current polling cycle rather than forcibly revoking all already-submitted work