Airspace Management – NFZ Creation & CLZ Management

Andi Lamprecht ·2026-05-11· 6 min read· Draft

Overview

This PRD defines the requirements for adding airspace management capabilities to the Uncrew UI: a dedicated No-Fly Zone (NFZ) management page allowing managers to create and delete NFZs, and a CLZ (Contingency Landing Zone) management section within the site configuration page allowing managers to add, delete, and bulk-import CLZ points per site. CLZ storage will migrate from GCS bucket files to a database as part of this work.

Problem

Operations managers currently have no self-service UI to define or remove NFZs — they must call the utm-atlas-airchitect API directly. CLZ definitions per site are managed by manually uploading GeoJSON files to a GCS bucket, with no audit trail, no UI validation, and a 5-minute propagation delay. This creates operational friction and error risk when configuring new sites.

Goals & Non-Goals

Goals

• Managers can create and delete NFZs from the Uncrew UI without direct API access.
• Managers can add, delete, and bulk-import CLZ points per site from the site configuration page.
• CLZ data is migrated from GCS bucket files to a database, deprecating the bucket-polling pattern.
• All CRUD operations are gated behind Frontegg permissions following the du.uncrew.* scope pattern.

Non-Goals

• Editing / updating existing NFZs or CLZs (rename, move) — fast-follow.
• CLZ polygon support — current model is Point only; no scope change.
• LZ (Landing Zone) management — sourced from UTM, explicitly out of scope.
• Any UTM-side changes beyond the existing NFZ REST API.

Requirements

Functional

NFZ Management

• NFZ-01 Manager can view all NFZs showing name, tag, floor, ceiling, and creation date.
• NFZ-02 Manager can create an NFZ by drawing a polygon on a map canvas.
• NFZ-03 Manager can alternatively create an NFZ by pasting a raw GeoJSON Feature into a text input; the map previews the polygon before submission.
• NFZ-04 Create form includes: name (required), tag (optional), floor value + unit + ref (required, default 0 AGL FT), ceiling value + unit + ref (optional).
• NFZ-05 On submit, the frontend POSTs to utm-atlas-airchitect /no_fly_zones/ and shows success/error feedback within 3 seconds.
• NFZ-06 Manager can delete an NFZ with a confirmation dialog; calls DELETE /no_fly_zones/{id}.
• NFZ-07 NFZ management is accessible via a dedicated top-level page (e.g. /no-fly-zones).

CLZ Management

• CLZ-01 The Site Configuration page (/settings/flight-settings) gains a CLZ sub-section showing all CLZ points for the selected site (name, latitude, longitude).
• CLZ-02 Manager can add a single CLZ by clicking a point on the map or entering lat/lng coordinates manually; name is required.
• CLZ-03 Manager can delete a CLZ with a confirmation dialog; the list updates immediately (optimistic UI).
• CLZ-04 Manager can bulk-import CLZs for a site by uploading a GeoJSON FeatureCollection file (.geojson or .json); the UI validates the format and previews the points before confirming.
• CLZ-05 Bulk import merges with existing CLZs — it does not replace them. Duplicate names within a site are rejected with a validation error.
• CLZ-06 CLZ CRUD calls new REST endpoints in uncrew-missions-service; the GCS bucket-polling path is deprecated and removed once the DB is live.

Non-Functional

• NF-01 All CLZ/NFZ write endpoints require Frontegg scopes (new scopes: du.uncrew.manage.clz, du.uncrew.manage.nfz).
• NF-02 GeoJSON input is validated client-side before submission; malformed input shows a field-level error, never a raw 4xx response.

User Stories / Scenarios

Regulatory & Compliance

NFZ creation directly restricts drone flight paths. No FAA approval is required for operator-defined internal NFZs used within DroneUp’s own operational airspace management. However, created NFZs will influence autonomous flight path planning — any NFZ overlapping an active mission should surface a warning in the UI (fast-follow, not MVP). No DO-178C applicability. No PII involved.

Technical Specifications

Architecture Overview

Uncrew Apollo Frontend
  ├── /no-fly-zones page → utm-atlas-airchitect REST API (direct)
  └── /settings/flight-settings (site config)
        └── CLZ section → uncrew-missions-service (new gRPC/REST endpoints)
                              └── PostgreSQL (new clz table, replaces GCS bucket)

Affected Repos

Integration Points

• NFZ: Frontend calls utm-atlas-airchitect directly at https://airchitect.utm.{env}.droneup.cloud/no_fly_zones/. Auth mechanism is Frontegg token;
• CLZ: New endpoints in uncrew-missions-service following the existing gRPC permission pattern. New Frontegg scope du.uncrew.manage.clz added to getFronteggGRPCPermissionsMap in config/config.go. DB writes must invalidate the in-memory clzData cache.

Data Model Changes

New table in uncrew-missions-service PostgreSQL:

CREATE TABLE clz (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  site_id     TEXT NOT NULL,
  name        TEXT NOT NULL,
  latitude    DOUBLE PRECISION NOT NULL,
  longitude   DOUBLE PRECISION NOT NULL,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (site_id, name)
);

One-time migration script to seed from all existing GCS bucket files into the new table before deprecating the bucket provider.

Security & Privacy

• New Frontegg scopes: du.uncrew.manage.clz, du.uncrew.manage.nfz — to be provisioned in Frontegg console and added to permission maps in uncrew-missions-service/config/config.go.

Risks & Phased Rollout

Phased Rollout

• MVP: NFZ list + create (map draw) + delete. CLZ list + single add + delete per site. New CLZ DB + migration.
• v1.1: NFZ create via GeoJSON paste. CLZ bulk import. Deprecate and remove GCS bucket provider.
• v2.0: NFZ edit. CLZ edit (rename/move). NFZ overlap warning for active missions.

Estimation Input

prd_sizing_input:
  feature: "Airspace Management – NFZ Creation & CLZ Management"
  scope_clarity: "A"
  key_terms:
    - "no_fly_zone"
    - "clz"
    - "site configuration"
    - "airchitect"
  risk_flags:
    - "db-migration"
    - "third-party-api-auth"
    - "map-draw-library"
  affected_repos:
    - "uncrew-apollo-frontend"
    - "uncrew-missions-service"
    - "utm-atlas-airchitect"
  domains:
    - "frontend-react"
    - "backend-go"
    - "python-fastapi"
  regulatory: false
  discovery_needed: false

Open Questions

• Does utm-atlas-airchitect accept Frontegg user tokens, or does it require service-level auth? (determines BFF proxy need)
• Should CLZ migration script run as part of the service startup or as a standalone job?
• What environment-specific bucket names exist beyond uncrew_droneup_clz_nonprod? (needed for migration)