---

1. Executive Summary

This document provides a comprehensive technical description of the UK SORA (Specific Operations Risk Assessment) workflow as implemented in Dronedesk, the drone operations management platform developed and operated by Grey Rock Innovations Ltd.

Dronedesk implements the UK SORA framework, as defined in AMC1 Article 11 of the Air Navigation Order, as its primary regulatory basis. The flight geography calculator and zone boundary engine follows the JARUS SORA v2.5 Annex A methodology exactly. For the determination of maximum population density, Dronedesk additionally applies the sliding-window kernel method described in JARUS SORA v2.5 Annex F, Section 3.9.1.

1.1 Purpose

This document serves the following purposes:

• To provide a complete technical description of the UK SORA workflow implemented in Dronedesk, sufficient for independent review and audit of the methodology.
• To document the sliding-window kernel method for maximum population density assessment as described in Sections 5.3 and Appendix E, including the rationale for its adoption.
• To establish a shared methodological reference that can be used to expedite the assessment of operational authorisation applications submitted by Dronedesk users, without requiring each applicant to independently justify the underlying methodology.
• To be read as a standalone document.

1.2 Scope

This document covers the full UK SORA workflow as implemented in Dronedesk:

• Operational volume definition (FG, CV, GRB, AV)
• Population density assessment (people count, maximum density, average density)
• iGRC determination
• Ground risk mitigation framework (M1(A), M1(B), M1(C), M2)
• Air risk assessment (ARC determination)
• SAIL determination
• Assemblies of people assessment
• Report generation and audit trail

1.3 Key Methodological Positions

Flight geography and zone calculations: Dronedesk implements the JARUS SORA v2.5 Annex A methodology (JAR doc_26) for all flight geography calculations. The lateral and vertical boundaries of the Contingency Volume, Ground Risk Buffer and Adjacent Volume are computed from operator-declared UAS parameters and selected termination method using the formulae specified in Annex A, Section A.5. This provides a consistent, auditable basis for zone geometry that is directly traceable to the regulatory source.

Population density assessment - maximum density: Dronedesk implements the JARUS Annex F Section 3.9.1 sliding-window kernel method. Rather than deriving maximum density from a single GHS-POP grid cell, the kernel method assesses density across the realistic lateral dispersion area of the UAS at the declared operating altitude. Every GHS-POP cell wholly within or whose polygon crosses the FG+CV+GRB zone boundary is evaluated as a cell centre. Neighbour cell populations are accumulated using proportional overlap weighting, and the denominator is the kernel circle area clipped to the zone polygon. The kernel radius is derived directly from Annex F equation (21) as r = z / tan(30°), with a minimum of 100 m.

Air risk - ARC strategic mitigations: ARC strategic mitigations are presented to the operator for awareness but are not applied computationally to the residual ARC. The application of ARC mitigations requires independent assessor judgement and cannot be validated automatically by the platform.

Ground risk mitigations: M1(A), M1(B), M1(C) and M2 are available for operator selection with mandatory written justification. GRC credits vary by robustness level (see Figure 18). Dronedesk does not validate the sufficiency of operator justifications; the operator accepts responsibility for the accuracy and applicability of declared mitigations.

Data sources: Population data is sourced from GHS-POP R2023A (JRC, European Commission). Airspace classification uses OpenAIP. Assemblies of people are identified via OpenStreetMap Overpass API. All data sources are described in Section 3.4.

1.4 Justification and Notes Fields

At various points in both the flight geography calculator and the SORA assessment workflow, you will be asked to provide notes, justification or explanation. This is not there to slow you down. Each prompt is a direct response to an entry that the CAA would otherwise ask about during the review of an application. Capturing the reasoning at the point of entry ensures the final report is self-contained and complete, significantly reducing the likelihood of an application being returned pending clarification and helping to deliver a smoother path to authorisation.

The specific points at which additional input is required are highlighted throughout this document with a panel like the one below:

---

2. Scope and Regulatory Context

2.1 Applicable Regulatory Framework

The primary regulatory framework for SORA-based operational authorisations in the United Kingdom is UK SORA, as defined in AMC1 Article 11 of the UK Air Navigation Order. This framework specifies the methodology for assessing ground risk (GRC), air risk (ARC), and the resulting SAIL level for UAS operations in the Specific category.

Dronedesk implements UK SORA as its primary framework. Where UK SORA does not provide explicit guidance on specific methodological points, Dronedesk draws on JARUS SORA v2.5 published guidance documents. There are two instances of this:

• Flight geography and zone boundary calculations: The Dronedesk flight geography calculator implements the JARUS SORA v2.5 Annex A methodology (JAR doc_26, June 2024) to compute lateral and vertical CV, GRB and AV boundaries from the declared UAS parameters and selected termination method.
• Maximum population density: The sliding-window kernel method described in JARUS SORA v2.5 Annex F, Section 3.9.1 (JAR doc_29, June 2024) is applied to determine maximum population density. This methodology has been discussed and agreed with the UK SORA assessment team.

In all other respects, the Dronedesk SORA implementation follows UK SORA directly.

2.2 What This Document Covers

This document provides a complete technical description of all components of the SORA workflow as implemented in Dronedesk, including: zone geometry computation, population density methodology and data sources, iGRC determination, ground risk mitigation framework, air risk assessment, SAIL determination, assemblies of people assessment, and report generation. All formulae and worked examples are included in the appendices.

2.3 What This Document Does Not Cover

• Assessment of individual operator operational authorisation applications
• Airspace restriction or operational limitation determination
• Technical robustness or containment system assessment (SORA Step 8)
• Operational Safety Objective (OSO) compliance assessment
• Specific Category operator responsibilities or accountability

---

3. System Architecture Overview

3.1 Platform Description

Dronedesk is a SaaS drone operations management platform developed and operated by Grey Rock Innovations Ltd. The platform provides professional drone operators with tools for flight logging, client and job management, risk assessment, compliance documentation, and regulatory reporting. The SORA module is a discrete component within the platform, available as a paid add-on to subscribers on the Pro and Enterprise tiers.

The SORA module is accessed via a web browser. All SORA calculations and report generation are performed using the methodology described in this document. The operator provides input parameters; the platform performs all geospatial and risk calculations and produces a PDF assessment report.

White-label deployments of Dronedesk exist for third-party partners. These deployments use identical underlying technology and methodology; the SORA calculation engine is the same across all deployments.

3.2 Data Flow

The SORA workflow follows this ten-step sequence:

1. The operator selects the UA and declares drone parameters (characteristic dimension, maximum speed, MTOW) and termination method. The Dronedesk flight geography calculator, implementing the JARUS SORA v2.5 Annex A methodology, uses these inputs to compute the required lateral and vertical CV, GRB and AV boundaries.
2. The operator defines the Flight Geography (FG) geometry by drawing on an interactive map.
3. Zone geometries are computed client-side using Turf.js.
4. Population density assessment is performed using GHS-POP raster data.
5. iGRC is determined from the maximum density result and drone parameters.
6. Operator selects applicable ground risk mitigations with justification.
7. Airspace classification is retrieved from OpenAIP; operator confirms or amends ARC.
8. SAIL is determined from residual GRC and ARC.
9. Assemblies of people check is performed via OpenStreetMap Overpass API.
10. Assessment report is generated as a PDF.

SORA Workflow

10-step process from parameter input to report generation

3.3 Geospatial Computation Stack

Component	Library	Purpose
Map rendering	Leaflet.js v1.9.4	Interactive map display, zone polygon rendering, geometry capture
Geospatial maths	Turf.js v7	Geodesic buffer computation, polygon intersection, area calculation (ellipsoidal geometry)
Raster data access	georaster + geoblaze	GHS-POP Cloud-Optimised GeoTIFF (COG) fetch and pixel extraction
Threaded compute	Web Workers	Population density kernel computation offloaded from main thread
Coordinate system	WGS84 throughout	All coordinates, distances and areas use WGS84; geodesic (not planar) calculations throughout

Geodesic area calculation: All polygon areas are computed using turf.area(), which implements the ellipsoidal (geodesic) formula based on the WGS84 reference ellipsoid. Planar geometry is not used at any point in the calculation chain.

3.4 Data Sources

Data source	Purpose	Update cadence	Limitations
GHS-POP R2023A (JRC, European Commission)	Population density raster for all density calculations	Decadal dataset; current epoch 2025	Census-derived; epoch averaging; no intra-day or seasonal variation
OpenAIP (openaip.net)	Airspace classification for ARC determination	Continuous community updates	Community-maintained; not the authoritative UK airspace source; operator must verify
OpenStreetMap Overpass API	Assemblies of people within 1 km of operational volume	Live query at time of assessment	Community-maintained; temporary assemblies not captured; operator must verify

GHS-POP data preparation and optimisation

The GHS-POP R2023A dataset is not served to Dronedesk directly in its raw downloaded form. The source data from Copernicus is distributed as a set of regional GeoTIFF tiles at 3 arc-second resolution, which are not suitable for efficient in-browser querying across large or arbitrary operational areas. Before deployment, Dronedesk pre-processes the source tiles using GDAL to produce a single merged Cloud Optimised GeoTIFF (COG). The processing pipeline merges all regional tiles into a unified virtual raster, then converts this to a COG using lossless DEFLATE compression with horizontal differencing (PREDICTOR=2), averaged internal overview pyramids (RESAMPLING=AVERAGE), and 32-bit floating-point output (Float32) to preserve the full decimal precision of the fractional population values.

