FlightGear wiki - User contributions [en]

Using TerraGear

2021-10-14T18:23:43Z

IskenderWang: /* Related content */ add new guide

{{Out of date}}

[[File:Terragearprocesschart.png|thumb|TerraGear Process Flow Chart]]
The [[TerraGear]] software project supports [[FlightGear]] by creating the files used by FlightGear to represent the elevation and texture of the earth, including airports, cities, fields, forests, rivers, roads and so on. The TerraGear software reads data files containing ground elevation, airport locations and layouts, geographical land-cover data, and more, and produces the scenery files used by FlightGear to represent the terrain of the world.

For simplicity and convenience, most FlightGear users simply download the plug-and-play scenery files from the FlightGear scenery server, or use [[TerraSync]] to automatically download scenery as needed. But there is a variety of reasons you might want to use TerraGear to produce your own terrain files, rather than downloading the standard FlightGear scenery.

For instance, if you use [[WorldEditor]] to modify/improve information about an [[:Category:Airports|airport]]'s taxiway/apron layout, you might wish to see how that modified airport would look in the scenery before deciding you're happy with the results. Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher-resolution vector data (vmap1, Tiger, osm) to get better roads/streams. For all these reasons, learning how to use TerraGear is a good idea.

== Obtaining TerraGear ==
You can either build TerraGear yourself, or download a pre-compiled binary. The latter is the easiest and advised for starters.

