Resources for data designers ...
This page contains resources to help designers create accurate and efficient airport and navigation data for X-Plane.
X-Plane's data files are simple text files. But creating reliable, accurate content for those files requires:
- Access to the best tools to help build the data.
- Access to 'real-world' information sources to help model X-Plane's data.
- Knowledge of the 'real-world' concepts that the data describes . For example, it is helpful to be (or to have access to) an instrument-rated pilot to understand the nuances of ILS placement.
- Understanding of the data file formats.
- Knowledge of the techniques, tricks and tips that help create data that can be used most effectively and efficiently within X-Plane.
There are other resources available on the FAQ page of this web site, for data designers and for users..
Tools
World Editor (WED) is a free, open source tool that enables complex airport designs to be edited (for X-Plane 8.50 and later). It has been written by the X-Plane development team. All airport details can be seen with a CAD-like editor, and complex shapes and curves can be built to define taxiways, aprons, markings, lighting, along with many other airport features. WED is a complex tool and the learning curve is steep (but short). It allows background aerial images from Terraserver to be automatically downloaded and aligned under the airport design (USA only). Other images can also be sized, stretched and aligned manually as a background (eg. a screenshot from Google Maps, or a downloaded or scanned airport diagram).
TaxiDraw is a free tool that was developed to allow earlier versions of the airport data to be edited (prior to X-Plane 8.50). It is simple to use and allows basic taxiway layouts to be constructed within the constraints of the earlier file formats (all taxiways are built from overlapping, rectangular blocks). It allows background aerial images from Terraserver to be automatically aligned under the airport design (USA only).
Marginal's Overlay Editor (at X-Plane.org) allows objects to be placed into the X-Plane scenery, including buildings and other items at airports. Versions are available for Windows, Mac and Linux. It also allows overlays to be defined exclude roads and/or trees that may impinge upon your airport design in X-Plane. There is an active discussion thread for this tool at X-Plane.org.
The Aviation Formulary is a treasure trove of useful formulae used in aviation, usually explained in easy-to-understand terms.
A good text editor is often useful, to review and search the data files. For Windows, I recommend Notepad++. Amongst other features, it will convert files between Windows, Mac and Linux formats.
'Real-world' aviation data sources
X-Plane relies upon publicly-available, freely-available data sources. We cannot reverse-engineer proprietary databases and use that data. Of course, it is hard to find high-quality, global data that meet these criteria.
There are many sources of 'real world' aviation data, and each country often has its own process for maintaining and (perhaps) publishing its data. Some make their data freely available, but others regard this data as a valuable asset to which a high price is associated! Within the USA, data is available by subscription for a nominal fee from the FAA's National Flight Database (NFD), which we are planning to leverage for the US data in X-Plane.
Common sources of data are AirNav.com and World Aero Data. The National Aeronautical Charting Office (NACO) gives free access to all US airport and instrument approach charts (other sources offering the same data include AOPA, if you are a member). Many countries offer some kind on on-line access to their aviation data and/or charts - for example, the UK NATS site has detailed colour charts of all UK aerodromes.
Google Earth, Google Maps, Live Search Maps and TerraServer all have a role to play in airport design. Depending upon the imagery available, these tools can provide detailed aerial views of many airports. Ortho-rectification of the images is usually good, but remember to switch off any features that try to show 3D terrain (this can distort the images).
- Google Earth can be used to obtain latitude/longitude positions for many features (remember to set the format of the lat/lon to decimal degrees in the Tools/Options menu).
- The 'birds eye' view on Live Search Maps offers extremely detailed imagery - good enough in many cases so that taxiway signs can be read. But coverage is limited.
'Real-world' concepts
The US FAA has published standards for the design of airports:
- FAA Aeronautical Information Manual (a very important resource for any aviator).
- FAA AC on airport design (a large PDF file).
Magnetic variation: All X-Plane data that contains directional/heading information is defined as a true headings. But published data for localizers almost is always expressed on charts as a magnetic heading, so these need to be converted to a true heading for out data files to ensure correct alignment in X-Plane. But ... one 'gotcha' is that localizers (and other nav-aids) can be edited within X-Plane itself (on the map screen), and here the bearing is shown as magnetic (on the assumption that users may be trying to build an ILS based upon a real-world chart). The data will be automatically converted to a true heading when X-Plane saves the data.
Global data: X-Plane's data
coverage is global. Different countries often have different standards for the
definition and use of their aviation data.
- Many pilots who fly only within the USA believe that altimeters should always be switched from a local barometric setting to a standard setting (29.92 inches or 1013 hPa) when climbing through 18,000 feet (the Transition Altitude). But in many countries the TA is much lower, and may even vary within a country (it is usually printed on airport diagrams and approach charts). For example, the TA is at 3,000 feet over much of England, so it is normal for a VFR pilot to cruise at FL40.
- The UK and some other countries uses different types of runway markings - these are available in X-Plane, but must be explicitly selected in WED.
- Taxiway signs and painted markings are generally consistent around the world, but stylistic difference do exist.
Double check the units of measure: Many countries use a complex mix of metric and imperial units in aviation. The USA generally uses imperial units (but uses the Celsius scale for temperatures). Many other countries use metric units for all measurements, except for elevations (which are - usually - in feet). So, it's easy to look at an airport diagram and to forget to convert a measurement to the appropriate units for X-Plane. For example, X-Plane now requires all distances (such as displaced thresholds, blastpads) to be defined in metres in its data files, though elevations are still defined in feet.
Data file formats
The specifications of the file formats for X-Plane have evolved over time, usually to incorporate additional features that the sim now supports. Each file specification is given a version number (eg. 850) which refers to the X-Plane version for which this file specification was first valid (X-Plane 8.50 in this example). X-Plane maintains backwards compatibility with most file versions.
The X-Plane file specifications are in the process of being re-written into a more user-friendly format. Until that task is complete, here are links to the old-style file specifications. Links from within these pages may not work properly:
Airports: 850 Version
(latest - revised May 2009),
715 Version (expired)
Nav-aids: 810 version (latest
- revised July 2009),
740 Version (expired)
Fixes: 600 Version (latest
- revised July 2009)
Airways: 640 Version
(latest)
Astronomical: 740 Version
(latest)
A revision of the airport file specification is currently underway (9xx Version), with the goal of enhancing the features that can be added to an airport in WED and in X-Plane. If you have any requests for new airport features in the new file specification, please let me know as soon as possible.
Hints and Tips
The authors of WorldEditor (WED) have documented and illustrated some simple best practices for designing airports. Please follow their recommendations. Basic ideas here are:
Joining lines
Lines (painted lines or light strings) and taxiway pavement should always join at nodes, even if this means creating an extra node on an otherwise unbroken line to form the junction. This helps X-Plane's line-drawing algorithm guarantee that these lines will always meet without an ugly gap.
Overlaps
Be careful designing control nodes for Bezier curves to avoid unnecessary overlaps of lines where they join. This is especially important for taxiway pavement , where it is easy for a sloppily-placed Bezier control point to imply an internally overlapping edge - all pavement must be composed of 'simple' polygons (ie. none of the edges overlap each other). This is not allowed in X-Plane, and will cause the pavement not to be rendered in X-Plane.
It is common to see such unintentional overlaps where a designer creates a smooth 'fillet' to join a taxiway to a runway. The result is that the entire pavement section is invisible in X-Plane
Smooth curves
Minimize the use of nodes on curves. There is a temptation to add many nodes to force a smooth curve, but a single, carefully-placed Bezier control point will allow X-Plane to use its own algorithms to generate the best curve it can, to match the user's preferences set in the rendering options in the sim.
Straight edges
If you want to ensure that all the edges (or centre lines) of a long taxiways (that has multiple connections to other taxiways) are aligned, then create a temporary, dummy 'straight edge' as a line in WED against which the taxiway nodes can be aligned to ensure consistency. I usually assign the colour white to this temporary line - it contrasts well against the yellow colour of taxiway edge lines in WED. This temporary 'straight edge' can be deleted later. Temporary lines can also be used to ensure that all taxiway signs are spaced the same distance away from the taxiway to which they relate.
Airport boundaries
Always add an airport boundary polygon to your design in WED, similar to the pale orange outline in the screenshot of Seattle-Tacoma (KSEA) on this page. This is very quick and simple. The boundaries are not (yet) leveraged in X-Plane (eventually they might be leveraged to render an optional airport boundary fence), but they are used when new global terrain is generated - they enable our scenery generation algorithms to 'flatten' the appropriate airport terrain, and to apply appropriate land use textures.
Roads on airports
Many airports include public roads on their property. These are included in the separate road data for X-Plane and should not be modeled as part of the airport data. Internal airport roads can be modeled in the data - an example is the long access road (in white) down the centre of Seattle-Tacoma (KSEA) in the screenshot from WED on the right.
Taxiway signs
Taxiway signs have a highly-defined syntax that defines
their text. It is easy to make errors in these text
strings, and it is almost impossible to move around and view every
taxiway sign created within X-Plane. Taxiway signs with an
incorrect syntax are ignored in the sim and are logged in the log.txt file
in your X-Plane system folder. Please make it a habit to
check this file after testing new airport data, to identify and
correct any
'bad' taxiway signs.
Latitude & longitude formats
X-Plane stores all latitudes and longitudes as decimal degrees. Within aviation, many different formats are used. The following examples all refer to the same latitude:
- 50.500000 (as used in X-Plane. North and East are positive, South and West are negative)
- 50 30 00 N (50 degrees 30 minutes 0 seconds north of the equator)
- 50 30 00.00 (as above, but with extra decimal precision for the seconds - as seen on AirNav.com)
- 503000N (Often hard to identify. Could be decimal degrees skipping the decimal point, or degrees and decimal minutes, or ...)
X-Plane Airport & Navigation Data