Airports

More than an
airport database.

VPT airports are built for performance — combining official aeronautical publications, runway data, obstacles, engine-failure procedures and Live Airport Updates into one continuously maintained database.

Database operational
—
Airports implemented
—
Obstacles in performance calcs
—
Engine-failure procedures
24/7
Automated runway monitoring

Airport data sourced in partnership with a professional aviation database provider trusted by real-world airlines

16 airports included. No credit card required.

Live coverage

Explore the VPT airport network.

Every dot represents an airport built and maintained specifically for aircraft-performance calculations. Search an ICAO code to see its coverage and monitoring status.

Why airport data matters

A runway is not just a length.

Declared distances, slope, intersections, obstacles, displaced thresholds, temporary restrictions and engine-failure procedures can all change the available aircraft performance.

Most airport databases are built for navigation. VPT's airport database is built for performance.

The foundation

Building the airport foundation

Every airport in our database started from a blank page.

The work begins with the Aeronautical Information Publication — the AIP — issued by the civil aviation authority of the country where the airport is located. This is the document that contains everything permanent and essential: airspace, navigation facilities, and airport data.

From the AIP, we extract the foundation:

  • ICAO and IATA codes
  • Official airport name
  • Reference coordinates and elevation
  • Magnetic variation and time zone
  • Operational airport information

Everything that follows — runways, obstacles, procedures, monitoring — gets attached to this base. What looks like a simple entry in a dropdown requires collecting and cross-checking dozens of data points before a single performance number can be produced.

— airports implemented
An Aeronautical Information Publication (AIP) page referenced when building an airport in VPT.
AIP source
Beyond a published length

Building the runway model

A runway is far more than its published length.

For each runway, we implement the declared distances — TORA, TODA, ASDA — along with threshold coordinates, QFU, both end elevations, slope calculations, pavement classification, and intersection data.

We also perform an operational review to determine which intersections should actually be available for departure input, and which ones would lead to unrealistic calculations.

Some airports require multiple variants of the same runway. A ship crossing the departure path. A crane installed mid-construction. Temporary displaced thresholds. Rather than overwriting the permanent data, we create parallel configurations so the pilot can select the one that reflects the current situation — and always depart on solid numbers.

— runways in the database
— runway intersections mapped
Obstacle analysis

A performance tool is only as good as its obstacle database.

We build that database in layers. It starts with terrain data scanned from multiple authoritative global providers — a first picture of what surrounds the airport. We then overlay AIP-published obstacles: trees, antennas, towers, cranes, and man-made structures as declared by the civil aviation authority of each country in their Aeronautical Information Publication.

The raw dataset is substantial. Across all airports, hundreds of thousands of individual obstacles are gathered and catalogued from these sources. Then the filtering begins: only the obstacles that geometrically intersect or come within defined safety margins of a departure or missed-approach path are retained in the performance engine. Those are the ones that truly shape a calculation.

Terrain. Buildings. Towers. Antennas. Cranes. Natural features. All gathered, all evaluated — only the impacting ones carried forward.

— estimated raw terrain & obstacle points processed
— impacting performance calculations
Obstacle analysis showing terrain, buildings and towers catalogued and evaluated against departure and missed-approach paths.
Obstacle analysis · EBCI RWY 24 — initial obstacles
Engine-out analysis at LOWS: multiple engine-failure trajectories sampled against terrain and thousands of obstacle points in 3D.
Engine-out trajectories sampled against real terrain and thousands of obstacle points — the analysis behind every engine-failure procedure.
What the analysis shows
  • Engine-out obstacle cone Area analysed for the Engine Failure Procedure
  • Terrain analysis Terrain points evaluated along the procedure
  • Obstacle points Published terrain and structures
  • Real terrain High-resolution 3D terrain data
  • Aircraft-dependent Analysis adapted to each aircraft and procedure
  • Safe procedures Obstacle clearance checked before implementation
Engine failure procedures

Why they exist — and how they're built

Obstacle clearance after an engine failure can limit takeoff weight more than runway length ever does. At many airports, flying straight ahead isn't possible or safe, so an Engine Failure Procedure is designed instead — an aircraft-specific escape route that can unlock weight a generic straight-ahead climb would leave on the table.

Designing one means studying the terrain, obstacles, navigation aids and the aircraft's own turn and climb performance, then running multiple scenarios — inside-turn, outside-turn, worst-case combinations — until every margin is met.

— standard procedures
— handcrafted procedures
Sometimes the best answer isn't the obvious one

At Princess Juliana Airport (TNCM), the ATR family faces two hills directly in the runway axis. The solution was counter-intuitive: deliberately shorten the published runway length so the Engine Failure Procedure cone begins earlier, enabling a turn that clears the terrain before it becomes a problem.

