tg-construct

Everything before this converts raw data into intermediate form. tg-construct is where the pieces become terrain, and it is the only stage whose resource use you have to plan around.

What it costs

The same square, built twice. Identical elevation, identical airports. The only difference is ten land-cover layers:

Two gigabytes of resident memory for one degree square is the number to carry into any sizing decision. It is not the area that costs, it is how many polygons have to be clipped against each other and against the terrain mesh. A region twice as large at the same detail roughly doubles; the same region with denser shapefiles can do considerably worse.

Which makes the honest answer to “how much RAM do I need” a question back: how detailed is your land cover? The decode stage is where that is decided, and Hardware and build times puts the rest of the pipeline next to it.

The arguments that change the result

The load list is positional, and order decides overlaps

tg-construct --work-dir=$WORK --output-dir=$OUT \
             --min-lon=-123 --max-lon=-122 --min-lat=37 --max-lat=38 \
             --priorities=/usr/local/share/TerraGear/default_priorities.txt \
             --threads \
             SRTMGL1 Landmass Lake Marsh Forest Grass Scrub Urban \
             Industrial Crop Sand AirportArea AirportObj

The trailing names are subdirectories of the work directory, not paths, and they are the layers to assemble. Where polygons overlap, later entries take precedence, so the order you type them in changes what you get. Airports last is deliberate: a runway should win against the grass it sits on.

--priorities is not optional in practice

default_priorities.txt installs with the binaries at /usr/local/share/TerraGear/. It decides which material wins where areas overlap, and it is 106 lines of ordering worth reading before you choose area types. Nothing looks for it on your behalf; pass the path.

--ignore-landmass builds without a coastline

If you have elevation and airports but no shapefiles yet, this lets the build finish. You get correct heights and working airports, and everything that is not an airport stays ocean, which looks exactly as strange as it sounds. It is the right way to get a first build done before taking on land cover, and it is why the left column of that table exists.

Bounds or tile id

--min-lon and friends select a rectangle; --tile-id selects one tile. A 1°×1° rectangle at latitude 37 covers 32 tiles, so the single-tile form is what you want when iterating on one area rather than rebuilding the other 31.

What it wrote

44 files without land cover, 53 with, in output/w130n30/w123n37/. Every one parses cleanly against SimGear’s own reader, 115,989 vertices in the first build, 1,265,905 in the second. KSFO.btg.gz holds 311 top-level objects: 214 triangle-face groups and 92 point groups, the latter being runway and approach lighting.

Alongside the .btg.gz files it writes .stg index files, which are plain text and worth opening; both formats are described here. They name the terrain object, the airports on the tile, and every windsock, beacon and taxiway sign with its coordinates, including real sign legends such as {@L}D{@R}10R-28L.

Running it across machines

Two further binaries, tg-construct-server and tg-construct-client, spread construction over several machines. They are the project’s answer to continent-scale builds, and given the memory figures above the reason for them is clear enough. Neither was exercised here.

One thing this page reports rather than observes: the FlightGear wiki describes tg-construct exhausting the resources available to it and terminating with no diagnostic, and suggests adjusting the setrlimit call in the source. Neither build here hit that. But the land-cover run reached 2.2 GB for a single degree square, which is not far from the conditions the warning describes, so treat it as a real ceiling rather than folklore.