The rationale for this approach is both practical and methodological. The COG format is internally tiled and organised to support HTTP range requests, meaning the georaster library used in Dronedesk can stream only the specific raster region relevant to a given flight geography rather than loading the entire dataset. This makes in-browser raster queries responsive regardless of the size of the source dataset. The use of averaged pyramids ensures that the population values remain accurate at all zoom levels, which is important for the visual overlay as well as for the kernel density calculation. The Float32 output type preserves the sub-integer population counts present in the GHS-POP data, which are a product of the dasymetric disaggregation methodology used to produce the dataset and are essential for accurate weighted population calculations at cell level.

OpenStreetMap Overpass API: self-hosted instance

Dronedesk does not query the public Overpass API (overpass-api.de) for assemblies of people data. The public service is a shared, rate-limited resource serving thousands of applications simultaneously, which makes it unsuitable for a production platform where query reliability and response consistency are requirements. Instead, Dronedesk operates its own private Overpass API instance hosting a complete copy of the global OSM planet database. The instance runs on dedicated bare-metal infrastructure using the wiktorn/overpass-api Docker image, initialised via clone mode from the official Overpass development server. This copies a pre-indexed planet database directly, avoiding the multi-day re-indexing process that would otherwise be required to ingest the raw planet file from scratch.

The self-hosted instance is kept current through automatic minutely diff updates sourced from the OpenStreetMap Foundation planet replication feed, meaning the dataset is typically no more than one to five minutes behind the live OSM planet at any given time. All queries are routed through an Nginx reverse proxy with API key authentication, gzip compression, and extended timeouts to accommodate complex spatial queries. Because Dronedesk is the sole user of the instance, there are no rate limits, no shared contention, and no dependency on third-party infrastructure decisions. The result is consistent, predictable query latency regardless of global OSM traffic levels, and complete global coverage across all supported Dronedesk regions.

---

4. Operational Volume Definition

The Dronedesk SORA module implements the four-zone operational volume model defined in UK SORA: Flight Geography (FG), Contingency Volume (CV), Ground Risk Buffer (GRB), and Adjacent Volume (AV). UK SORA documentation also refers to this outermost zone as the Adjacent Area; the terms are interchangeable and both are used in this document. All zones are computed using geodesic buffer operations applied to the operator-defined FG geometry.

The CV, GRB and AV dimensions are derived from the Dronedesk flight geography calculator, which implements the JARUS SORA v2.5 Annex A methodology. Operators may adjust individual values, but where any entered value falls outside the Annex A suggested range, the platform requires a mandatory written justification.

4.1 Flight Geography (FG)

The FG is the operator-defined volume within which the UAS is intended to operate under normal conditions. In Dronedesk, the FG is defined by one of three geometry types:

• Point geography (polygon): The operator draws a closed polygon on the interactive map.
• Radius geography: The operator places a centre point and declares a radius (m). Zone buffers are applied radially to the circle boundary.
• Linear corridor: The operator defines a route as a series of waypoints with a declared corridor half-width (m).

Flight Geography Geometry Types

All three types support the same CV, GRB and AV buffer calculations

The operator declares the FG ceiling height in metres AGL. This value is used as z in the kernel radius formula (see Section 5.3.3).

4.2 Contingency Volume (CV)

The CV is the volume immediately surrounding the FG, entered when the operator triggers a contingency procedure. The CV outer boundary is computed as a geodesic buffer of the declared CV distance applied to the FG boundary.

Operational Volume (OV): the FG + CV make up the Operational Volume.

4.3 Ground Risk Buffer (GRB)

The GRB is the area beyond the Operational Volume (FG+CV) within which the aircraft is expected to land in the event of a loss-of-control event. The GRB inner boundary is the CV outer boundary. The GRB outer boundary is computed as a geodesic buffer of the cumulative distance (CV + GRB distance) applied to the FG boundary. The population density within the FG+CV+GRB zone is used to determine the maximum density figure for iGRC.

4.4 Adjacent Volume (AV)

The AV is the area used for the average population density assessment. The AV is a doughnut zone (annular region) whose inner boundary is the CV outer boundary and whose outer boundary is the AV outer boundary. The GRB sits geometrically within the AV - both share the same inner boundary (CV outer). The AV distance is declared in metres, measured from the CV outer boundary.

Zone boundary clipping: When computing the maximum density kernel (Section 5.3), only cells wholly within or intersecting the FG+CV+GRB zone polygon outer boundary are evaluated. Cells in the AV area outside the GRB outer boundary are excluded.

4.5 Zone Stacking and Cumulative Distances

Zone	Inner boundary	Outer boundary	Purpose
FG	FG edge	FG edge	Normal operating volume
OV (FG+CV)	FG edge	FG edge + CV distance	People count
FG+CV+GRB	FG edge	FG edge + CV + GRB distance	Maximum population density (iGRC)
AV	CV outer boundary (= GRB inner boundary)	CV outer + AV distance	Average population density

Note: the GRB and AV zones share the same inner boundary - the CV outer boundary. The GRB outer boundary lies within the AV zone. S_AV is measured from the CV outer boundary, not from the GRB outer boundary.

Operational Volume - Plan View

Zone geometry plan view (top-down). GRB and AV share the same inner boundary.

Operational Volume - Vertical Cross-Section

Relative zone heights and lateral extents (not to scale)

4.6 Annex A Flight Geography Calculator - Detailed Methodology

This section describes the detailed input parameters and formulae implemented in the Dronedesk flight geography calculator, which follows the JARUS SORA v2.5 Annex A Section A.5.2 methodology. All parameters have system-suggested default values derived from the Annex A specification.

4.6.1 Input Parameters

Parameter	Symbol	Notes and validation rules
UAV type	-	Rotorcraft | Fixed-wing | VTOL/Hybrid
Max UAV dimension (m)	CD	Largest physical dimension of the UA
Maximum UA speed (m/s)	v0	Minimum 3 m/s ✎ Justification required Values below manufacturer's published max speed require written justification.
Equipped with parachute	-	Yes | No
Parachute deployment time (s)	tp	Required if parachute equipped
Ground visibility (m)	GV	Maximum value applied: 5,000 m
Attitude line of sight (m)	ALOSmax	Rotorcraft: 327 × CD + 20. Fixed-wing/VTOL: 490 × CD + 30
Detection line of sight (m)	DLOS	DLOS = 0.3 × GV
Max visual line of sight (m)	VLOSmax	VLOSmax = min(ALOSmax, DLOS)
Max wind speed for parachute (m/s)	vwind	Minimum 3 m/s
Descent rate with parachute (m/s)	vz	Required if parachute equipped
Height of flight geography (m)	HFG	Minimum: CD × 3
Lateral flight geography (m)	SFG	Minimum: CD × 3
Gravity (m/s²)	g	Fixed at 9.81 m/s², not user-editable
Type of altimetry	-	Barometric or GPS-based
Altimetry error (m)	Hδ	Values <1 m (barometric) or <3 m (GPS-based). ✎ Justification required Values below these thresholds require written justification.
GPS inaccuracy (m)	SGPS	Values <3 m. ✎ Justification required Values below 3 m require written justification.
Positioning error (m)	SPOS	Values <3 m. ✎ Justification required Values below 3 m require written justification.
Map error (m)	Sk	Values <1 m. ✎ Justification required Values below 1 m require written justification.
Pilot reaction time (s)	tRZ	Values <1 s. ✎ Justification required Values below 1 s require written justification.
Maximum pitch angle - rotorcraft (deg)	Θ	Maximum 45°
Roll angle - fixed-wing/VTOL (deg)	Φ	Maximum 30°
Glide ratio denominator - fixed-wing/VTOL	ε	Default value: 20. ✎ Justification required Any value other than 20 requires written justification.
Flight continuation time (s)	tf	Default value: 180 s. ✎ Justification required Values below 180s require written justification.
Controlled ground area	-	Yes | No

4.6.2 Manoeuvre and Termination Options

CV lateral manoeuvre options

Manoeuvre option	Rotorcraft	Fixed-wing / VTOL
Stopping	Yes	No
Deploy parachute	No	Yes
180° turn	Yes	Yes

CV vertical manoeuvre options

Manoeuvre option	Rotorcraft	Fixed-wing / VTOL
Convert forward energy to potential energy	Yes	No
Deploy parachute	Yes	Yes
Pitch 45° and circle to level flight	No	Yes

GRB termination options

Termination method	Rotorcraft	Fixed-wing / VTOL
Simplified (1:1 rule)	Yes	Yes
Ballistic	Yes	No
Deploy parachute	Yes	Yes
Power-off glide	No	Yes

CV Lateral Manoeuvre Geometry

S_CV = distance from FG edge to outermost point reached during the contingency manoeuvre

4.6.3 Contingency Volume Calculation

Reaction distance

Contingency manoeuvre lateral distance

Rotorcraft - stopping:

Fixed-wing / VTOL - 180° turn:

With parachute:

Contingency manoeuvre height loss

Rotorcraft - 100% forward energy to potential energy:

