
Obstacle Limitation Surface Survey by Drone
The OLS survey is in active development and not offered yet. The register in two height datums, data sheet exports and approach surface warning are…
The protection surface over an approach is a plane, and the question is whether anything crosses it. The planned check flies an arc on that plane and aims along it, so any object breaking through cuts the sightline. In active development, not offered yet. Flight planning already warns of obstacles penetrating the Annex 14 approach surface.
Every picture below comes from an inspection we flew: drone frames, field photos and app screens. The brackets mark what the analysis reads.
4K frame from a PAPI flight on 9 Sep 2026, downscaled to 2880 px.
4K frame from a PAPI flight on 9 Sep 2026, downscaled to 2880 px.
This page is for the person who has to sign that the approach surface a crew relies on is clear, and knows that the last survey is a statement about the day it was made. It fits the operator closing out works near the approach, the manager of a regional aerodrome with woodland under the glide path, and the aerodrome that has just re-aimed its PAPI and moved the plane with it.
Two software pieces are built and one is in development, and each has a state you can check. None of them is sold as a service yet.
Obstacles in the register are tested against the Annex 14 approach surface, and a penetration shows as a warning when the flight is planned. This is the approach surface, not the PAPI obstacle protection surface.
Each obstacle has a polygon, a type, a height above ground and MSL and ellipsoid (HAE) heights, entered by hand, imported from OpenAIP or seeded from the Slovak eAIP. The register exports on the airport data sheet as JSON, CSV or PDF, and flight-plan KML can include obstacles as no-fly polygons.
A check against the PAPI's own obstacle protection surface, with a flown sightline for the objects no register contains, is in development. It is not available today.
A complete check tests the same surface twice, once against your survey data and once against what the camera sees. The first half exists today for the approach surface.

A protection surface is built for the runway direction from its own geometry: where the surface starts relative to the threshold, how wide its inner edge is, and how fast it diverges outward, using the ICAO Annex 14 values where the aerodrome has not published its own. Every registered obstacle is then tested against that solid: does its footprint fall inside the surface, and does its top break through the plane above it. Today TarmacView does this for the Annex 14 approach surface and shows the result as a flight-planning warning. Building the PAPI protection surface from the set angle is in development.

Survey data goes stale, which is the whole reason for a flight. The arc is flown at the altitude the plane reaches at that radius, with the camera locked on a safe point out on the extended centre line that sits on the same plane. That makes the sightline a physical sample of the surface: anything penetrating it passes in front of the camera rather than being inferred from a spreadsheet. Flying this for obstacles is in development and is not available today.
Each item with the state it is in today, and the standard values a PAPI protection surface check would use.
Registered obstacles tested against the Annex 14 approach surface and shown as a warning in flight planning. Not a report.
Per obstacle a polygon, a type, a height above ground and MSL and ellipsoid (HAE) heights, exported on the airport data sheet as JSON, CSV or PDF.
No object breaks through the obstacle protection surface for the runway direction, tested against the register and on a flown sightline.
The plane a PAPI protection surface check is run on, taken from a published value or derived from the published glide path.
Origin offset from the threshold, inner edge width and outward divergence of the PAPI protection surface.
A flown arc would sweep the sector either side of the runway axis rather than sampling the centre line alone.
Not available. Object heights are the registered values and are not measured from drone imagery.
The runway ends, threshold positions, published glide path and PAPI data go into TarmacView, with the obstacle register if one exists. Output is the geometry the surfaces are built from.
Obstacles are entered by hand, imported from OpenAIP or seeded from the Slovak eAIP, each with a polygon, a type, a height above ground and MSL and ellipsoid heights.
In flight planning every registered obstacle is tested against the Annex 14 approach surface. Output is a warning for each one that penetrates.
The airport data sheet carries the register as JSON, CSV or PDF, and flight-plan KML can include obstacles as no-fly polygons.
Building the PAPI obstacle protection surface from the set angle and testing the register against it is in development. It is not available today.
Flying an arc on the plane with the camera locked on a point that also lies on it, to find what no register contains, is in development. It is not available today.

Approach surface clearance warning beside the runway and the registered obstacles
A protection surface is a geometric object, and the honest way to check one is to construct it exactly and then test things against it. The surface for a precision approach path indicator starts near the threshold at a set width, diverges outward at a fixed rate and climbs at an angle a little below the glide path the units are set to. Annex 14 gives the dimensions by runway type and code, and the aerodrome may have published its own. A complete check builds the plane from those figures and from the runway’s own geometry and tests every object in the obstacle register against it as a computation. Anything that penetrates or comes within a margin is a candidate. Today that computation exists for the approach surface and appears as a flight-planning warning. The PAPI protection surface version is in development.
In a complete check, the flight is what turns the computation into evidence. The register contains what was surveyed on the day it was surveyed and nothing else, and obstacle clearance is lost to the things it does not contain: a season of growth, a mast that was not notified, a crane on a permit that expired. The arc is flown at the height the plane reaches at that radius, with the camera aimed at a point on the extended centreline that also lies on the plane, so the sightline itself lies in the surface. Anything rising through the surface between the two passes in front of the camera. That is a physical sample of the plane, not an inference from a spreadsheet. The flown half is in development.
Today the heights in the register are the values entered, imported or seeded, not heights measured from drone imagery, so the warning is only as good as the register.
Nor does the check cover the rest of the obstacle limitation surfaces around the aerodrome, the take-off climb, transitional, inner horizontal and conical surfaces that reach kilometres out. A whole-aerodrome evaluation is in development.
Three things can degrade the result, and each has an owner.
A flown sightline, once available, has to be read over two kilometres of approach, so haze, precipitation and low sun on the axis would stop the capture, and wind above the drone's limit would stop the arc. This does not affect the warning in flight planning.
The surface needs the published glide path, threshold and PAPI data, because a plane built on the wrong angle tests the wrong volume. Tower coordination and permission for land outside the aerodrome boundary also sit with the aerodrome operator.
A clearance statement is only as good as the surface it was made against. The approach surface warning uses the Annex 14 dimensions. A PAPI protection surface check would use the aerodrome's published dimensions or slope where they exist, and say which it used.

The OLS survey is in active development and not offered yet. The register in two height datums, data sheet exports and approach surface warning are…

Drone survey of non-aeronautical ground lights near an aerodrome, in active development and not offered yet. The app already plans the observation…

How an aerodrome shows its PAPI approach is unobstructed after works or tree growth. TarmacView's own check is in active development and not offered…
The approach obstacle clearance check is in active development and not offered yet. If you want to follow it or try it early at your aerodrome, tell us about the aerodrome, the runway ends and whether an obstacle register exists.