What is TerraGear?

The problem it solves

Scenery generation is the job of turning survey data into something a flight simulator can draw, and it exists because nobody models a planet by hand. The data already exists: elevation surveys, coastlines, land cover classifications, airport layouts, but it exists as GIS data, which a rendering engine cannot draw.

TerraGear is the bridge. The FlightGear wiki describes it as “a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations”; concretely, it reads published survey data and writes the tiled 3D terrain FlightGear loads. It is the tool the project’s own scenery is built with.

Its output is a directory of .btg.gz files laid out in FlightGear’s bucket scheme. One degree square of the San Francisco Bay becomes 32 tiles and 44 of those files; see the gallery for what that looks like.

What it reads

• DEM terrain grids; elevation samples on a regular grid.
• 2D polygon data sets; coastlines, city outlines, lake outlines.
• 2D raster data sets; such as the 1 km NOAA land use and land cover data.
• FAA data; used to generate airports, runways and lighting.

That is the whole job. See the gallery for how the same view looks with no scenery at all, which is what FlightGear shows for anywhere TerraGear has not been run.

What it produces

Terrain, tiled to FlightGear’s scheme, with land cover applied and airports in place. The process runs in two distinct stages, and understanding the split explains most of what you will encounter later:

1. Preprocess. Raw source data is chopped up into FlightGear’s tiling scheme and saved in a simple intermediate format. Each kind of input (elevation, airports, land cover) is prepared separately.
2. Construct. Everything prepared so far is resolved into one surface, tile by tile, and written out in the form FlightGear loads.

This is why a TerraGear build is not a single command. You run several tools in sequence, each responsible for one kind of data, and only the last one produces scenery.

Why build your own scenery?

FlightGear ships with scenery, and most people never need more than that. The original terragear.org gave four reasons to build your own, and three of them still hold:

• Data the default scenery does not have. Roads, rivers, a lake that is missing, a coastline that is wrong.
• A new airport, or a better one. If you know a field well enough to notice what is wrong with it, you can rebuild it.
• Features that have not reached the released scenery yet. The tools move ahead of the published tiles; runway lighting was the example given in 2004, and the pattern repeats.
• A slow connection; download the source data once and rebuild locally rather than re-downloading tiles every time they change. This one has aged: scenery downloads are no longer the bottleneck they were, and a land-cover build now moves more bytes than the tiles would.

To which a fourth can be added from building it today: it is a way to find out what your terrain is actually made of. A tile that looks wrong in the simulator is opaque; the shapefiles behind it are not.

What the project set out to do

TerraGear has a mission statement, written by Curtis Olson on 27 January 2000 and never published anywhere except the project’s own site. Four principles, and the second one still governs what you can do with what you build:

• Open source. The standalone tools are GPL; the rendering libraries meant to be linked into an application are LGPL.
• Free GIS data. Only source data that places no restrictions on derivative works, because the output has to be unrestricted. Processing restricted data with the tools imposes no extra terms on your result; but whatever the source data required still applies.
• 3D maps. Terrain, land use, rivers, land mass, roads, buildings, bridges, airports: preprocess the raw data, split it into manageable chunks, resolve the conflicts, combine it into something renderable.
• Real-time rendering. Detail and data sources chosen for simulators, explicitly not for photo-realistic ray tracing.

The second principle is why the data guide cares which licence a shapefile carries.

Scale and hardware

Cost scales with the ground you ask for and with how finely it is mapped. The warning in the repository is about the planet; one degree square finished in 37 seconds and used 11 MB; see Hardware and build times for the full measurements. For builds at the large end, the terrain builder can be run in parallel across a cluster of workstations.

Where the source lives

TerraGear is developed at gitlab.com/flightgear/terragear. A mirror also exists on GitHub; it is a mirror only, and it lags behind.