Fixed-wing / VTOL - pitch 45° and circle to level:

With parachute:

Minimum lateral CV

Minimum vertical CV

GRB Termination Methods - Lateral Footprint

Each method translates H_CV into a lateral ground footprint S_GRB

4.6.4 Ground Risk Buffer Calculation

Simplified - 1:1 rule

Ballistic - rotorcraft only

Termination with parachute

Power-off glide - fixed-wing / VTOL only

4.6.5 Adjacent Volume Calculation

AV lateral distance

Minimum 5,000 m, maximum 35,000 m. v₀ here is the manufacturer maximum speed regardless of operational adjustments.

AV vertical height

---

5. Population Density Assessment

Population density is assessed across three zones, each serving a distinct purpose in the UK SORA framework: the Operational Volume (FG+CV) for people count, the FG+CV+GRB zone for maximum density used in iGRC determination, and the Adjacent Volume (AV) for average density.

5.1 Population Data Source

All population density calculations use the GHS-POP R2023A dataset (Global Human Settlement Population Grid), published by the European Commission Joint Research Centre (JRC).

Parameter	Value
Full name	GHS-POP R2023A - GHS Population Grid, multitemporal (1975-2030)
Producer	European Commission, Joint Research Centre (JRC)
Epoch used	2025
Spatial resolution	3 arc-seconds (~90 m N/S × 55-65 m E/W at UK latitudes)
Coordinate system	WGS84 geographic (EPSG:4326)
Format accessed	Cloud-Optimised GeoTIFF (COG), fetched on demand via georaster
Citation	Schiavina, M., Freire, S., Carioli, A., MacManus, K. (2023): GHS-POP R2023A. JRC. doi:10.2905/2FF68A52-5B5B-4A22-8F40-C41DA8332CFE

Each GHS-POP grid cell holds a raw headcount: the estimated residential population for that specific patch of ground, derived from census data, building footprint analysis, and remote sensing. At UK latitudes, each cell covers approximately 4,500-5,800 m².

Known limitations: The dataset is census-derived and uses epoch averaging; it does not reflect rapid population change, intra-day variation, or transient gatherings. Operators are responsible for applying appropriate judgement where these factors may be material.

5.2 People Count - FG+CV Zone

5.2.1 Purpose

The people count provides an estimate of the number of people present within the Flight Geography and Contingency Volume combined. This figure is reported in the assessment but does not directly determine the iGRC.

5.2.2 Methodology

1. All GHS-POP cells whose extent fall wholly within or intersects the FG+CV polygon boundary are identified.
2. For each cell, the intersection polygon is computed using Turf.js (turf.intersect).
3. Coverage fraction: f = A_intersection / A_cell.
4. Weighted population contribution: P_weighted = P_raw × f.
5. Total people count = sum of all weighted contributions.

5.2.3 Average Density (FG+CV)

The denominator is the total FG+CV zone area including cells with zero population, producing a true area-weighted mean density.

People Count - FG+CV Zone

GHS-POP cells intersected with FG+CV zone, weighted by coverage fraction

Table 5.2a: People count: all 25 cells intersecting the FG+CV zone. Raw Population = GHS-POP fractional resident count for the cell. Coverage % = proportion of cell area inside the FG+CV zone boundary. Weighted Pop = Raw Population × Coverage fraction, contributing to the total people count.

Cell #	Raw Pop	Coverage %	Weighted Pop
1	0.59	16.0%	0.09
2	1.54	79.6%	1.22
3	3.07	87.8%	2.69
4	0.05	87.3%	0.04
5	0.04	86.8%	0.03
…	…	…	…
21	0.12	100%	0.12
22	0.36	17.0%	0.06
23	0.67	24.3%	0.16
24	0.31	24.6%	0.08
25	0.15	24.8%	0.04
TOTAL	19.4	-	15.1

5.3 Maximum Population Density - FG+CV+GRB Zone

5.3.1 Purpose

The maximum population density within the FG+CV+GRB zone is the primary input to iGRC determination. It represents the highest density of people that the UAS could realistically overfly or impact in the event of a loss-of-control event.

5.3.2 The Problem with Single-Cell Extrapolation

The conventional approach divides a cell's raw population by the cell area and scales to ppl/km²:

At UK latitudes, a cell covering ~4,500 m² containing 2 people yields:

The Single-Cell Extrapolation Problem

One populated cell implies that same density across the entire surrounding km²

This assumes that density is uniform across the entire surrounding square kilometre. In a rural or semi-rural setting, neighbouring cells will typically contain zero people, making this a gross overestimate. The consequence is that iGRC is systematically overstated for semi-rural and corridor operations.

5.3.3 JARUS Annex F Section 3.9.1 - The Sliding-Window Kernel Methodology

JARUS SORA v2.5 Annex F (JAR doc_29, June 2024), Section 3.9.1, "Map resolution as a function of intended operating altitude," directly addresses the appropriate spatial scale for population density assessment. It introduces the concept of the dispersion area: the realistic ground footprint within which a UAS could impact following a loss-of-control event at a given operating altitude.

The Annex F reasoning: when a UAS fails, it does not fall vertically. It disperses laterally from its current position, with the extent of dispersion proportional to the operating altitude and the angle of impact. The dispersion area is modelled as a circle on the ground. If the population density figure is derived from a spatial scale matched to this dispersion area, the result reflects the realistic density across the area actually at risk.

The angle of impact adopted in Annex F is 30°, justified as a midpoint between the 10° glide angle used in critical area models and the 45° angle used for low-robustness GRB calculations.

Dispersion Area Concept

Lateral dispersion from a loss-of-control event at altitude z, with 30° impact angle

5.3.4 Kernel Radius Derivation

Annex F Section 3.9.1 derives acceptable grid cell sizes as a function of operating altitude z and angle of inclination θ in equation (21):

Substituting the upper bound and applying the sampling constraint l_grid ≤ r_disp:

Verified by Table 11 in Annex F: at z = 152.4 m, l_grid,max = 527.9 m, r_disp = 264 m = 152.4 / tan(30°). The formula is confirmed. The kernel radius used in Dronedesk is therefore:

Minimum radius of 100 m: below approximately one GHS-POP cell width (55-65 m at UK latitudes), the kernel converges towards single-cell behaviour. A minimum of 100 m ensures meaningful spatial averaging. This minimum was discussed and agreed with the UK SORA assessment team.

Altitude parameter - FG ceiling height: Annex F defines z as "the altitude of the operation under normal operating conditions." The FG is where normal operations take place; the CV is entered only after a contingency has been triggered (an abnormal state). Accordingly, z is taken as the FG ceiling height in metres AGL, not the CV ceiling height.

5.3.5 Kernel Algorithm

Sliding-Window Kernel Density — Actual Dataset

Cell colour = kernel raw pop sum. Labels on peak row = kernel density (ppl/km²). Actual KML boundaries overlaid.

#	Raw pop sum	Numerator	Denominator (km²)	Coverage	Density (ppl/km²)
1	14.42	14.4180	0.052929	1.0000	273.0	Dmax
2	13.53	13.4987	0.052929	1.0000	256.0
3	13.10	13.0648	0.052929	1.0000	248.0
4	11.18	10.8989	0.051521	0.9749	217.0
5	9.53	8.7710	0.048636	0.9201	196.0
6	5.61	5.4326	0.041409	0.7836	136.0
7	3.98	3.9800	0.052929	1.0000	76.0
8	0.03	0.0258	0.025913	0.4897	1.0
9	0.00	0.0000	0.016152	0.3052	0.0
10	0.00	0.0000	0.019212	0.3634	0.0

Representative rows from the maximum density export, keyed to cell labels in Figure 10. 158 cell centres were evaluated in full for this assessment (z = 75 m AGL, r = 130 m).

The sliding-window kernel is computed as follows:

1. Compute kernel radius: r = max(100, z / tan(30°)) where z is the FG ceiling height in metres AGL.
2. Expand pixel fetch: the bounding box of the FG+CV+GRB polygon is expanded by ceil(r / 90) + 2 cells on each edge.
3. Identify cell centres: every GHS-POP cell that falls wholly within, or whose polygon crosses, the FG+CV+GRB zone boundary is evaluated. This includes cells with zero population. For each cell centre:
   1. Clip the kernel circle (64-vertex polygon) to the zone polygon. The area of the clipped polygon is used as the denominator for that cell centre.
   2. For each neighbouring cell within radius r: compute the overlap of the cell polygon with the zone polygon. Coverage fraction = overlap area / cell area. Cells wholly inside the zone contribute 100%; cells that cross the boundary contribute proportionally; cells wholly outside contribute 0%.

The kernel algorithm evaluates every raster cell in the fetch window as a potential cell centre, including cells with zero population. Zero-population cells are invisible on the population map overlay but are valid kernel centres: a kernel centred on an unpopulated location may still capture populated cells within its radius and may represent the worst-case density exposure point. Many rows in the maximum density export will therefore show zero or near-zero kernel raw population sums.

4. Compute kernel density: D_kernel = kernel_population_sum / clipped_kernel_area_km².
5. Record: store cell centre coordinates, neighbour count, kernel population sum, and kernel density.
6. Maximum density: D_max = MAX(D_kernel) across all cell centres wholly within or crossing the FG+CV+GRB zone boundary.

