Airchitect Endpoints ATLAS Airchitect Endpoints 1 Nfzs

Andi Lamprecht ·2026-05-11· 4 min read· Accepted

Atlas Airchitect No-Fly Zones

Context

Atlas Airspace data needs an API which allows the internal user to modify the existing datasets by adding removing and updating a no-fly zones.

Enduser will control the no-fly zones through the frontend interface and expects the data to immediately be presented by Airspace API

Decision

No-Fly zones control endpoints are served via REST API endpoints of following structure

Invalid Image Path

Due to low latency requirements the endpoints are designed according to real-time data pipeline architecture, described in ATLAS_AIRCHITECT_1_RealTimePipeline [1].

Consequences

The service expose REST API the basic actions to interact with:

• add new NFZ: POST /no_fly_zones
• modify existing NFZ: PUT /no_fly_zones/<uuid>
• delete existing NFZ: DELETE /no_fly_zones/<uuid>

The action on the API puts a message into a PubSub (acc to real-time data pipeline architecture mentioned in description) which propagates the information to both data lake and Airspaces API.

Endpoint Definitions

POST /no_fly_zones and PUT /no_fly_zones/{uuid}

Input

Endpoint expects a GeoJSON with the geometry of type Polygon with following properties:

Altitude object:

Schedule object:

Example request body:

    {
      "type": "Feature",
      "properties": {
        "name": "EXAMPLE-NO-FLY-ZONE",
        "description": "This is example NO-FLY-ZONE",
        "schedule": {
          "start_date": "2024-05-24T00:00:00Z",
          "end_date": "2024-06-24T00:00:00Z"
        },
        "floor": {
          "value": 0,
          "unit": "FT",
          "ref": "AGL"
        },
        "ceiling": {
          "value": 200,
          "unit": "FT",
          "ref": "AGL"
        }
      },
      "geometry": {
        "coordinates": [
          [
            [
              -85.48,
              33.50
            ],
            [
              -85.48,
              32.51
            ],
            [
              -84.26,
              32.51
            ],
            [
              -84.26,
              33.50
            ],
            [
              -85.48,
              33.50
            ]
          ]
        ],
        "type": "Polygon"
      }
    }

Output

Rest API

In case of POST the endpoint returns 201 with the uuid of newly created No-Fly Zone. Otherwise it returns 422 if the request body does not meets the schema requirements.

PubSub Message

The API generates a Pub/Sub message which is propagated to Airspace Charger and Atlas Data Lake replication with following data fields

PubSub Message Data Field Schema

Metadata Field Content

PubSub Message Attribute Field Schema

Example Message

    {
        data: b"{
            'uuid': '241fsa-521gg-5521aaz',
            'metadata':{
                "name":"my-test-nfz",
                "description":"this is nfz for test",
            }
            'floor':{
               value: '0',
               unit: 'ft',
               ref: 'AGL'

            }
            'ceiling':  {
               value: '400',
               unit: 'ft',
               ref: 'AGL'

            }
            'schedule': {
                start_date: 2021-01-01T00:00:00Z,
                end_date: 2022-01-01T00:00:00Z
            }
            'geometry': 'POLYGON((11 12), (1 1), (11 12))'
        "
        attributes: {
            "action": "insert",
            "kind": nfz,
            "commit_timestamp": 2022-01-01T00:00:00Z
            "version": 2,
        }
    }

DELETE /no_fly_zones/{uuid}

Rest API output

Since the Airchitect has no connection to the storage layer, it does not know if an object was deleted. It only passes the command through PubSub. The delete endpoint always returns 200.

PubSub Output

Delete endpoint output message has the same format as Airspace API delete message

Example message

    {
        data: b"{
            'uuid': '241fsa-521gg-5521aaz'
        "
        attributes: {
            "action": "delete",
            "kind": nfz,
            "commit_timestamp": 2022-01-01T00:00:00Z
            "version": 1,
        }
    }

Alternatives Considered

Add GET endpoint to NFZ

Airspaces API is the main point of retrieving for the Airspace of all kinds. Airchitect NFZ endpoint serves only as injection/modification layer.

Insert data through data lake pipeline

Data Lake interaction is the processing bottle neck since it takes multiple seconds. After that the data cannot be considered real-time anymore. Therefore propagating the NFZ to Airspaces API and replicating the results to data lake are parallel actions, preceded by NFZ processing.

Links

[1] Real-Time pipeline ADR