---

1. Executive Summary

This document provides a comprehensive technical description of the JARUS 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 JARUS SORA v2.5 framework (JAR-DEL-SRM-SORA-MB-2.5, May 2024) as its primary regulatory basis. The flight geography calculator and zone boundary engine follow the JARUS SORA v2.5 Annex A methodology. For the determination of maximum population density, Dronedesk 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 JARUS 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 JARUS 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 JARUS 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 your NAA 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 methodological framework implemented in Dronedesk is JARUS SORA v2.5, as defined in the JARUS guidelines on Specific Operations Risk Assessment (JAR-DEL-SRM-SORA-MB-2.5, Edition 2.5, 13 May 2024). The JARUS Main Body specifies the methodology for assessing ground risk (GRC), air risk (ARC), and the resulting SAIL level for UAS operations in the Specific category. JARUS SORA v2.5 is published by the Joint Authorities for Rulemaking on Unmanned Systems and is the basis on which several national regulators have built their own operational authorisation frameworks.

Dronedesk implements the JARUS Main Body and supporting Annexes directly:

• Flight geography and zone boundary calculations: The Dronedesk flight geography calculator implements the JARUS SORA v2.5 Annex A methodology (JAR doc_26) 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) is applied to determine maximum population density.
• iGRC determination: JARUS SORA v2.5 Main Body, Section 4.2, Table 2.
• Ground risk mitigations: JARUS SORA v2.5 Main Body, Section 4.3, Table 5; Annex B.
• Air risk classification: JARUS SORA v2.5 Main Body, Section 4.4, Figure 6.
• SAIL determination: JARUS SORA v2.5 Main Body, Section 4.7, Table 7.

Operators using Dronedesk in jurisdictions that adopt or adapt JARUS SORA v2.5 are responsible for verifying any national variations or additional requirements set by their competent authority before submitting an operational authorisation application.

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 (spherical geodesic geometry, mean Earth radius 6,371,008.8 m)
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, including every GHS-POP cell, are computed using turf.area(), which calculates geodesic area on a sphere of radius 6,371,008.8 m (the mean Earth radius). Coordinates are WGS84. Distances between points are great-circle distances on the same sphere (turf.distance). Compared with the WGS84 ellipsoid, spherical areas are smaller at latitudes above about 35° (by about 0.38% at 52°), which makes densities slightly higher and therefore conservative, and larger below about 35° (by up to about 0.45% at the equator). Coverage fractions are unaffected, because the cell area and the intersection area are both measured on the same model.

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 EU 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 JARUS SORA v2.5: Flight Geography (FG), Contingency Volume (CV), Ground Risk Buffer (GRB), and Adjacent Volume (AV). JARUS Main Body Section 2.2 refers to the outermost zone as the Adjacent Area; Dronedesk uses the term Adjacent Volume (AV) consistently in its UI and reports, but the two terms are equivalent. 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 donut 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 JARUS 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 EU 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 EU 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 EU 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 mid-latitudes), the kernel converges towards single-cell behaviour. A minimum of 100 m ensures meaningful spatial averaging across at least the immediate 3x3 cell neighbourhood.

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). These rows were exported before version 1.3; exports from version 1.3 onwards show n/a in the Denominator and Coverage columns for any cell centre whose kernel population is exactly zero (Section 5.7.4).

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. For each neighbouring cell whose centre lies within radius r of the cell centre (great-circle distance, measured on the same Earth model used to draw the kernel circle): 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 coverage-weighted sum of these populations is the kernel population (the numerator).
   2. If the kernel population is greater than zero, 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. If the kernel population is zero, the density at that cell centre is zero whatever the denominator, so the clip is not performed and the denominator and kernel coverage are recorded as n/a (Section 5.7.4).

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. Rows whose kernel population is exactly zero show a density of 0 and n/a for the denominator and kernel coverage.