Proportional Cell Centre Overlap at Zone Boundary

Coverage fraction = overlap area / cell area, applied to raw population

Clipped Kernel Denominator

Only the zone-intersecting portion of the kernel circle is used as the denominator

5.3.6 Effect of the Kernel Method

Method	Effective area	Density	Assumption
Single-cell extrapolation	~4,500 m²	444 ppl/km²	Population density assumed uniform across the entire surrounding km²
Kernel method (r = 208 m at z = 120 m AGL)	~0.136 km² (clipped to zone)	14.7 ppl/km²	Density assessed across the realistic lateral dispersion area

The figures in the table below are based on a synthetic illustrative scenario and are not derived from the actual dataset shown above. They are intended to demonstrate the proportional difference between the two methods, not to correspond to the worked example.

Single-cell extrapolation calculation:

Kernel method calculation (z = 120 m AGL):

In practice A_kernel is clipped to the assessment zone boundary, so the effective denominator may be smaller. The kernel radius has a minimum floor of 100 m regardless of altitude.

Density Method Comparison - Consistent Scale

Scenario: z = 120 m AGL, 2 people in the populated cell. Purple box = 1 km² reference area.

The kernel result converges towards the single-cell result where population is spatially homogeneous - in a densely populated urban area both methods produce similar figures. The material difference appears in semi-rural, suburban fringe, and corridor operations where isolated populated cells are surrounded by empty cells.

5.3.7 Relationship to UK SORA

The sliding-window kernel method is an application of JARUS Annex F Section 3.9.1 guidance to fill a gap not explicitly addressed in the UK SORA text. It does not replace or modify any component of UK SORA; it provides the spatial scale at which the maximum density assessment is performed.

5.3.8 Audit Trail

For every maximum density calculation, the following data is produced and retained:

• Per-cell-centre table: for each GHS-POP cell evaluated (including cells crossing the boundary), the cell centre coordinates, populated neighbour count, kernel raw population sum, kernel weighted population, denominator (km²), kernel coverage (0-1), kernel density (ppl/km²), and a flag indicating whether that cell centre produced the maximum result.
• This data is included in Appendix C of the assessment report (first 50 rows inline; full dataset available as CSV download from within the platform).
• The kernel radius, clipped kernel area, and FG altitude used are recorded in every report.

5.4 Average Population Density - Adjacent Volume (AV)

Adjacent Volume - doughnut Zone

Average density assessed across the shaded AV area (CV outer to AV outer)

5.4.1 Zone Definition

Average population density is assessed across the full Adjacent Volume (AV). The AV is a doughnut zone with its inner boundary at the CV outer boundary and its outer boundary at the AV outer boundary. The GRB sits geometrically within this doughnut but is not excluded from the average density calculation.

5.4.2 Methodology

1. Intersect each GHS-POP cell with the AV outer boundary polygon.
2. Subtract any intersection with the CV outer boundary polygon (the inner exclude boundary).
3. Compute net coverage fraction: f = A_net_intersection / A_cell.
4. Compute weighted population: P_weighted = P_raw × f.
5. Sum weighted populations across all cells.
6. Divide by the total AV zone area (including zero-population cells) to produce average density in ppl/km².

Denominator: The full AV zone area - area of AV outer polygon minus area of CV outer polygon - including cells with zero population. Using the full zone area produces a true area-weighted mean density.

Average Population Density — Adjacent Volume

AV cells near GRB/CV/FG boundaries. Partial cells straddle CV outer (AV inner boundary). D_avg = 428 ppl/km²

How to read this figure: Each coloured cell is a GHS-POP raster cell with measured population. Cell number (top-left) and weighted population P_raw × f_coverage (centre) are shown. Cells shown in amber tint lie inside the CV boundary and are excluded from the AV calculation. Hatched cells straddle the AV outer or inner boundary and contribute proportionally. The full AV extends ~10 km in each direction; this detail window shows ~2 km × 1.5 km near the inner boundary to illustrate the exclusion zone.

Table 5.4a: Example extract from the full 17,295 AV cells. Raw Population = GHS-POP fractional resident count for the full cell. Coverage % = proportion of cell area inside the AV zone boundary; partial cells straddle the CV outer boundary. Weighted Pop = Raw Pop × Coverage fraction.

Cell #	Raw Pop	Coverage %	Weighted Pop
3182	0.0046	90%	0.00
3183	0.0116	100%	0.01
3184	0.0211	100%	0.02
3185	0.3085	100%	0.31
3186	0.4313	100%	0.43
…	…	…	…
3492	0.5543	100%	0.55
3577	0.1573	100%	0.16
3578	0.2360	100%	0.24
3579	0.0150	100%	0.02
3580	0.0089	100%	0.01

Table 5.4b: Full AV zone result summary (all 17,295 cells):

Metric	Value
Non-zero cells in AV	7,408
Zero-population cells	~9,887
Total zone area (AV outer − CV outer)	88.9 km²
Σ weighted population	38,069.9
Average density Davg(AV)	428 ppl/km²

5.5 Assemblies of People Assessment

UK SORA requires that the presence of assemblies of people within 1 km of the operational volume outer limit is determined prior to operation. Dronedesk queries OpenStreetMap via the Overpass API to identify known assemblies within 1,000 m of the CV outer boundary.

Assemblies of People - Search Radius

1 km search from CV outer boundary via OpenStreetMap Overpass API

Data Source

The Overpass query targets the following OpenStreetMap tags:

• nwr["leisure"="stadium"]
• nwr["building"="stadium"]
• nwr["amenity"~"events_venue|conference_centre|exhibition_centre"]
• nwr["leisure"~"horse_racing|dog_racing"]
• nwr["landuse"~"recreation_ground|fairground"]
• nwr["amenity"~"showground|fairground"]
• nwr["leisure"="track"]["sport"~"motor|karting"]
• nwr["highway"="raceway"]

Output States

State	Description
Clear	No assemblies found within the search boundary. Confirmed in the assessment report.
Found	One or more assemblies found. Listed with name, OSM category, estimated distance, and bearing. Operator must review and confirm awareness.
Check failed	The Overpass query was unsuccessful. The report flags that manual verification is required.

Assessment Requirement on Finding

Whenever a possible assembly of people is found, the assessment process requires the operator to enter notes explaining the assembly in the context of operational containment and the robustness of ground risk mitigations. The explanation should address the average population density in the area and the likely scale of any assemblies, with reference to the relevant UK SORA thresholds of more than 400,000 people, between 40,000 and 400,000 people, or fewer than 40,000 people. These notes are captured in the platform and passed through in full to the final report output, where they form part of the ground risk justification.

Limitations

• OpenStreetMap is community-maintained and coverage may be incomplete for some venue types or geographic areas.
• Temporary assemblies (markets, events, fixtures, concerts) are not captured. Operators must conduct manual assessments for temporary gatherings.
• The operator is responsible for confirming the completeness of the automated check.

5.6 Data Currency and Recalculation

Full per-cell and per-sample audit data is not persisted between browser sessions. Summary density metrics (maximum density, average density, people count, iGRC) are persisted alongside a stale flag for each Flight Geography.

The stale flag is set when a Flight Geography geometry is modified. It is persisted across sessions. On page load, any Flight Geography with a stale flag triggers an automatic recalculation, shown to the user via a progress modal titled "Recalculating stale metrics". If an operator clicks a stale FG before recalculation completes, the info panel displays the previous metrics with a prominent warning and a manual recalculate button.

The assessment report cannot be generated while any stale flag is outstanding.

5.7 Computational Performance Optimisation

The GHS-POP population density calculations described in Sections 5.2, 5.3 and 5.4 involve iterating over every raster cell in the bounding box of the zone polygon and, for each qualifying cell, performing geometric intersection tests against the zone polygon. For typical flight geographies (a few hundred metres to a few kilometres in extent) this is fast. For very large or geometrically complex flight geographies (such as corridor operations spanning tens of kilometres, or polygons with many hundreds of vertices), the naive approach becomes computationally prohibitive, with calculation times measured in tens of minutes or more.

Dronedesk applies a set of optimisations that substantially reduce calculation time for large or complex zones while preserving full accuracy for the cell coverage fractions used in the final density and population count figures. This section documents the approach, the conditions under which each optimisation is applied, and the accuracy implications of each change.

5.7.1 Optimisation Gate: When Optimisations Apply

A zone is classified as large and complex if both of the following conditions are met simultaneously:

Condition	Threshold	Rationale
Polygon vertex count	> 100 vertices AND > 25 km²	Both conditions must be met. A large simple polygon does not need simplification as each intersection test is already cheap. A small complex polygon covers few cells so the calculation is fast regardless. Only when the zone is both large and complex does simplification materially reduce computation time while remaining low-risk.
Bounding box area	See above — combined condition only	See above

The gate is evaluated once at the start of each zone calculation. Optimisations that affect the zone polygon geometry (Section 5.7.2) only activate when the gate fires. Optimisations that are purely computational shortcuts with zero geometric effect (Sections 5.7.3-5.7.6) apply unconditionally to all calculations.

5.7.2 Zone Polygon Simplification (Gated)

