SORA population density calculations: how to make sure your iGRC figures are accurate

Picture a SORA population density calculation for a corridor operation over mixed farmland. The GHS-POP data shows a single populated cell in the relevant area containing 2 people. The calculation returns 370 people per km². That figure feeds directly into your iGRC determination.

Does 370 ppl/km² sound right for a field with two people in it? That density would be unremarkable in a market town. Applied to an agricultural field, it suggests a level of ground risk that doesn't reflect what's actually there.

This isn't an obscure edge case. It's an outcome that can arise from a straightforward approach to processing population grid data, and it's worth understanding exactly why it happens. More usefully, JARUS Annex F describes a specific method for deriving population density that avoids the problem entirely.

Here's how the two approaches work, where they diverge, and what the correct method means for your iGRC calculations.

Where the 370 comes from

The population data behind most SORA tools is the GHS-POP dataset (Global Human Settlement Population Grid), produced by the European Commission's Joint Research Centre. It's peer-reviewed, publicly available, and widely used by researchers and regulators around the world. The data quality isn't the problem.

GHS-POP uses a 3 arc-second grid. At UK latitudes, that produces cells roughly 90m tall by 55–65m wide, each covering around 4,700–5,800 m² of ground. Each cell holds a headcount: the estimated number of people resident in that specific patch of terrain.

Converting those headcounts to a density figure has traditionally worked like this:

People per km² = (People ÷ Cell area m²) × 1,000,000

For a rural cell with 2 residents over an area of roughly 5,400 m²:

(2 ÷ 5,400) × 1,000,000 = 370 ppl/km²

The arithmetic is correct. The assumption isn't.

Single-cell extrapolation treats one small populated cell as representative of the entire surrounding km². In sparse areas, this dramatically overstates the true density.

By dividing a ~5,000 m² cell count and scaling it to 1 km², the method implicitly assumes that population density is uniform across the entire surrounding square kilometre. Those neighbouring cells, which in rural terrain will often be completely empty, don't factor into the calculation at all.

This matters particularly because iGRC determination uses the maximum population density within the FG+CV+GRB zone. A single high-count cell surrounded by empty ones will dominate that maximum, and the scaling from ~5,000 m² up to 1,000,000 m² amplifies it dramatically. The result can be a ground risk class that reflects a worst-case reading of one small patch of land, projected uniformly across a kilometre of surrounding terrain that may be completely uninhabited.

That's not the GHS-POP dataset being inaccurate. It's the method of extracting a density figure from it being wrong.

What JARUS Annex F says instead

JARUS published SORA v2.5 Annex F in June 2024 (JAR doc_29). Section 3.9.1, "Map resolution as a function of intended operating altitude," addresses this problem directly. 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 operating altitude.

The reasoning runs like this. When a UAS fails in flight, it doesn't fall vertically. It disperses laterally, and the extent of that dispersion scales with operating altitude. Annex F models this as a circle on the ground, using a 30-degree angle of impact as its geometric basis. That 30° figure sits midway between two established angles in the SORA framework: the shallow 10° glide angle used in critical area models, and the 45° angle used for lower-robustness GRB calculations.

The radius of the dispersion circle comes from equation (21):

r = z ÷ tan(30°),   minimum 100m

Where z is operating altitude AGL under normal conditions. At 120m AGL, a typical ceiling for UK commercial operations:

r = 120 ÷ tan(30°) ≈ 208m

A circle of radius 208m covers approximately 0.136 km² of ground.

Annex F equation (21) sizes the assessment kernel to the realistic lateral dispersion footprint of a UAS from its operating altitude, using a 30° angle of impact.

The logic from there is direct. If 0.136 km² represents the realistic impact footprint from that altitude, the population density figure used for iGRC should reflect the actual density across that area, not the contents of a single ~5,000 m² cell projected outward to fill a square kilometre.

One detail worth being precise about: Annex F defines z as "the altitude of the operation under normal operating conditions." In the SORA model, normal operations take place within the FG. The CV is entered only after a contingency procedure has been triggered, which is by definition an abnormal state. So z should be your FG ceiling height, not your CV ceiling height. Using CV altitude produces a larger kernel radius than Annex F intends, and treating that as a conservative measure isn't justified by the standard.

The sliding-window kernel in practice

The method that correctly implements the Annex F approach is called a sliding-window kernel. The name sounds complex. The process isn't.

For every GHS-POP cell centre that falls within the FG+CV+GRB zone:

1. Draw a circle of radius r centred on that sample point
2. Sum the populations of all cells whose centres fall within that circle and within the zone boundary
3. Divide that sum by the kernel circle area (πr²) to get a density in ppl/km²
4. Move to the next sample point and repeat

Do this across all sample points in the zone. The highest result is the reported maximum population density.

The zone boundary clipping in step 2 matters. SORA assesses population in the Adjacent Volume separately from the operation zone. Pulling population from outside the zone boundary into the kernel sum would double-count risk already addressed elsewhere in the framework. Clipping at the boundary prevents that.

The sliding-window kernel sums all populated cells within the dispersion radius, clipped to the zone boundary. The same 2-person cell that produced 370 ppl/km² contributes to a kernel density of 22 ppl/km².

Back to the 2-person rural cell. With the kernel applied at 120m AGL, you're no longer looking at that cell in isolation. You're summing everything within a 208m radius of each sample point across the zone. If the surrounding area within the zone contains a total of 3 people across all populated cells:

3 ÷ 0.136 = 22 ppl/km²

Not 370. A reduction of roughly 17-fold from the same underlying data.

That's not a marginal adjustment. Depending on where those figures fall on the iGRC table, a result like this could reduce your SORA ground risk class by one step, which changes what operational mitigations you need to demonstrate and how straightforward the authorisation pathway becomes.

Where does the kernel make the biggest difference? Not over dense urban terrain. In a city, populated cells fill the kernel in every direction regardless, and the result converges with the single-cell method. The meaningful improvement comes in semi-rural areas, suburban fringes, and corridor operations where a high-count cell sits alongside sparse or empty ground. That describes a large proportion of commercial operations in the UK.

Put another way: the single-cell method produces its least representative results precisely where population distribution is most variable. A farmhouse or a small industrial yard sitting among empty agricultural land is exactly that scenario.

Checking your methodology aligns with Annex F

The key question for any SORA population density figure is whether it reflects what JARUS Annex F describes. If your assessment was produced using the single-cell extrapolation method, it's worth understanding what difference the kernel approach would make. For operations over genuinely dense urban terrain, the gap is typically small. For rural, semi-rural, and corridor operations, it can be significant.

Where the kernel method produces a lower iGRC than a single-cell calculation, that lower figure is the more accurate one, grounded in the spatial scale that Annex F says is appropriate for the assessment. It's not a generous reading of the data; it's the right reading.

Dronedesk's SORA tools now implement the sliding-window kernel as standard across all assessments. Existing assessments can be regenerated to use the updated calculation, and the full methodology is documented in the report.

What's in the report

A population density figure is only useful to a CAA if you can explain how you derived it. That's historically been one of the more opaque aspects of a SORA submission, partly because the underlying methodology wasn't always surfaced in reports and partly because Annex F's guidance on the correct spatial scale was only formalised in the v2.5 release in June 2024.

Every Dronedesk SORA report now includes full documentation of the kernel method:

• Kernel radius and area in the Section 6 metrics table, calculated from your FG ceiling height per Annex F equation (21)
• Full methodology explanation with the JARUS Annex F, Section 3.9.1 citation in Appendix A.5, including the rationale for using FG height as z
• Per-sample audit table in Appendix C showing every cell centre evaluated, the kernel population sum at that sample point, and the resulting density, with the maximum highlighted
• CSV export of the full kernel dataset for operators who need to review or reproduce the calculation independently

If a CAA inspector asks how you arrived at your population density figure, you hand them the report. The source data, methodology, calculation, and complete audit trail are all there. You're not relying on "the tool said so."

Here's an example PDF report output.

Getting the methodology right

The sliding-window kernel isn't a clever workaround. It's what Annex F describes when you read Section 3.9.1 carefully and follow the reasoning through. Single-cell extrapolation is simpler to implement, but it can produce inflated results in sparse terrain by assuming population uniformity at a spatial scale the GHS-POP data doesn't support.

SORA v2.5 Annex F was published in June 2024, so some of this guidance is relatively recent. If your population density methodology predates it, it's worth confirming your approach aligns with what Section 3.9.1 now specifies.

Getting this right matters practically. A more accurate density figure means a more defensible iGRC determination. And a more defensible iGRC is exactly what you need when you're presenting a SORA to a CAA assessor who knows the framework well.

If you're building a new SORA, or reviewing an existing one for semi-rural or corridor operations, verify that your population density method accounts for the dispersion area at your FG altitude and that the derivation is fully documented. If whoever produced the assessment can't explain the methodology clearly, that's a gap worth closing before the submission reaches a CAA.

The method is there in Annex F. Making sure your assessment reflects it is the practical next step.