4. Compute kernel density: D_kernel = kernel_population_sum / clipped_kernel_area_km².
5. Record: store cell centre coordinates, neighbour count, kernel population sum, denominator and kernel coverage (n/a where the kernel population is zero), 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 JARUS Annex F

The sliding-window kernel method is a direct application of JARUS Annex F Section 3.9.1 guidance. It implements the approach Annex F prescribes for assessing maximum population density across the realistic dispersion footprint of the UAS, rather than reading a single GHS-POP cell value. Section 5.3.4 above derives the kernel radius from Annex F equation (21).

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. The denominator and kernel coverage are recorded as n/a where the kernel population is exactly zero (Section 5.7.4).
• This data is summarised in Appendix C of the assessment report: the number of cell centres evaluated, D_max, and the 50 cell centres with the highest kernel density, ranked highest first so the D_max row is always listed. The full dataset is available as a CSV download from within the platform (Section 5.6).
• 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 - Donut 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 donut 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 donut 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

JARUS SORA v2.5 Main Body Section 4.8.3 (Containment) requires that the presence of outdoor assemblies of people within 1 km of the operational volume outer limit is assessed. 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 JARUS containment thresholds in Tables 8 to 13: 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

Summary density metrics (maximum density, average density, people count, iGRC) are persisted for each Flight Geography, together with a stale flag and a compact audit summary for each zone.

The full per-cell and per-sample datasets are not persisted between browser sessions; for a large zone they can run to hundreds of thousands of rows. Instead, for each zone (FG+CV, FG+CV+GRB and AV) the audit summary records:

• the number of cells or kernel sample centres evaluated;
• the zone totals (raw population, weighted population and coverage area), summed over every cell;
• the maximum density, taken over every cell or sample centre;
• the 50 rows with the highest density, ranked highest first, so the row that determines D_max is always included.

The totals and maximum are computed from the complete dataset at the time of calculation, not from the 50 stored rows. The assessment report appendix (Section 10.1) is generated from this summary, so producing a report never requires the population to be recalculated. The full datasets used for CSV export are held in memory after a calculation; in a later session a CSV download recalculates them first, and the refreshed audit summary is saved at the same time.

Every result is stamped with the version of the calculation method that produced it, and the method version is shown in the assessment report. When a plan is opened, any result produced by an earlier method version is marked stale and recalculated automatically, in the same way as a Flight Geography whose geometry has changed. Locked plans are the exception: they are not recalculated automatically, because a locked plan cannot be changed. Their stored figures are shown with a warning that they come from an earlier method version, and the report is blocked, until the plan is unlocked and recalculated.

Flight Geographies last calculated before version 1.3 of this methodology have no stored audit summary. Their report shows the kernel parameters and D_max but no per-cell rows, with a note that the rows were not stored, until the Flight Geography is next recalculated.

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 for a Flight Geography cannot be generated while its stale flag is outstanding, whether because the geometry has changed or because its results come from an earlier method version.

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. Every optimisation in this section is exact: each one either determines which cells reach the expensive geometric operations, or skips an operation whose outcome cannot affect any reported value. None of them alters the zone polygon: every calculation uses the zone geometry exactly as generated from the flight geography and buffer distances. Section 5.7.6 describes how cell areas and kernel distances are measured, Section 5.7.7 how the calculation was verified against an independent reference, and Section 5.7.9 the accuracy corrections made in version 1.3.

Version 1.2 and earlier of this methodology described a gated simplification of the zone polygon (Ramer-Douglas-Peucker via turf.simplify, tolerance 0.0001°) applied to zones of more than 100 vertices and 25 km². That step could move the zone boundary by up to approximately 11 m, inwards or outwards, and so could change the coverage fraction and kernel denominator of cells near the boundary. It was removed in version 1.3. The AV shortcuts that shared its gate were made exact and now apply to every calculation (Section 5.7.5).

5.7.1 Bounding Box Pre-filter