When the gate fires, the zone polygon is simplified using the Ramer-Douglas-Peucker algorithm (via turf.simplify) with a tolerance of 0.0001 degrees before any raster iteration begins. At the GHS-POP cell resolution of approximately 90 m north-south and 55-65 m east-west at UK latitudes, this tolerance introduces a maximum boundary displacement of approximately 7-11 metres per simplified segment. At UK latitudes GHS-POP cells are approximately 92 m N-S and 56 m E-W, so this displacement represents less than one fifth of a cell width east-west and less than one ninth north-south.

Polygon simplification is applied only to the working polygon used for the raster iteration. The original zone polygon is retained and displayed on the map and is used for all other calculations (zone area, report display) throughout the assessment.

Accuracy qualification: simplification may affect the coverage fraction and kernel denominator for cells that straddle the simplified boundary. D_max is only affected if the peak kernel centre is itself a boundary cell and the boundary displacement at that location is sufficient to change the clipped kernel area materially. This risk is low for large zones where the peak density typically occurs in a built-up area well inside the zone, but cannot be excluded for all geometries. Operators with safety-critical assessments near zone boundaries should be aware that simplification is applied when the zone exceeds both 100 vertices and 25 km².

5.7.3 Bounding Box Pre-filter (Unconditional)

Before any geometric test is performed on a cell, the cell centre coordinates are compared against the zone polygon bounding box. If the cell centre falls outside the bbox, the cell is skipped without any turf call. This has zero accuracy cost: a cell whose centre is outside the polygon bounding box cannot intersect the polygon, and eliminates a significant fraction of cells for elongated or irregular zone shapes where the bbox is substantially larger than the zone itself.

5.7.4 Point-in-Polygon Sample Qualification (Unconditional)

The most expensive step in the original implementation was calling turf.intersect(cellPolygon, zonePolygon) to determine whether each cell qualifies as a sample point. This computes the full intersection geometry even when the result is null (no intersection). For large zones the vast majority of cells in the bbox fall outside the zone polygon, meaning most turf.intersect calls returned null and were wasted.

The optimised qualification uses a two-stage approach:

1. Point-in-polygon test first: turf.booleanPointInPolygon(centrePoint, zonePolygon) is called for every non-bbox-skipped cell. This is an O(n vertices) ray-casting test that returns a boolean without computing any intersection geometry. If the cell centre is inside the zone, the cell qualifies immediately.
2. Boundary cells: If the cell centre is outside, turf.booleanIntersects(cellPolygon, zonePolygon) is called. This returns a boolean indicating whether the cell polygon touches the zone boundary, again without computing intersection geometry. Only if this returns true does the cell qualify as a boundary cell requiring accurate coverage fraction computation.

Boundary cells are preserved in the qualification set specifically to avoid under-counting population near zone edges, for example, where the GRB outer boundary skirts a populated area. Skipping boundary cells would risk missing the worst-case density kernel centre in exactly the scenario SORA is designed to identify.

5.7.5 Wholly-Inside Fast Path (Unconditional)

For cells that qualify via the point-in-polygon test (centre inside the zone), a further check determines whether the entire cell polygon is contained within the zone polygon using turf.booleanContains. If true, the coverage fraction is 1.0 and no intersection geometry needs to be computed. turf.intersect is only called for the small minority of qualifying cells that straddle the zone boundary.

5.7.6 AV Exclude Zone Optimisations (Unconditional)

The Adjacent Volume density calculation (Section 5.4) uses a donut-shaped zone: the area between the CV outer boundary (inner edge) and the AV outer boundary (outer edge). Computationally this is represented as a polygon with an exclude polygon (the CV outer boundary) subtracted. Two additional optimisations apply:

• Early exclude check: Before any AV outer polygon qualification, the cell centre is tested against the CV exclude polygon using turf.booleanPointInPolygon. Cells whose centre is inside the CV are skipped immediately. This eliminates all cells in the inner part of the AV bbox without any AV polygon test.
• Exclude boundary gate: For qualifying AV cells, the CV boundary carve-out (the turf.intersect / turf.difference operation that subtracts the CV area from boundary cells) is only performed for cells that turf.booleanIntersects confirms actually touch the CV boundary. Cells clearly in the AV band, away from the CV inner boundary, skip the carve-out entirely.

5.7.7 Additional Computational Shortcuts (Unconditional)

• Euclidean distance approximation: The kernel neighbour distance test (determining which cells fall within kernel radius r) uses a planar Euclidean approximation rather than turf.distance. At the distances involved (maximum 400-500 m), the geodesic error is less than 0.05%. The approximation: d = √((Δlat × 111,320)² + (Δlon × 111,320 × cos(lat))²).
• Precomputed cell area: GHS-POP cell area is constant across the zone for any given latitude band. The cell area is computed once before the raster loop and reused for every cell, replacing a turf.area(cellPolygon) call per cell.

5.7.8 Accuracy Impact Summary

Optimisation	Gated?	Accuracy impact	Rationale
Polygon simplification	Yes (>100 vertices AND >25 km²)	Small but non-zero at zone boundary	Tolerance of 0.0001° introduces max ~10 m boundary displacement, less than one fifth of a GHS-POP cell width at UK latitudes. Dmax is unaffected if the peak kernel centre is interior to the zone. If the peak coincides with a boundary cell, a small denominator difference is possible. Original polygon retained for all non-raster uses.
Bounding box pre-filter	No	None	Logically equivalent to the full test. A cell outside the bbox cannot intersect the polygon.
Point-in-polygon qualification	No	None	Boolean result is identical to checking for a non-null intersection. Boundary cells are still included via booleanIntersects.
Wholly-inside fast path	No	None	Coverage fraction of 1.0 is the mathematically correct result when the cell polygon is fully contained by the zone polygon.
AV early exclude check	No	None	Cells inside CV are correctly excluded from the AV calculation regardless of method.
AV exclude boundary gate	No	None	Cells not touching the CV boundary receive no carve-out, which is correct; their full area is within the AV band.
Euclidean distance (kernel)	No	<0.05% error at max kernel radius	At radii of 100-400 m the planar approximation diverges from geodesic distance by less than 0.05%. Impact on final density figure is immeasurable.
Precomputed cell area	No	None	Cell area is constant for all cells in a zone. Single computation is mathematically identical to per-cell computation.

No optimisation alters the coverage fraction calculation itself. For every cell that qualifies, the coverage fraction is computed using the same turf.intersect geometry as the unoptimised implementation. The optimisations only determine which cells reach that step and by what route.

---

6. iGRC Determination

The intrinsic Ground Risk Class (iGRC) is determined by cross-referencing the maximum population density from Section 5.3 with the UAS characteristic dimension and maximum speed, using the UK SORA iGRC determination table (AMC1 Article 11, Table 3).

6.1 Inputs

Input	Source
Maximum population density (ppl/km²)	Calculated per Section 5.3; or operator-declared override (see Section 6.3)
UAS characteristic dimension (m)	Operator-declared; the largest physical dimension of the UA
UAS maximum speed (m/s)	Operator-declared; the maximum horizontal speed in the operating configuration
Controlled ground area flag	Operator-declared; if set, density is treated as the controlled/zero row

6.2 iGRC Lookup

The iGRC is determined by cross-referencing the population density band with the UAS size/speed category using the table below (AMC1 Article 11, Table 3). The following are entered into the Flight Geography calculator:

UA Characteristic Dimension

To establish the characteristic dimension of the UA:

• For rotorcraft: use the maximum distance between blade tips (not motor-to-motor distance).
• For fixed-wing aircraft: use the larger of maximum wingspan or fuselage length.

Maximum Speed

The applicant must enter the potential maximum speed of the UA, not the maximum speed of the proposed operation. Any value entered below the manufacturer's listed maximum speed must be accompanied by prompt written justification. That justification is captured in the platform and passed through to the final report output.

iGRC Determination

AMC1 Article 11, Table 3 - grey cells (n/a) are outside the scope of UK SORA

Cells marked n/a represent combinations outside the scope of UK SORA. Controlled area overrides all density calculations. A UA weighing less than or equal to 250g and having a maximum speed less than or equal to 25 m/s is considered to have an iGRC of 1 regardless of population density.

6.3 Population Density Overrides

An operator may declare a lower maximum density where operational circumstances justify a figure lower than the calculated result. An override requires mandatory written justification. The platform records both the calculated density and the declared density; both values and the justification text are included in the assessment report.

Note: Dronedesk does not validate the sufficiency of operator justifications. The operator accepts full responsibility for the accuracy and applicability of any declared override.

---

7. Ground Risk Mitigation

7.1 Framework

UK SORA defines four strategic ground risk mitigations (AMC1 Article 11, Table 5): M1(A), M1(B), M1(C), and M2. The GRC credit available for each mitigation depends on the robustness level of evidence provided by the operator. N/A entries indicate that robustness level is not applicable for that mitigation.

The floor value of 1 ensures the residual GRC is never less than GRC 1.

Strategic Ground Risk Mitigations

AMC1 Article 11, Table 5 - GRC reduction depends on robustness of evidence provided

Within the Dronedesk assessment process, the operator selects which mitigations apply to their operation at the relevant step in the assessment flow. For each mitigation selected, the platform mandates a written justification or description of how that mitigation is achieved in practice. This justification is stored against the assessment and passed through in full to the final SORA report output, providing the auditable evidence required to support the claimed GRC reduction.

