Google Earth Flight Path Visualization

By: Andrew Sarangan

This program can generate the scripts necessary for viewing a visual approach path on Google Earth. It allows a pilot to see what the terrain and runway looks like from the air prior to embarking on the flight.

Type the route in the following box to generate the kmz file (see instructions below). If you have Google Earth installed, double clicking on the kmz file will show the moving cockpit view.

The route is defined by waypoints separated by ground speeds (in knots). All turn will be made at twice the standard rate (6 deg/sec).

A waypoint is a point in 3D space. It requires a ground reference, as well as an altitude. Optionally, a vertical speed can also be specified. If no vertical speed is specified, the flight path will climb/descend at a continuous rate between waypoints. If a vertical speed is specified, the initial climb or descend will be at the specified rate, leveling off as necessary after reaching the specified altitude. If the specified vertical speed is smaller than the value required to reach the next waypoint, it will be ignored, and the minimum required rate will be used.

Waypoints can be specified using one of several keywords followed by a few parameters:

  • RWY is the start (or end) of a runway:
    • RWY:20:MGY:SFC specifies runway 20 at MGY. The last term, SFC, says the altitude is the ground elevation. Alternatively, TCA means threshold crossing altitude, which is 75 ft above the touchdown elevation.
    • RWY:04:I69:3000 specifies runway 4 (the leading zero is required) at I69 airport at an altitude of 3000 ft (MSL)
  • FIX is any fix in the FAA database.
    • A fix can be an airport code, navaid, an approach fix or an enroute fix.
    • Because some navaid stations share the same name as an airport, such navaids should be prefixed with the special character ^. For example, SFO would refer to the airport, whereas ^SFO would refer to the VOR station.
    • FIX:TALAC:2000,-500 specifies TALAC (which is a final approach fix) at an altitude of 2000 ft. The ‘,-500’ says to start the descent from the previous waypoint at 500 fpm to reach TALAC at 2000 ft.
  • RAD defines a waypoint at a specific radial & distance from a fix, airport or navaid.
    • RAD:180:2.0:DQN:5000 represents a point 2.0 miles from the DQN navaid at a radial of 180 deg (magnetic). This waypoint will be crossed at 5000 ft.
    • RAD:330:5.0:^ONM:8000,500 specifies a point 5 miles from the ONM VOR (instead of the airport ONM) at a radial of 330 (magnetic). Crossing altitude will be 8000 ft using an initial climb rate of 500 fpm.
  • RWP is Relative Waypoint. It defines the next waypoint relative to the previous waypoint.
    • RWP:250:2.0:5000 defines the next way point 2.0 miles on a radial of 250 (magnetic) from the previous fix. The crossing altitude will be 5000 ft.
  • FLY defines the next waypoint at a specified distance from the previous waypoint, on the same heading.
    • FLY:5.0:3000,500 defines the next waypoint 5.0 miles ahead on the current heading, with a crossing altitude of 3000 ft and a 500 fpm climb rate.
  • nGS defines the location where the glide slope from the runway intersects with the current altitude. n is the glide slope angle in degrees (it can be any integer value up to 9).
    • If the current altitude is 2000 ft, 3GS:20:MGY will locate the position such that the slope to runway 20 at MGY will be 3 deg.
  • TPL/TPR produces a  traffic pattern around any runway. TPL is left traffic and TPR is right traffic.
      • TPL:20:MGY:1.0:1000:800:100 will produce a left traffic pattern taking off from runway 20 at MGY and landing back at the same runway. The pattern width is 1.0 nautical miles, and the pattern altitude is 1000 AGL. The climb rate in the pattern is 800 fpm and the forward speed is 100 knots.
  • By default, all waypoints are treated as fly-by waypoints. It is possible to specify a fly-over waypoint. This can be done by including a ‘1’ in the last field of the waypoint description. For example, FIX:APE:5000:1 will make it a fly-over waypoint. Fly-over waypoints will require two turns – one to make the course change at the waypoint, followed by a second turn in the opposite direction to intercept the new course.


The following are some example routes. Simply download the KMZ files, or copy and paste these routes into the box above to see how it works.

  • Telluride, CO – Right hand pattern to Runway 9 – Youtube
    • TPR:09:TEX:0.75:1000:1200:100
  • Catalina Island, CA – Right hand pattern to Runway 22 – Youtube
    • TPR:22:AVX:0.75:1000:1200:100
  • Glenwood Springs, CO – Visual Approach to Runway 32 – Youtube
    • RAD:73.2:15.6:^RIL:10000 100 RWP:080:1:9000 100 RWP:100:1.5:8000 100 RWP:160:1:7500 100 RWP:150:1:7000 100 RWP:155:2.0:6800 80 RWP:150:1.0:6800 80 RWP:50:0.6:6500 80 5GS:32:GWS 80 RWY:32:GWS:6000
  • Aspen, CO – Roaring Fork Visual Approach to Runway 15 – Youtube
    • RAD:228:8:DBL:9000 200 RWP:120:3:9000 200 RWP:100:2.0:9000 200 RWP:140:1.5:8500 200 RWP:120:2.2:8000 200 5GS:15:ASE 200 RWY:15:ASE:7750
  • Washington, DC (DCA)- RNAV Approach to Runway 19 – Youtube
    • FIX:DARIC:2600 200 FIX:GREYZ:1700 200 FIX:SETOC:1500 200 FIX:FONVI:1214 200 FIX:JUBOL:955 200 FIX:WIRSO:480 200 FIX:FIROP:253 200 RWY:19:DCA:100

Notes:

  • The syntax must be followed exactly. Invalid entries will cause the script to crash, and it is not going to tell you why.
  • The first waypoint cannot be RWP, FLY or nGS. This should be obvious.
  • The second waypoint cannot be FLY.
  • Don’t use this for long routes. This program is primarily intended for final approach visualization. It generates the flight path by creating a large number of intermediate waypoints. Longer routes will require a lot more points, and may overload the server. The script will self-terminate if it takes longer than 30 seconds.
  • This is running on a single-board computer (similar to a Raspberry Pi) with limited memory and processing power.