Before any geometric test is performed on a cell, the cell's extent is compared against the zone polygon bounding box. If the whole cell lies outside the bbox, the cell is skipped without any turf call. This has zero accuracy cost: a cell lying entirely outside the bounding box cannot touch the polygon. Cells that straddle the edge of the bbox are kept, because they can overlap the zone. The pre-filter eliminates a significant fraction of cells for elongated or irregular zone shapes where the bbox is substantially larger than the zone itself.

5.7.2 Point-in-Polygon Sample Qualification

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. In the kernel calculation the cell polygon for this test is only constructed when it is needed, that is, for cells whose centre lies outside the zone.

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.3 Wholly-Inside Fast Path

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 cell lies entirely within the zone 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.4 Population-First Kernel Evaluation

For each kernel sample centre (Section 5.3.5) two quantities are needed:

• the kernel population K: the coverage-weighted population of the neighbouring cells within radius r;
• the clipped kernel area A: the area of the 64-vertex kernel circle after clipping to the zone polygon.

Computing A requires a full polygon intersection of the kernel circle with the zone polygon at every sample centre, which is the most expensive single operation in the calculation. The kernel density at a sample centre is:

K and A are independent: K depends only on the neighbouring cells and their coverage fractions, A only on the kernel circle and the zone polygon. Dronedesk therefore computes K first. Where K is greater than zero, A is computed exactly as before and D_kernel = K / A. Where K is exactly zero (no populated cell within radius r), D_kernel is zero whatever the value of A, so the clip is not performed.

This is exact, for three reasons:

• Zero numerator: a numerator of zero gives a density of zero for any positive denominator. The clipped area is always positive, because the minimum kernel radius (100 m) is larger than the half-diagonal of a GHS-POP cell, so the kernel circle always covers the qualifying cell's part of the zone.
• Maximum unaffected: D_max is the maximum over all sample centres and is never less than zero, so a sample centre with zero density can never determine it.
• Populated centres unchanged: for every sample centre with K greater than zero, the same operations run in the same order on the same inputs, so its numerator, denominator, coverage and density are bit-for-bit identical to the previous implementation.

The only visible difference is in the audit data. For sample centres with K = 0 the denominator and kernel coverage are recorded as n/a, because they were not computed, and the density is recorded as 0. The number of sample centres, their coordinates and every other field are unchanged.

The saving depends on how much of the FG+CV+GRB zone is unpopulated. In built-up areas almost every sample centre has populated neighbours and calculation time is essentially unchanged. Over water, moorland or sparsely populated land most sample centres have K = 0 and the clip is skipped for nearly all of them. In testing, calculations over sparsely populated zones ran between 6 and 18 times faster, and a wholly unpopulated zone completed almost instantly. A production flight geography over the sea, which previously took many minutes, showed the largest reduction.

5.7.5 AV Exclude Zone Optimisations

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 exact optimisations apply to every AV calculation:

• Wholly-excluded cells skipped: before any AV polygon test, a cell is skipped if it lies entirely inside the exclude polygon. This is tested with turf.booleanPointInPolygon on the cell centre, followed by turf.booleanContains on the whole cell. After the carve-out such a cell would have no remaining area, so skipping it gives the same result. Cells that straddle the CV boundary are not skipped; the part of each one that lies in the AV band is counted proportionally.
• Carve-out gate: the carve-out (turf.intersect / turf.difference) that subtracts the CV area from a cell is only performed for cells that turf.booleanIntersects confirms touch the exclude polygon. A cell that does not touch it has nothing to remove, so the result is the same.

Up to version 1.2 both shortcuts applied only to zones of more than 100 vertices and 25 km², and the first one skipped any cell whose centre fell inside the exclude polygon. That dropped the AV portion of cells straddling the CV boundary. From version 1.3 only cells lying wholly inside the exclude polygon are skipped, and both shortcuts apply to every calculation.

5.7.6 Cell Areas and Kernel Distances