Note: Dronedesk does not validate the sufficiency or accuracy of operator justifications. The operator accepts full responsibility for the appropriateness of each declared mitigation.

See Annex B to Article 11 for additional details about the application of ground risk mitigations.

7.2 M1(A) - Strategic Mitigation: Sheltering

M1(A) (Sheltering) applies where people in the area are sheltered - for example, in buildings - such that the effective population density at risk is lower than the GHS-POP figure. GRC credit: Low robustness = -1; Medium robustness = -2; High robustness = N/A (sheltering effect is inherently limited).

A UA expected to not penetrate a standard dwelling will get a -1 GRC reduction in sheltering mitigation when not overflying large open-air assemblies of people.

7.3 M1(B) - Strategic Mitigations: Operational Restrictions

M1(B) (Operational restrictions) applies where strategic operational restrictions reduce population exposure - for example, restricting the operation to specific geographic areas, routes, or times of day that demonstrably reduce the population density. GRC credit: Low robustness = N/A; Medium robustness = -1; High robustness = -2.

7.4 M1(C) - Tactical Mitigations: Ground Observation

M1(C) (Ground observation) applies where a ground observer monitors the operational area and can halt or redirect the operation if people enter the FG. This is a tactical mitigation applied during flight. GRC credit: Low robustness = -1; Medium robustness = N/A; High robustness = N/A.

7.5 M2 - Effects of UA Impact Dynamics are Reduced

M2 applies where design or operational measures reduce the effects of UA impact dynamics - for example, a parachute, frangible structure, or kinetic energy limiter that reduces the severity of impact in the event of a loss-of-control event. GRC credit: Low robustness = N/A; Medium robustness = -1; High robustness = -2.

7.6 Residual GRC and Report Output

The assessment report includes a full mitigation table showing: each available mitigation, whether it was selected, the credit value applied, the operator's justification text (verbatim), and the resulting residual GRC.

---

8. Air Risk Assessment (ARC)

ARC Determination Flowchart

Based on AMC1 Article 11, Figure 5. Strategic mitigations may reduce final ARC subject to independent assessment.

8.1 Assessment Approach

The Air Risk Class (ARC) is determined by working through the UK SORA quantitative air risk flowchart (AMC1 Article 11, Figure 5), corresponding to Figure 19 above. The following inputs and decisions are presented to the operator in the Dronedesk assessment flow, in the order they appear in the flowchart:

Above FL660: The CV ceiling altitude is checked automatically against FL660. If the CV ceiling exceeds FL660, ARC assessment cannot be completed within UK SORA. The assessment is blocked and the operator is advised to contact the CAA directly at uksora@caa.co.uk for guidance. No further ARC, SAIL, or report generation steps are available until the operation is brought within scope.

Atypical air environment (AAE): The operator declares via a Yes/No radio button whether the operation takes place in an atypical air environment, for example a segregated volume with no other airspace users. This defaults to No and is not auto-detected from infrastructure proximity. A declaration of Yes results in an initial ARC of ARC-a and bypasses the airspace classification branch entirely. Mandatory written justification is required.

Airspace classification: The initial airspace class is determined automatically using OpenAIP data for the CV ceiling altitude. The system lists all airspace volumes intersecting the operational area with their associated floor (lower flight level, LFL), enabling the operator to review and amend the classification if required. Where the operational volume intersects multiple airspace classifications, the highest (most restrictive) ARC applies.

OpenAIP is a community-maintained data source and is not the authoritative UK airspace dataset. Operators are responsible for verifying the airspace classification against official UK airspace data sources prior to operation.

Cooperative traffic (Class D, below 500 ft AGL): Where the operation takes place in Class D airspace below 500 ft AGL, and the operator declares that all traffic in the operational area is known and cooperative (that is, ADS-B or Mode S equipped and visible to ATC), the initial ARC may be determined as ARC-b rather than ARC-c. This reflects the reduced collision risk where conflicting traffic can be positively identified and coordinated. This determination follows the case-by-case guidance at §1.121 of AMC1 Article 11. The operator is required to provide written justification demonstrating that the cooperative traffic assumption is valid for the specific operation, which in practice means evidence of ATC coordination confirming that non-cooperative traffic will not be present in the operational volume during the planned period.

VLOS tactical mitigation: A VLOS checkbox option is provided. If selected, the operator must choose one of three methods via radio button: Direct observation, Airspace observation, or UA observation. Selecting this tactical mitigation reduces the ARC by one step. The VLOS option is not presented where the initial ARC is already ARC-a (AAE) or where the outcome is out of scope (above FL660). Written justification is required.

8.1.1 Determination Logic

The following pseudocode documents the precise logic implemented in Dronedesk for ARC determination. It is included here for audit traceability and to support independent review of the implementation against AMC1 Article 11, Figure 5.

Inputs: CV ceiling altitude (derived from FG calculator), atypical air environment flag (operator-declared), airspace class (OpenAIP, operator-amendable), VLOS mitigation selection (operator-declared).

Outputs: final_arc (ARC-a through ARC-d, or OUT_OF_SCOPE), encounter_type (1 or 2, used for SAIL determination).

FUNCTION determine_arc(operation):

  // Step 1: FL660 check — automated from CV ceiling altitude
  // Terminal if exceeded. Blocks SAIL calculation.
  // Banner directs operator to contact CAA at uksora@caa.co.uk.
  IF operation.cv_ceiling_altitude > FL660:
    RETURN OUT_OF_SCOPE

  // Step 2: Atypical Air Environment (AAE)
  // Operator-declared, defaults to No.
  // Not auto-detected from infrastructure proximity (detection
  // is shown as a non-binding hint only).
  // AAE == Yes results in ARC-a — the floor — so VLOS is hidden
  // and not offered. Mandatory justification required.
  IF operation.atypical_air_environment == YES:
    REQUIRE operation.aae_justification NOT EMPTY
    initial_arc    = ARC-a
    encounter_type = 1
    GOTO step_vlos  // skip airspace class branch

  // Step 3: Airspace class branch
  // Pre-populated from OpenAIP. Operator may amend.
  // Override justification is mandatory only when the operator's
  // chosen class has a more permissive baseline than the auto-
  // detected class (i.e. baseline_arc[operator] < baseline_arc[detected]).
  // In practice this triggers only on A → anything else.
  IF operator.airspace_class != auto_detected_class
     AND baseline_arc[operator.airspace_class] < baseline_arc[auto_detected_class]:
    REQUIRE operation.airspace_override_justification NOT EMPTY

  SWITCH operation.airspace_class:

    CASE A:
      initial_arc    = ARC-d
      encounter_type = 2

    CASE C, D:
      IF in_known_IFPS:
        initial_arc    = ARC-d
        encounter_type = 2
      ELSE IF in_VFR_corridor:
        initial_arc    = ARC-c
        encounter_type = 1
      ELSE IF class == D AND below_500ft AND traffic_known_cooperative:
        // Operator must justify the cooperative traffic claim
        // with ATC coordination evidence (per §1.121).
        REQUIRE operation.cooperative_justification NOT EMPTY
        initial_arc    = ARC-b
        encounter_type = 1
      ELSE:
        initial_arc    = ARC-c
        encounter_type = 1

    CASE E:
      initial_arc    = ARC-c
      encounter_type = in_known_IFPS ? 2 : 1  // case-by-case per §1.124

    CASE F, G:  // Class F is treated as Class G
      initial_arc    = ARC-c
      encounter_type = 1

  // Step 4: VLOS tactical mitigation
  // Optional. UI hides this section when initial_arc == ARC-a
  // (i.e. when AAE == Yes), so in practice the floor below
  // always evaluates to ARC-b.
  LABEL step_vlos:

  IF operator.claims_vlos_mitigation:
    REQUIRE operation.vlos_method IN
      [direct_observation, airspace_observer, ua_observer]
    REQUIRE operation.vlos_justification NOT EMPTY
    floor     = ARC-b
    final_arc = MAX(reduce_by_one(initial_arc), floor)
  ELSE:
    final_arc = initial_arc

  RETURN final_arc, encounter_type


FUNCTION reduce_by_one(arc):
  // Floor is enforced by the caller, not here
  MAP = { ARC-d: ARC-c,  ARC-c: ARC-b,  ARC-b: ARC-a,  ARC-a: ARC-a }
  RETURN MAP[arc]

The pseudocode above reflects the implemented logic as of version 1.0. The Class C/D sub-branch conditions (IFPS, VFR corridor, cooperative traffic) are evaluated against OpenAIP data and operator inputs at assessment time. The encounter_type output is passed directly to the SAIL determination step.

8.2 Design Rationale - Non-Application of ARC Strategic Mitigations

ARC strategic mitigations under UK SORA require independent judgement to apply. Mitigations such as BVLOS communication requirements, detect-and-avoid capability, or coordination with an ANSP cannot be automatically verified by the platform. Automatically reducing ARC based on operator-declared mitigations without independent verification would misrepresent the risk assessment.

Dronedesk presents the ten available strategic mitigations for operator selection. Each mitigation can be selected individually. Any mitigation selected requires the operator to provide a written justification and explanation of how it is achieved in practice. These are passed through in full to the final report output. The operative residual ARC is not automatically reduced by these selections; that determination requires independent assessor judgement.