* '''Option 1a - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear (TerraGearGUI included) build from: http://www.mediafire.com/file/ul2xy2ykgig2mct/160605_Sucessfull_Terragear_Win_Built.7z. This is by BecOzlacan, it's very stable and works well.
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package.

* '''Option 1b - Download ppa packages for Ubuntu Linux'''

https://launchpad.net/~saiarcot895/+archive/ubuntu/flightgear-edge/+index?batch=75&memo=75&start=75

* '''Option 1c - Use the TerraGear Docker instance'''

[[Howto:Docker_scenery_toolchain]]

* '''Option 2 - Compile TerraGear from source code''' as explained in [[Building TerraGear|this article]].

{{note|1=You might need <code>default_priorities.txt</code> from the {{terragear source|path=src/BuildTiles/Main/default_priorities.txt|text=git repository}} or from the archive downloaded from the build server (in the <code>archive/install/msvc100/TerraGear/share</code> subdirectory). See [http://forum.flightgear.org/viewtopic.php?f=5&p=77950 this forum thread] for details.}}

=== GUI tool ===
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Using TerraGear ==
First, choose the boundaries for the area of scenery you want to build, in terms of latitude and longitude. The smaller the area of scenery you generate, the smaller the amount of data you will need, and the less CPU time it will take. For example, if you are just interested in generating a new airport layout at 12.3W 34.4N, then simply generating the scenery between 12W 34N and 13W 35N would be sufficient.

Write down the bounding box (minimum and maximum longitude and latitude) for the scenery you want to generate. Remember that West and South are negative - in essence 4W 10S would be -4, -10. Try not to get mixed up, otherwise you'll end up generating scenery or airports on the other side of the planet!

You'll be dealing with multiple different types of data in various formats. Create a new directory for your scenery work. Within that directory, create the following sub-directories:

; <code>data/</code>: For raw and pre-processed data (eg elevation files)
; <code>output/</code>: For the scenery files you will create
; <code>work/</code>: For data that has been processed (eg by shape-decode) and is ready to be munged into scenery

=== Obtaining and processing data ===
TerraGear uses three different kinds of information to generate scenery:

# The elevation of the land (provided by SRTM)
# The location and layout of airports (provided by apt.dat or a custom .dat)
# Whether a given lat/lon is sea, land, city, forest, town, road, railway (provided by VMAP0, [[CORINE]] etc. or custom shapefiles)

This article describes how obtain and process each of these types of data in order, and bring it together for use by FlightGear. The order of these steps is important. For example, the airport data step needs the elevation data to determine the elevation of the airports and thus you should start with preparing elevation data.

{{caution|For inclusion in the official FlightGear scenery, all data '''must''' come from [[GNU GPL]] compatible sources!}}

==== Elevation data ====
The best worldwide elevation data currently available is from the Shuttle Radar Topography Mission (SRTM). There are two types of SRTM data:
* Highly accurate 1-arcsecond resolution data, known as SRTM-1, for the USA
* Less accurate 3-arcsecond resolution data, known as SRTM-3, for the rest of the world.
From now on, we'll assume you are using SRTM-3 data. Unless otherwise noted, the process for SRTM-1 is identical.

You can download the appropriate data from http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm. You want all .hgt.zip files covering your region of interest. Depending on the size of your scenery, there may be quite a few. Download them to <code>data/SRTM-3/</code> (or SRTM-1/SRTM-30 depending on the type you downloaded) in your base directory. (Genapts looks for a few known, hardcoded elevation data directories in its working directory. SRTM-30 is one of them and this is the least confusing in that list. Note: W.E.F. 31st July 2010, the genapts tool now also looks for SRTM-1/SRTM-3 directories. If you are using an older version, please supply the directories using --dem-path).

Now we've got the data, we need to convert it into something of use to TerraGear. First, you need to unzip each of the .hgt files. After that, open the commandline (Windows: Start > Run > <code>cmd.exe</code>) and change into the base directory (<code>cd .../.../TerraGear</code>).

{{note|According to [[TerraGear_Documentation]], hgtchop is superseded by gdalchop.}}
{{note|For SRTM-1 data, replace the <code>3</code> by a <code>1</code> in the first argument to hgtchop}}
{{tip|If you want to create a batch-file, replace <code>%f</code> with <code>%%f</code>, see [http://technet.microsoft.com/en-us/library/bb490909.aspx]}}

For Windows:
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 %f .\work\SRTM-3
or
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 .\data\SRTM-3\%f .\work\SRTM-3

For Linux:
for f in ${PWD}/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 "${f}" "${PWD}/work/SRTM-3"; done

Now you will get a lot of .arr.gz files in your work/SRTM-3/ directory. We need to convert these to the .fit.gz format. Run the commandline again with

{{note|The space and dot at the and are important!}}

For Windows:
.\Terragear\terrafit.exe work\SRTM-3

For Linux:
./Terragear/terrafit work/SRTM-3

==== Airport data ====
Now we've got elevation data, we can generate our airports. First, create a <code>data/airports/</code> directory and copy in your apt.dat file. This may be direct from your FlightGear data package (though you'll need to unzip it), or it may be one that you've modified with [[WorldEditor]].

The command to create airports is "genapts850". Run it without any arguments to see the various command-line options.

If it is simply run with a specified apt.dat and work directory, it will generate airport layouts for every airport in the file, which can take a long time. Make sure the input is not the apt.dat.gz, but an uncompressed file. Otherwise genapts850 will block and not produce any output.

If you are just creating a single airport and you know the ICAO ID (for example [[San Francisco International Airport|KSFO]], EGPH or EG32), use it as follows from your root scenery directory (in essence the directory above your data, work and output directories). If you use an apt.dat file with one single airport in it you should omit the <code>--airport</code> parameter.

genapts850 --input=data/airports/apt.dat --work=./work --airport=<AIRPORT_ID>

or, if you have elevation data available:

genapts850 --input=data/airports/apt.dat --work=./work --dem-path=SRTM-3

If you are generating a larger set of scenery, then you can specify the minimum and maximum longitude and latitude.

Genapts will create two sub-directories in your work directory:

* <code>AirportArea/</code>
* <code>AirportObj/</code>

These contain the definitions of the airport layout and any objects present (e.g. windsocks and beacons).

==== Landuse data ====

{{note|The text in this section refers to using data from the MapServer, which has been discontinued. Land use data (shapefiles) should be acquired from another source for now.}}

The final piece of data we need to generate is the landuse data. In general, this is taken from the VMAP0 dataset as shapefiles from the scenery database mapserver, but other sources can also be used.

The landuse data can be split into a number of different types:

; Landmass: Separates the land from the sea. It can be used as a mask for all other data. The most commonly used is the VMAP0 Landmass, but GSHHS can also be used. When running tg-construct with <code>--ignore-landmass</code>, all input shapefiles will be taken into consideration, so no landmass mask is required then.
; Land use data: Defines whether a piece of land is forest, urban, sand, lava, glacier etc. These are usually VMAP0 data, defined as polygons.
; Line data: Includes railroads, streams, roads. Typically VMAP0, but also OpenStreetMap for roads.
; Point data: Is currently only used for defining towns.

By far the easiest way to get this data is to download shapefiles from the wonderful [http://mapserver.flightgear.org MapServer]. The MapServer lets you download the shapefiles for any selected scenery area. Click on the "Download Shapefiles" link (or go direct: http://mapserver.flightgear.org/download.psp). Enter in the bounding box of the scenery you want to generate, select the type of shapefile data you want, and click download.

==== Layers ====

; <code>v0</code>: Global coverage, low detail. This is "the last resort", but unfortunately it is the only layer that covers the entire world.
; <code>cs</code>: It is v0 with some contributions someone did in the past. Get this instead of v0.
; <code>v1</code>: Only parts of some countries available, higher detail than v0.
; <code>clc06</code>: European '''only'''. Very high detail, this is the preferred choice for an European country.
; <code>osm</code>: Global coverage, high resolution but very low detail.
: This means: if you are interested in an area out of Europe and forests are defined in OpenStreetMaps for your area, this is going to be the best data source. If forests are not defined, you will get a dull, neverending DEFAULT landclass. OSM provides the best coastline and I encourage you to use this coastline even in Europe. [http://forum.flightgear.org/viewtopic.php?f=5&t=25549&sid=d501cb651ef9e34ca9dc8fae429d51ab&p=234002#p234002]

{{caution|Make sure each shape file is in its own directory whether you download shape files or create your own otherwise the ogrDecode step will fail.}}
Download each shapefile into a seperate (!) <code>data/shapefiles/...</code> directory. So, for v0_landmass, you would end up with <code>data/shapefiles/v0_landmass/v0_landmass.shp</code> etc.

You can load these shapefiles into a GIS editor such as [[QGIS]] or GRASS to view and edit. This is a good idea to verify you have the correct files! Later on, you can experiment with replacing various shapefiles with other versions (GSHHS for coastline, OSM for roads etc.).

The next step is to decode the shape-files into TerraGear format using the '''ogr-decode''' command (renamed to '''poly-decode''' in recent versions of TerraGear).

There are three important command-line arguments for ogr-decode:
* the destination directory for the decoded data
* the location of the shapefile's directory
* the material type

Each shape-file corresponds with one of the material types defined in the materials.xml files. The mapping is pretty obvious. For example, <code>v0_mixedcroppasturecover</code> maps to <code>MixedCropPastureCover</code>. Note that the material types are case-sensitive, so it is a good idea to refer to the <code>[[$FG_ROOT]]/Materials/default/materials.xml</code> file (<code>[[$FG ROOT]]/materials.xml</code> in FlightGear 2.6.0 and older) to hand so you can check. The exception is landmass, which - when used - MUST be mapped onto the type Default.

Additionally, there are a number of optional arguments, to indicate the width of line data (for roads, streams, railways), how large to make point data (for towns) and how long the longest straight line is allowed to be.

For example, to decode the <code>v0_landmass</code> shapefile, you use the following command:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/v0_landmass

To create streams of width 10 metres

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

To generate some towns about 1km across

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Run this command for each shapefile in the set.

== Generating scenery ==
You will now have a work directory, with subdirectories like:
{|
|
: AirportArea
: AirportObj
: Bog
: Default
: DryCropPastureCover
: EvergreenBroadCover
: GrassCover
: IrrCropPastureCover
: Lake
: Marsh
: MixedCropPastureCover
| valign="top" |
: MixedForestCover
: Railroad
: Road
: Sand
: ScrubCover
: Shared
: SRTM-3
: Stream
: Town
: Urban
|}

Now we can actually generate the scenery. This is done by the tg-construct command. Run the command with <code>--help</code> to get usage information.

We need to define:
* The work (<code>--work-dir</code>) and output (<code>--output-dir</code>) directories.
* The center of the scenery we want to generate (<code>--lat</code> and <code>--lon</code>).
* The radius (<code>--xdist</code> and <code>--ydist</code>) from which to generate.
* All the work directories to include in the scenery.

{{note|The output directory must point to a <code>Terrain/</code> directory, else recent FlightGear versions will be unable to load the terrain.}}

For example:
{{Pre2|<nowiki>tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=55 --max-lon=57 --min-lat=60 --max-lat=62 AirportArea SRTM-3 AirportObj Default Stream Bog IrrCropPastureCover Town Lake Urban Railroad DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover MixedForestCover</nowiki> }}

When this finishes, the output directory will contain a scenery sub-tree. Point to it by setting either [[$FG_SCENERY]] or by using the <code>--fg-scenery</code> command-line option to fgfs, and give your new scenery a try!

== Troubleshooting ==
Below is a list of common problems and solutions. If in doubt - Google it. Many problems (particularly when compiling TerraGear) have been hit before:

* Crashes in genapts. Sometimes genapts will crash when dealing with a particular airport. In that case, try running it again with the <code>--start-id</code> argument to start at the airport it failed on, and the <code>--nudge</code> argument which tries to nudge the calculations in the right direction.
* tg-construct killed. The tg-construct process may kill itself if it is using too many system resources. Increasing the values for <code>setrlimit</code> in <code>src/BuildTiles/Main/main.cxx</code> is the best solution.
* tg-construct silently stops immediately without an error and nothing goes to the "output" directory: make sure that lon/lat values correspond to tiles boundaries. See [[Tile Index Scheme]]
* tg-construct says it is building the tiles requested, but at the end, nothing has been built: even if the requested tiles are covered by the elevation file (.hgt), tg-construct needs at least a default shapefile covering any terrain, or else it skips the tile with no output.
* Airports appear in the bottom of holes, or there are spaces between the airports and the scenery. This typically happens when genapts is unable to find the correct elevation data, or the elevation data changed between running genapts and shape-decode. Try generating a single airport in your scenery area using genapts, and look at the output. In particular, make sure there is a work/SRTM-3 directory.
* Only the airports appear in the scenery. There are three typical causes for this:
** You didn't download the correct shapefiles for the area.
** You haven't run shape-decode on the <code>v0_landmass</code> shapefile as Default
** You didn't include the correct directories in tg-construct.
* Generate scenery includes data removed from the shapefiles. If you are editing shapefiles, you need to delete the appropriate work subdirectory before running shape-decode. Otherwise your changes will be in addition to those already present.
* All the scenery is flat and at sea-level. Typically this is because you didn't include any elevation data in your tg-construct command. Make sure there's a STRM-3 directory included in the command-line.
* All terrain copies the material of a certain shapefile. You have probably forgotten to put each of the downloaded shapefiles in a seperate directory inside the Data/shapefiles directory.
* genapts850 never passes the stage "Adding airport <ICAO> to parse list": did you unzip <code>apt.dat.gz</code>?

== General comments from forum discussion ==
{{cquote|f-ojac, you are right, the parameters used in scenery 2.0 were "-e 5 -x 20000" according to the wiki. I don't know why I had the impression these parameters were not public. In any case, it does not matter because using the same parameters will create closer results, but they are not guaranteed to be the same.

The parameters used to create scenery 2,0 seem to be:

-m ??: the minimum number of vertices in a tile. In FG, any number bellow 100 (and probably, any number below 1000) will do. I don't think there is any surface on the world perfectly flat for several kilometers. The default value is 50 and I'm sure is ok for any normal use.
-e 5: the max allowed error for elevation, in meters. That is: if terrafit calculates a simplification of the terrain where all points are at most this distance from the real elevation, no more vertices are created. The default value is 40 meters: a point may have an elevation error up to 40m (~100ft) High values for this parameter create less detailed mountains and smaller (in disk size) and more efficient (in FPS) terrain.
-x 20000: the max number of vertices in a tile. If this number of vertices is reached, terrafit stop regardless the max error of the vertices. The default value is 1000

Keep in mind you can set values that do not make sense:

* "-e 1 -x 100" does not make sense because it is going to be impossible to calculate errors less than 1 meters using only 100 vertices. The max number of vertices will be reached always and the max error will be probably ignored.
* "-e 300 -x 20000" does not make sense, tiles are going to use for sure much less vertices than 20,000 because you are allowing huge elevation errors.

If you want an efficient scenery (less vertices), use the default values "-e 40 -x 1000". If you want more accurate elevation at the cost of disk space and FPS, use values similar to scenery 2.0 ("-e 5 -x 20000") Anything in the middle will produce performance and disk use in the middle.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=5&t=24681#p225363
|title=Re: Terrasync Help (surprinsingly!) :)
|author=ludomotico |date= Mon Nov 24, 2014 4:28 am}}</ref>|ludomotico}}

<references/>

== Related content ==
* [[Howto:Use TerraGear without wanting to kill yourself]], self-explanatory, contains the most recent info.
* [[Howto:Create custom terrain]], editing/making terrain data.
* [[TerraGear CORINE]], building terrain from CORINE data.
* [[TerraGear Documentation]], using TerraGear details.

{{Terra}}

[[Category:Scenery enhancement|TerraGear, Using]]

[[fr:Utiliser TerraGear]]
[[zh:Using TerraGear]]

TerraGear Documentation

2021-10-14T18:20:28Z

IskenderWang: /* Related content */ Add new guide

There has been a lot of questions relating to scenery generation tools. This page is an attempt to document each of the tools I use. I will also document the design, and what each tool is actually doing.

My hope is to attract more developers to work on the tools to make it easier to create better scenery for [[FlightGear]].

== Toolchain ==
If you just want see every options/arguments available for each tool you can use this command line in the terragear/bin directory : (only for linux user)
for file in *; do echo "" && echo "###################################" && echo $file && echo "###################################" && ./$file --help; done
or alternatively
find * -exec bash './{}' '--help' \;

=== gdalchop ===

gdalchop is a tool responsible for cropping height data files into SimGear buckets (or tiles).

Most height data is published in fairly large data files that cover 1 square degree. For SRTM-1 data, there are 3601 x 3601 data points per file. For SRTM-3 data, there are 1201 x 1201 data points per file. SRTM datafiles are named by their southwestern most point.

When TerraGear tools need to query elevation data, they do so expecting the data to be located in a standard SimGear folder structure as follows:

{| class="wikitable"
|-
! Format !! Example
|-
|''10 deg x 10 deg folder''|| ''w070n10''
|-
|— ''1 degree by 1 degree subfolder ''||— ''w065n17''
|-
|—— ''bucket file ''||—— ''1891048.arr.gz ''
|}

gdalchop will create this directory structure in the work folder, and create sgbucket.arr.gz files within.

==== command options ====
gdalchop <work dir> <height data dir>/*hgt

'''<work_dir>''' 
This is where gdalchop will generate the elevation directory structure described above.

'''<height data dir>''' 
This is the directory your height data resides in. (i.e. .hgt files for SRTM)

'''<height data dir>/*hgt''' 
Points to all the hgt files in the data directory

==== notes ====
# remember to use gdalchop on directories, rather than individual files. It handles height data stitching for you. Using individual files will produce data with missing elevation data where stitching could not be performed.

For example, this command will process all the .hgt file from the folder "SRTM-source" and the result will go in the folder "work/SRTM3"
gdalchop work/SRTM3 SRTM-source/*hgt

 

=== hgtchop (deprecated) ===
hgtchop is also a too responsible for cropping height data files into SimGear buckets (or tiles). This tool only work with data in the .hgt format (SRTM, viewfinder).

Reasons for using gdalchop:
* handles heightdata in many more formats
* is based on gdal, an actively maintained open source GIS library

==== command options ====
hgtchop <resolution> <hgt_file> <work_dir>

'''resolution''' 
Each file created contains ALL of the data points for the simgear tile. For SRTM-1 data, the resultant grid (for tiles near the equator) is 450 x 450 points. For SRTM-3 data, the grid is 150 x 150 points. The resolution parameter tells hgtcop the distance between sampled points. Note that tile width varies with latitude. So 'square' tiles really only exist between 22 degrees N - 22 degrees S. The tile widths are explained here: [[Tile_Index_Scheme|Tile Index Scheme]]

'''hgt_file''' 
The source file. Usually, the source files are 1 degree by 1 degree, and have enough data to create 64 simgear buckets (near the equator).

'''work_dir''' 
This is where hgt-chop will generate the elevation directory structure described above.

==== notes ====
#zip files : In TGHgt::open, if the file extension is '.zip', then unzip executable is executed through system(). If the host system doesn't have unzip, then hgtchop will fail. The unzip should be performed via SimGear - Investigation needed 
 

=== terrafit ===

terrafit is responsible for taking the raw heightfield data for one bucket, and picking the most important points to generate a triangle mesh. It uses [http://mgarland.org/archive/cmu/scape/terra.html Terra] to perform the work. The output is not a triangulation, but rather a list of nodes that can be fed to a triangulation routine. The quality of FlightGear's terrain is directly related to what parameters are fed into terrafit.

==== command options ====
terrafit [options] <file | path>

{| class="wikitable"
|-
! Option !! Default !! Description
|-
| -m ''or'' --minnodes||50||smallest number of nodes to produce. For a mostly flat tile, more nodes are wasteful.
|-
| -x ''or'' --maxnodes||1000||largest number of nodes to produce. 
For a very complex tile, limiting this will reduce the detail of the resulting mesh.
|-
| -e ''or'' --maxerror||40||While picking points, and we have at least minnodes, but not yet maxnodes, the mesh will be completed 
if any of the remaining points maximum elevation error drops below this value.
|-
| -f ''or'' --force|| ||If you have an already fitted work directory, and want to regenerate with different parameters, be sure to use force. 
Otherwise, the work directory is checked for updated height data and merged with current data
|}

As you can see, the default parameters are pretty conservative. At most, we will output 1,000 nodes. The input data for SRTM-1 contains 202,500 nodes, so we are only keeping 0.5% of the source data (or for SRTM-3, with 22,500 nodes, we keep ~5% of the source data)

For my experiments, I've increased maxnodes to 20,000, and decreased max error to 10 meters, and didn't see a major frame rate hit).

If you consider the number of nodes added when using detailed landclass, it's unfortunate that the height lookup for these points will be based on such an inaccurate mesh. 

For example, this command will process all the *.arr.gz file (previously generated with gdalchop) from the folder "work/SRTM3", the result will go among .arr.gz files
terrafit -f -m 50 -x 20000 -e 10 work/SRTM3
 

=== ogr-decode ===

ogrdecode is responsible for decoding landclass and line vector data into terragears internal textured polygon format. It also performs the 'chop' operation, so the output is structured in the same directory format as described in gdalchop. ogr-decode is capable of decoding shapefiles stored on disk, or retrieving the data from a PosGIS database.

==== command options ====
ogr-decode [options...] <work dir> <datasource> [<layername>...]

{| class="wikitable"
|-
! Option !! Default !! Description
|-
| --line-width||50||for line data, this is the width in meters the generated polygons will be.
|-
| --line-width-column||''none''||for line data, this optional field can be used to retrieve the width from the database row, under the given column. 
If data is present in the row, it overrides the line-width parameter.
|-
| --point-width||500||for point data, this is the 'width' of the square generated. Both width and height will be this large.
|-
| --point-width-column||''none''||for point data, this optional field can be used to retrieve the width from the database row, under the given column. 
If data is present in the row, it overrides the point-width parameter.
|-
| --area-type||Default||This string is used to define the type of landclass the generated polygons will be saved under. 
In tgconstruct, the landclass priorities file is used to determine the priority of each landclass. higher priorities are 'on top' of lower. 
The name given here must match a landclass type in your priorities configuration file.
|-
|}

=== genapts / genapts850 ===

The general approach that genapts uses this. Start with a simple square polygon representing the airport area. As we proceed and add shapes to the airport, they are subtracted from this initial polygon. Also start with an empty polygon representing the airport shapes. As we proceed, objects are "added" to this polygon. Then we iterate through all the runways and taxiways for the airport. For each 8.10 taxiway we draw the corresponding box. We "intersect" that box with the accumulated shape polygon, so we can only cover areas that haven't been covered already. Then we add this "intersected" shape to the airport shape polygon and subtract it from the enclosing polygon. We get to pick the order we process the airport surface objects, so we pick the runways first, and probably the biggest runways before the smaller runways. Then the bigger taxiways before the littler taxiways, etc. Biggest/most important to smallest, least important. In the end we have a jigsaw puzle of all the individual shapes (so we can texture them properly individually) as well as a master surrounding polygon with holes cut out for all the shapes, plus a master polygon of all the shapes. Then in the end we can cover the whole area perfectly with no overlaps and no seams. In addition, there is a fairly sophisticated (and I think cool) step where we fit a natural curved surface across the airport elevation and used the curved surface instead of raw SRTM points. This eliminates the "noise" in the raw data and gives the airport surface a natural looking slope and correct hills and valleys (in most cases.) After that we generate all the light points and adjust their height based on the fitted curved surface. I think this approach could be updated for the 8.5 format by just generating different polygon shapes instead of the older collection of rectangles. The down side to the current approach is that it's hard to add markings over the surface. Without getting into all the technical details, if you cut in the markings into the surface structure you end up with an incredibly complex shape with an incredible number of triangles. Bad for load speeds and rendering speeds. If you lay the runway / taxiway markings and skid marks over the top of the base surface, then you have a lot of issues with z-buffer fighting and other odd graphics artifacts. Because our runway surface is curved/sloped we just use a simple draw order trick like other sims might use. But maybe in the past few years people have developed better tricks and techniques for handling this difficult problem of adding complex / arbitrary markings to a surface in a way that looks good mostly edge on (when landing or taxiing) and doesn't blow up your polygon count or encounter z-buffer problems, or require odd hacks of lifting the markings high enough above the runway that you can start to see that they are actually floating and not attached. <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/28066427/
| title = <nowiki>Re: [Flightgear-devel] New experimental mapserver</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Sep 9th, 2011
| added = Sep 9th, 2011
| script_version = 0.25
}}
</ref>

<references/>

==== design ====
:Step 1 : Parse

:Step 2 : Clip

:Step 3 : Clean

:Step 4 : Elevation

:Step 5 : Output

=== fgfs-construct ===

== Related content ==
* [[Using Terragear]]
* [[Howto:Use TerraGear without wanting to kill yourself]]
* [[TerraGear CORINE]]

{{Terra}}
{{Building}}

[[Category:Scenery enhancement]]

TerraGear

2021-10-14T18:20:16Z

IskenderWang: /* Related content */ Add new guide