• Cell area: each cell's area is measured from its own polygon with turf.area, the same function used to measure its intersection with the zone. A cell lying wholly inside the zone therefore has a coverage fraction of exactly 1.0, and every coverage fraction is a like-for-like ratio.
• Kernel neighbour distance: a neighbouring cell is included in the kernel when the great-circle distance between its centre and the sample centre, measured with turf.distance, is no more than r. This is the same Earth model that turf.circle uses to draw the kernel circle, so cell inclusion and the kernel denominator are consistent.
• Kernel search window: candidate neighbours are drawn from a window of cells around the sample centre. East-west the window is widened by 1 / cos(latitude), because a degree of longitude is shorter than a degree of latitude, and one extra cell is added on every side, so no cell within r is outside the window.

5.7.7 Verification

The calculation code was verified against an independent reference implementation, run outside the browser with the same Turf.js version. The reference evaluates the formulas in Sections 5.2, 5.3 and 5.4 directly, with none of the optimisations in this section:

• People count and AV density: every populated cell in the fetch window is intersected with the zone (and the CV removed for the AV), with coverage = intersection area / cell area, both from turf.area;
• Kernel density: every cell that touches the zone is a sample centre; its kernel population sums every populated cell whose centre is within r by turf.distance, with no search window; its denominator is the clipped 64-vertex kernel circle.

Test inputs covered rectangular, concave, long diagonal corridor and large complex zones; dense urban, rural, sparse, mixed (with no-data cells), very small and wholly unpopulated population patterns; kernel radii of 100 m to 350 m; and latitudes of 52.6°N, 60.2°N, 36.5°N and 33.9°S. For every case the number of cells or sample centres was identical, and the people count, average density, maximum density and every per-sample kernel density matched the reference to within floating-point rounding (relative difference below 10^-9).

The version 1.3 optimisations in Sections 5.7.4 and 5.7.5 were also checked by running the version 1.2 and version 1.3 code side by side: apart from the corrections in Section 5.7.9, results were identical, except that zero-population kernel rows show n/a for the denominator and coverage.

5.7.8 Accuracy Impact Summary

Optimisation	Applies to	Accuracy impact	Rationale
Bounding box pre-filter	All zones	None	Only cells lying entirely outside the bbox are skipped; such a cell cannot touch the polygon. Cells straddling the bbox edge are kept.
Point-in-polygon qualification	All zones	None	Boolean result is identical to checking for a non-null intersection. Boundary cells are still included via booleanIntersects.
Wholly-inside fast path	All zones	None	A cell fully contained by the zone polygon has no part outside it, so no intersection geometry is needed.
Population-first kernel evaluation	FG+CV+GRB (kernel)	None on any reported value	Where the kernel population is zero the density is zero whatever the denominator, and cannot set Dmax. Every populated sample centre is computed bit-for-bit as before. The denominator and coverage audit columns show n/a for zero-population rows.
AV wholly-excluded cell skip	AV	None	A cell entirely inside the exclude polygon has no area left after the carve-out. Cells straddling the CV boundary are still counted proportionally.
AV carve-out gate	AV	None	Cells not touching the CV boundary receive no carve-out, which is correct; their full area is within the AV band.

Cell areas and kernel distances (Section 5.7.6) are measured exactly with Turf.js functions rather than approximated, so they do not appear in this table.

No optimisation alters the zone geometry or 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.

5.7.9 Accuracy Corrections in Version 1.3

Verification against the independent reference (Section 5.7.7) identified the following departures from the documented method in version 1.2 and earlier. Each has been corrected. Except where noted below, their effect could only be to understate population figures.