Code	Description
SM1	Operational restriction by boundary
SM2	Operational restriction by chronology
SM3	Operational restriction by time of exposure
SM4	Special Use Airspace (SUA)
SM5	Other airspace requirements
SM6	Pre-agreement of ANSP services
SM7	Pre-agreement of UTM services
SM8	NOTAM of intended operation
SM9	Military low flying notification
SM10	Outreach to local flying clubs and pilots

8.3 ARC Output

The assessment report includes: the initial ARC from the automated OpenAIP classification, the operator-confirmed or amended ARC with justification where amended, the VLOS tactical mitigation selection and justification where applied, and a list of available strategic mitigations for operator reference.

---

9. SAIL Determination

The Specific Assurance and Integrity Level (SAIL) is determined by cross-referencing the final (residual) GRC with the final ARC, using the UK SORA SAIL determination table (AMC1 Article 11, Table 6).

9.1 Inputs

• Final GRC: The residual GRC after all applicable M1 and M2 mitigations have been applied (Section 7.6).
• Final ARC: The operator-confirmed ARC from the air risk assessment (Section 8.3).

9.2 SAIL Lookup

The SAIL is read directly from the UK SORA SAIL determination table. The output ranges from SAIL I (lowest assurance requirement) through SAIL VI, or the Certified category.

SAIL Determination Matrix

Per AMC1 Article 11, Table 6. C = Certified category.

9.3 Report Output

The assessment report includes the full SAIL determination: the final GRC, final ARC, and the resulting SAIL level. Associated Operational Safety Objectives (OSOs) are noted for operator reference.

---

10. Report Generation

10.1 Report Structure

• Sections 1-4: Operation details, drone parameters, pilot information, location
• Section 5: Flight geography geometry and KML export
• Section 6: Population analysis metrics table (maximum density method, cell centre count, kernel radius/area, calculation timestamp)
• Section 6.1: Assemblies of people
• Section 6.2: Population density overrides (where applicable)
• Section 7: Ground risk determination (iGRC table, selected mitigations with justifications, residual GRC)
• Section 8: Air risk determination (initial ARC, override if applicable, strategic mitigations list)
• Section 9: SAIL determination
• Appendix A: Calculation methodology (textual description)
• Appendix B: Data sources and references
• Appendix C: Per-sample kernel audit data (first 50 rows inline; full dataset via CSV download)

10.2 Audit Trail

• All user-entered information will be displaying in bold blue text to make it easily distinguishable.
• Per-sample kernel table: sample centre coordinates, populated neighbour count, raw population sum, neighbour cell area, area coverage fraction, coverage area, population-weighted coverage fraction, kernel weighted population, kernel density, is-maximum flag.
• Per-cell weighted table for people count and average density.
• All operator-declared overrides: declared density values and justification text (verbatim).
• All mitigation selections: credit values and justification text (verbatim).
• ARC assessment: automated classification, operator amendment and justification where applicable.
• CSV exports: full per-sample and per-cell datasets available for download for independent verification.

10.3 Report Delivery

The assessment report is generated as a PDF document via headless Chromium (api2pdf / Puppeteer). Map tiles in the report are rendered using MapTiler vector tiles. The report is a point-in-time document; recalculation is required if any parameter or geometry is subsequently changed.

10.4 Report Generation Contexts

• Authenticated session: Full SORA assessment with CSRF-validated data. All assessment data is retrieved from the operator's session and the platform database.
• Headless export path (job_export): Used for PDF generation by the headless Chromium renderer. SORA feature entitlement is validated server-side.

---

11. Known Limitations and Planned Development

12.1 ARC Strategic Mitigations

As described in Section 8.2, ARC strategic mitigations are presented for reference only. This is a deliberate design decision. There are no current plans to implement automatic ARC mitigation credit computation, as this would require verified operator capability declarations that cannot be automated.

12.2 Population Data Currency

GHS-POP uses epoch averaging and does not reflect rapid population change, intra-day variation, or transient gatherings. Operators are responsible for applying appropriate judgement on the applicability of automated figures to their specific operation and timing.

12.3 Assemblies of People Data

OpenStreetMap coverage is not guaranteed to be complete for all venue types or geographic areas. Temporary assemblies are not captured. Operators must conduct manual assessments where OSM coverage may be incomplete and for all temporary gatherings.

12.4 Annex F Section 3.9.1 Methodology

The sliding-window kernel methodology for maximum population density is an application of JARUS Annex F Section 3.9.1 guidance. Its adoption has been discussed and agreed with the UK SORA assessment team.

12.5 Kernel Radius - Minimum Value and Configurable Angle

A minimum kernel radius of 100 m was discussed and agreed with the UK SORA assessment team. This minimum applies only to operations below approximately 58 m AGL.

The use of a configurable angle θ - allowing operators to use a site-specific angle of inclination in place of the 30° Annex F default - was considered and deferred. The current version uses θ = 30° as a fixed value, ensuring a consistent, auditable methodology.

---

Appendix A: Calculation Methodology

This appendix provides a textual description of each calculation performed in the SORA workflow. All formulae are consolidated in Appendix E.

A.1 Zone Definitions and Geometry

All zone boundaries are computed as geodesic buffers of the operator-defined FG polygon, using Turf.js (turf.buffer) with WGS84 ellipsoidal geometry. The CV outer boundary is at FG edge + CV distance. The GRB outer boundary is at FG edge + CV distance + GRB distance. The AV outer boundary is at FG edge + CV distance + AV distance. All buffer distances are in metres.

A.2 Cell Area Calculation

Each GHS-POP grid cell is treated as a polygon defined by its four corner coordinates in WGS84. The area of each cell polygon is computed using turf.area(), which implements the geodesic (ellipsoidal) area formula. Cell areas vary with latitude; at UK latitudes a 3 arc-second cell is approximately 4,500-5,800 m².

A.3 Cell-Polygon Intersection

The intersection of a cell polygon with a zone polygon is computed using turf.intersect(). The area of the intersection polygon is computed using turf.area(). All intersection calculations use WGS84 geodesic geometry.

A.4 People Count and Weighted Population

For each GHS-POP cell intersecting the FG+CV zone, the coverage fraction is the intersection area divided by the full cell area. The weighted population contribution is the raw cell headcount multiplied by the coverage fraction. The total people count is the sum of all weighted contributions. Average density for the FG+CV zone is the total weighted population divided by the total zone area, scaled to ppl/km².

A.5 Maximum Population Density - Kernel Method

The kernel radius is r = max(100, z / tan(30°)), where z is the FG ceiling height in metres AGL. Every GHS-POP cell wholly within or whose polygon crosses the FG+CV+GRB zone boundary is evaluated as a cell centre.

For each cell centre, the kernel circle is clipped to the zone polygon; the resulting area is the denominator. For each neighbouring cell within radius r, the overlap of the cell polygon with the zone polygon is computed and the coverage fraction applied to that cell's raw population. The kernel density is the sum of all weighted neighbour contributions divided by the clipped kernel area. The maximum kernel density across all cell centres is the reported maximum population density.

A.6 Average Density

The average density for the AV doughnut zone: each cell's intersection with the outer boundary polygon is computed, then the inner boundary polygon subtracted to give the net intersection area. Coverage fraction = net intersection area / full cell area. Average density = sum of weighted populations / total doughnut zone area (outer polygon area minus inner polygon area, computed geodesically), scaled to ppl/km².

---

Appendix B: Glossary

Term	Definition
ARC	Air Risk Class. Describes the level of air traffic risk associated with a UAS operation, ranging from ARC-a (lowest) to ARC-d.
AV	Adjacent Volume (also referred to as Adjacent Area in UK SORA documentation). The zone beyond the GRB used for average population density assessment.
COG	Cloud-Optimised GeoTIFF. A GeoTIFF format optimised for efficient partial reads over HTTP, enabling on-demand tile fetching.
Coverage fraction	The ratio of the intersection area of a cell polygon with a zone polygon to the full area of the cell.
CV	Contingency Volume. The zone immediately surrounding the FG, entered when a contingency procedure is triggered.
Dispersion area	The circular ground footprint within which a UAS could impact following a loss-of-control event at a given altitude, modelled per JARUS Annex F Section 3.9.1.
FG	Flight Geography. The operator-defined volume within which the UAS is intended to operate under normal conditions.
GHS-POP	Global Human Settlement Population Grid. A population raster dataset produced by the European Commission Joint Research Centre.
GRC	Ground Risk Class. A measure of the risk of harm to people on the ground from a UAS operation.
GRB	Ground Risk Buffer. The zone beyond the CV within which the aircraft is expected to land following a loss-of-control event.
iGRC	Intrinsic Ground Risk Class. The GRC determined from the maximum population density and UAS parameters, before mitigations are applied.
Kernel density	The population density computed for a given cell centre using the sliding-window kernel method: kernel weighted population divided by the clipped kernel area.
M1(A), M1(B), M1(C), M2	UK SORA strategic ground risk mitigations (AMC1 Article 11, Table 5). GRC credit depends on robustness level: M1(A) (Sheltering) -1/-2/N/A; M1(B) (Operational restrictions) N/A/-1/-2; M1(C) (Ground observation) -1/N/A/N/A; M2 (Impact dynamics) N/A/-1/-2.
OSO	Operational Safety Objective. A requirement associated with a given SAIL level.
OV	Operational Volume. The union of the FG and CV (FG+CV).
SAIL	Specific Assurance and Integrity Level. Determined by cross-referencing the final GRC with the final ARC.
SORA	Specific Operations Risk Assessment. The risk assessment framework for UAS operations in the Specific category.
Weighted population	The population contribution of a cell to a zone calculation: raw cell headcount multiplied by the coverage fraction.