{{Hatnote|Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.}}

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

Without terragear, it is possible to change Terrain '''textures''' but not terrain '''shapes'''. If you want to change the texture for cities, you change the materials file. If you want to change the coast line, you need terragear.
Check the material files in directory FGDATA/Material. Identify the material file that includes Montevideo, which is probably latin_american_cities.xml ([[Howto:Regional texturing]] and this page [[Procedural Texturing]]<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=311143#p311143
|title = <nowiki> Re: Improving terrain realism </nowiki>
|author = <nowiki> ludomotico </nowiki>
|date = May 25th, 2017
|added = May 25th, 2017
|script_version = 0.40
}}</ref>

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[WED]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Using the download_and_compile.sh script (Linux distros using apt) ===
Get the script download_and_compile.sh if you don't already have it. Copy it into a specific directory, no need to be root.
{{#tag: syntaxhighlight |
wget {{fgmeta url|view=raw|path=download_and_compile.sh}}
mv download_and_compile.sh\?format\=raw download_and_compile.sh
chmod 755 download_and_compile.sh
./download_and_compile.sh SIMGEAR TERRAGEAR
| lang="bash"
}}
This will build SIMGEAR (pre-requisite) and TERRAGEAR properly, installing dependencies if necessary and you will be done for the TG compilation part of the process.