Issue (version 1.2 and earlier)	Effect	Correction (version 1.3)
Bounding box pre-filter tested the cell centre	Cells straddling the edge of the zone's bounding box were skipped, so boundary cells on the zone's outermost sides were not counted and could not act as kernel sample centres. People count, AV density and maximum density could be understated; the effect is largest for small zones and where population lies at the zone edge.	The pre-filter tests the whole cell extent (Section 5.7.1).
Cell area estimated from a planar formula	Cell area was estimated once per zone at its mid-latitude using 111,320 m per degree, about 0.23% larger than the turf.area value at that latitude. Coverage fractions, people counts and densities were understated by about that proportion. For zones extending more than about 10 km north-south, the error grew towards the pole-ward end of the zone and could reverse (overstating slightly) towards the equator-ward end.	Each cell's area is measured with turf.area (Section 5.7.6).
Kernel search window too narrow east-west	The window used the same number of cells in both directions, but cells are narrower east-west. At larger kernel radii or higher latitudes, populated cells within r could fall outside the window and be missed, understating maximum density.	The east-west window is widened for latitude (Section 5.7.6).
Planar kernel distance	Neighbour distance used a planar approximation with 111,320 m per degree, inconsistent with the kernel circle.	Distance is measured with turf.distance (Section 5.7.6).
Zone polygon simplification and AV centre-in-CV skip	Simplification could move the zone boundary inwards or outwards by up to about 11 m; the AV skip dropped the AV portion of cells straddling the CV boundary, understating AV density (see Section 5.7 and Section 5.7.5).	Removed; replaced with exact optimisations.

Results calculated with an earlier method version are marked stale when the plan is next opened, and recalculated automatically unless the plan is locked (Section 5.6).

Recommendation for existing assessments

Assessments calculated before 12 October 2026 (method version 1.2 or earlier) may have understated population figures. We recommend recalculating and regenerating the report for any such assessment, particularly where:

• the operational volume is small;
• population lies near the outer edge of the Ground Risk Buffer;
• the FG operating height is above about 100 m AGL, or above about 80 m AGL at latitudes above 58°.

Opening the plan recalculates it automatically; a locked plan must be unlocked first. If the iGRC changes, review the assessment and any submission based on it.

---

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 JARUS SORA v2.5 iGRC determination table (Main Body, Section 4.2, Table 2).

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 (JARUS Main Body Table 2). 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

JARUS SORA v2.5 Main Body, Table 2 - grey cells (n/a) are outside the scope of SORA

Cells marked n/a represent combinations outside the scope of JARUS 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

