How long does it take to build FlightGear scenery? The README says to expect “multiple gigabytes of disk space and days or weeks of crunching”. That is the figure for building the whole world, and it has scared off more first attempts than it has saved. One degree square containing a major international airport took 37 seconds and 11 MB.

Both numbers are true. Which one applies to you depends entirely on how much of the earth you asked for.

One measured build

N37W123: latitude 37 to 38 north, longitude 123 to 122 west. That square holds San Francisco Bay, and with it KSFO, KOAK, KPAO, KNUQ and 27 smaller fields. The elevation input was one SRTM 1-arc-second tile, 25.9 MB.

Wall clock and peak resident memory per stage, 10 cores.
Stage	Time	Peak RAM	Produced
`hgtchop`	2 s	29 MB	32 `.arr.gz`
`terrafit`	1 s	46 MB	32 `.fit.gz`
`genapts`	19 s	103 MB	31 airports
`tg-construct`	15 s	81 MB	44 `.btg.gz`
Total	37 s	103 MB	3.5 MB of scenery

The machine: 10 cores, 7 GB of RAM available to the container, Debian 12 under Docker. TerraGear next at commit eba49f2, SimGear release/2024.1, gcc 12.2, GDAL 3.6.2, CGAL 5.5.1.

Building the toolchain itself took another 36 seconds: 11 for SimGear headless, 20 for TerraGear, the rest configuring.

What drives build time

Area

This dominates everything else, and it is why the README’s warning and the table above can both be right. Data volume, tile count and airport count all scale with the square you asked for. One degree at this latitude is 32 tiles.

For a first build, take one degree. You want a build you can watch finish, and at 37 seconds you can.

How much of it is airports

Without land cover, the expensive stage was genapts, not tg-construct: 19 seconds against 15. That is not a general law: it reflects a square with 31 airports in it, including a major international one, and a square of empty countryside would invert the ratio. Add land cover and it inverts anyway: construction goes to 286 seconds and airports become a rounding error.

genapts does scan the entire apt.dat; all 34,074 airports, 106 MB of text; whatever your bounds. It is tempting to call that the fixed cost and stop there, and this page did. Measured against an empty bounding box, the whole scan is 0.55 s. The other 19 seconds were the airports themselves: KCCR alone took 2.05 s to build. The cost is per-airport, and a square of empty countryside pays almost none of it; seven airports in another square came to 1.5 s.

How much the terrain is doing

terrafit‘s job is to throw data away: it fits a surface to the raw elevation grid within an error tolerance. For this square it reduced 12,967,201 elevation posts to 15,828 fitted nodes, a ratio of about 818 to 1. Rough ground needs more nodes than flat ground, so a mountainous square costs more here and produces larger output than a coastal plain of the same size. Raising --maxnodes or lowering --maxerror buys accuracy with time and disk.

Land cover: by far the biggest lever

Everything above is second order next to this. Building the same square with ten land-cover layers instead of none multiplies the construction stage by 19× in time and 27× in memory: seconds become minutes, and 81 MB becomes 2.2 GB. The full before-and-after, including what happens to the output size and the vertex count, belongs with the stage it describes; tg-construct.

The decode itself is not the expense: ten layers took eight seconds. Nor is it the area. It is polygon count: every shape clipped against every other and against the mesh, so the sizing question is not “how big a region” but “how finely mapped”. A coarse source over a large area can cost less than OpenStreetMap at full detail over a small one. What that detail looks like in practice is on ogr-decode.

If you are provisioning a machine and want one number: budget a couple of gigabytes per concurrent degree square with dense land cover, and re-measure before scaling, because the figure moves with your data rather than with your map.

Threads

More threads is not reliably faster, and past a point it is not reliable at all. genapts took 19 seconds single-threaded and 11 with four threads: a real gain. Above four it crashes, because the airports in a tile race each other writing one shared index file. At ten threads it failed on all twelve attempts. Four is the setting that was both fast and safe here; see Common errors and fixes.

For genuinely large builds the project’s answer is not a faster machine but more of them: tg-construct ships client and server binaries for spreading construction across a cluster.

Disk space

For the square above: 11 MB of working files and 3.5 MB of finished scenery, on top of 132 MB of inputs; and 106 MB of that is the world airport database you only download once.

The intermediate files live on disk at the same time as both the source data and the output, so the peak is the sum, not the largest.

When a build dies

The failure this build actually hit was the genapts threading crash above: exit status 139, and a partial set of airports left behind that looks plausible until you count them. Check exit statuses in any script you write.

The wiki also warns that tg-construct can hit its own resource limits and stop, and suggests a source change to raise them. That did not occur in this build, at this size, and is recorded here as reported rather than observed.

One machine, three squares. These are measurements, not benchmarks; different hardware or a different core count will move them. The other two are built and compared here, along with a figure this page used to carry and had to withdraw: that most of those 286 seconds went on tiles outside the region. They did not. The full record, every command, the raw logs and the software versions, is on the sources page. If you run a build of your own, the numbers are worth sending in.