=== Pre-compiled builds ===
* [http://build.flightgear.org:8080/job/TerraGearGUI-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[Git]] repository at SourceForge..
{{#tag: syntaxhighlight |
{{terragear clone|post=flightgear-terragear}}
| lang="bash"
}}

you have to use the stable branch called "scenery/ws2.0"!
{{terragear url|branch=scenery/ws2.0/~}}

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
==== Debian ====
* [[Building FlightGear - Debian#TerraGear]]
==== Gentoo ====
* emerge -av terragear</tt>
See [[Building Flightgear - Gentoo]].
==== Ubuntu ====
* [[Building terragear in Ubuntu 910 (32- or 64-bit)]]
* [[TerraGear compilation - Ubuntu 14.04]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[Howto:Use TerraGear without wanting to kill yourself]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear]]

[[es:TerraGear]]
[[fr:TerraGear]]

Howto:Use TerraGear without wanting to kill yourself

2021-10-14T18:08:12Z

IskenderWang: Adding to category

My aim was to go through this whole process successfully with as little manual labour (don’t have the knowledge to go fine tuning in QGIS? no problem! neither did I) as possible. "Automation ftw" has been my perspective entering this endeavour.

Special thanks to some brilliant lads who walked these roads long before I did, for helping me discover the way! Shoutout [[User:Fahim Dalvi|Fahim]], [[User:D-ECHO|D-ECHO]], and [[User:Legoboyvdlp|legoboyvdlp]], among several others (you know who you are) – in fact, big up the whole FG community.

Hopefully, some of you will find this guide helpful – though at the time of writing, it appears that TerraGear is on the verge of becoming obsolete any minute now. So, if nothing else, it can serve as a time capsule of sorts – a way of recollecting how this task used to be done. Cheers! –– [[User:IskenderWang|IskenderWang]] ([[User talk:IskenderWang|talk]])

== Directory structure ==

Inside your working directory for TerraGear you will simply need three subdirectories – one for your starting '''data''' which you will process as necessary, one for the '''work''' that the TG tools will achieve which provides it with the actual recipe for constructing your scenery, and one for the '''output''' or end product after running tg-construct (the final step) to generate your terrain. My directory structure in the midst of generating several sceneries was looking as pictured.

[[File:TG directory structure.png|thumb|right|A directory format one could expect to utilize while working with TG]]

As you can see, what I like to do is compartmentalise the various sceneries I’ve created/aim to create in their own subdirectories in ''/data'' so to prevent any confusion and easily keep them separate them as I use the TG tools. Since you’re generating terrain one at a time though, I’d strongly recommend clearing out your ''/work'' directory completely in between each.

== Gather all the necessary starting data ==

The materials you will need to embark on your TG journey are:
# '''Elevation data''': Numerous sources for that but the best option will probably still be [http://viewfinderpanoramas.org/dem3.html viewfinderpanorama].
# '''All the airports in the area you aim to build''': Best to use some tool like [[TerraMaster]] for this, but keep in mind that Docker TG (even running terragear:latest) seems to only support up to XP apt.dat version 1100 – it unfortunately won’t work with 1130 which is the version most of the latest and greatest airports on [https://gateway.x-plane.com the gateway] will come with, whereas if you compiled the latest TG you should be all good in this respect.
# '''[https://osmdata.openstreetmap.de/download/land-polygons-complete-4326.zip World landmass polygon]''': This is great since it serves as your base layer and also has very accurate coastlines.
# '''Shapefiles''': This is where things get interesting, there are numerous sources one can defer to. In the past, people mainly relied on vmap0 and there was a nice mapserver that made it easy to acquire. Nowadays, the mapserver’s gone by the looks of it. Today, while you can still choose [https://gis-lab.info/qa/vmap0-eng.html vmap0], far better options exist for most areas nowadays thanks to the availability of [https://download.geofabrik.de OSM shapefiles] (solid option almost anywhere these days) as well as [[Coordination of Information on the Environment|CORINE]] (Europe), [[Howto:Using QGIS to process NLCD data|NLCD]] (U.S.), and [[User:D-ECHO/Canada Land Cover|LCC]] (Canada), though these others can be a bit less straightforward to obtain and work with – thankfully, if you’d like to try them out there’s documentation for all of those supplied by some top blokes in the FG community.

== Process your elevation data ==

When you unpack your elevation data, make sure to somehow place ALL the hgt files you intend to use in the relevant folder for the scenery in question, with no subdirectories dividing them – using <code>mv</code> and the wildcard to move all the contents of the needed folders from VFP to where they belonged worked just fine for me; quick and efficient.

For only this step, you could use this command: <code>docker run -i -v ~/terragear-work:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash</code>

Since this is guaranteed to not have buggy elevation tools, so it’s really your call – you could do it just in case, especially if you’re working exclusively with Docker.

for f in ${PWD}/data/SRTM-3/scenery-in-question/*.hgt; do hgtchop 3 "${f}" "${PWD}/work/SRTM-3"; done
terrafit work/SRTM-3

Now for everything else: <code>docker run -i -v ~/terragear-work:/terragear-work/ -t flightgear/terragear:latest /bin/bash</code>

== Process your airports ==

Once you’ve collected all your airports from the gateway and you’re confident that they’ll work with genapts (perhaps through trial and error) you can just place all the zips in a burner directory and create an airports directory inside of that – then if you have zsh you can simply run my script here in the command line:

#!/bin/zsh
for file in *.zip
do
FILENAME=$( echo $file | sed s/.zip// )
ICAO=$( echo $file | sed s/_Scenery_Pack.zip// )
unzip $file
cd $FILENAME/"Earth nav data"
mv apt.dat ../../airports/$ICAO.dat
cd ../..
trash $FILENAME
done
trash ./*zip

and there you have it – all your .dat’s are there and sorted correctly by ICAO, which you can then transfer to your TG ''/data/airports'' folder.

Another way which is even better in a perfect world is to cut out the middleman by using the [https://github.com/mherweg/d-laser-fgtools dlaser tools], however this will always fetch the latest ones, which may not work for you if you’re using Docker TG.

Either way, this step may or may not be cumbersome depending on the amount of ''.dat'' files you’ll need, which can often include not just airports and airfields but also other things such as helipads – for instance, my Hong Kong scenery needed only 5 in total, while 12 tiles of scenery for Florida required 177 (!!) rasclart .dat files, which meant that using the ''gateway_pull.py'' script was a must (you'll need to run it through Python 2 though).

Then, once you’re ready, simply run this command:

for i in ./data/airports/scenery-in-question/*.dat; do genapts850 --threads --input=$i --work=./work --dem-path=SRTM-3; done

== Determine your bounding box coordinates ==

You may have already done this step in the very beginning, but if not, now would be a good time.
'''Think of the corners as bottom left, upper right, longitude BEFORE latitude.'''

In my case, for the Hong Kong scenery, the relevant coordinates were <code>113 21</code> and <code>115 23</code>.

== Crop your shapefiles ==

Before we dive more deeply into shapefiles, an important thing to mention is that while the .shp files will be the “stars of the show” in a sense, many of the other files it will come with are also NECESSARY! This means you should not try to delete files that may have seemed redundant to the uninitiated (i.e. me, at that point), and that if you’re going to move shapefiles between directories you’ll have to copy/move ALL of the ones that you will need which come in a set (by having the same filename, just different extensions). After all, most of those other files are there for a good reason, and not just to provide alternative options for GIS users as I had initially assumed. This had me stumped for a little while, wondering why this next tool wasn’t working and almost concerned that I wouldn’t be able to advance beyond this step, UNTIL I came across [https://gis.stackexchange.com/questions/262505/python-cant-read-shapefile/262509 this post on Stack Exchange] and it all made sense, so big up Michael Stimson as well for the helpful answer.

Something to note so that you don’t have to make that same mistake :) First, make sure you're inside ''/data/shapefiles'' (run a quick <code>cd</code> if not). Then, we simply run:

ogr2ogr -clipsrc 113 21 115 23 hk.shp land_polygons.shp

and so on for ALL the others as well – you can even use colons to run them all in one go, as I did. Be patient, though, because if your initial region & shapefiles are large then it can take longer than you may have expected at first.

== Split your shapefiles ==

At this point, you can put your cropped project shapefiles in their own directory and then delete or keep the full shapefiles depending on if you intend to use them again or not – that said, you should probably keep the land polygons (default) shapefile for future use since it can act as the base for the whole world, but for your cropped landmass shapefile for THIS scenery you can make a separate directory. I called mine simply “landmass” and now it may look something like what you see in the screenshot.

[[File:Shapefiles folder.png|thumb|center|The directory for shapefiles and how it could look at the extraction/splitting step]]

Here is Fahim's wonderful script, which allows us to perform this step:

#!/bin/bash
# Check arguments
if [ $# -lt 2 ]; then
echo "Usage: bash extract_features_shapefile.sh <path-to-shapefile> <path-to-output-dir>"
exit
fi
src_shp=$1
dest_dir=$2
# Extract available feature list in supplied shapefile
echo "Extracting available features..."
feature_list=$(ogrinfo -al $src_shp | grep 'fclass (String)' | tr -s ' ' | cut -d' ' -f5 | sort | uniq)
echo "Found following features:"
for feat in ${feature_list}; do
echo $feat
done
# Create shapefile per feature from supplied shapefile
echo "Creating new shapefiles..."
mkdir -p $dest_dir
for feat in ${feature_list}; do
echo "Processing $feat..."
mkdir -p $dest_dir/osm_$feat
ogr2ogr -where "FCLASS LIKE '"$feat"'" $dest_dir/osm_$feat/osm_$feat.shp $src_shp
done

Now you can use it on each of your shapefiles in the project directory, like this:

bash extract_features_shapefile.sh hk/gis_osm_landuse_a_free_1-hk.shp .

and so on.

This step prepares us to translate each of the specific types of land classes we need to the FlightGear format, as defined by Material definitions, while also deciding which ones to prune – bear in mind that many of these we can (and should) exclude because leaving them in the final recipe would add too much complexity.

== Map and decode your shapefiles ==

Once you reach this stage, you may now have a shit-ton of directories – that was certainly the case for me, as the screenshot illustrates.

[[File:Shapefiles split.png|thumb|center|Oh my, that seems like a lot]]

Not to fear – the light at the end of this tunnel is in sight already. Now we have to do something called [[OSM to materials mapping|mapping]], which is basically the translation I mentioned earlier, and then run ALL these inputs through the TG tool called ogr-decode.

This step can be time-consuming: deciding what to exclude [from the decoding step], and how to map the landclasses you do include.
You don’t need expertise in QGIS by any means – however, it can certainly come in handy with helping you view all your split shapefiles by importing them in and then tinkering with the layer visibilities to decide on what you don’t need/would add too much complexity versus what is necessary, because remember, performance in FG is of the essence as well (always keep that in mind during this step).

[[File:QGIS example for TG 1.png|thumb|right|Obviously we'd never need all this, that's why we had further split up these shapefiles]]

'''BRO TIP''': I didn’t realise this myself at first as a n00b to the toolkit, but I was advised by legoboyvdlp that osm_unclassified actually includes numerous roads and isn’t as irrelevant as the name would suggest, in fact it’s better to include this and PRUNE osm_residential for improved performance.

[[File:QGIS example for TG 2.png|thumb|left|Here you can see a big difference, not to mention I also ended up pruning the selected osm_residential landclass]]

When you map, try to use more standard landclass names as much as possible since those cover mostly everything – unless you have something specific in mind (such as for a custom scenery with its own set of material definitions), try to avoid using any landclasses that aren’t even mentioned in the [https://sourceforge.net/p/flightgear/terragear/ci/next/tree/src/BuildTiles/Main/default_priorities.txt default priorities file].
That said, if you insist on using other landclasses for whatever reason, you can always create your custom priorities file and add your own landclasses to it, and then just tell tg-construct to use that instead.
We’ll likely be doing this in bulk, so it makes a ton of sense to create a script for this (shoutout to D-ECHO who I would say has championed this approach) and place it in the TOP level of the TG working directory (so it’s level with ''/data'', ''/work'', ''/output'').

Then, all the arguments will essentially follow this sort of format exactly:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/landmass/
ogr-decode --max-segment 500 --line-width 12 --area-type Asphalt work/Asphalt data/shapefiles/osm_motorway/

and so on for ALL the other landclasses, hoping you’ve mapped it all correctly.
So once that’s set, you simply run the script:

./decode_osm_data.sh

(note: if you're doing it like this make sure it’s executable first, a quick <code>chmod +x</code> may come in handy – I like to do this here instead of invoking bash because when I was on Ubuntu in a zsh shell it may have been more efficient for it to simply work through the same shell, entirely up to your preference though)

== Generate your terrain ==

At long last! This step requires us to use the final utility in the TG workflow, <code>tg-construct</code>, and I like to use a modified version of D-ECHO’s script for this as well:

./tg-construct.sh

In my case, the one command I was truly running was as follows:

tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=113 --max-lon=115 --min-lat=21 --max-lat=23 --threads=3 --priorities=/usr/local/share/TerraGear/default_priorities.txt AirportArea SRTM-3 AirportObj Default Ocean Hole Road-Motorway Road-Trunk Road-Residential Road-Primary Road-Secondary Road-Tertiary Road-Service Road-Pedestrian Road-Steps Road-Unclassified Airport Pond Lake DryLake Reservoir IntermittentLake IntermittentStream Watercourse Canal Cliffs Glacier PackIce PolarIce Ocean Estuary Urban SubUrban Town Fishing Construction Industrial Port Dump FloodLand Lagoon Bog Marsh SaltMarsh Sand Saline Littoral Dirt Rock Lava OpenMining BuiltUpCover Transport Cemetery DryCrop IrrCrop Rice MixedCrop Vineyard Bamboo Mangrove ComplexCrop NaturalCrop CropGrass CropWood AgroForest Olives GolfCourse Greenspace GrassCover Grassland ScrubCover Scrub ShrubGrassCover SavannaCover Orchard DeciduousForest DeciduousBroadCover EvergreenForest EvergreenBroadCover MixedForest RainForest BarrenCover HerbTundra Sclerophyllous Heath Burnt SnowCover Island Default Void Null Unknown River Freeway Road Asphalt Railroad Stream

When I changed computers, the only thing I had to alter here was the thread count and the path to the default priorities file.

Now just sit back n relax and enjoy everything, you feel me, because you know what’s about to happen.

[[File:TG success.png|thumb|Success]]

And have patience, because this could take a while! '''Seriously!!'''
For legoboyvdlp, Ireland took a whole week (nonstop!!) to generate! And even for a relatively small scale such as Hong Kong and some of the surrounding area, because the Pearl River Delta is rather dense and data-rich, it took me 24 hours on my 2017 Macbook Pro just for it to reach stage 2 (the second stage out of three, the last of which generates the BTG files), at which point it inexplicably killed the process! So I was left with no choice but to bring out the heavy artillery, and on my beefier rig (8 core CPU, running at 14 threads) at last I was able to complete the whole process in just about three hours (wow!) with Ubuntu in WSL, compiled from source using the download_and_compile script, followed by adding ''install/terragear/bin'' to my user <code>$PATH</code> (in .zshrc, for me) – this way, all the terragear tools can be called normally.

So you see, the quickness of this step will depend entirely on a) the processing power at your disposal and b) the size and richness of the scenery you aim to generate. It may fail along the way for reasons you don’t understand – that’s OK, as long as you know you followed the process correctly just try again and most likely, it should work after some time.

[[Category:TerraGear]]

Howto:Use TerraGear Without Wanting to Kill Yourself

2021-10-14T18:02:14Z

IskenderWang: IskenderWang moved page Howto:Use TerraGear Without Wanting to Kill Yourself to Howto:Use TerraGear without wanting to kill yourself: Sentence case preferred

#REDIRECT [[Howto:Use TerraGear without wanting to kill yourself]]

Howto:Use TerraGear without wanting to kill yourself

2021-10-14T18:02:14Z

IskenderWang: IskenderWang moved page Howto:Use TerraGear Without Wanting to Kill Yourself to Howto:Use TerraGear without wanting to kill yourself: Sentence case preferred

Howto:Use TerraGear without wanting to kill yourself

2021-10-14T16:23:12Z

IskenderWang: /* Generate your terrain */ reworded

Howto:Use TerraGear without wanting to kill yourself

2021-10-14T16:17:57Z

IskenderWang: some clarification+ce

My aim was to go through this whole process successfully with as little manual labour (don’t have the knowledge to go fine tuning in QGIS? no problem! neither did I) as possible. "Automation ftw" has been my perspective entering this endeavour.

Special thanks to some brilliant lads who walked these roads long before I did, for helping me discover the way! Shoutout [[User:Fahim Dalvi|Fahim]], [[User:D-ECHO|D-ECHO]], and [[User:Legoboyvdlp|legoboyvdlp]], among several others (you know who you are) – in fact, big up the whole FG community.

Hopefully, some of you will find this guide helpful – though at the time of writing, it appears that TerraGear is on the verge of becoming obsolete any minute now. So, if nothing else, it can serve as a time capsule of sorts – a way of recollecting how this task used to be done. Cheers! –– [[User:IskenderWang|IskenderWang]] ([[User talk:IskenderWang|talk]])

== Directory structure ==

Inside your working directory for TerraGear you will simply need three subdirectories – one for your starting '''data''' which you will process as necessary, one for the '''work''' that the TG tools will achieve which provides it with the actual recipe for constructing your scenery, and one for the '''output''' or end product after running tg-construct (the final step) to generate your terrain. My directory structure in the midst of generating several sceneries was looking as pictured.

[[File:TG directory structure.png|thumb|right|A directory format one could expect to utilize while working with TG]]

As you can see, what I like to do is compartmentalise the various sceneries I’ve created/aim to create in their own subdirectories in ''/data'' so to prevent any confusion and easily keep them separate them as I use the TG tools. Since you’re generating terrain one at a time though, I’d strongly recommend clearing out your ''/work'' directory completely in between each.

== Gather all the necessary starting data ==

The materials you will need to embark on your TG journey are:
# '''Elevation data''': Numerous sources for that but the best option will probably still be [http://viewfinderpanoramas.org/dem3.html viewfinderpanorama].
# '''All the airports in the area you aim to build''': Best to use some tool like [[TerraMaster]] for this, but keep in mind that Docker TG (even running terragear:latest) seems to only support up to XP apt.dat version 1100 – it unfortunately won’t work with 1130 which is the version most of the latest and greatest airports on [https://gateway.x-plane.com the gateway] will come with, whereas if you compiled the latest TG you should be all good in this respect.
# '''[https://osmdata.openstreetmap.de/download/land-polygons-complete-4326.zip World landmass polygon]''': This is great since it serves as your base layer and also has very accurate coastlines.
# '''Shapefiles''': This is where things get interesting, there are numerous sources one can defer to. In the past, people mainly relied on vmap0 and there was a nice mapserver that made it easy to acquire. Nowadays, the mapserver’s gone by the looks of it. Today, while you can still choose [https://gis-lab.info/qa/vmap0-eng.html vmap0], far better options exist for most areas nowadays thanks to the availability of [https://download.geofabrik.de OSM shapefiles] (solid option almost anywhere these days) as well as [[Coordination of Information on the Environment|CORINE]] (Europe), [[Howto:Using QGIS to process NLCD data|NLCD]] (U.S.), and [[User:D-ECHO/Canada Land Cover|LCC]] (Canada), though these others can be a bit less straightforward to obtain and work with – thankfully, if you’d like to try them out there’s documentation for all of those supplied by some top blokes in the FG community.

== Process your elevation data ==

When you unpack your elevation data, make sure to somehow place ALL the hgt files you intend to use in the relevant folder for the scenery in question, with no subdirectories dividing them – using <code>mv</code> and the wildcard to move all the contents of the needed folders from VFP to where they belonged worked just fine for me; quick and efficient.

For only this step, you could use this command: <code>docker run -i -v ~/terragear-work:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash</code>

Since this is guaranteed to not have buggy elevation tools, so it’s really your call – you could do it just in case, especially if you’re working exclusively with Docker.

for f in ${PWD}/data/SRTM-3/scenery-in-question/*.hgt; do hgtchop 3 "${f}" "${PWD}/work/SRTM-3"; done
terrafit work/SRTM-3

Now for everything else: <code>docker run -i -v ~/terragear-work:/terragear-work/ -t flightgear/terragear:latest /bin/bash</code>

== Process your airports ==

Once you’ve collected all your airports from the gateway and you’re confident that they’ll work with genapts (perhaps through trial and error) you can just place all the zips in a burner directory and create an airports directory inside of that – then if you have zsh you can simply run my script here in the command line:

#!/bin/zsh
for file in *.zip
do
FILENAME=$( echo $file | sed s/.zip// )
ICAO=$( echo $file | sed s/_Scenery_Pack.zip// )
unzip $file
cd $FILENAME/"Earth nav data"
mv apt.dat ../../airports/$ICAO.dat
cd ../..
trash $FILENAME
done
trash ./*zip

and there you have it – all your .dat’s are there and sorted correctly by ICAO, which you can then transfer to your TG ''/data/airports'' folder.

Another way which is even better in a perfect world is to cut out the middleman by using the [https://github.com/mherweg/d-laser-fgtools dlaser tools], however this will always fetch the latest ones, which may not work for you if you’re using Docker TG.

Either way, this step may or may not be cumbersome depending on the amount of ''.dat'' files you’ll need, which can often include not just airports and airfields but also other things such as helipads – for instance, my Hong Kong scenery needed only 5 in total, while 12 tiles of scenery for Florida required 177 (!!) rasclart .dat files, which meant that using the ''gateway_pull.py'' script was a must (you'll need to run it through Python 2 though).

Then, once you’re ready, simply run this command:

for i in ./data/airports/scenery-in-question/*.dat; do genapts850 --threads --input=$i --work=./work --dem-path=SRTM-3; done

== Determine your bounding box coordinates ==

You may have already done this step in the very beginning, but if not, now would be a good time.
'''Think of the corners as bottom left, upper right, longitude BEFORE latitude.'''

In my case, for the Hong Kong scenery, the relevant coordinates were <code>113 21</code> and <code>115 23</code>.

== Crop your shapefiles ==

Before we dive more deeply into shapefiles, an important thing to mention is that while the .shp files will be the “stars of the show” in a sense, many of the other files it will come with are also NECESSARY! This means you should not try to delete files that may have seemed redundant to the uninitiated (i.e. me, at that point), and that if you’re going to move shapefiles between directories you’ll have to copy/move ALL of the ones that you will need which come in a set (by having the same filename, just different extensions). After all, most of those other files are there for a good reason, and not just to provide alternative options for GIS users as I had initially assumed. This had me stumped for a little while, wondering why this next tool wasn’t working and almost concerned that I wouldn’t be able to advance beyond this step, UNTIL I came across [https://gis.stackexchange.com/questions/262505/python-cant-read-shapefile/262509 this post on Stack Exchange] and it all made sense, so big up Michael Stimson as well for the helpful answer.

Something to note so that you don’t have to make that same mistake :) First, make sure you're inside ''/data/shapefiles'' (run a quick <code>cd</code> if not). Then, we simply run:

ogr2ogr -clipsrc 113 21 115 23 hk.shp land_polygons.shp

and so on for ALL the others as well – you can even use colons to run them all in one go, as I did. Be patient, though, because if your initial region & shapefiles are large then it can take longer than you may have expected at first.

== Split your shapefiles ==

At this point, you can put your cropped project shapefiles in their own directory and then delete or keep the full shapefiles depending on if you intend to use them again or not – that said, you should probably keep the land polygons (default) shapefile for future use since it can act as the base for the whole world, but for your cropped landmass shapefile for THIS scenery you can make a separate directory. I called mine simply “landmass” and now it may look something like what you see in the screenshot.

[[File:Shapefiles folder.png|thumb|center|The directory for shapefiles and how it could look at the extraction/splitting step]]

Here is Fahim's wonderful script, which allows us to perform this step:

#!/bin/bash
# Check arguments
if [ $# -lt 2 ]; then
echo "Usage: bash extract_features_shapefile.sh <path-to-shapefile> <path-to-output-dir>"
exit
fi
src_shp=$1
dest_dir=$2
# Extract available feature list in supplied shapefile
echo "Extracting available features..."
feature_list=$(ogrinfo -al $src_shp | grep 'fclass (String)' | tr -s ' ' | cut -d' ' -f5 | sort | uniq)
echo "Found following features:"
for feat in ${feature_list}; do
echo $feat
done
# Create shapefile per feature from supplied shapefile
echo "Creating new shapefiles..."
mkdir -p $dest_dir
for feat in ${feature_list}; do
echo "Processing $feat..."
mkdir -p $dest_dir/osm_$feat
ogr2ogr -where "FCLASS LIKE '"$feat"'" $dest_dir/osm_$feat/osm_$feat.shp $src_shp
done

Now you can use it on each of your shapefiles in the project directory, like this:

bash extract_features_shapefile.sh hk/gis_osm_landuse_a_free_1-hk.shp .

and so on.

This step prepares us to translate each of the specific types of land classes we need to the FlightGear format, as defined by Material definitions, while also deciding which ones to prune – bear in mind that many of these we can (and should) exclude because leaving them in the final recipe would add too much complexity.

== Map and decode your shapefiles ==

Once you reach this stage, you may now have a shit-ton of directories – that was certainly the case for me, as the screenshot illustrates.

[[File:Shapefiles split.png|thumb|center|Oh my, that seems like a lot]]

Not to fear – the light at the end of this tunnel is in sight already. Now we have to do something called [[OSM to materials mapping|mapping]], which is basically the translation I mentioned earlier, and then run ALL these inputs through the TG tool called ogr-decode.

This step can be time-consuming: deciding what to exclude [from the decoding step], and how to map the landclasses you do include.
You don’t need expertise in QGIS by any means – however, it can certainly come in handy with helping you view all your split shapefiles by importing them in and then tinkering with the layer visibilities to decide on what you don’t need/would add too much complexity versus what is necessary, because remember, performance in FG is of the essence as well (always keep that in mind during this step).

[[File:QGIS example for TG 1.png|thumb|right|Obviously we'd never need all this, that's why we had further split up these shapefiles]]

'''BRO TIP''': I didn’t realise this myself at first as a n00b to the toolkit, but I was advised by legoboyvdlp that osm_unclassified actually includes numerous roads and isn’t as irrelevant as the name would suggest, in fact it’s better to include this and PRUNE osm_residential for improved performance.

[[File:QGIS example for TG 2.png|thumb|left|Here you can see a big difference, not to mention I also ended up pruning the selected osm_residential landclass]]

When you map, try to use more standard landclass names as much as possible since those cover mostly everything – unless you have something specific in mind (such as for a custom scenery with its own set of material definitions), try to avoid using any landclasses that aren’t even mentioned in the [https://sourceforge.net/p/flightgear/terragear/ci/next/tree/src/BuildTiles/Main/default_priorities.txt default priorities file].
That said, if you insist on using other landclasses for whatever reason, you can always create your custom priorities file and add your own landclasses to it, and then just tell tg-construct to use that instead.
We’ll likely be doing this in bulk, so it makes a ton of sense to create a script for this (shoutout to D-ECHO who I would say has championed this approach) and place it in the TOP level of the TG working directory (so it’s level with ''/data'', ''/work'', ''/output'').

Then, all the arguments will essentially follow this sort of format exactly:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/landmass/
ogr-decode --max-segment 500 --line-width 12 --area-type Asphalt work/Asphalt data/shapefiles/osm_motorway/

and so on for ALL the other landclasses, hoping you’ve mapped it all correctly.
So once that’s set, you simply run the script:

./decode_osm_data.sh

(note: if you're doing it like this make sure it’s executable first, a quick <code>chmod +x</code> may come in handy – I like to do this here instead of invoking bash because when I was on Ubuntu in a zsh shell it may have been more efficient for it to simply work through the same shell, entirely up to your preference though)

== Generate your terrain ==

At long last! This step requires us to use the final utility in the TG workflow, <code>tg-construct</code>, and I like to use a modified version of D-ECHO’s script for this as well:

./tg-construct.sh

In my case, the one command I was truly running was as follows:

tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=113 --max-lon=115 --min-lat=21 --max-lat=23 --threads=3 --priorities=/usr/local/share/TerraGear/default_priorities.txt AirportArea SRTM-3 AirportObj Default Ocean Hole Road-Motorway Road-Trunk Road-Residential Road-Primary Road-Secondary Road-Tertiary Road-Service Road-Pedestrian Road-Steps Road-Unclassified Airport Pond Lake DryLake Reservoir IntermittentLake IntermittentStream Watercourse Canal Cliffs Glacier PackIce PolarIce Ocean Estuary Urban SubUrban Town Fishing Construction Industrial Port Dump FloodLand Lagoon Bog Marsh SaltMarsh Sand Saline Littoral Dirt Rock Lava OpenMining BuiltUpCover Transport Cemetery DryCrop IrrCrop Rice MixedCrop Vineyard Bamboo Mangrove ComplexCrop NaturalCrop CropGrass CropWood AgroForest Olives GolfCourse Greenspace GrassCover Grassland ScrubCover Scrub ShrubGrassCover SavannaCover Orchard DeciduousForest DeciduousBroadCover EvergreenForest EvergreenBroadCover MixedForest RainForest BarrenCover HerbTundra Sclerophyllous Heath Burnt SnowCover Island Default Void Null Unknown River Freeway Road Asphalt Railroad Stream

When I changed computers, the only thing I had to alter here was the thread count and the path to the default priorities file.

Now just sit back n relax and enjoy everything, you feel me, because you know what’s about to happen.

[[File:TG success.png|thumb|Success]]

And have patience, because this could take a while! '''Seriously!!'''
For legoboyvdlp, Ireland took a whole week (nonstop!!) to generate! And even for a relatively small scale such as Hong Kong and some of the surrounding area, because the Pearl River Delta is rather dense and data-rich, it took me 24 hours on my 2017 Macbook Pro just for it to reach stage 2 (the second stage out of three, the last of which generates the BTG files), at which point it inexplicably killed the process! So I had to pull out the big guns, and on my heavier rig (8 core CPU, running at 14 threads) at last I was able to complete the whole process in just about three hours (wow!) with Ubuntu in WSL, compiled from source using the download_and_compile script, followed by adding ''install/terragear/bin'' to my user <code>$PATH</code> (in .zshrc, for me) – this way, all the terragear tools can be called normally.

So you see, the quickness of this step will depend entirely on a) the processing power at your disposal and b) the size and richness of the scenery you aim to generate. It may fail along the way for reasons you don’t understand – that’s OK, as long as you know you followed the process correctly just try again and most likely, it should work after some time.

User:IskenderWang

2021-10-14T07:08:10Z

IskenderWang: Created page with "You can find me/show me some love over at my [https://github.com/IskenderWang GitHub page] Feel free to [https://www.youtube.com/watch?v=JDy-ZLlYEGw holla at ya boy] over on..."

You can find me/show me some love over at my [https://github.com/IskenderWang GitHub page]

Feel free to [https://www.youtube.com/watch?v=JDy-ZLlYEGw holla at ya boy] over on the [[Discord|Discord for FG]] as well ;)

Howto:Use TerraGear without wanting to kill yourself

2021-10-14T07:00:51Z

IskenderWang: Created page with "My aim was to go through this whole process successfully with as little manual labour (don’t have the knowledge to go fine tuning in QGIS? no problem! neither did I) as poss..."

My aim was to go through this whole process successfully with as little manual labour (don’t have the knowledge to go fine tuning in QGIS? no problem! neither did I) as possible. "Automation ftw" has been my perspective entering this endeavour.

Special thanks to some brilliant lads who walked these roads long before I did, for helping me discover the way! Shoutout [[User:Fahim Dalvi|Fahim]], [[User:D-ECHO|D-ECHO]], and [[User:Legoboyvdlp|legoboyvdlp]], among several others (you know who you are) – in fact, big up the whole FG community.

Hopefully, some of you will find this guide helpful – though at the time of writing, it appears that TerraGear is on the verge of becoming obsolete any minute now. So, if nothing else, it can serve as a time capsule of sorts – a way of recollecting how this task used to be done. Cheers! –– [[User:IskenderWang|IskenderWang]] ([[User talk:IskenderWang|talk]])

== Directory structure ==

Inside your working directory for TerraGear you will simply need three subdirectories – one for your starting '''data''' which you will process as necessary, one for the '''work''' that the TG tools will achieve which provides it with the actual recipe for constructing your scenery, and one for the '''output''' or end product after running tg-construct (the final step) to generate your terrain. My directory structure in the midst of generating several sceneries was looking as pictured.

[[File:TG directory structure.png|thumb|right|A directory format one could expect to utilize while working with TG]]

As you can see, what I like to do is compartmentalise the various sceneries I’ve created/aim to create in their own subdirectories in ''/data'' so to prevent any confusion and easily keep them separate them as I use the TG tools. Since you’re generating terrain one at a time though, I’d strongly recommend clearing out your ''/work'' directory completely in between each.

== Gather all the necessary starting data ==

The materials you will need to embark on your TG journey are:
# '''Elevation data''': Numerous sources for that but the best option will probably still be [http://viewfinderpanoramas.org/dem3.html viewfinderpanorama].
# '''All the airports in the area you aim to build''': Best to use some tool like [[TerraMaster]] for this, but keep in mind that Docker TG (even running terragear:latest) seems to only support up to XP apt.dat version 1100 – it unfortunately won’t work with 1130 which is the version most of the latest and greatest airports on [https://gateway.x-plane.com the gateway] will come with, whereas if you compiled the latest TG you should be all good in this respect.
# '''[https://osmdata.openstreetmap.de/download/land-polygons-complete-4326.zip World landmass polygon]''': This is great since it serves as your base layer and also has very accurate coastlines.
# '''Shapefiles''': This is where things get interesting, there are numerous sources one can defer to. In the past, people mainly relied on vmap0 and there was a nice mapserver that made it easy to acquire. Nowadays, the mapserver’s gone by the looks of it. Today, while you can still choose [https://gis-lab.info/qa/vmap0-eng.html vmap0], far better options exist for most areas nowadays thanks to the availability of [https://download.geofabrik.de OSM shapefiles] (solid option almost anywhere these days) as well as [[Coordination of Information on the Environment|CORINE]] (Europe), [[Howto:Using QGIS to process NLCD data|NLCD]] (U.S.), and [[User:D-ECHO/Canada Land Cover|LCC]] (Canada), though these others can be a bit less straightforward to obtain and work with – thankfully, if you’d like to try them out there’s documentation for all of those supplied by some top blokes in the FG community.

== Process your elevation data ==

When you unpack your elevation data, make sure to somehow place ALL the hgt files you intend to use in the relevant folder for the scenery in question, with no subdirectories dividing them – using <code>mv</code> and the wildcard to move all the contents of the needed folders from VFP to where they belonged worked just fine for me; quick and efficient.

For only this step, you could use this command: <code>docker run -i -v ~/terragear-work:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash</code>

Since this is guaranteed to not have buggy elevation tools, so it’s really your call – you could do it just in case, especially if you’re working exclusively with Docker.

for f in ${PWD}/data/SRTM-3/scenery-in-question/*.hgt; do hgtchop 3 "${f}" "${PWD}/work/SRTM-3"; done
terrafit work/SRTM-3

Now for everything else: <code>docker run -i -v ~/terragear-work:/terragear-work/ -t flightgear/terragear:latest /bin/bash</code>

== Process your airports ==

Once you’ve collected all your airports from the gateway and you’re confident that they’ll work with genapts (perhaps through trial and error) you can just place all the zips in a burner directory and create an airports directory inside of that – then if you have zsh you can simply run my script here in the command line:

#!/bin/zsh
for file in *.zip
do
FILENAME=$( echo $file | sed s/.zip// )
ICAO=$( echo $file | sed s/_Scenery_Pack.zip// )
unzip $file
cd $FILENAME/"Earth nav data"
mv apt.dat ../../airports/$ICAO.dat
cd ../..
trash $FILENAME
done
trash ./*zip

and there you have it – all your .dat’s are there and sorted correctly by ICAO, which you can then transfer to your TG ''/data/airports'' folder.

Another way which is even better in a perfect world is to cut out the middleman by using the [https://github.com/mherweg/d-laser-fgtools dlaser tools], however this will always fetch the latest ones, which may not work for you if you’re using Docker TG.

Either way, this step may or may not be cumbersome depending on the amount of ''.dat'' files you’ll need, which can often include not just airports and airfields but also other things such as helipads – for instance, my Hong Kong scenery needed only 5 in total, while 12 tiles of scenery for Florida required 177 (!!) rasclart .dat files, which meant that using the ''gateway_pull.py'' script was a must (you'll need to run it through Python 2 though).

Then, once you’re ready, simply run this command:

for i in ./data/airports/scenery-in-question/*.dat; do genapts850 --threads --input=$i --work=./work --dem-path=SRTM-3; done

== Determine your bounding box coordinates ==

You may have already done this step in the very beginning, but if not, now would be a good time.
'''Think of the corners as bottom left, upper right, longitude BEFORE latitude.'''

In my case, for the Hong Kong scenery, the relevant coordinates were <code>113 21</code> and <code>115 23</code>.

== Crop your shapefiles ==

Before we dive more deeply into shapefiles, an important thing to mention is that while the .shp files will be the “stars of the show” in a sense, many of the other files it will come with are also NECESSARY! This means you should not try to delete files that may have seemed redundant to the uninitiated (i.e. me, at that point), and that if you’re going to move shapefiles between directories you’ll have to copy/move ALL of the ones that you will need which come in a set (by having the same filename, just different extensions). After all, most of those other files are there for a good reason, and not just to provide alternative options for GIS users as I had initially assumed. This had me stumped for a little while, wondering why this next tool wasn’t working and almost concerned that I wouldn’t be able to advance beyond this step, UNTIL I came across [https://gis.stackexchange.com/questions/262505/python-cant-read-shapefile/262509 this post on Stack Exchange] and it all made sense, so big up Michael Stimson as well for the helpful answer.

Something to note so that you don’t have to make that same mistake :) First, make sure you're inside ''/data/shapefiles'' (run a quick <code>cd</code> if not). Then, we simply run:

ogr2ogr -clipsrc 113 21 115 23 hk.shp land_polygons.shp

and so on for ALL the others as well – you can even use colons to run them all in one go, as I did. Be patient, though, because if your initial region & shapefiles are large then it can take longer than you may have expected at first.

== Split your shapefiles ==

At this point, you can put your cropped project shapefiles in their own directory and then delete or keep the full shapefiles depending on if you intend to use them again or not – that said, you should probably keep the land polygons (default) shapefile for future use since it can act as the base for the whole world, but for your cropped landmass shapefile for THIS scenery you can make a separate directory. I called mine simply “landmass” and now it may look something like what you see in the screenshot.

[[File:Shapefiles folder.png|thumb|center|The directory for shapefiles and how it could look at the extraction/splitting step]]

Here is Fahim's wonderful script, which allows us to perform this step:

#!/bin/bash
# Check arguments
if [ $# -lt 2 ]; then
echo "Usage: bash extract_features_shapefile.sh <path-to-shapefile> <path-to-output-dir>"
exit
fi
src_shp=$1
dest_dir=$2
# Extract available feature list in supplied shapefile
echo "Extracting available features..."
feature_list=$(ogrinfo -al $src_shp | grep 'fclass (String)' | tr -s ' ' | cut -d' ' -f5 | sort | uniq)
echo "Found following features:"
for feat in ${feature_list}; do
echo $feat
done
# Create shapefile per feature from supplied shapefile
echo "Creating new shapefiles..."
mkdir -p $dest_dir
for feat in ${feature_list}; do
echo "Processing $feat..."
mkdir -p $dest_dir/osm_$feat
ogr2ogr -where "FCLASS LIKE '"$feat"'" $dest_dir/osm_$feat/osm_$feat.shp $src_shp
done

Now you can use it on each of your shapefiles in the project directory, like this:

bash extract_features_shapefile.sh hk/gis_osm_landuse_a_free_1-hk.shp .

and so on.

This step prepares us to translate each of the specific types of land classes we need to the FlightGear format, as defined by Material definitions, while also deciding which ones to prune – bear in mind that many of these we can (and should) exclude because leaving them in the final recipe would add too much complexity.

== Map and decode your shapefiles ==

Once you reach this stage, you may now have a shit-ton of directories – that was certainly the case for me, as the screenshot illustrates.

[[File:Shapefiles split.png|thumb|center|Oh my, that seems like a lot]]

Not to fear – the light at the end of this tunnel is in sight already. Now we have to do something called [[OSM to materials mapping|mapping]], which is basically the translation I mentioned earlier, and then run ALL these inputs through the TG tool called ogr-decode.

This step can be time-consuming: deciding what to exclude [from the decoding step], and how to map the landclasses you do include.
You don’t need expertise in QGIS by any means – however, it can certainly come in handy with helping you view all your split shapefiles by importing them in and then tinkering with the layer visibilities to decide on what you don’t need/would add too much complexity versus what is necessary, because remember, performance in FG is of the essence as well (always keep that in mind during this step).

[[File:QGIS example for TG 1.png|thumb|right|Obviously we'd never need all this, that's why we had further split up these shapefiles]]

'''BRO TIP''': I didn’t realize this myself at first as a n00b to the toolkit, but I was advised by legoboyvdlp that osm_unclassified actually includes numerous roads and isn’t as irrelevant as the name would suggest, in fact it’s better to include this and PRUNE osm_residential for improved performance.

[[File:QGIS example for TG 2.png|thumb|left|Here you can see a big difference, not to mention I also ended up pruning the selected osm_residential landclass]]

When you map, try to use more standard landclass names as much as possible since those cover mostly everything – unless you have something specific in mind (such as for a custom scenery with its own set of material definitions), try to avoid using any landclasses that aren’t even mentioned in the [https://sourceforge.net/p/flightgear/terragear/ci/next/tree/src/BuildTiles/Main/default_priorities.txt default priorities file].
That said, if you insist on using other landclasses for whatever reason, you can always create your custom priorities file and add your own landclasses to it, and then just tell tg-construct to use that instead.
We’ll likely be doing this in bulk, so it makes a ton of sense to create a script for this (shoutout to D-ECHO who I would say has championed this approach) and place it in the TOP level of the TG working directory (so it’s level with ''/data'', ''/work'', ''/output'').

Then, all the arguments will essentially follow this sort of format exactly:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/landmass/
ogr-decode --max-segment 500 --line-width 12 --area-type Asphalt work/Asphalt data/shapefiles/osm_motorway/

and so on for ALL the other landclasses, hoping you’ve mapped it all correctly.
So once that’s set, you simply run the script:

./decode_osm_data.sh

(note: if you're doing it like this make sure it’s executable first, a quick <code>chmod +x</code> may come in handy – I like to do this here instead of invoking bash because when I was on Ubuntu in a zsh shell it may have been more efficient for it to simply work through the same shell, entirely up to your preference though)

== Generate your terrain ==

At long last! This step requires us to use the final utility in the TG workflow, <code>tg-construct</code>, and I like to use a modified version of D-ECHO’s script for this as well:

./tg-construct.sh

In my case, the one command I was truly running was as follows:

tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=113 --max-lon=115 --min-lat=21 --max-lat=23 --threads=3 --priorities=/usr/local/share/TerraGear/default_priorities.txt AirportArea SRTM-3 AirportObj Default Ocean Hole Road-Motorway Road-Trunk Road-Residential Road-Primary Road-Secondary Road-Tertiary Road-Service Road-Pedestrian Road-Steps Road-Unclassified Airport Pond Lake DryLake Reservoir IntermittentLake IntermittentStream Watercourse Canal Cliffs Glacier PackIce PolarIce Ocean Estuary Urban SubUrban Town Fishing Construction Industrial Port Dump FloodLand Lagoon Bog Marsh SaltMarsh Sand Saline Littoral Dirt Rock Lava OpenMining BuiltUpCover Transport Cemetery DryCrop IrrCrop Rice MixedCrop Vineyard Bamboo Mangrove ComplexCrop NaturalCrop CropGrass CropWood AgroForest Olives GolfCourse Greenspace GrassCover Grassland ScrubCover Scrub ShrubGrassCover SavannaCover Orchard DeciduousForest DeciduousBroadCover EvergreenForest EvergreenBroadCover MixedForest RainForest BarrenCover HerbTundra Sclerophyllous Heath Burnt SnowCover Island Default Void Null Unknown River Freeway Road Asphalt Railroad Stream

When I changed computers, the only thing I had to alter here was the thread count and the path to the default priorities file.

Now just sit back n relax and enjoy everything, you feel me, because you know what’s about to happen.

[[File:TG success.png|thumb|Success]]

And have patience, because this could take a while! '''Seriously!!'''
For legoboyvdlp, Ireland took a whole week (nonstop!!) to generate! And even for a relatively small scale such as Hong Kong and some of the surrounding area, because the Pearl River Delta is rather dense and data-rich, it took me 24 hours on my 2017 Macbook Pro just for it to reach stage 2 (the second stage out of three, the last of which generates the BTG files), at which point it inexplicably killed the process! So I had to pull out the big guns, and on my heavier rig (8 core CPU, running at 14 threads) at last I was able to complete the whole process in just about three hours (wow!) with Ubuntu in WSL, compiled from source using the download_and_compile script, followed by adding ''install/terragear/bin'' to my <code>$PATH</code> – this way, all the terragear tools can be called normally.

So you see, the quickness of this step will depend entirely on a) the processing power at your disposal and b) the size and richness of the scenery you aim to generate. It may fail along the way for reasons you don’t understand – that’s OK, as long as you know you followed the process correctly just try again and most likely, it should work after some time.

File:TG success.png

2021-10-14T06:36:18Z

IskenderWang:

tg-construct has finished successfully

File:Shapefiles folder.png

2021-10-14T06:13:26Z

IskenderWang:

The directory for shapefiles and how it could look at the extraction/splitting step

User talk:Gijs

2021-10-14T06:09:38Z

IskenderWang: /* Oversight/deletion of images */ new section

{{Archives|[[/Archive 2008-2011|2008-2011]]|[[/Archive 2012|2012]]}}

=="Talk:Eurocopter EC135" (Author request: Author blanked page)==

Did I miss something? Can't remember seen that...
Can you tell what it was about?
Cheers --[[User:HHS|HHS]] 12:24, 17 February 2013 (UTC)

: Hi,
: F-JJTH wrote " Heiko, is V1.0 full "Rembrandt compatible" ?" on the page but blanked it shortly thereafter. I think he found the answer already... So all I did was delete that blank page.
: [[User:Gijs|Gijs]] 16:08, 17 February 2013 (UTC)

==About the wiki..==
Hi Gijs, hope all is well. I was stopping by because I noticed the words "Please post only encyclopedic information that can be verified by external sources. Please maintain a neutral, unbiased point of view. " in the editor. Its really not right to say this, because the FlightGear wiki has to be a "primary source". The contributions are typically original writing, and it specifically includes opinions (such as reviews), as well as first-hand accounts. Thank you. [[User:Fg|Fg]] 20:19, 17 July 2013 (UTC)

The wiki is mostly a primary source, saying "Please post only encyclopedic information that can be verified by external sources. .. " makes no sense. Most of what is written here is orginal content, and it does not make sense to have this in the edit box. Also, I don't agree with many of the articles you have deleted. These are small issues in view of your large contributions to the project, and I want to thank you for those, but I must also bring up these issues. Thanks again. [[User:Fg|Fg]] ([[User talk:Fg|talk]]) 20:32, 28 October 2013 (UTC)
: Hi,
: You're right about the "external sources" statement. That was just a default from MediaWiki but is not very applicable to our wiki. I've removed it now. Thanks for notifying me!
: What is it that you don't agree with? Is it the airport articles? Those were not deleted yet, they were only marked for deletion. The notice mentioned why I think they should be deleted. Feel free to share your arguments that make you think they should be kept. As the template stated "Do not remove this tag until the discussion is closed.", so I've placed the templates back and am looking forward to your (argued) opinion.
: Cheers,
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 17:47, 31 October 2013 (UTC)
::Great, thanks for fixing that! Come to think of it "Please maintain a neutral, unbiased point of view." may also be unneeded, as we have sections for reviews (with opinions) of aircraft, etc. but I will leave that up to you. I will check out the articles for deletion again. Thank you. [[User:Fg|Fg]] ([[User talk:Fg|talk]]) 22:57, 4 December 2013 (UTC)

== Adding the village pump to the sidebar or not ==

I have been pondering adding the village pump to the sidebar. I would probably add it between Recent changes and Random page. I have read in a bit on the sidebar on the MediaWiki help pages, but before I actually do it I want to ask you about your opinion about doing that.

The biggest pros and cons as I see it is that anyone will find it so it will be used a bit more, but at the same time that those that will not even read a few sentences of text (including people not comfortably reading English) sometimes will go there for help on using the simulator itself instead of going to the forum.

So what do you think about it?

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 09:00, 5 January 2014 (UTC)

: Hi,
: how about creating a "Wiki" header that contains the "Recent changes" and "Help" links? It could then also have a link to the village pump. I don't think we should call it "Village pump" though, as probably no-one will guess that's a place to talk about the wiki ;-) Something like "Wiki discussions" or so is more descriptive...
: Cheers, [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 13:52, 5 January 2014 (UTC)

:: I have been thinking of changing the name of that page as well. "Village pump" is used on WikiMedia Commons, the Swedish Wikipedia (though translated) and probably a few other wikis so someone coming from one of those places would be at home with it, but not everyone are from those places.
:: I have in the past considered suggesting changing it into say "Editor lounge" or rather something aviation related, but for instance "Pilot lounge" would have been so horribly misleading. ;-)
:: A "Wiki" header will help organise the contents but might hide contents by default, but hopefully people are curious enough to spend a few seconds looking around.
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 19:19, 5 January 2014 (UTC)
::: Went ahead and added a link in the sidebar titled "[[FlightGear wiki:Village pump|Discuss!]]".
::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 13:58, 2 March 2014 (UTC)

== Help with Fatal error: Class 'Services_JSON' /CategoryTree/CategoryTreeFunctions.php on line 224 Error ==

Gijs

I saw you had mentioned the issue with the JSON class. I was wondering if you ever found a resolution for this problem. I support a wiki group and have been suffering for the last month trying to resolve this issue. I would be grateful for any help.

I am running mediawiki 1.22 with php 5.3.10

On another note, I have been flying RC planes and gliders for years. I have wanted to get a simulator program. Would this be a good one to start with ?

Many Thanks

Peter

: Hi Peter,
: like I said at [[FlightGear wiki:Village pump#Found bugs]]
: "The CategoryTree extension relies on a function that was removed as of 1.22.0, so the extensions needs some fixing. I've disabled it for now."
: So my solution was to disable it. The extension itself needs fixing to work with more recent version of MediaWiki, that's not something I intended to do ;-)
: And yes, FlightGear would be a good simulator to start (and even stick) with. I'm biased though...
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 09:56, 25 March 2014 (UTC)

== Two bot jobs – Moving categories to plural form ==

Hello Gijs, I got stumbled upon a request for a bot job that I added to [[User talk:BotFlightGear#Moving Category:List and Category:Resource to titles in plural form|User talk:BotFlightGear]] a while ago. Just a gentle reminder. ;-)

The requested moves are intended to be a part of trying to make the category names more logical and harder to mistype etc.

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 14:51, 1 May 2014 (UTC)

: Thanks for the reminder. He's [http://wiki.flightgear.org/Special:Contributions/BotFlightGear running]!
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 15:33, 1 May 2014 (UTC)

:: Thank you kindly. :-)
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:48, 1 May 2014 (UTC)

== 06/2014 newsletter: too much of a mess ==

: [http://wiki.flightgear.org/index.php?title=FlightGear_Newsletter_June_2014&curid=12417&diff=73490&oldid=73455 Use new templates; cleanup (except for Canvas stuff, which is too much of a mess right now))]

:: Please feel free to clean up or just remove the "mess". I realize that it's messy (Thorsten also said so recently), I added those things when we didn't have a whole lot of content, and I didn't bother writing anything from scratch, I just took stuff from the forum using the [[Instant-Cquotes]] script, which is why it's a bit "messy". But if you should decide to clean it up, I'll volunteer to help cleaning up navdisplay.mfd::update() on your behalf ;-) --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:00, 29 June 2014 (UTC)

::: Hi,
::: There's not just instant cquotes, but also sections with no text at all. Garmin and Aircraft Center for example. I don't know how someone who hasn't been following the progress is supposed to make sense out of that; which is why I think you're the best person to work on it.
:::: When I close the newsletter and "publish" it, I usually make sure the layout is somewhat readable. Right now that job would require more time than I have and/or would like to spend.
::: Cheers,
::: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 19:27, 30 June 2014 (UTC)

:::: I've added instant-cquotes content from the corresponding wiki articles. Sorry for the mess, and thanks for the new newsletter layout - even though it's a bit awkward to edit now, can we still edit individual sections directly please ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:41, 30 June 2014 (UTC)

::::: Hey, good job - that looks indeed much better. I was wondering if we should slightly extend the template, and then simply port [[Instant-cquotes]] to optionally create tailored sections for the newsletter, i.e. without the cquote, and using galleries, what do you think ?--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:37, 30 June 2014 (UTC)

:::::: With the new section titles (that come with an author field), we don't need those quotes to make clear who's saying stuff. I've changed them to running texts now, which is a lot nicer to read IMO. Doing that on the first run is a lot easier than doing it later on, as I had to dig up the posts, get acquainted with the subject etc. The script you're using adds quite some nasty HTML to the wiki (treating normal urls as wiki links, adding dozens of <nowiki> </nowiki>, ignoring bullet lists), so I would suggest to not use it on large scale for now. If you can change it to produce running texts with correct wiki markup it would be a whole lot better ;-)
:::::: I'll have a look if we can re-enable sectional edits. Removing that was definitely unintended. My intention was to make the newsletter a little more appealing and less of an ordinary wiki article.
:::::: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 20:44, 30 June 2014 (UTC)

:: right, what I am more concerned about is proper crediting-I already added Tom's nick twice there, because I wasn't involved in the development of the [[Aircraft Center]], I merely posted some updates on the forum-which is why the cquotes script used my nick, and it was obvious that it was just a quote-now it looked like I was announcing my own work. But obviously the credit should go to TheTom & Zakalawe. The changes you suggest should be straightforward still. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:50, 30 June 2014 (UTC)

::: The new "By" tag is not meant to be used to credit the person that the section is about. It is meant to show who's written that section. So if you write something about Tom's work, your name ends up under the tile "By Hooray". Tom's name will end up in the text, where you can something along the lines of "Thanks to Tom's recent work...". Some people are not happy with articles that appear to have been written by them when they are not.
::: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 20:59, 30 June 2014 (UTC)

:: ok, thanks for clarifying - maybe we should simply make it '''Written by ''' (and '''Developed by''') then to be on the safe side, i.e. change the template accordingly ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:01, 30 June 2014 (UTC)
:: And just to be clear about it, I totally appreciate your work here, and I am looking forward to seeing if we can find a way to generalize the concept and reuse it for the changelog, even if that should just mean to partially include contents from 6 newsletters in it (as per [[FlightGear_wiki:Village_pump#Template_for_announcement_of_changes_and_new_features]]).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:05, 30 June 2014 (UTC)

== Livery texture aspect ratio ==

Did you accidentally remove the paragraph about that all liveries for an aircraft have to have the same aspect ratio in [http://wiki.flightgear.org/index.php?title=Howto:Edit_a_livery&diff=74832&oldid=74831 this edit]?

Apart from that thanks for catching and fixing my ''very'' old error, n2 → 2n ;-)

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:31, 8 August 2014 (UTC)

: No, it was deliberate. UVmaps use coordinates like 0.3*width, 0*heigth instead of absolute values (eg. 3rd pixel up, 15th pixel to the right). That's also why you can replace textures with different resolutions without having to edit the mapping.
: You'll probably get an overly stretched texture (since pixels will beno longer "squares", as in the most likely ideal original mapping), but it is not impossible or principally wrong ;-)
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 16:53, 8 August 2014 (UTC)

:: Thanks for the explanation.
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 18:58, 8 August 2014 (UTC)

== Strange infobox image bug ==
I recently found a very strange bug I can not wrap my head around. It appears that an image from English Wikipedia is used instead of an image with the identical name on this wiki.

When I looked at the rather new page {{plink|Yakovlev Yak-130|76122}} as well as the page I moved it from, I noticed that the aircraft picture is a photo and was about to edit the file page. Instead of seeing a photo on the file page I see a FlightGear screenshot [[:File:Yak-130.jpg]]. The {{tl|infobox aircraft}} seems to be as it should be. Going to English Wikipedia and looking for the image I find the very same image as I see rendered on the page, {{wikipedia|File:Yak-130.jpg}}.

I have no idea what is going on.

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:53, 10 September 2014 (UTC)

: Hi,
: that seems to be an unwanted side-effect of [[mw:InstantCommons]]. In principle this shouldn't conflict, but I suspect someone did load the Commons image before uploading the one to our wiki. Thus, the Commons one ended up in the thumbnail cache.
: I've now disabled this feature, as I don't think we use it anywhere on the wiki. Not even sure why it was enabled in the first place...
: Cheers,
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 14:44, 10 September 2014 (UTC)

:: Thanks for the help. I would not even have imagined.
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 16:08, 10 September 2014 (UTC)

== PA32 deleted ==

Hi

Noticed this is deleted - not enough info or inappropriate? Pls let me know. I have set myself a personal goal to review over 35 civil aviation aircraft and upload screenshots.

http://wiki.flightgear.org/index.php?title=Piper_PA-32&action=edit&redlink=1

[[User:Openflight|Openflight]] ([[User talk:Openflight|talk]]) 01:26, 18 September 2015 (EDT)

: Not enough info (nothing FlightGear specific). The only content was "The Piper PA 32 is a single engined aircraft built by Piper." That's not what our wiki is for ;-) Feel free to restart the article if you've got more to write now.
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 02:30, 18 September 2015 (EDT)

Sure will do, thanks. [[User:Openflight|Openflight]] ([[User talk:Openflight|talk]]) 02:44, 18 September 2015 (EDT)

== Adding Table of Aircraft to Wiki page ==

Hi, if it's ok , will edit Wiki home page and add link to table of aircraft as follows:

Using
New to FlightGear
Frequently asked questions • Troubleshooting • List of aircraft •
Installing scenery • Installing aircraft
Helicopter flying

My concern is those new to Flight Gear do not get to see the list of aircraft and the aircraft detaisl right away from Wiki home page or FG home page

== Wrong link ==

Hi Gijs!
You still have a link for our Gitorius account you know.

== Red Leader's pygments Nasal lexer ==

Hi Gijs, referring to Red Leader's work at [http://wiki.flightgear.org/FlightGear_wiki:Village_pump#Nasal_Syntaxhighlighting], is there any way we/I can help to get this applied ? If you are too busy to handle/review this currently, can we get in touch with someone else who's got the corresponding access/privileges on the wiki (Curt, Simon?). Thanks --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:19, 22 April 2016 (EDT)

'''BUMP''' ?

== Wiki Edits ==

Gijs,

Thanks for your recent edits of Howto pages I'm working on. In my future posts, I'll try to follow suit with the style corrections you made.

Is there a style guide I should read?

[[User:Callahanp|Callahanp]] ([[User talk:Callahanp|talk]]) 07:55, 3 August 2016 (EDT)

: Hi,
: there is, at [[FlightGear wiki:Manual of Style]]. [[Help:Formatting]] may also be useful to consult when you're in doubt about certain things. I mostly changed some minor things that you now know how to do "correct", so don't be afraid to make mistakes. We're very pleased with your contributions!
: Cheers,
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:44, 3 August 2016 (EDT)

== SOTM in the Newsletter of August 2016 ==

Hi Gijs, would you please add the following text to August's Newsletter (below the "Screenshots" section)?

<syntaxhighlight>
==== Screenshot of the Month ====
FlightGear's Screenshot of the Month August 2016 is ''Bad weather take off from EDDI'' by {{usr|Dg-505|Jonathan S. (Dg-505)}}
[[File:Ju-52 taking off from EDDI.jpg|900px|center|Bad weather take off from EDDI]]

If you want to participate in the screenshot contest of September 2016, you can submit your candidate to [https://forum.flightgear.org/viewtopic.php?f=19&t=30364 this] forum topic. Be sure to see the [https://forum.flightgear.org/viewtopic.php?f=19&t=30364#p293984 first post] for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of September 2016.
</syntaxhighlight>

Thanks
Jonathan

: {{done}}
: [[User:Red_Leader|'''''Red Leader''''']] ([[User_talk:Red_Leader|Talk]], [[Special:Contributions/Red_Leader|contribs]]) 11:30, 8 September 2016 (EDT)

Thank you :-)

[[User:Dg-505|Dg-505]] ([[User talk:Dg-505|talk]]) 11:50, 8 September 2016 (EDT)

== Oversight/deletion of images ==

Hello Gijs! I was wondering if it would be at all possible for you to completely [https://en.wikipedia.org/wiki/Wikipedia:Oversight oversight] or, if that's not possible here, to just completely delete the pages [[File:Split shapefiles.png]] and '''File:Split shapefiles rm.png'''. When I uploaded the screenshot, I forgot to exclude a name I would have preferred not become associated with my alias IskenderWang, in the interest of privacy. Once this matter is resolved, you don't need to let me know, in fact you can delete this talk page entry itself as well. I would greatly appreciate any help. Cheers! [[User:IskenderWang|IskenderWang]] ([[User talk:IskenderWang|talk]]) 06:09, 14 October 2021 (UTC)

File:Shapefiles split.png

2021-10-14T05:55:00Z

IskenderWang:

Shapefiles directory, now with split shapefiles

File:QGIS example for TG 2.png

2021-10-14T05:38:46Z

IskenderWang:

Screenshot of QGIS displaying shapefiles for TG use

File:QGIS example for TG 1.png

2021-10-14T05:37:07Z

IskenderWang:

Screenshot of QGIS displaying shapefiles for TG use

File:TG directory structure.png

2021-10-14T03:23:27Z

IskenderWang:

A directory format one could expect to utilize while working with TG