JARUS SORA v2.5 defines four ground risk mitigations (Main Body, Section 4.3, 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

JARUS SORA v2.5 Main Body, 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 JARUS Annex B 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

JARUS SORA v2.5 Main Body, Figure 6. ARC reduction by strategic mitigations is subject to independent assessment.

8.1 Assessment Approach

The Air Risk Class (ARC) is determined by working through the JARUS SORA v2.5 ARC assignment process (Main Body, Section 4.4, Figure 6), 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:

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.

Above FL600: The CV ceiling altitude is checked automatically against FL600. Per JARUS Figure 6, operations above FL600 are assigned ARC-b. The operator may proceed with the remainder of the assessment.

Airport / heliport environment: Where the operational volume is in an airport or heliport environment, the airspace class is checked. If the operation is in Class B, C or D airspace, ARC-d is assigned; otherwise ARC-c.

Airspace classification: The 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 airspace dataset for any jurisdiction. Operators are responsible for verifying the airspace classification against the official airspace data sources of the competent authority prior to operation.

Altitude band, Mode-C Veil/TMZ, controlled airspace, urban or rural: For operations outside an airport / heliport environment and below FL600, the ARC is assigned by stepping through the altitude-banded sub-flowchart shown in Figure 19. The operator declares the operating altitude band (above or at/below 500ft AGL), then answers the Mode-C Veil/TMZ, controlled airspace, and uncontrolled-over-urban-area questions. The resulting ARC follows the path through the flowchart.

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. Per JARUS Main Body Section 4.5.4, the VLOS mitigation cannot be used to reduce the ARC to ARC-a, and is not presented where the initial ARC is already ARC-a (AAE). 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 JARUS SORA v2.5 Main Body Figure 6.

Inputs: CV ceiling altitude (derived from FG calculator), atypical air environment flag (operator-declared), airport/heliport environment flag (operator-declared, OpenAIP-supported), airspace class (OpenAIP, operator-amendable), Mode-C Veil/TMZ flag, urban/rural classification, VLOS mitigation selection (operator-declared).

Outputs: final_arc (ARC_a through ARC_d).

FUNCTION determine_arc(operation):

  // Step 1: Atypical Air Environment (AAE)
  // Operator-declared, defaults to No.
  // Not auto-detected from infrastructure proximity.
  // AAE == Yes results in ARC_a — the floor — so VLOS cannot
  // reduce it further. Mandatory justification required.
  IF operation.atypical_air_environment == YES:
    REQUIRE operation.aae_justification NOT EMPTY
    initial_arc = ARC_a
    GOTO step_vlos  // skip remaining airspace branches

  // Step 2: FL600 check — automated from CV ceiling altitude
  // Per JARUS Figure 6, operations above FL600 are ARC-b.
  IF operation.cv_ceiling_altitude > FL600:
    initial_arc = ARC_b
    GOTO step_vlos

  // Step 3: Airport / heliport environment branch
  // Operator-declared, supported by OpenAIP airport data.
  IF operation.in_airport_heliport_environment:
    IF operation.airspace_class IN [B, C, D]:
      initial_arc = ARC_d
    ELSE:
      initial_arc = ARC_c
    GOTO step_vlos

  // Step 4: Airspace class override consistency check.
  // Pre-populated from OpenAIP. Operator may amend.
  // If operator selects a less restrictive class than auto-detected,
  // mandatory written justification is required.
  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

  // Step 5: Altitude-banded sub-flowchart per JARUS Figure 6.
  // Operations <= FL600 and outside airport/heliport environments are
  // routed by altitude band, then by Mode-C Veil/TMZ, then by
  // controlled vs uncontrolled, then by urban vs rural.
  IF operation.altitude_above_500ft_agl:
    // High band: above 500ft AGL but at or below FL600
    IF operation.in_mode_c_veil_or_tmz:
      initial_arc = ARC_d
    ELSE IF operation.in_controlled_airspace:
      initial_arc = ARC_d
    ELSE IF operation.over_urban_area:
      initial_arc = ARC_c
    ELSE:                              // uncontrolled airspace over rural
      initial_arc = ARC_c
  ELSE:
    // Low band: at or below 500ft AGL
    IF operation.in_mode_c_veil_or_tmz:
      initial_arc = ARC_c
    ELSE IF operation.in_controlled_airspace:
      initial_arc = ARC_c
    ELSE IF operation.over_urban_area:
      initial_arc = ARC_c
    ELSE:                              // uncontrolled airspace over rural
      initial_arc = ARC_b

  // Step 6: VLOS tactical mitigation (Main Body §4.5.4)
  // Optional operator selection. Reduces ARC by one step but cannot
  // reduce to ARC-a. Not offered when initial_arc is already ARC-a.
  LABEL step_vlos:

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

  RETURN final_arc


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 reflects the implemented logic as of version 1.0. Inputs that depend on jurisdictional data (Mode-C Veil/TMZ flag, urban/rural classification, airport/heliport boundaries) are sourced from OpenAIP and operator inputs at assessment time. Operators should verify these against authoritative national datasets before operation.

8.2 Design Rationale - Non-Application of ARC Strategic Mitigations

Strategic ARC mitigations under JARUS SORA (Main Body Section 4.5; Annex C) 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 JARUS SORA v2.5 SAIL determination table (Main Body, Section 4.7, Table 7).

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 JARUS SAIL determination table. The output ranges from SAIL I (lowest assurance requirement) through SAIL VI, or the Certified category.

SAIL Determination Matrix

Per JARUS SORA v2.5 Main Body, Table 7. 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, calculation method version)
• 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-cell and per-sample audit data for each zone (count and totals over all cells, plus the 50 highest-density rows inline, ranked highest first; full dataset via CSV download)

