Every image on this page is output. One degree of California, put through the toolchain twice and then flown to, with the run recorded on the sources page. Nothing here is a stock photograph, a diagram of what the tools might do, or a screenshot of somebody else’s scenery.

The sequence is the point: the elevation the tools were handed, what they kept of it, and the same view in the simulator with nothing, with airports only, and with the land cover decoded. A second square at the end, to show the same tools somewhere that looks nothing like California.

The square

Shaded relief of San Francisco Bay: the peninsula, the bay, and the
East Bay hills, rendered from SRTM elevation data. — N37W123 rendered from the SRTM 1-arc-second tile that fed the build: 3601 × 3601 samples, 25.9 MB. KSFO sits on the west shore of the bay, KOAK on the east. This is the *input*; the elevation the tools were handed, before any of them ran.

How one degree is divided

The same terrain overlaid with a four by eight grid of yellow
rectangles marking FlightGear's scenery tiles. — The grid is not drawn on: those are the boundaries of the **32 files** the build actually wrote, plotted from their names. Why they are landscape rather than square, and why the count changes with latitude, is on the terrain page. What the picture adds is the scale; a tile is about 22 km across here, so each rectangle is roughly a city.

What terrafit keeps

Scatter of fitted terrain nodes across the same square. The ocean
half is nearly empty; nodes crowd along the coastline and the ridges. — Every node `terrafit` kept, coloured by elevation. **15,828 of 12,967,201 samples** survive; and you can read the coastline off the survivors alone, without any coastline data being involved. Flat water earns almost no nodes; ridgelines earn crowds of them. The mesh knows the shape of the land because the land is what decided the spacing. How the fit chooses.

In the simulator

The point of all of it. Three views from the same position over KSFO, at the same altitude, time of day and visibility: the only difference is what scenery FlightGear was given. Rendered in FlightGear 2020.3.16 on software OpenGL, no graphics card involved.

FlightGear at San Francisco showing nothing but open water to the
horizon. — **Control: no scenery at all.** FlightGear ships no terrain for this part of the world, so KSFO is open ocean. Everything in the next two images is what TerraGear put there.

San Francisco International's runways and taxiways rendered in
FlightGear, surrounded by ocean on every side. — **Built without land cover.** Thirty-one airports, correctly placed and correctly elevated, floating on an unbroken sea, because `--ignore-landmass` was passed and nothing told the builder where the land was. Worth looking at before skipping land cover to save time: this is the thing you would be saving it on.

The same view with terrain: hills to the horizon, urban ground
textures, the bay, and KSFO in the foreground. — **Built with land cover.** The same square, the same elevation data, the same airports; plus the ten decoded layers. The bay is water rather than everything being water, the peninsula is ground, the hills are where the hills are. That difference cost 286 seconds instead of 15 and 2.2 GB of memory instead of 81 MB.

What the surface is made of

Land cover map of the same square: blue ocean and bay, mauve urban
areas, dark green coastal forest, olive scrub and grassland inland. — What the simulator is actually colouring by: ten OpenStreetMap and Natural Earth layers, rasterised in the order the builder resolves them. The bay reappears as water, the two cities as grey, the peninsula ridge as forest, and the bright rectangles at the bottom of the bay are the Alviso salt ponds: a landmark you can navigate by, and proof the decode is following real geometry rather than approximating a coast. The ten layers, and the mapping.

Somewhere else entirely

FlightGear over Ramstein air base: two parallel runways and a large
apron, farmland and forest beyond, wooded hills on the horizon. — Ramstein, in Germany, from the second build. Put it beside the three views above: no water anywhere, hills in every direction, and a field pattern instead of a street grid. Same tools, same machine, same container: a different-looking planet. What travelled and what did not.

Land cover map of the Pfalz square: forest over most of it, yellow
farmland, purple vineyard strips in the north-east river valleys, and a
large unclassified area in the south-west. — Its land cover, drawn the same way, and worth holding against the map above. Green instead of grey and blue: forest takes 49% of this square and 12% of the Californian one. The purple threads are vineyards, tracing the river valleys exactly. It took five merged OpenStreetMap extracts to cover the square: the first attempt used one, left a quarter of it blank, and understated every figure on the page.

How these were made. FlightGear 2020.3.16 from Debian, in a container with no graphics card. The recipe covers the two failures that stand between a fresh container and a frame, and the capture script sits with the build record, so none of this has to be taken on trust.

Contributing a shot. Terrain you built, from a region you know, is still the most useful thing you can send: the build takes under a minute once the tools are compiled. See About the project.