DATA Pipeline ATLAS 1 Ruleapplication

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

Rule Application

Context

In order to generate an airspace Atlas data pipeline must apply a rule to a given geo-object.

Atlas processing main assumption:

GeoObject + Rule = Airspace

A rules is an object representing law that must be obeyed inside given airspace.
It can be defined with following properties:

• geo_object_type - To which type of geo-object rule should be applied to (eg. airport, laanc_grid etc.)
• ruleset - An abstraction that groups a rules coming from the same source. (eg. PART-107)
• jurisdiction - An area where the rule should be obeyed. (eg. country borders)
• metadata_filters - A geo_object_type specific properties that are used to decide if a rule should be applied to a given geo_object (eg. apply the rule only if a grid requires authorization)
• uav_filters - An UAV specific filters that informs the pilot if rule is applicable for him (eg. drone weight, flight type etc.)

We could split rules into following categories:

• Airspaces
• Operations

Rules are used to define restriction level on the airspace they were used to create. Additionally rules can have an impact on airspace geometry.

Decision

To become a robust data source Atlas must process Rule Application as a part of a pipeline. Explanation for that can be found in Alternatives Considered section, point 1 and 2.

If Rule application is processed inside Atlas pipeline, rule methods (procedure how to apply the rule) must also be a part of Atlas codebase.

Example methods:

• Add restriction to GeoObject area (default method)
• Modify GeoObject area and add the restriction

Rule Application

To achieve this Atlas must receive following information from Rule Manager:

• To what type of geo_objects does the rule apply
• What is the area where the rules should be applied
• What level of restriction does the rule enforces ?
• Is there any geo_object metadata filters that should be applied to select correct geo objects (as an example - LAANC grids contains information in it’s meta data if LAANC applies to them)
• Which method known to Atlas should be applied on a geo_object in order to produce an airspace
• Are there any additional uav-related filters that must be passed to application layer ?

Atlas receives all the rules from Rule Manager and with information provided above apply them to GeoObjects to create an Airspace

Rule application process overview:

Invalid Image Path

Airspace creation:

Invalid Image Path

To get the rules Atlas can:

• Query Rule Manager API
• Subscribe to a Pub/Sub topic where Rule Manager publish new rules / changes to rules

The relation with Rule Manager can be presented as in diagram below:

Invalid Image Path

Rule Creation

What Atlas must expose to Rule Manager to allow custom-rule creation:

• Supported GeoObject Types
• For Each GeoObject Type - methods which application is supported by Atlas

In case if existing methods or geo_objects does not satisfy the new rule requirements, a ticket can be created for the Atlas team to add support for new method or ingest new type of geo_objects.

Example process flow for new rule creation:

Invalid Image Path

Rule Management Atlas

Atlas can manage each rule source in separate pipeline. With this approach a rules and therefore airspaces will preserve a link to an owner who created them. This will help with keeping whole system up to date and prevent being flooded with obsolete data.

Grouping a rules into a rulesets allows atlas to manage those pipelines effectively.

Consequences

1. Atlas reads rules from Rule Manager
2. Rule Manager owns and maintains the rules
3. Rules are bound to an Area, GeoObject Type and Restriction Type
4. Rules are grouped by rulesets
5. Rules application takes place inside Atlas Pipeline (aka. Airspace Factory)
6. Atlas is the owner of rule methods
7. Rule methods are bound to GeoObject type
8. Atlas provides an API that allows Rule Manager know what methods are supported for selected GeoObject types
9. Rule Manager provides an API that allows atlas to ingest the rules

Alternatives Considered

1. Lazy Atlas Scenario - Atlas provide only geo-object data, rules are applied by external client.

On an image below we have a tile that represent Atlas client area of interest [1]. The tile has 2 polygon geo-objects (eg. class airspace type)[2,3] inside of it, and one geo object outside (eg. stadium) [4]. The client cannot be aware about anything outside it’s area of interest.

Invalid Image Path

However, an element outside area of interest may have a rule connected to it that changes it’s geometry (eg. rules that requires to create a buffer of radius X around point). Since the client received only objects inside queried area [2,3] information that there is also an part of airspace created from object outside [4] is lost.

Invalid Image Path

On the other hand, if rule application is made by Atlas, all geometries are pre-computed and known by the client on query time.

Due to this conditions in order to guarantee no information loss, all of the rules that modifies geometry should be applied on atlas level.

2. Hybrid scenario - atlas pre-computes only the airspaces that modifies the geometry, others are computed by the client.

This approach have 2 main challenges:

1. Rule application logics is scattered among the organization.

It will be harder to manage and control the methodology of rule application. It also may end up with unnecessary coupling among the services

1. This has the potential to result in a greater number of elements being returned by the Atlas query.

Rule application done in the Atlas pipeline works also as a filter that removes unnecessary geo_objects from final airspaces. Omitting this step increases the number of objects that need to be processed by the client service which leads to extended processing time.

Because of that the design is more robust if atlas is responsible for all of the rule application methods.

3. Atlas analyses also uav filters

This cannot be achieved since this relates to application data. Atlas can attach this information to the airspace and let application decide based on each UAV metadata if those rules should be applied or not.

4. Rules are not groupped into rulesets

! THIS IS BASED ON INTIAL DISCUSSION WITH AIRBOSS - WE MIGHT WANT TO CHALLANGE THAT WITH UTM 2.0 ASSUMPTIONS !

Multiple rules from a different source can be applied to the same object. Having a ruleset allows to subscribe only the the ones, which are meaningful for our operations.