10.2 Audit Trail

• 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. The kernel denominator and coverage are shown as n/a where the kernel population is exactly zero.
• 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 a direct application of JARUS Annex F Section 3.9.1 guidance. Operators in jurisdictions that adopt JARUS SORA v2.5 with national variations should confirm with their competent authority that the kernel approach is acceptable as the basis for the maximum density assessment.

12.5 Kernel Radius - Minimum Value and Configurable Angle

A minimum kernel radius of 100 m is applied to ensure meaningful spatial averaging across at least the immediate 3x3 GHS-POP cell neighbourhood. 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) on a spherical Earth model. 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 from that polygon using turf.area(), which calculates geodesic area on a sphere of radius 6,371,008.8 m. Cell areas vary with latitude; at EU 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 donut 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 donut 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. The zone beyond the GRB used for average population density assessment. JARUS SORA v2.5 Main Body Section 2.2.5 refers to this region as the Adjacent Area; Dronedesk uses the term Adjacent Volume consistently in its UI and reports, but the two terms are equivalent.
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	JARUS SORA v2.5 ground risk mitigations (Main Body, 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
JARUS SORA v2.5 Main Body	JARUS guidelines on Specific Operations Risk Assessment (SORA). JAR-DEL-SRM-SORA-MB-2.5, Edition 2.5, 13 May 2024. Joint Authorities for Rulemaking on Unmanned Systems. jarus-rpas.org
JARUS SORA v2.5 Annex A	Guidelines on collecting and presenting system and operation information for a specific UAS operation. JAR doc_26. jarus-rpas.org
JARUS SORA v2.5 Annex B	Integrity and assurance levels for the mitigations used to reduce the intrinsic Ground Risk Class. JAR doc_27. jarus-rpas.org
JARUS SORA v2.5 Annex C	Strategic Mitigation Collision Risk Assessment. jarus-rpas.org
JARUS SORA v2.5 Annex F	Theoretical basis for ground risk classification and mitigation. Section 3.9.1: Sliding-window kernel for maximum population density. JAR doc_29. 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. JAR doc_29.
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	JARUS SORA v2.5 Main Body, Section 4.2, Table 2	Intrinsic Ground Risk Class determination table.
Ground Risk Mitigations	JARUS SORA v2.5 Main Body, Section 4.3, Table 5; Annex B	Mitigations for Final GRC determination.
ARC Determination	JARUS SORA v2.5 Main Body, Section 4.4, Figure 6	ARC assignment process.
ARC Strategic Mitigations	JARUS SORA v2.5 Main Body, Section 4.5; Annex C	Strategic Mitigation Collision Risk Assessment.
SAIL Determination	JARUS SORA v2.5 Main Body, Section 4.7, Table 7	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 JARUS SORA v2.5 Main Body Table 2: 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 over rural area, below 500ft AGL, ARC-b. Operator confirms. Final GRC = 3, Final ARC = ARC-b. From JARUS SORA v2.5 Main Body Table 7: 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 JARUS SORA 2.5 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 the JARUS SORA v2.5 Main Body Table 2
• 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

Run this workflow yourself from as little as £67/mo

Complete your JARUS SORA 2.5 assessments in Dronedesk

Everything described in this document, from automated population density and iGRC through to ARC, SAIL and a ready-to-submit report, runs inside Dronedesk. Skip the spreadsheets and GIS tools and let the platform do the heavy lifting.

• Automated iGRC from Copernicus GHS-POP data and the JARUS Annex F kernel method
• Guided ARC and SAIL determination, fully documented
• One-click, audit-ready SORA report export
• Start on a free trial and upgrade only when you are ready

Start your free trial → Already have an account? Sign in

Start your free trial at https://dronedesk.io/pricing

— END OF DOCUMENT —