---

Appendix C: References

C.1 Regulatory and Technical References

Reference	Details
UK SORA	AMC1 Article 11 - Conducting a UK Specific Operations Risk Assessment. UK Civil Aviation Authority. regulatorylibrary.caa.co.uk
JARUS SORA v2.5 Annex A	Guidelines on collecting and presenting system and operation information for a specific UAS operation. JARUS doc_26, June 2024. jarus-rpas.org
JARUS SORA v2.5 Annex F	Specific guidance for the ground risk model. Section 3.9.1: Sliding-window kernel for maximum population density. JARUS doc_29, June 2024. jarus-rpas.org
GHS-POP R2023A	Schiavina, M., Freire, S., Carioli, A., MacManus, K. (2023): GHS-POP R2023A - GHS population grid multitemporal (1975-2030). European Commission, Joint Research Centre (JRC). doi:10.2905/2FF68A52-5B5B-4A22-8F40-C41DA8332CFE
OpenAIP	Community aviation data platform. Airspace classification data. openaip.net
OpenStreetMap / Overpass API	OpenStreetMap community geographic data. Overpass API query interface. overpass-api.de
Turf.js	Advanced geospatial analysis for browsers and Node.js. Used for all polygon geometry and area calculations. turfjs.org
georaster	Parse and query GeoTIFFs in-browser. Used to access GHS-POP raster data. github.com/geotiff/georaster

C.2 Data Sources

Data Layer	Source	Details
Population Density	Copernicus GHS-POP R2023A	Global Human Settlement Population Grid (R2023). JRC, European Commission. Epoch: 2025. Resolution: 3 arc-seconds (~56 x 92 m at lat 52.8°). Coord. system: WGS84.
Assemblies of People	OpenStreetMap / Overpass API	Overpass query targeting: leisure=stadium; building=stadium; amenity~events_venue|conference_centre|exhibition_centre; leisure~horse_racing|dog_racing; landuse~recreation_ground|fairground; amenity~showground|fairground; leisure=track + sport~motor|karting; highway=raceway.

C.3 Methodology Lookups

Method	Source	Details
Max Density Kernel Method	JARUS SORA v2.5 Annex F, Section 3.9.1	Sliding-window kernel for maximum population density. Dispersion radius per equation (21): r = z / tan(30°), minimum 100 m. JARUS doc_29, June 2024.
Flight Geography Calculations	JARUS SORA v2.5 Annex A, Section A.5	Guidelines on system and operation information for a specific UAS operation.
iGRC Determination	AMC1 Article 11 (UK SORA), Table 3	iGRC determination table.
Ground Risk Mitigations	AMC1 Article 11 (UK SORA), Table 5	Strategic ground risk mitigations.
ARC Determination	AMC1 Article 11 (UK SORA), Figure 5	Quantitative air risk flowchart.
ARC Strategic Mitigations	AMC1 Article 11 (UK SORA), Annex C	GM1 strategic mitigation collision risk assessment.
SAIL Determination	AMC1 Article 11 (UK SORA), Table 6	SAIL determination matrix.

---

Appendix D: Worked Examples

All examples use synthetic data and coordinates, designed to illustrate the calculation methodology clearly. No real operational data is used.

D.1 Point Geography Operation - End-to-End Walkthrough

D.1.1 Inputs

Parameter	Value
FG geometry	Polygon, approximately 500 m × 400 m (synthetic coordinates)
FG ceiling height (z)	120 m AGL
CV distance	100 m
GRB distance	100 m (cumulative from FG: 200 m)
AV distance	500 m (cumulative from CV outer: 600 m from FG)
UAS characteristic dimension	3 m
UAS maximum speed	35 m/s
GHS-POP (synthetic)	Maximum populated cell in FG+CV+GRB: 3 people; zone population: 47 people

D.1.2 Maximum Density - Kernel Calculation

Kernel radius: r = max(100, 120 / tan(30°)) = max(100, 207.8) = 208 m.

For the maximum cell centre (synthetic): 3 people in contributing cells after proportional boundary weighting; clipped kernel area = 0.118 km² (circle extends beyond GRB boundary).

D.1.3 iGRC Determination

Maximum density 25.4 ppl/km² falls in the "less than 50 ppl/km²" band. UAS: 3 m / 35 m/s. From AMC1 Article 11 Table 3: iGRC = 4.

D.1.4 Ground Risk Mitigation

Operator selects M1(B), credit = −1. Justification: "Operation planned for 06:00-08:00 on weekdays, outside school and commuter hours."

D.1.5 ARC and SAIL Determination

Automated OpenAIP classification: uncontrolled airspace, ARC-b. Operator confirms. Final GRC = 3, Final ARC = ARC-b. From AMC1 Article 11 Table 6: SAIL II.

D.2 Linear Corridor Operation

The methodology for a linear corridor operation is identical to D.1. The FG geometry is a buffered polyline rather than a closed polygon. Zone buffers are applied radially to the corridor boundary. The kernel algorithm evaluates all cells whose polygon intersects the FG+CV+GRB zone, producing an elongated zone along the route.

D.3 Kernel Density - Sample-Level Walkthrough

D.3.1 Synthetic Grid

A 5 × 5 synthetic GHS-POP grid (each cell 90 m N-S × 60 m E-W). Columns are labelled A-E and rows 1-5. The FG+CV+GRB zone polygon covers cells B1-D3 (GRB outer boundary, red dashed). The kernel circle (r = 139 m) is centred on the peak cell C2.

D.3.2 Kernel Parameters

z = 80 m AGL. r = max(100, 80 / tan(30°)) = max(100, 138.6) = 139 m.

D.3.3 Sample Point Evaluation (centre cell)

Cell centre C2 (population = 5) is the peak cell. The kernel circle (r = 139 m) is centred here.

1. Clip kernel circle (r = 139 m) to zone polygon: clipped area = 0.058 km² (circle extends outside zone on two sides).
2. Neighbour cells within r = 139 m: B1, C1, D1, B2, C2, D2, B3, C3, D3 (the GRB zone).
3. Coverage fractions:

• B1: population 0 - excluded (zero population).
• C1: population 2, coverage fraction 0.85 (straddles top boundary) - contribution = 2 × 0.85 = 1.70.
• D1: population 0 - excluded.
• B2: population 1, coverage fraction 1.00 (wholly inside) - contribution = 1.00.
• C2: population 5, coverage fraction 1.00 - contribution = 5.00.
• D2: population 1, coverage fraction 1.00 - contribution = 1.00.
• B3: population 0 - excluded.
• C3: population 3, coverage fraction 1.00 - contribution = 3.00.
• D3: population 0 - excluded.

This process repeats for all cell centres. The maximum across all cell centres is reported.

---

Appendix E: Consolidated Formulae

All formulae referenced in this document. All areas in m² unless stated otherwise; densities in ppl/km².

E.1 Flight Geography Calculator

E.1.1 Contingency Volume (4.6.3)

E.1.2 Ground Risk Buffer (4.6.4)

E.1.3 Adjacent Volume (4.6.5)

E.4 Zone Geometry

E.4 Cell Area

E.5 Coverage Fraction

E.6 Weighted Population

E.7 People Count (FG+CV)

for all cells i whose polygon intersects the FG+CV zone

E.8 Average Density (FG+CV and AV)

where A_zone = full zone area including zero-population cells (m²)

E.9 Dispersion Radius (Annex F Equation 21)

where z = FG ceiling height (m AGL), θ = 30° (fixed per Annex F)

E.10 Clipped Kernel Area

E.11 Kernel Weighted Population

for all neighbour cells n where:

• distance(sample_centre, cell_centre_n) ≤ r_kernel, AND
• cell_polygon_n intersects zone polygon (f_coverage > 0)

E.12 Kernel Density

for each cell centre s

E.13 Maximum Density

for all cell centres s wholly within or crossing the FG+CV+GRB zone boundary

E.14 Residual GRC

E.15 SAIL

---

Appendix F: Video Walkthrough

The following video provides a complete end-to-end walkthrough of the UK SORA workflow in Dronedesk, covering every step from flight geography design through to SAIL determination and report generation. It is intended as a companion to this document for drone operators completing their own assessments, instructors and trainers, and consultants reviewing assessments on behalf of clients.

Video available at: https://youtu.be/2cjTKsnYHww

Topics covered in the video:

• Drawing and configuring the Flight Geography (FG), Contingency Volume (CV) and Ground Risk Buffer (GRB)
• Automated population density assessment using Copernicus GHS-POP data and the JARUS Annex F sliding-window kernel method
• iGRC determination from AMC1 Article 11 Table 3
• Air Risk Class (ARC) assessment including airspace classification, atypical air environment declaration and VLOS tactical mitigation
• SAIL determination and strategic ground risk mitigation selection
• Generating and exporting the completed SORA report

— END OF DOCUMENT —