On larger aircraft, that early turn isn't possible. For the ATR, it unlocks significantly better performance — without compromising a single safety margin. Two aircraft, two different procedures.

active monitoring

Real people monitor the data. Every day.

A performance calculation is only useful if the data behind it reflects the current operational environment.

Performance data does not maintain itself.

For airports covered by Active Monitoring, the Provider's performance officers monitor operational publications 24 hours a day, 7 days a week — reviewing AIP amendments, AIP Supplements, NOTAMs, obstacle changes and other information that may affect takeoff or landing performance.

When a relevant change is identified, it is analysed and, where necessary, implemented into the VPT airport database.

This level of surveillance requires continuous specialist work for every airport covered. Active surveillance is therefore focused primarily on major airports and airports regularly used by airline operations, currently representing approximately 43% of the VPT airport database.

24/7 active monitoring
~3/day average database updates per day

AIRAC cycles

Every 28 days, new AIRAC publications can introduce changes to runway distances, airport configuration, obstacle data and procedures. Relevant performance changes at airports covered by Active Monitoring are reviewed by the Provider's performance officers and implemented into the VPT airport database.

AIP supplements

AIP Supplements can introduce significant temporary changes outside the normal AIRAC cycle — construction, displaced thresholds, temporary runway configurations, new obstacles and operational restrictions. These publications are reviewed when they may affect performance.

NOTAM monitoring

Thousands of NOTAMs are published every day. VPT combines automated filtering with human operational review to identify information that can affect aircraft performance and implement the necessary changes.

When a runway is affected, VPT does more than display an alert.

Where required, a temporary runway configuration is created with the relevant operational changes already applied. If a new obstacle affects an Engine Failure Procedure, the performance analysis is re-run across all applicable aircraft types.

The result is visible directly in the EFB: human-reviewed NOTAM changes become usable runway configurations, while runway closures are detected automatically from current NOTAM data.

KLAX runway status in VPT

Temporary NOTAM configurations and current runway closures are shown together directly in the runway selection.

Human-reviewed NOTAM changes

Performance-relevant NOTAMs are reviewed by the Provider's performance officers and, where required, implemented as temporary runway configurations.

Automated Runway Monitoring

VPT automatically identifies runway-closure NOTAMs, applies the active period and warns the pilot directly when a closed runway is selected.

Want an airport monitored?

Our Active Monitoring programme focuses on major and frequently used airports, where daily human surveillance brings the most value.

Need another airport covered? We can review requests, especially when they represent a virtual airline or larger community.

Request an airport
Automated runway monitoring

Live runway closure detection

Runway closures receive an additional, fully automated layer of real-time processing — complementing Active Monitoring above rather than replacing it.

VPT analyses runway-closure NOTAMs, including the abbreviated, ambiguous and context-dependent wording commonly found in NOTAMs. Our processing logic, supported by artificial intelligence, identifies affected runways, closure periods and partial restrictions.

  • Full-day closures Runways closed for the entire operating day.
  • Time-limited closures Closures active only during specific hours.
  • Complex closure schedules Recurring days such as MON WED FRI, specific calendar dates, or combinations of dates and times.

VPT evaluates the current date and time against the NOTAM schedule so the runway status reflects whether the closure is actually active at that moment.

24/7 automated runway monitoring
— runways currently closed by NOTAM

Runway closure monitoring applies to every VPT airport. It runs automatically and is independent of the active human monitoring programme.

Operational layers beyond the runway

Built for how pilots actually fly

Runway exits

We maintain a dedicated runway-exit database to help pilots anticipate vacating points, refine autobrake selection, and approach landing with a clearer plan. Custom internal tools accelerate collection, eliminate duplicates, and reverse-engineer takeoff intersection data into exit information for the reciprocal runway direction wherever possible.

— runway exits in the database

Missed approach climb gradients

Some approaches require a higher missed-approach climb gradient due to obstacles in the missed-approach path. Published minima reflect this — but lower minima sometimes exist for operators who can demonstrate the required climb performance. VPT maintains a growing MACG database to surface these cases, and users can submit airports for review.

— missed approach climb gradients implemented
Professional source data

Built on real-world aviation data.

To maintain this level of accuracy, VPT works with a professional airport database provider with more than 15 years of experience in aircraft performance software and database services. Their data supports airline performance operations worldwide. Under our confidentiality agreement, the company is referred to publicly as “the Provider.”

In commercial aviation, this type of airport data is supplied in structured formats for use by airline performance systems such as Boeing OPT and Airbus Flysmart. VPT takes the same professional source material and adapts it for simulation, adding its own performance-specific layers including runway exits, MACG analysis, AI-assisted runway closure detection and tools developed specifically for virtual pilots.

VPT is a flight-simulation tool. Regardless of the source of its data, it is not approved for real-world flight calculations.