Ipanema, Rio de Janiero and night.

Americas Scenery

2024-01-10T23:34:48Z

David.megginson: Update for broader coverage.

Canada-US custom scenery

2024-01-10T23:31:53Z

David.megginson: David.megginson moved page Canada-US custom scenery to FlightGear Americas Scenery (custom): SCenery renamed

#REDIRECT [[FlightGear Americas Scenery (custom)]]

Americas Scenery

2024-01-10T23:31:53Z

David.megginson: David.megginson moved page Canada-US custom scenery to FlightGear Americas Scenery (custom): SCenery renamed

Custom scenery covering all of the Continental US, most of Canada, and parts of Mexico is available at

https://davidmegginson.github.io/fgfs-scenery-build/

This scenery has detailed coastlines and waterways, together with basic roads, railroads, and powerline rights-of-way, all from OpenStreetMap (to be supplemented by [[osm2city]]). The airports come from a more-recent snapshot of the X-Plane Scenery Gateway, so they are more up-to-date than the ones in the default FlightGear distro. It was begun in 2022, and as of May 2023, is being continually updated.

== Gallery ==

<gallery mode="packed">
File:Vancouver BC evening.png|Downtown Vancouver BC at dusk, facing north, with Kitsilano in the foreground and Stanley Park on the left.
File:St Louis arch.png|Flying towards the Gateway Arch in St Louis, MO.
File:Jasper BC Rocky Mountains.png|SAR DHC-3 Otter flying through the Rocky Mountains near Jasper AB (CYJA).
File:Miami Beach FL hazy afternoon.png|Piper Cub flying along Miami Beach on a hazy afternoon.
File:Goderich ON winter.png|Cessna 140 approaching a frozen-over Georgian Bay (Lake Huron) in winter, near Goderich ON (CYGD).
</gallery>

[[Category:Scenery in North America]]
[[Category:Custom scenery]]

Howto:Create custom terrain

2023-12-02T16:02:51Z

David.megginson: /* Resources */ fix dead link

'''Custom terrain''' in [[FlightGear]] is currently generated through processing shapefiles with [[TerraGear]]. In order to add custom scenery to FlightGear, you must create a custom shapefile.

A shapefile is a proprietary spatial information format. You can edit them with almost every GIS package. QGIS is quite a good package for this type of project.

Your goal for editing area data is to create a shapefile of a seamless layer of polygons which correspond to some type of land cover. This data is then fed into [http://mapserver.flightgear.org the mapserver] and, possibly, TerraGear to create new scenery.

=== Evaluating the current data ===
Before you begin, please make sure the area you want to improve doesn't already have good coverage. Just because it looks bad in FlightGear does not mean the area has not been improved. For this, you will need to check the Flightgear Mapserver, at [http://mapserver.flightgear.org/ mapserver.flightgear.org].

Let's take a look at the Finistère in Brittany, Western France: if you click [http://mapserver.flightgear.org/map/?lon=-4.41840585539649&lat=48.4484146908477&zoom=11&layers=0B000000FTTFFFFFTFT here], you will quickly see and understand how FlightGear interprets the data pertaining to Finistère county. Some towns/cities (red), a few forests (green), etc. Overall, it is not a very good resolution: a lot of angles, the detail level is not that good, some towns are missing. If you want a better definition on ground, there is some work to be done! The goal being to obtain something like this:

# [http://mapserver.flightgear.org/map/?lon=13.40385&lat=52.50199&zoom=11&layers=B0000000TFFFTFFFTFFFFFFF Berlin]
# [http://mapserver.flightgear.org/map/?lon=9.40368&lat=47.63699&zoom=11&layers=B0000000TFFFTFFFTFFFFFFF Bodensee surroundings]
# [http://mapserver.flightgear.org/map/?lon=-88.55704&lat=43.98436&zoom=11&layers=B0000000TFFFTFFFTFFFFFFF Oshkosh surroundings]
# [http://mapserver.flightgear.org/map/?lon=-62.87648&lat=17.69865&zoom=10&layers=B0000000TFFFTFFFTFFFFFFF Carribean Islands]

You will immediately notice the improvement to the ground. When flying, the difference is huge. Moreover, this enables the autogeneration of cities, trees, farmland, and so on.

=== Downloading the Landsat pictures ===
[[File:C31e36f2a2cbb278a1603dfe2ba91193.media.395x288.png|thumb|200px|Landsat Map Search]]
[[File:1c9334d970963364b5ce1bc3a166a4fa.media.426x192.png|thumb|200px|Preview and download Landsat image]]
Browse to [http://glcfapp.glcf.umd.edu:8080/esdi/index.jsp the Earth Science Data Interface interface] to grab your [http://en.wikipedia.org/wiki/Landsat Landsat] data.

# Click ''Map Search''.
# Tick the ETM+ box (left column).
# Click on ''Update Map'' on the right bottom of the map.
# Click on the ''Place'' tab on the upper side of the map, in order to do a search by place, or you can do a search by latitude/longitude.
# In the Place field, type ''Amsterdam, Netherlands'' for instance.
# Now click the button with the mouse and the small + sign. This will allow you to select image tiles. Select all images that cover your area of interest, in our example this is just one image.
# Click on ''Preview and download''. This bring you to a selection page were you can choose what image you want to download. It is likely that there are pictures available from different dates for your area. Picking the most recent one is best, for known reasons.
# Clicking the ID will not bring you directly to the download page, first you have to click the ''Download'' button.
# Download the _nn80.tif.gz file (if this is not available, try an older image). Note that Landsat images are separated in different bands. Band 1/2/3/4/5/7 have 30m/Pixel resolution while band 8 (_nn80.tif.gz) has 15 meters per pixel.
# Uncompress the ''.tif.gz'' files in the directory of your choice.

=== Working with QGIS ===
[[File:QGIS_texel_1.png|thumb|200px|QGIS with the TIFF image.]]
[[File:QGIS_texel_2.png|thumb|200px|Creating the class column.]]
[[File:QGIS_texel_3.png|thumb|200px|Toggle editing.]]
[[File:QGIS_texel_4.png|thumb|200px|Tracing the small island.]]
[[File:QGIS_texel_5.png|thumb|200px|The finished small island polygon.]]
Using a GIS software gives you the opportunity to realize a full range of interesting operations: modification of map data, updates on the ground classification, etc.

* QGIS Download for Linux/OSX/Windows [http://www.qgis.org/en/download/current-software.html]

The following is largely adapted from the [http://stattosoftware.com/flightgear/tutorial/index.html original QGIS scenery tutorial], which you may find of use.
# Launch QGIS.
# Click on <tt>Layer > Add a Raster layer</tt>.
# Modify the filter to search for *.tif files.
# Add the TIFF file you have just downloaded.
# Rightclick on the image in the layer sidebar and choose <tt>Set layer CRS</tt>, to select a projection model. This depends on the location of the area you're about to create. Look up your project's UTM coordinate through [http://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg this image]. For Texel this is 31U, north of the equator, so we choose <tt>Projected Coordinate Systems > Universal Transverse Mercator (UTM) > WSG84 / UTM zone 31N</tt>. Locations south of the equator may need to use the 'N' zones as well. For example, the correct projection for Perth, Australia is <tt>Projected Coordinate Systems > Universal Transverse Mercator (UTM) > WSG84 / UTM zone 50N</tt>. Always select 'WGS84', as that is the globe model used in FlightGear.
# Click on <tt>Layer > New > New Shapefile Layer</tt> or on the corresponding icon. A dialog should pop up.
## Make sure the vector type is set to polygon.
## Click the 'specify CRS' button, to select a projection model. This must be the same as we did for the tiff background image.
## You need to create a data column for this layer. Create a new attribute called 'class'. Make sure it is a 'text data' (string) column. Add it to the attribute list.
## The 'OK' button should now be available for you to select. Select 'OK'.
## There should be a dialog box prompting you to save your vector layer. Save it in your scenery directory with your GeoTIFF. (This is not required but significantly helps organization.)
# Your vector layer should appear in the left-hand toolbar. You are ready to begin digitizing.
# Select the newly created layer in the layer list, toggle editing (<tt>Layer > Toggle Editing</tt>) and finally select Capture Polygon from the same menu/toolbar.
# With your mouse, left-click on a point at the southwestern edge of the small island.
# We now want to trace the outline of the island. Move your mouse to another point below the first point and click it again. Your mouse should show a red line. The points should not be redundant - for instance, as long as the line between two points is straight, there is no need for another point in between the two.
# You will want to digitize features in a circular manner to avoid problems. You can always go back and add points later. With this in mind, move your mouse to a third point on the island. A small triangle should form, representing the polygon which would result if you decided you were done with the polygon.
# Continue outlining the island by clicking along its shoreline. When you are on your last point, instead of left-clicking, right-click. QGIS will finish the polygon.
# A dialog box will pop up, asking you to type in the value for 'class'. Since this is a shoal, existing of just sand, type in ''Sand''. This step is important - it is how you know what each polygon should be mapped to in our finished scenery. A list of "allowed" materials (and thus classes) is available [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail here].

Continue with tracing all shapes on the island: towns, industrial areas, grass, farmland etc.

===Snapping===
It is very important to enable "snapping" now.

Snapping means each polygon will fit together nicely, like a jigsaw puzzle. If snapping is not enabled, the polygons will not form a continuous layer, which has a number of different problems.

We don't want small holes in our scenery, nor do we want overlapping polygons. Snapping adjusts each point as you go by - you will miss occasionally and have to correct it - so you don't have to worry about lining the polygons up precisely.

# Open <tt>Settings > Snapping Options</tt>.
# Click the tickbox(es) in front of your layer(s) and set Tolerance to 20 (map units). A smaller tolerance will make it easier to work with very small and detailed layers, while a bigger value makes it easier to snap when zoomed out.
# Click OK to save the snapping options.

==== Distinguishing Land Class Types from LANDSAT data ====
You may Google Maps or Yahoo Maps running alongside your program to see what is what on the black/white image, but most areas are recognizable without use of the software. If you need help determining what part of the black-and-white image, please currently refer to the [http://stattosoftware.com/flightgear/tutorial/index.html#distinguishing original Stattosoftware Scenery Tutorial]. Instead of determining in a single band image you can also combine different ETM+ bands in a RGB file. Some information about different band combinations can be found here [http://web.pdx.edu/~emch/ip1/bandcombinations.html].

=== Exporting the shapefile ===
In order to turn the landclass into scenery we have to split it into seperate shapefiles for each landclass.

# Open the Attribute table (<tt>Layer > Open Attribute Table</tt>).
# Type "Sand" (or another class) into the search box and press the Search button. This will select all polygons that have the Sand class assigned.
# Go to <tt>Layer > Save Selection as vector file</tt> and save the sand shapefile somewhere on your computer.
# Do the same for all other classes.
# To make the difference between land and sea (landmass) we save the entiry shapefile (<tt>Layer > Save as...</tt>, ESRI Shapefile).

If you want to see these shapefiles integrated into the Custom Scenery database you can contact papillon81 and statto (through IRC or Forum). Please be remembered that your data has to be derived from freely available (public domain) sources. Other material can not be integrated due to legal issues.

=== Generating scenery ===
Please continue with [[TerraGear]] to generate the landclass into useable scenery.

== External links ==
{{forum|5|scenery enhancement}}
* [https://web.archive.org/web/20220309095842/https://www.custom-scenery.org/ Terragear-cs website] (archived version; domain is now a spam link)
* [http://wiki.qgis.org QGIS Wiki]
* [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail OSGEO Wiki]
* {{forum link|t=5566|text=Editing shapefiles for inclussion in official scenery}} (forum topic)

=== Resources ===
* [https://web.archive.org/web/20160625080941/http://www.stattosoftware.com/flightgear/tutorial/index.html Tutorial by John Holden] (archived copy; original link is dead)

[[Category:Howto]]
[[Category:Scenery enhancement]]

[[fr:Howto: Utiliser QGIS et images satellites]]

Howto:Create custom terrain

2023-12-02T16:01:08Z

David.megginson: /* External links */ fix spam link

'''Custom terrain''' in [[FlightGear]] is currently generated through processing shapefiles with [[TerraGear]]. In order to add custom scenery to FlightGear, you must create a custom shapefile.

A shapefile is a proprietary spatial information format. You can edit them with almost every GIS package. QGIS is quite a good package for this type of project.

Your goal for editing area data is to create a shapefile of a seamless layer of polygons which correspond to some type of land cover. This data is then fed into [http://mapserver.flightgear.org the mapserver] and, possibly, TerraGear to create new scenery.

=== Evaluating the current data ===
Before you begin, please make sure the area you want to improve doesn't already have good coverage. Just because it looks bad in FlightGear does not mean the area has not been improved. For this, you will need to check the Flightgear Mapserver, at [http://mapserver.flightgear.org/ mapserver.flightgear.org].

Let's take a look at the Finistère in Brittany, Western France: if you click [http://mapserver.flightgear.org/map/?lon=-4.41840585539649&lat=48.4484146908477&zoom=11&layers=0B000000FTTFFFFFTFT here], you will quickly see and understand how FlightGear interprets the data pertaining to Finistère county. Some towns/cities (red), a few forests (green), etc. Overall, it is not a very good resolution: a lot of angles, the detail level is not that good, some towns are missing. If you want a better definition on ground, there is some work to be done! The goal being to obtain something like this:

# [http://mapserver.flightgear.org/map/?lon=13.40385&lat=52.50199&zoom=11&layers=B0000000TFFFTFFFTFFFFFFF Berlin]
# [http://mapserver.flightgear.org/map/?lon=9.40368&lat=47.63699&zoom=11&layers=B0000000TFFFTFFFTFFFFFFF Bodensee surroundings]
# [http://mapserver.flightgear.org/map/?lon=-88.55704&lat=43.98436&zoom=11&layers=B0000000TFFFTFFFTFFFFFFF Oshkosh surroundings]
# [http://mapserver.flightgear.org/map/?lon=-62.87648&lat=17.69865&zoom=10&layers=B0000000TFFFTFFFTFFFFFFF Carribean Islands]

You will immediately notice the improvement to the ground. When flying, the difference is huge. Moreover, this enables the autogeneration of cities, trees, farmland, and so on.

=== Downloading the Landsat pictures ===
[[File:C31e36f2a2cbb278a1603dfe2ba91193.media.395x288.png|thumb|200px|Landsat Map Search]]
[[File:1c9334d970963364b5ce1bc3a166a4fa.media.426x192.png|thumb|200px|Preview and download Landsat image]]
Browse to [http://glcfapp.glcf.umd.edu:8080/esdi/index.jsp the Earth Science Data Interface interface] to grab your [http://en.wikipedia.org/wiki/Landsat Landsat] data.

# Click ''Map Search''.
# Tick the ETM+ box (left column).
# Click on ''Update Map'' on the right bottom of the map.
# Click on the ''Place'' tab on the upper side of the map, in order to do a search by place, or you can do a search by latitude/longitude.
# In the Place field, type ''Amsterdam, Netherlands'' for instance.
# Now click the button with the mouse and the small + sign. This will allow you to select image tiles. Select all images that cover your area of interest, in our example this is just one image.
# Click on ''Preview and download''. This bring you to a selection page were you can choose what image you want to download. It is likely that there are pictures available from different dates for your area. Picking the most recent one is best, for known reasons.
# Clicking the ID will not bring you directly to the download page, first you have to click the ''Download'' button.
# Download the _nn80.tif.gz file (if this is not available, try an older image). Note that Landsat images are separated in different bands. Band 1/2/3/4/5/7 have 30m/Pixel resolution while band 8 (_nn80.tif.gz) has 15 meters per pixel.
# Uncompress the ''.tif.gz'' files in the directory of your choice.

=== Working with QGIS ===
[[File:QGIS_texel_1.png|thumb|200px|QGIS with the TIFF image.]]
[[File:QGIS_texel_2.png|thumb|200px|Creating the class column.]]
[[File:QGIS_texel_3.png|thumb|200px|Toggle editing.]]
[[File:QGIS_texel_4.png|thumb|200px|Tracing the small island.]]
[[File:QGIS_texel_5.png|thumb|200px|The finished small island polygon.]]
Using a GIS software gives you the opportunity to realize a full range of interesting operations: modification of map data, updates on the ground classification, etc.

* QGIS Download for Linux/OSX/Windows [http://www.qgis.org/en/download/current-software.html]

The following is largely adapted from the [http://stattosoftware.com/flightgear/tutorial/index.html original QGIS scenery tutorial], which you may find of use.
# Launch QGIS.
# Click on <tt>Layer > Add a Raster layer</tt>.
# Modify the filter to search for *.tif files.
# Add the TIFF file you have just downloaded.
# Rightclick on the image in the layer sidebar and choose <tt>Set layer CRS</tt>, to select a projection model. This depends on the location of the area you're about to create. Look up your project's UTM coordinate through [http://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg this image]. For Texel this is 31U, north of the equator, so we choose <tt>Projected Coordinate Systems > Universal Transverse Mercator (UTM) > WSG84 / UTM zone 31N</tt>. Locations south of the equator may need to use the 'N' zones as well. For example, the correct projection for Perth, Australia is <tt>Projected Coordinate Systems > Universal Transverse Mercator (UTM) > WSG84 / UTM zone 50N</tt>. Always select 'WGS84', as that is the globe model used in FlightGear.
# Click on <tt>Layer > New > New Shapefile Layer</tt> or on the corresponding icon. A dialog should pop up.
## Make sure the vector type is set to polygon.
## Click the 'specify CRS' button, to select a projection model. This must be the same as we did for the tiff background image.
## You need to create a data column for this layer. Create a new attribute called 'class'. Make sure it is a 'text data' (string) column. Add it to the attribute list.
## The 'OK' button should now be available for you to select. Select 'OK'.
## There should be a dialog box prompting you to save your vector layer. Save it in your scenery directory with your GeoTIFF. (This is not required but significantly helps organization.)
# Your vector layer should appear in the left-hand toolbar. You are ready to begin digitizing.
# Select the newly created layer in the layer list, toggle editing (<tt>Layer > Toggle Editing</tt>) and finally select Capture Polygon from the same menu/toolbar.
# With your mouse, left-click on a point at the southwestern edge of the small island.
# We now want to trace the outline of the island. Move your mouse to another point below the first point and click it again. Your mouse should show a red line. The points should not be redundant - for instance, as long as the line between two points is straight, there is no need for another point in between the two.
# You will want to digitize features in a circular manner to avoid problems. You can always go back and add points later. With this in mind, move your mouse to a third point on the island. A small triangle should form, representing the polygon which would result if you decided you were done with the polygon.
# Continue outlining the island by clicking along its shoreline. When you are on your last point, instead of left-clicking, right-click. QGIS will finish the polygon.
# A dialog box will pop up, asking you to type in the value for 'class'. Since this is a shoal, existing of just sand, type in ''Sand''. This step is important - it is how you know what each polygon should be mapped to in our finished scenery. A list of "allowed" materials (and thus classes) is available [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail here].

Continue with tracing all shapes on the island: towns, industrial areas, grass, farmland etc.

===Snapping===
It is very important to enable "snapping" now.

Snapping means each polygon will fit together nicely, like a jigsaw puzzle. If snapping is not enabled, the polygons will not form a continuous layer, which has a number of different problems.

We don't want small holes in our scenery, nor do we want overlapping polygons. Snapping adjusts each point as you go by - you will miss occasionally and have to correct it - so you don't have to worry about lining the polygons up precisely.

# Open <tt>Settings > Snapping Options</tt>.
# Click the tickbox(es) in front of your layer(s) and set Tolerance to 20 (map units). A smaller tolerance will make it easier to work with very small and detailed layers, while a bigger value makes it easier to snap when zoomed out.
# Click OK to save the snapping options.

==== Distinguishing Land Class Types from LANDSAT data ====
You may Google Maps or Yahoo Maps running alongside your program to see what is what on the black/white image, but most areas are recognizable without use of the software. If you need help determining what part of the black-and-white image, please currently refer to the [http://stattosoftware.com/flightgear/tutorial/index.html#distinguishing original Stattosoftware Scenery Tutorial]. Instead of determining in a single band image you can also combine different ETM+ bands in a RGB file. Some information about different band combinations can be found here [http://web.pdx.edu/~emch/ip1/bandcombinations.html].

=== Exporting the shapefile ===
In order to turn the landclass into scenery we have to split it into seperate shapefiles for each landclass.

# Open the Attribute table (<tt>Layer > Open Attribute Table</tt>).
# Type "Sand" (or another class) into the search box and press the Search button. This will select all polygons that have the Sand class assigned.
# Go to <tt>Layer > Save Selection as vector file</tt> and save the sand shapefile somewhere on your computer.
# Do the same for all other classes.
# To make the difference between land and sea (landmass) we save the entiry shapefile (<tt>Layer > Save as...</tt>, ESRI Shapefile).

If you want to see these shapefiles integrated into the Custom Scenery database you can contact papillon81 and statto (through IRC or Forum). Please be remembered that your data has to be derived from freely available (public domain) sources. Other material can not be integrated due to legal issues.

=== Generating scenery ===
Please continue with [[TerraGear]] to generate the landclass into useable scenery.

== External links ==
{{forum|5|scenery enhancement}}
* [https://web.archive.org/web/20220309095842/https://www.custom-scenery.org/ Terragear-cs website] (archived version; domain is now a spam link)
* [http://wiki.qgis.org QGIS Wiki]
* [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail OSGEO Wiki]
* {{forum link|t=5566|text=Editing shapefiles for inclussion in official scenery}} (forum topic)

=== Resources ===
* [http://stattosoftware.com/flightgear/tutorial/index.html Tutorial by John Holden]

[[Category:Howto]]
[[Category:Scenery enhancement]]

[[fr:Howto: Utiliser QGIS et images satellites]]

Howto:Using FlightGear with an EFB

2023-08-24T02:35:14Z

David.megginson: /* Configuring your EFB */

An '''Electronic Flight Bag''' (EFB) is an application that includes maps, weight-and-balance, and other tools that used to exist physically in a pilot's flight bag. The best-known EFB applications available on consumer mobile devices include [https://foreflight.com/ ForeFlight] ($$, iOS only, global), [https://www.garmin.com/en-CA/aviation/garminpilot/overview/ Garmin Pilot] ($$, Android and iOS, global), [https://flttrack.fltplan.com/FltPlanInfo/FltPlan_Go-Android-iPad_Info.html FltPlan Go] (cost-free, Android and iOS, Canada/U.S./Caribbean), and [https://www.apps4av.com/ Avare] (cost-free, Android only, U.S. only). Note that U.S. coverage typically overlaps slightly into southern Canada and northern Mexico.

FlightGear can feed data to most EFB applications to replace real GPS data in plane, so you can use your tablet for a moving map and flight planner beside your computer, just like you would in a real cockpit.

The instructions in this article are tested with FltPlan Go (because it's cost-free), but have been used in the past with Garmin Pilot as well, and should also work at least with ForeFlight.

== Configuring FlightGear ==

The necessary protocol files already exist in FlightGear, so all you need to do is add the following two lines to your $HOME/.fgfsrc file or to the "Additional Settings" subsection of "Settings" in the visual launcher:

--generic=socket,out,10,255.255.255.255,49002,udp,foreflight-xatt
--generic=socket,out,1,255.255.255.255,49002,udp,foreflight-xgps

== Configuring your EFB ==

[[File:FltPlan Go settings.jpg|thumb|80px|FltPlan Go External settings to connect with FlightGear]]
[[File:FltPlan Go map page.jpg|thumb|80px|Moving map showing a FlightGear flight over a Canadian VNC (Sectional).]]

Your mobile device ''must'' be connected to the same network as the computer running FlightGear. The following instructions apply to FltPlan Go, but the process for other EFBs will be similar (follow the instructions for connecting to X-Plane).

Go to the "External" side tab for FltPlan Go, and select "X-Plane" or "ForeFlight" under "Simulators". Then start FlightGear (in the same network), and wait for the altitude, latitude, longitude, course, and speed information to appear in the fields to the right: these will confirm that you have made a connection.

You can now navigate to other tabs, such as the moving map or airport diagrams and instrument procedures, and see your aircraft position live.

== Related content ==

* [[Generic protocol]]
* [[Interfacing FlightGear]]

[[Category:Interfacing protocols| ]]
[[Category:FlightGear]]

Interfacing FlightGear

2023-08-24T02:34:22Z

David.megginson: /* Wiki articles */

{{stub}}

There are several different ways to '''interface FlightGear''' to either feed FlightGear with data, get data from FlightGear or both.

There could be many different reasons to interface FlightGear, for example:

* Using an external [[Flight Dynamics Model|FDM]]
* Feeding FlightGear properties when using FlightGear for visualization
* Feeding external traffic data using either the AI/MP systems, or a combination of both
* Interfacing FlightGear with external hardware, for example a home-built autopilot control panel

== Screen shots ==

But we do provide png screenshots, too. Change the url from
/screenshot?type=jpg to /screenshot?type=png

== Video ==

We can do MJPEG stream, try to use /screenshot?stream=y as the screenshot
url. MJPEG is ugly and a resource hog but works reasonable well for image
sizes of probably 640x480. Scale down your FG window and give it a try.

== Generic protocol ==
{{main article|Generic protocol}}

Using a generic protocol you can use either an existing protocol or a protocol custom made for your need. The protocols are defined in [[PropertyList XML files]], and can both be used for reading from or to a file and to communicate through a serial connection.

== Native protocol ==
{{main article|Property Tree/Sockets}}

This uses a native protocol primarily when communicating with an external FDM.

== Telnet ==
{{main article|Telnet usage}}

FlightGear can be given command line arguments that will start FlightGear with a telnet server, <code>--telnet=''port''</code>.

There is an interactive mode with a handful of commands that can be used for interacting with FlightGear's [[property tree]] and a data mode for connecting to FlightGear through a socket.

== HTTP ==
{{main article|Property Tree Servers}}

FlightGear have an built in web server which allow you to view and interact with the property tree through a web browser or through HTTP requests.

== Scripted AI ==

== Multiplayer ==

== Flight recorder tapes ==

== Related content ==
=== Wiki articles ===
* [[Howto:Build your own procedure trainer]]
* [[Howto:Using FlightGear with an EFB]]
* [[FlightGear I/O Considerations]]
* [[Head tracking]]
* [[Logging properties]]
* [[MATLAB]]
* [[Professional and educational FlightGear users]]
* [[Property tree]]
* [[Howto:Record, analyze and replay multiplayer flights with network tools]]
* [[Howto:Use Arduino with FlightGear]]

=== Readme files ===
* {{readme file|IO}}

[[Category:Interfacing protocols| ]]
[[Category:FlightGear]]

Generic protocol

2023-08-24T02:33:41Z

David.megginson: /* Wiki articles */

{{PropertyTree}}
FlightGear supports multiple concurrent IO connections.

You could use the FGNetFDM (<code>--native</code>) protocol or the <code>--generic</code> protocol (which allows you to design custom packets with the specific fields you choose.) Both of these can send the data out as UDP packets which then can be read by your external program using standard socket communication.

This same basic mechanism also would permit your external program to send control commands so if some day you want to do some sort of hardware or software in the loop testing of your UAV controller, that is also a possibility.

There is a slightly complex, but pretty flexible mechanism for specifying an IO channel, what type of communication will get sent over it, which direction, and at what rate. Look for a file called README.IO that briefly explains much of this.

In addition, there is a "generic" protocol where you can create an XML file specifying exactly what data values you wish to send across your IO channel. We don't have generic "USB" support, but if you have a Serial -> USB device that looks like a COM port on the computer side, then that should work without any problem ... just be careful which COM port your USB device gets assigned to.

There is the native_fdm protocol to control FlightGear using an external FDM and there is the generic protocol that uses the XML configuration files.

The ''generic'' communication protocol for FlightGear provides a powerful way of adding a simple ASCII based or binary input/output protocol, just by defining an XML encoded configuration file and placing it in the <code>[[$FG ROOT]]/Protocol/</code> directory.

The generic protocol can be easily set up for both input and output. And it supports not just a single medium, but can be easily made to use files, FIFOs, sockets etc. The generic protocol is really good for things like exporting to a delimited ASCII file for import into spreadsheet for instance.

I think it makes sense (when dealing with live data) for the generic protocol to enter a while loop and read data until there is no more available. That way if the sender is sending at a higher rate or FlightGear gets behind for any reason, FlightGear will get caught up each iteration. This obviously does not work well for file input though, so you'd have to differentiate.

== XML File Layout ==

A protocol file can contain either or both of '''<input>''' and '''<output>''' definition blocks. Which one is used depends on how the protocol is called. The following example would only use the <output> definitions block.
<syntaxhighlight lang="text">
--generic=file,out,1,/tmp/data.xml,myproto
</syntaxhighlight>

If you're using a serial port under Windows, you must use a special escape sequence for COM port numbers higher than COM9, for example:

--generic=\\.\COM10,out,1,/tmp/data.xml,myproto

More detail can be found in this Microsoft KB article: https://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx

Overview of the XML file

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>

<output>
<binary_mode>false</binary_mode>
<line_separator></line_separator>
<var_separator></var_separator>
<preamble></preamble>
<postamble></postamble>

<chunk>

</chunk>

<chunk>

</chunk>
</output>

<input>
<line_separator></line_separator>
<var_separator></var_separator>

<chunk>

</chunk>

<chunk>

</chunk>
</input>

</generic>
</PropertyList>
</syntaxhighlight>

== Input/Output Parameters ==

Both '''<input>''' and '''<input>''' blocks can contain information about the data mode (ascii/binary) and about separators between fields and data sets, as well as a list of '''<chunk>'''s. Each '''<chunk>''' defines a property that should be written (and how), or a variable and which property it should be written to.

==== ASCII protocol parameters ====
Note that some parameters only can be used for output.

{| class="wikitable"
! Parameter tag
! Out
! In
! Type
! Default
! Purpose
|-
| <tt><preamble></tt>
| {{yes}}
| {{no}}
| String
| ""
| File header put on top of the file
|-
| <tt><postamble></tt>
| {{yes}}
| {{no}}
| String
| ""
| File footer put at the end of the file
|-
| <tt><binary_mode></tt>
| {{yes}}
| {{yes}}
| Boolean
| False
| Indicates if binary mode is to be used instead of ASCII
|-
| <tt><var_separator></tt>
| {{yes}}
| {{yes}}
| String
| ""
| Field separator
|-
| <tt><line_separator></tt>
| {{yes}}
| {{yes}}
| String
| ""
| Separator between data sets
|}

* '''<var_separator>''' is put between each of the properties.
* '''<line_separator>''' is put at the end of each data set.
Both can contain arbitrary strings or one of the following keywords:

{| class="wikitable"
! Keyword !! Special character
|-
| newline || <tt>\n</tt>
|-
| tab || <tt>\t</tt>
|-
| formfeed || <tt>\f</tt>
|-
| carriagereturn || <tt>\r</tt>
|-
| verticaltab || <tt>\v</tt>
|}

Typical use could be:
<syntaxhighlight lang="xml">
<var_separator>tab</var_separator>
<line_separator>newline</var_separator>
</syntaxhighlight>
or
<syntaxhighlight lang="xml">
<var_separator>\t</var_separator>
<line_separator>\r\n</line_separator>
</syntaxhighlight>

==== Binary protocol parameters ====

To enable binary mode, simply include a '''<binary_mode>true</binary_mode>''' tag in your XML file. The format of the binary output is tightly packed, with 1 byte for bool, 4 bytes for int, and 8 bytes for double. At this time, strings are not supported. A configurable footer at the end of each "line" or packet of binary output can be added using the '''<binary_footer>''' tag. Options include the length of the packet, a magic number to simplify decoding. Examples:
<syntaxhighlight lang="xml">
<binary_footer>magic,0x12345678</binary_footer>
<binary_footer>length</binary_footer>
<binary_footer>none</binary_footer> 
</syntaxhighlight>

In addition, you can specify endianness of the data sent. This is done with the '''<byte_order>''' flag. The two options are network (big endian) and host.
<syntaxhighlight lang="xml">
<byte_order>host</byte_order>
<byte_order>network</byte_order> 
</syntaxhighlight>

If your generic protocol file specifies

<syntaxhighlight lang="xml">
<binary_mode>true</binary_mode>
<byte_order>network</byte_order>
</syntaxhighlight>

your receiver (or sender) code also have to use that encoding convention.
The encoding used by the generic protocol is independent of the output
channel you choose (file, TCP socket, UDP socket, serial port or
whatever).

Also with sending/receiving UDP packets, you need to use different ports for
the sending and receiving channels.

If you are unsure about what encoding FG uses for
binary data src/Network/generic.cxx is the place to find out. It is
pretty much standard for the basic types as far as I know, though.

Network order is MSB first (as is host order if your system is big
endian but that is not so common these days). If you use host order and
both your systems have the same endianness (and you only care about
your use case) you don't have to worry about this.

If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).

== Variable Parameters - <chunk> spec ==

Both <input> and <output> block can contain a list of <chunk> specs, each of which describes the properties of on variable to write/read.
===== <name> =====
For ease of use and not transferred (like a notes tag)

===== <node> =====
The [[Property Tree|property tree]] node which provides the data

===== <type> =====
The value type which is needed for formatting, one of string, float, bool, int (default: int). Its recommended that this tag is present otherwise spurious results can occur.

===== <format> =====
ASCII protocol only, not used or needed in binary mode. Defines the actual piece of text which should be sent. it can include "printf" style formatting options like:

{| class="wikitable"
! Formatting option !! Type
|-
| <tt>%s</tt> || String
|-
| <tt>%d</tt> || Integer (default)
|-
| <tt>%f</tt> || Float
|}

Note: the type attribute tells the property tree how to store a value internally, using the most appropriate data type saves memory and reduces conversion overhead (bool, int, float, double, string).
Using the printf-style format strings in a generic protocol XML file, merely tells the I/O system how to encode/decode a property - so that it can be saved/transmitted and restored properly. Using the wrong type and/or format string in a binary protocol, would cause wrong data to be transmitted/processed by FG.

Basically, each type specifier tells FG how long each data type is in memory (bits-wise). For example, a boolean value is just 0 or 1 - so it only requires a single bit. A byte, on the other hand, requires 8 bits - and an integer (int) 4 bytes (32 bit).

So telling FG that something is a bit, will cause the data to be truncated to just a bit - which is what the format specifiers are all about: you can affect the re-interpretation of values from the property tree. In addition, there's the concept of signed-ness, i.e. numbers being positive or negative, or numbers having a mantissa - these affect how the values are stored in memory, and accordingly, the receiver must know how a value was encoded, to transform it back to what you want it to be.

===== <factor> =====
An optional multiplication factor which can be used for unit conversion, for example, radians to degrees.

===== <offset> =====
An optional offset which can be used for unit conversion, for example, degrees Celcius to degrees Fahrenheit.

==== <format> ====
Chunks can also consist of a single constant <format>, like in:
<syntaxhighlight lang="xml">
<format>Data Section</format>
</syntaxhighlight>

== Serial I/O ==

You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager
and set it between 1 and 255.

There are a lot of make of these kind of device. Some are good, others not so ...

{{Note|Windows:To specify a COM port number greater than 9, use the following syntax: <code>\\.\COM10</code>. This syntax works for all port numbers and hardware that allows COM port numbers to be specified.}}

it doesn't appear that the "generic" interface code
is setup to transmit and receive at the same time. You can't open up the
same device twice, so you two command line options won't work either. As
far as I can tell this will require some code modifications if you want to
use direct serial communication.

Another option might be to write a thin glue layer that talks to FlightGear
over the network, and talks to your hardware over a serial port and then
does all the appropriate data translation as required.

The good way to verify if the transmission of float values work is to
print the value in your receiver and compare that to the value of the
property you transmit in FG.
Btw. if your generic protocol is set to use network byte order
(endianness MSB) you have to take that into account when unpacking the
float value.

== Examples ==
==== Example 1 ====
Writes log of this form:
<pre>
V=16
H=3.590505
P=3.59
V=12
H=3.589020
P=3.59
</pre>

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>

<output>
<line_separator>newline</line_separator>
<var_separator>newline</var_separator>
<binary_mode>false</binary_mode>

<chunk>
<name>speed</name>
<format>V=%d</format>
<node>/velocities/airspeed-kt</node>
</chunk>

<chunk>
<name>heading (rad)</name>
<format>H=%.6f</format>
<type>float</type>
<node>/orientation/heading-deg</node>
<factor>0.0174532925199433</factor> 
</chunk>

<chunk>
<name>pitch angle (deg)</name>
<format>P=%03.2f</format>
<node>/orientation/pitch-deg</node>
</chunk>
</output>

</generic>
</PropertyList>
</syntaxhighlight>

===Writing data in XML format===
Assuming the file is called <code>[[$FG_ROOT]]/Protocol/xmltest.xml</code>, then it could be used as
fgfs --generic=file,out,1,/tmp/data.xml,xmltest

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<binary_mode>false</binary_mode>
<var_separator>\n</var_separator>
<line_separator>\n</line_separator>
<preamble><?xml version="1.0"?>\n\n<data>\n</preamble>
<postamble></data>\n</postamble>

<chunk>
<format>\t<set></format>
</chunk>

<chunk>
<node>/position/altitude-ft</node>
<type>float</type>
<format>\t\t<altitude-ft>%.8f</altitude-ft></format>
</chunk>
</syntaxhighlight>

For more examples, see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37892.html mailing list thread].
<syntaxhighlight lang="xml">
<chunk>
<node>/velocities/airspeed-kt</node>
<type>float</type>
<format>\t\t<airspeed-kt>%.8f</airspeed-kt></format>
</chunk>

<chunk>
<format>\t</set></format>
</chunk>
</output>
</generic>
</PropertyList>
</syntaxhighlight>

== Analyzing the resulting binary packet format ==
A utility called ''generic-protocol-analyse'' can be found under <code>FlightGear/utils/xmlgrep</code> which can be used to analyze the resulting data packet for the binary protocol. The output would be something like:

<pre>
bintest.xml
Generic binary output protocol packet description:

pos | size | type | factor | description
-----|------|--------|------------|------------------------
0 | 4 | int | | indicated speed (kt)
4 | 4 | float | | pitch att (deg)
8 | 4 | float | | magnetic heading (deg)
12 | 4 | int | | outside air temperarure (degF)
16 | 1 | bool | | autocoord

total package size: 17 bytes
</pre>

== Generic Protocol ==
FlightGear has an inbuilt "generic" protocol to push and pull data. (todo)

To interface with FlightGear on a socket for example, the following steps need to be taken:
# Establish which "properties" you want to appear "on the wire".
# Create a <code>my_protocol.xml</code> file containing those properties.
# Start FlightGear with the generic protocol option using <code>my_protocol</code> sent through the network socket.

For this simple example say were interested in heading and altitude, and we want to "listen" ie output to a socket at port 6789, UDP and receiving 10 times a second in the format:
alt\thead\n
// ie altitude - tab - heading - newline

The first step is establishing the nodes, in this example
/position/altitude-agl-ft eg (22.4713923)
/orientation/heading-deg eg (297.966325)

Next create a file '''my_protocol.xml'''. This needs to be located at
[[$FG_ROOT]]/Protocol/my_protocol.xml

Edit the <code>my_protocol.xml</code> file and write in it:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<line_separator>newline</line_separator>
<var_separator>tab</var_separator>

<chunk>
<node>/position/altitude-agl-ft</node>
<name>altitude to go</name>
<type>float</type>
<format>%03.2f</format>
</chunk>

<chunk>
<node>/orientation/heading-deg</node>
<name>Heading</name>
<type>float</type>
<format>%03.3f</format>
</chunk>

</output>
</generic>
</PropertyList>
</syntaxhighlight>

* The '''output''' tag indicates the protocol for output. The same "protocol" file can contain an "input" section, absent in this example (more later).
* '''line_seperator''' - the end of line (todo - is this <code>\r\n</code>?)
* '''var_seperator''' - the delimiter for the properties, this could be "|", "###", any string.
* The two '''chunk''' blocks contain our data. Note that these appear in the order presented within the XML file.
** '''node''' - the node of data we want
** '''name''' - it there for a reference, its not transmitted and note necessary (like a note)
** '''type''' - the way this xml is to interpret the value. This is quite important tag. For example if its not there or a string, then "floats" go wild and end up being a string of 32 characters with two decimal places!
** '''format''' - same syntax as <code>printf</code> function in C/C++
** There's more that can be done {todo - link to a full blown example/reference}

We can now start FlightGear and listen with:
fgfs --generic=socket,out,10,localhost,6789,udp,my_protocol

[todo] - link here to the tutorial

== Alternative start using Nasal ==
It is also possible to start and stop from within the Nasal console. Start the Nasal console from the Debug menu and type the following (modify accordingly) and click Execute:
fgcommand("add-io-channel", {"config": "generic,socket,out,10,localhost,6789,udp,my_protocol", "name": "test"});
Name is optional but can be used to stop the connection using:
fgcommand("remove-io-channel", {"name": "test"});

== Related content ==
=== Wiki articles ===
* [[Logging properties]] – ''A simpler way to log properties to a file.''
* [[Howto:Record, analyze and replay multiplayer flights with network tools]] - ''Logging the network traffic between your computer and a multiplayer server.''
* [[Howto:Using FlightGear with an EFB]]

=== Readme files ===
* {{readme file|protocol}}
* {{readme file|IO}}

=== Source code ===
* {{fgdata source|Protocol/}} – ''Predefined protocols''
* {{flightgear source|src/Network/generic.hxx}}
* {{flightgear source|src/Network/generic.cxx}}

[[Category:Interfacing protocols]]
[[Category:FlightGear]]
[[Category:XML]]
[[Category:Property Tree]]

[[pl:Protokół ogólny]]

Generic protocol

2023-08-24T02:32:27Z

David.megginson: /* Wiki articles */ fix link

{{PropertyTree}}
FlightGear supports multiple concurrent IO connections.

You could use the FGNetFDM (<code>--native</code>) protocol or the <code>--generic</code> protocol (which allows you to design custom packets with the specific fields you choose.) Both of these can send the data out as UDP packets which then can be read by your external program using standard socket communication.

This same basic mechanism also would permit your external program to send control commands so if some day you want to do some sort of hardware or software in the loop testing of your UAV controller, that is also a possibility.

There is a slightly complex, but pretty flexible mechanism for specifying an IO channel, what type of communication will get sent over it, which direction, and at what rate. Look for a file called README.IO that briefly explains much of this.

In addition, there is a "generic" protocol where you can create an XML file specifying exactly what data values you wish to send across your IO channel. We don't have generic "USB" support, but if you have a Serial -> USB device that looks like a COM port on the computer side, then that should work without any problem ... just be careful which COM port your USB device gets assigned to.

There is the native_fdm protocol to control FlightGear using an external FDM and there is the generic protocol that uses the XML configuration files.

The ''generic'' communication protocol for FlightGear provides a powerful way of adding a simple ASCII based or binary input/output protocol, just by defining an XML encoded configuration file and placing it in the <code>[[$FG ROOT]]/Protocol/</code> directory.

The generic protocol can be easily set up for both input and output. And it supports not just a single medium, but can be easily made to use files, FIFOs, sockets etc. The generic protocol is really good for things like exporting to a delimited ASCII file for import into spreadsheet for instance.

I think it makes sense (when dealing with live data) for the generic protocol to enter a while loop and read data until there is no more available. That way if the sender is sending at a higher rate or FlightGear gets behind for any reason, FlightGear will get caught up each iteration. This obviously does not work well for file input though, so you'd have to differentiate.

== XML File Layout ==

A protocol file can contain either or both of '''<input>''' and '''<output>''' definition blocks. Which one is used depends on how the protocol is called. The following example would only use the <output> definitions block.
<syntaxhighlight lang="text">
--generic=file,out,1,/tmp/data.xml,myproto
</syntaxhighlight>

If you're using a serial port under Windows, you must use a special escape sequence for COM port numbers higher than COM9, for example:

--generic=\\.\COM10,out,1,/tmp/data.xml,myproto

More detail can be found in this Microsoft KB article: https://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx

Overview of the XML file

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>

<output>
<binary_mode>false</binary_mode>
<line_separator></line_separator>
<var_separator></var_separator>
<preamble></preamble>
<postamble></postamble>

<chunk>

</chunk>

<chunk>

</chunk>
</output>

<input>
<line_separator></line_separator>
<var_separator></var_separator>

<chunk>

</chunk>

<chunk>

</chunk>
</input>

</generic>
</PropertyList>
</syntaxhighlight>

== Input/Output Parameters ==

Both '''<input>''' and '''<input>''' blocks can contain information about the data mode (ascii/binary) and about separators between fields and data sets, as well as a list of '''<chunk>'''s. Each '''<chunk>''' defines a property that should be written (and how), or a variable and which property it should be written to.

==== ASCII protocol parameters ====
Note that some parameters only can be used for output.

{| class="wikitable"
! Parameter tag
! Out
! In
! Type
! Default
! Purpose
|-
| <tt><preamble></tt>
| {{yes}}
| {{no}}
| String
| ""
| File header put on top of the file
|-
| <tt><postamble></tt>
| {{yes}}
| {{no}}
| String
| ""
| File footer put at the end of the file
|-
| <tt><binary_mode></tt>
| {{yes}}
| {{yes}}
| Boolean
| False
| Indicates if binary mode is to be used instead of ASCII
|-
| <tt><var_separator></tt>
| {{yes}}
| {{yes}}
| String
| ""
| Field separator
|-
| <tt><line_separator></tt>
| {{yes}}
| {{yes}}
| String
| ""
| Separator between data sets
|}

* '''<var_separator>''' is put between each of the properties.
* '''<line_separator>''' is put at the end of each data set.
Both can contain arbitrary strings or one of the following keywords:

{| class="wikitable"
! Keyword !! Special character
|-
| newline || <tt>\n</tt>
|-
| tab || <tt>\t</tt>
|-
| formfeed || <tt>\f</tt>
|-
| carriagereturn || <tt>\r</tt>
|-
| verticaltab || <tt>\v</tt>
|}

Typical use could be:
<syntaxhighlight lang="xml">
<var_separator>tab</var_separator>
<line_separator>newline</var_separator>
</syntaxhighlight>
or
<syntaxhighlight lang="xml">
<var_separator>\t</var_separator>
<line_separator>\r\n</line_separator>
</syntaxhighlight>

==== Binary protocol parameters ====

To enable binary mode, simply include a '''<binary_mode>true</binary_mode>''' tag in your XML file. The format of the binary output is tightly packed, with 1 byte for bool, 4 bytes for int, and 8 bytes for double. At this time, strings are not supported. A configurable footer at the end of each "line" or packet of binary output can be added using the '''<binary_footer>''' tag. Options include the length of the packet, a magic number to simplify decoding. Examples:
<syntaxhighlight lang="xml">
<binary_footer>magic,0x12345678</binary_footer>
<binary_footer>length</binary_footer>
<binary_footer>none</binary_footer> 
</syntaxhighlight>

In addition, you can specify endianness of the data sent. This is done with the '''<byte_order>''' flag. The two options are network (big endian) and host.
<syntaxhighlight lang="xml">
<byte_order>host</byte_order>
<byte_order>network</byte_order> 
</syntaxhighlight>

If your generic protocol file specifies

<syntaxhighlight lang="xml">
<binary_mode>true</binary_mode>
<byte_order>network</byte_order>
</syntaxhighlight>

your receiver (or sender) code also have to use that encoding convention.
The encoding used by the generic protocol is independent of the output
channel you choose (file, TCP socket, UDP socket, serial port or
whatever).

Also with sending/receiving UDP packets, you need to use different ports for
the sending and receiving channels.

If you are unsure about what encoding FG uses for
binary data src/Network/generic.cxx is the place to find out. It is
pretty much standard for the basic types as far as I know, though.

Network order is MSB first (as is host order if your system is big
endian but that is not so common these days). If you use host order and
both your systems have the same endianness (and you only care about
your use case) you don't have to worry about this.

If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).

== Variable Parameters - <chunk> spec ==

Both <input> and <output> block can contain a list of <chunk> specs, each of which describes the properties of on variable to write/read.
===== <name> =====
For ease of use and not transferred (like a notes tag)

===== <node> =====
The [[Property Tree|property tree]] node which provides the data

===== <type> =====
The value type which is needed for formatting, one of string, float, bool, int (default: int). Its recommended that this tag is present otherwise spurious results can occur.

===== <format> =====
ASCII protocol only, not used or needed in binary mode. Defines the actual piece of text which should be sent. it can include "printf" style formatting options like:

{| class="wikitable"
! Formatting option !! Type
|-
| <tt>%s</tt> || String
|-
| <tt>%d</tt> || Integer (default)
|-
| <tt>%f</tt> || Float
|}

Note: the type attribute tells the property tree how to store a value internally, using the most appropriate data type saves memory and reduces conversion overhead (bool, int, float, double, string).
Using the printf-style format strings in a generic protocol XML file, merely tells the I/O system how to encode/decode a property - so that it can be saved/transmitted and restored properly. Using the wrong type and/or format string in a binary protocol, would cause wrong data to be transmitted/processed by FG.

Basically, each type specifier tells FG how long each data type is in memory (bits-wise). For example, a boolean value is just 0 or 1 - so it only requires a single bit. A byte, on the other hand, requires 8 bits - and an integer (int) 4 bytes (32 bit).

So telling FG that something is a bit, will cause the data to be truncated to just a bit - which is what the format specifiers are all about: you can affect the re-interpretation of values from the property tree. In addition, there's the concept of signed-ness, i.e. numbers being positive or negative, or numbers having a mantissa - these affect how the values are stored in memory, and accordingly, the receiver must know how a value was encoded, to transform it back to what you want it to be.

===== <factor> =====
An optional multiplication factor which can be used for unit conversion, for example, radians to degrees.

===== <offset> =====
An optional offset which can be used for unit conversion, for example, degrees Celcius to degrees Fahrenheit.

==== <format> ====
Chunks can also consist of a single constant <format>, like in:
<syntaxhighlight lang="xml">
<format>Data Section</format>
</syntaxhighlight>

== Serial I/O ==

You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager
and set it between 1 and 255.

There are a lot of make of these kind of device. Some are good, others not so ...

{{Note|Windows:To specify a COM port number greater than 9, use the following syntax: <code>\\.\COM10</code>. This syntax works for all port numbers and hardware that allows COM port numbers to be specified.}}

it doesn't appear that the "generic" interface code
is setup to transmit and receive at the same time. You can't open up the
same device twice, so you two command line options won't work either. As
far as I can tell this will require some code modifications if you want to
use direct serial communication.

Another option might be to write a thin glue layer that talks to FlightGear
over the network, and talks to your hardware over a serial port and then
does all the appropriate data translation as required.

The good way to verify if the transmission of float values work is to
print the value in your receiver and compare that to the value of the
property you transmit in FG.
Btw. if your generic protocol is set to use network byte order
(endianness MSB) you have to take that into account when unpacking the
float value.

== Examples ==
==== Example 1 ====
Writes log of this form:
<pre>
V=16
H=3.590505
P=3.59
V=12
H=3.589020
P=3.59
</pre>

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>

<output>
<line_separator>newline</line_separator>
<var_separator>newline</var_separator>
<binary_mode>false</binary_mode>

<chunk>
<name>speed</name>
<format>V=%d</format>
<node>/velocities/airspeed-kt</node>
</chunk>

<chunk>
<name>heading (rad)</name>
<format>H=%.6f</format>
<type>float</type>
<node>/orientation/heading-deg</node>
<factor>0.0174532925199433</factor> 
</chunk>

<chunk>
<name>pitch angle (deg)</name>
<format>P=%03.2f</format>
<node>/orientation/pitch-deg</node>
</chunk>
</output>

</generic>
</PropertyList>
</syntaxhighlight>

===Writing data in XML format===
Assuming the file is called <code>[[$FG_ROOT]]/Protocol/xmltest.xml</code>, then it could be used as
fgfs --generic=file,out,1,/tmp/data.xml,xmltest

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<binary_mode>false</binary_mode>
<var_separator>\n</var_separator>
<line_separator>\n</line_separator>
<preamble><?xml version="1.0"?>\n\n<data>\n</preamble>
<postamble></data>\n</postamble>

<chunk>
<format>\t<set></format>
</chunk>

<chunk>
<node>/position/altitude-ft</node>
<type>float</type>
<format>\t\t<altitude-ft>%.8f</altitude-ft></format>
</chunk>
</syntaxhighlight>

For more examples, see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37892.html mailing list thread].
<syntaxhighlight lang="xml">
<chunk>
<node>/velocities/airspeed-kt</node>
<type>float</type>
<format>\t\t<airspeed-kt>%.8f</airspeed-kt></format>
</chunk>

<chunk>
<format>\t</set></format>
</chunk>
</output>
</generic>
</PropertyList>
</syntaxhighlight>

== Analyzing the resulting binary packet format ==
A utility called ''generic-protocol-analyse'' can be found under <code>FlightGear/utils/xmlgrep</code> which can be used to analyze the resulting data packet for the binary protocol. The output would be something like:

<pre>
bintest.xml
Generic binary output protocol packet description:

pos | size | type | factor | description
-----|------|--------|------------|------------------------
0 | 4 | int | | indicated speed (kt)
4 | 4 | float | | pitch att (deg)
8 | 4 | float | | magnetic heading (deg)
12 | 4 | int | | outside air temperarure (degF)
16 | 1 | bool | | autocoord

total package size: 17 bytes
</pre>

== Generic Protocol ==
FlightGear has an inbuilt "generic" protocol to push and pull data. (todo)

To interface with FlightGear on a socket for example, the following steps need to be taken:
# Establish which "properties" you want to appear "on the wire".
# Create a <code>my_protocol.xml</code> file containing those properties.
# Start FlightGear with the generic protocol option using <code>my_protocol</code> sent through the network socket.

For this simple example say were interested in heading and altitude, and we want to "listen" ie output to a socket at port 6789, UDP and receiving 10 times a second in the format:
alt\thead\n
// ie altitude - tab - heading - newline

The first step is establishing the nodes, in this example
/position/altitude-agl-ft eg (22.4713923)
/orientation/heading-deg eg (297.966325)

Next create a file '''my_protocol.xml'''. This needs to be located at
[[$FG_ROOT]]/Protocol/my_protocol.xml

Edit the <code>my_protocol.xml</code> file and write in it:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<line_separator>newline</line_separator>
<var_separator>tab</var_separator>

<chunk>
<node>/position/altitude-agl-ft</node>
<name>altitude to go</name>
<type>float</type>
<format>%03.2f</format>
</chunk>

<chunk>
<node>/orientation/heading-deg</node>
<name>Heading</name>
<type>float</type>
<format>%03.3f</format>
</chunk>

</output>
</generic>
</PropertyList>
</syntaxhighlight>

* The '''output''' tag indicates the protocol for output. The same "protocol" file can contain an "input" section, absent in this example (more later).
* '''line_seperator''' - the end of line (todo - is this <code>\r\n</code>?)
* '''var_seperator''' - the delimiter for the properties, this could be "|", "###", any string.
* The two '''chunk''' blocks contain our data. Note that these appear in the order presented within the XML file.
** '''node''' - the node of data we want
** '''name''' - it there for a reference, its not transmitted and note necessary (like a note)
** '''type''' - the way this xml is to interpret the value. This is quite important tag. For example if its not there or a string, then "floats" go wild and end up being a string of 32 characters with two decimal places!
** '''format''' - same syntax as <code>printf</code> function in C/C++
** There's more that can be done {todo - link to a full blown example/reference}

We can now start FlightGear and listen with:
fgfs --generic=socket,out,10,localhost,6789,udp,my_protocol

[todo] - link here to the tutorial

== Alternative start using Nasal ==
It is also possible to start and stop from within the Nasal console. Start the Nasal console from the Debug menu and type the following (modify accordingly) and click Execute:
fgcommand("add-io-channel", {"config": "generic,socket,out,10,localhost,6789,udp,my_protocol", "name": "test"});
Name is optional but can be used to stop the connection using:
fgcommand("remove-io-channel", {"name": "test"});

== Related content ==
=== Wiki articles ===
* [[Logging properties]] – ''A simpler way to log properties to a file.''
* [[Howto:Record, analyze and replay multiplayer flights with network tools]] - ''Logging the network traffic between your computer and a multiplayer server.''
* [[HowTo:Using FlightGear with an EFB]]

=== Readme files ===
* {{readme file|protocol}}
* {{readme file|IO}}

=== Source code ===
* {{fgdata source|Protocol/}} – ''Predefined protocols''
* {{flightgear source|src/Network/generic.hxx}}
* {{flightgear source|src/Network/generic.cxx}}

[[Category:Interfacing protocols]]
[[Category:FlightGear]]
[[Category:XML]]
[[Category:Property Tree]]

[[pl:Protokół ogólny]]

Using FlightGear with an EFB

2023-08-24T02:31:54Z

David.megginson: David.megginson moved page Using FlightGear with an EFB to Howto:Using FlightGear with an EFB: Follow naming convention.

#REDIRECT [[Howto:Using FlightGear with an EFB]]

Howto:Using FlightGear with an EFB

2023-08-24T02:31:54Z

David.megginson: David.megginson moved page Using FlightGear with an EFB to Howto:Using FlightGear with an EFB: Follow naming convention.

An '''Electronic Flight Bag''' (EFB) is an application that includes maps, weight-and-balance, and other tools that used to exist physically in a pilot's flight bag. The best-known EFB applications available on consumer mobile devices include [https://foreflight.com/ ForeFlight] ($$, iOS only, global), [https://www.garmin.com/en-CA/aviation/garminpilot/overview/ Garmin Pilot] ($$, Android and iOS, global), [https://flttrack.fltplan.com/FltPlanInfo/FltPlan_Go-Android-iPad_Info.html FltPlan Go] (cost-free, Android and iOS, Canada/U.S./Caribbean), and [https://www.apps4av.com/ Avare] (cost-free, Android only, U.S. only). Note that U.S. coverage typically overlaps slightly into southern Canada and northern Mexico.

FlightGear can feed data to most EFB applications to replace real GPS data in plane, so you can use your tablet for a moving map and flight planner beside your computer, just like you would in a real cockpit.

The instructions in this article are tested with FltPlan Go (because it's cost-free), but have been used in the past with Garmin Pilot as well, and should also work at least with ForeFlight.

== Configuring FlightGear ==

The necessary protocol files already exist in FlightGear, so all you need to do is add the following two lines to your $HOME/.fgfsrc file or to the "Additional Settings" subsection of "Settings" in the visual launcher:

--generic=socket,out,10,255.255.255.255,49002,udp,foreflight-xatt
--generic=socket,out,1,255.255.255.255,49002,udp,foreflight-xgps

== Configuring your EFB ==

[[File:FltPlan Go settings.jpg|thumb|80px|FltPlan Go External settings to connect with FlightGear]]
[[File:FltPlan Go map page.jpg|thumb|80px|Moving map showing a FlightGear flight over a Canadian VNC (Sectional).]]

Your mobile device ''must'' be connected to the same network as the computer running FlightGear. The following instructions apply to FltPlan Go, but the process for other EFBs will be similar (follow the instructions for connecting to X-Plane).

Go to the "External" side tab for FltPlan Go, and select "X-Plane" under "Simulators". Then start FlightGear (in the same network), and wait for the altitude, latitude, longitude, course, and speed information to appear in the fields to the right: these will confirm that you have made a connection.

You can now navigate to other tabs, such as the moving map or airport diagrams and instrument procedures, and see your aircraft position live.

== Related content ==

* [[Generic protocol]]
* [[Interfacing FlightGear]]

[[Category:Interfacing protocols| ]]
[[Category:FlightGear]]

Howto:Using FlightGear with an EFB

2023-08-24T02:30:13Z

David.megginson:

An '''Electronic Flight Bag''' (EFB) is an application that includes maps, weight-and-balance, and other tools that used to exist physically in a pilot's flight bag. The best-known EFB applications available on consumer mobile devices include [https://foreflight.com/ ForeFlight] ($$, iOS only, global), [https://www.garmin.com/en-CA/aviation/garminpilot/overview/ Garmin Pilot] ($$, Android and iOS, global), [https://flttrack.fltplan.com/FltPlanInfo/FltPlan_Go-Android-iPad_Info.html FltPlan Go] (cost-free, Android and iOS, Canada/U.S./Caribbean), and [https://www.apps4av.com/ Avare] (cost-free, Android only, U.S. only). Note that U.S. coverage typically overlaps slightly into southern Canada and northern Mexico.

FlightGear can feed data to most EFB applications to replace real GPS data in plane, so you can use your tablet for a moving map and flight planner beside your computer, just like you would in a real cockpit.

The instructions in this article are tested with FltPlan Go (because it's cost-free), but have been used in the past with Garmin Pilot as well, and should also work at least with ForeFlight.

== Configuring FlightGear ==

The necessary protocol files already exist in FlightGear, so all you need to do is add the following two lines to your $HOME/.fgfsrc file or to the "Additional Settings" subsection of "Settings" in the visual launcher:

--generic=socket,out,10,255.255.255.255,49002,udp,foreflight-xatt
--generic=socket,out,1,255.255.255.255,49002,udp,foreflight-xgps

== Configuring your EFB ==

[[File:FltPlan Go settings.jpg|thumb|80px|FltPlan Go External settings to connect with FlightGear]]
[[File:FltPlan Go map page.jpg|thumb|80px|Moving map showing a FlightGear flight over a Canadian VNC (Sectional).]]

Your mobile device ''must'' be connected to the same network as the computer running FlightGear. The following instructions apply to FltPlan Go, but the process for other EFBs will be similar (follow the instructions for connecting to X-Plane).

Go to the "External" side tab for FltPlan Go, and select "X-Plane" under "Simulators". Then start FlightGear (in the same network), and wait for the altitude, latitude, longitude, course, and speed information to appear in the fields to the right: these will confirm that you have made a connection.

You can now navigate to other tabs, such as the moving map or airport diagrams and instrument procedures, and see your aircraft position live.

== Related content ==

* [[Generic protocol]]
* [[Interfacing FlightGear]]

[[Category:Interfacing protocols| ]]
[[Category:FlightGear]]

Interfacing FlightGear

2023-08-24T02:29:33Z

David.megginson: /* Wiki articles */

{{stub}}

There are several different ways to '''interface FlightGear''' to either feed FlightGear with data, get data from FlightGear or both.

There could be many different reasons to interface FlightGear, for example:

* Using an external [[Flight Dynamics Model|FDM]]
* Feeding FlightGear properties when using FlightGear for visualization
* Feeding external traffic data using either the AI/MP systems, or a combination of both
* Interfacing FlightGear with external hardware, for example a home-built autopilot control panel

== Screen shots ==

But we do provide png screenshots, too. Change the url from
/screenshot?type=jpg to /screenshot?type=png

== Video ==

We can do MJPEG stream, try to use /screenshot?stream=y as the screenshot
url. MJPEG is ugly and a resource hog but works reasonable well for image
sizes of probably 640x480. Scale down your FG window and give it a try.

== Generic protocol ==
{{main article|Generic protocol}}

Using a generic protocol you can use either an existing protocol or a protocol custom made for your need. The protocols are defined in [[PropertyList XML files]], and can both be used for reading from or to a file and to communicate through a serial connection.

== Native protocol ==
{{main article|Property Tree/Sockets}}

This uses a native protocol primarily when communicating with an external FDM.

== Telnet ==
{{main article|Telnet usage}}

FlightGear can be given command line arguments that will start FlightGear with a telnet server, <code>--telnet=''port''</code>.

There is an interactive mode with a handful of commands that can be used for interacting with FlightGear's [[property tree]] and a data mode for connecting to FlightGear through a socket.

== HTTP ==
{{main article|Property Tree Servers}}

FlightGear have an built in web server which allow you to view and interact with the property tree through a web browser or through HTTP requests.

== Scripted AI ==

== Multiplayer ==

== Flight recorder tapes ==

== Related content ==
=== Wiki articles ===
* [[Howto:Build your own procedure trainer]]
* [[Using FlightGear with an EFB]]
* [[FlightGear I/O Considerations]]
* [[Head tracking]]
* [[Logging properties]]
* [[MATLAB]]
* [[Professional and educational FlightGear users]]
* [[Property tree]]
* [[Howto:Record, analyze and replay multiplayer flights with network tools]]
* [[Howto:Use Arduino with FlightGear]]

=== Readme files ===
* {{readme file|IO}}

[[Category:Interfacing protocols| ]]
[[Category:FlightGear]]

Generic protocol

2023-08-24T02:28:48Z

David.megginson: /* Related content */

{{PropertyTree}}
FlightGear supports multiple concurrent IO connections.

You could use the FGNetFDM (<code>--native</code>) protocol or the <code>--generic</code> protocol (which allows you to design custom packets with the specific fields you choose.) Both of these can send the data out as UDP packets which then can be read by your external program using standard socket communication.

This same basic mechanism also would permit your external program to send control commands so if some day you want to do some sort of hardware or software in the loop testing of your UAV controller, that is also a possibility.

There is a slightly complex, but pretty flexible mechanism for specifying an IO channel, what type of communication will get sent over it, which direction, and at what rate. Look for a file called README.IO that briefly explains much of this.

In addition, there is a "generic" protocol where you can create an XML file specifying exactly what data values you wish to send across your IO channel. We don't have generic "USB" support, but if you have a Serial -> USB device that looks like a COM port on the computer side, then that should work without any problem ... just be careful which COM port your USB device gets assigned to.

There is the native_fdm protocol to control FlightGear using an external FDM and there is the generic protocol that uses the XML configuration files.

The ''generic'' communication protocol for FlightGear provides a powerful way of adding a simple ASCII based or binary input/output protocol, just by defining an XML encoded configuration file and placing it in the <code>[[$FG ROOT]]/Protocol/</code> directory.

The generic protocol can be easily set up for both input and output. And it supports not just a single medium, but can be easily made to use files, FIFOs, sockets etc. The generic protocol is really good for things like exporting to a delimited ASCII file for import into spreadsheet for instance.

I think it makes sense (when dealing with live data) for the generic protocol to enter a while loop and read data until there is no more available. That way if the sender is sending at a higher rate or FlightGear gets behind for any reason, FlightGear will get caught up each iteration. This obviously does not work well for file input though, so you'd have to differentiate.

== XML File Layout ==

A protocol file can contain either or both of '''<input>''' and '''<output>''' definition blocks. Which one is used depends on how the protocol is called. The following example would only use the <output> definitions block.
<syntaxhighlight lang="text">
--generic=file,out,1,/tmp/data.xml,myproto
</syntaxhighlight>

If you're using a serial port under Windows, you must use a special escape sequence for COM port numbers higher than COM9, for example:

--generic=\\.\COM10,out,1,/tmp/data.xml,myproto

More detail can be found in this Microsoft KB article: https://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx

Overview of the XML file

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>

<output>
<binary_mode>false</binary_mode>
<line_separator></line_separator>
<var_separator></var_separator>
<preamble></preamble>
<postamble></postamble>

<chunk>

</chunk>

<chunk>

</chunk>
</output>

<input>
<line_separator></line_separator>
<var_separator></var_separator>

<chunk>

</chunk>

<chunk>

</chunk>
</input>

</generic>
</PropertyList>
</syntaxhighlight>

== Input/Output Parameters ==

Both '''<input>''' and '''<input>''' blocks can contain information about the data mode (ascii/binary) and about separators between fields and data sets, as well as a list of '''<chunk>'''s. Each '''<chunk>''' defines a property that should be written (and how), or a variable and which property it should be written to.

==== ASCII protocol parameters ====
Note that some parameters only can be used for output.

{| class="wikitable"
! Parameter tag
! Out
! In
! Type
! Default
! Purpose
|-
| <tt><preamble></tt>
| {{yes}}
| {{no}}
| String
| ""
| File header put on top of the file
|-
| <tt><postamble></tt>
| {{yes}}
| {{no}}
| String
| ""
| File footer put at the end of the file
|-
| <tt><binary_mode></tt>
| {{yes}}
| {{yes}}
| Boolean
| False
| Indicates if binary mode is to be used instead of ASCII
|-
| <tt><var_separator></tt>
| {{yes}}
| {{yes}}
| String
| ""
| Field separator
|-
| <tt><line_separator></tt>
| {{yes}}
| {{yes}}
| String
| ""
| Separator between data sets
|}

* '''<var_separator>''' is put between each of the properties.
* '''<line_separator>''' is put at the end of each data set.
Both can contain arbitrary strings or one of the following keywords:

{| class="wikitable"
! Keyword !! Special character
|-
| newline || <tt>\n</tt>
|-
| tab || <tt>\t</tt>
|-
| formfeed || <tt>\f</tt>
|-
| carriagereturn || <tt>\r</tt>
|-
| verticaltab || <tt>\v</tt>
|}

Typical use could be:
<syntaxhighlight lang="xml">
<var_separator>tab</var_separator>
<line_separator>newline</var_separator>
</syntaxhighlight>
or
<syntaxhighlight lang="xml">
<var_separator>\t</var_separator>
<line_separator>\r\n</line_separator>
</syntaxhighlight>

==== Binary protocol parameters ====

To enable binary mode, simply include a '''<binary_mode>true</binary_mode>''' tag in your XML file. The format of the binary output is tightly packed, with 1 byte for bool, 4 bytes for int, and 8 bytes for double. At this time, strings are not supported. A configurable footer at the end of each "line" or packet of binary output can be added using the '''<binary_footer>''' tag. Options include the length of the packet, a magic number to simplify decoding. Examples:
<syntaxhighlight lang="xml">
<binary_footer>magic,0x12345678</binary_footer>
<binary_footer>length</binary_footer>
<binary_footer>none</binary_footer> 
</syntaxhighlight>

In addition, you can specify endianness of the data sent. This is done with the '''<byte_order>''' flag. The two options are network (big endian) and host.
<syntaxhighlight lang="xml">
<byte_order>host</byte_order>
<byte_order>network</byte_order> 
</syntaxhighlight>

If your generic protocol file specifies

<syntaxhighlight lang="xml">
<binary_mode>true</binary_mode>
<byte_order>network</byte_order>
</syntaxhighlight>

your receiver (or sender) code also have to use that encoding convention.
The encoding used by the generic protocol is independent of the output
channel you choose (file, TCP socket, UDP socket, serial port or
whatever).

Also with sending/receiving UDP packets, you need to use different ports for
the sending and receiving channels.

If you are unsure about what encoding FG uses for
binary data src/Network/generic.cxx is the place to find out. It is
pretty much standard for the basic types as far as I know, though.

Network order is MSB first (as is host order if your system is big
endian but that is not so common these days). If you use host order and
both your systems have the same endianness (and you only care about
your use case) you don't have to worry about this.

If you don't specify byte order, host order will be used. Anything x86 is
very likely to use LSB order (a PC certainly is).

== Variable Parameters - <chunk> spec ==

Both <input> and <output> block can contain a list of <chunk> specs, each of which describes the properties of on variable to write/read.
===== <name> =====
For ease of use and not transferred (like a notes tag)

===== <node> =====
The [[Property Tree|property tree]] node which provides the data

===== <type> =====
The value type which is needed for formatting, one of string, float, bool, int (default: int). Its recommended that this tag is present otherwise spurious results can occur.

===== <format> =====
ASCII protocol only, not used or needed in binary mode. Defines the actual piece of text which should be sent. it can include "printf" style formatting options like:

{| class="wikitable"
! Formatting option !! Type
|-
| <tt>%s</tt> || String
|-
| <tt>%d</tt> || Integer (default)
|-
| <tt>%f</tt> || Float
|}

Note: the type attribute tells the property tree how to store a value internally, using the most appropriate data type saves memory and reduces conversion overhead (bool, int, float, double, string).
Using the printf-style format strings in a generic protocol XML file, merely tells the I/O system how to encode/decode a property - so that it can be saved/transmitted and restored properly. Using the wrong type and/or format string in a binary protocol, would cause wrong data to be transmitted/processed by FG.

Basically, each type specifier tells FG how long each data type is in memory (bits-wise). For example, a boolean value is just 0 or 1 - so it only requires a single bit. A byte, on the other hand, requires 8 bits - and an integer (int) 4 bytes (32 bit).

So telling FG that something is a bit, will cause the data to be truncated to just a bit - which is what the format specifiers are all about: you can affect the re-interpretation of values from the property tree. In addition, there's the concept of signed-ness, i.e. numbers being positive or negative, or numbers having a mantissa - these affect how the values are stored in memory, and accordingly, the receiver must know how a value was encoded, to transform it back to what you want it to be.

===== <factor> =====
An optional multiplication factor which can be used for unit conversion, for example, radians to degrees.

===== <offset> =====
An optional offset which can be used for unit conversion, for example, degrees Celcius to degrees Fahrenheit.

==== <format> ====
Chunks can also consist of a single constant <format>, like in:
<syntaxhighlight lang="xml">
<format>Data Section</format>
</syntaxhighlight>

== Serial I/O ==

You can assign any number you want to a COM port when it is driven by a USB-to-COM or Ethernet-to-COM adapter. Simply go to the Device Manager
and set it between 1 and 255.

There are a lot of make of these kind of device. Some are good, others not so ...

{{Note|Windows:To specify a COM port number greater than 9, use the following syntax: <code>\\.\COM10</code>. This syntax works for all port numbers and hardware that allows COM port numbers to be specified.}}

it doesn't appear that the "generic" interface code
is setup to transmit and receive at the same time. You can't open up the
same device twice, so you two command line options won't work either. As
far as I can tell this will require some code modifications if you want to
use direct serial communication.

Another option might be to write a thin glue layer that talks to FlightGear
over the network, and talks to your hardware over a serial port and then
does all the appropriate data translation as required.

The good way to verify if the transmission of float values work is to
print the value in your receiver and compare that to the value of the
property you transmit in FG.
Btw. if your generic protocol is set to use network byte order
(endianness MSB) you have to take that into account when unpacking the
float value.

== Examples ==
==== Example 1 ====
Writes log of this form:
<pre>
V=16
H=3.590505
P=3.59
V=12
H=3.589020
P=3.59
</pre>

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>

<output>
<line_separator>newline</line_separator>
<var_separator>newline</var_separator>
<binary_mode>false</binary_mode>

<chunk>
<name>speed</name>
<format>V=%d</format>
<node>/velocities/airspeed-kt</node>
</chunk>

<chunk>
<name>heading (rad)</name>
<format>H=%.6f</format>
<type>float</type>
<node>/orientation/heading-deg</node>
<factor>0.0174532925199433</factor> 
</chunk>

<chunk>
<name>pitch angle (deg)</name>
<format>P=%03.2f</format>
<node>/orientation/pitch-deg</node>
</chunk>
</output>

</generic>
</PropertyList>
</syntaxhighlight>

===Writing data in XML format===
Assuming the file is called <code>[[$FG_ROOT]]/Protocol/xmltest.xml</code>, then it could be used as
fgfs --generic=file,out,1,/tmp/data.xml,xmltest

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<binary_mode>false</binary_mode>
<var_separator>\n</var_separator>
<line_separator>\n</line_separator>
<preamble><?xml version="1.0"?>\n\n<data>\n</preamble>
<postamble></data>\n</postamble>

<chunk>
<format>\t<set></format>
</chunk>

<chunk>
<node>/position/altitude-ft</node>
<type>float</type>
<format>\t\t<altitude-ft>%.8f</altitude-ft></format>
</chunk>
</syntaxhighlight>

For more examples, see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37892.html mailing list thread].
<syntaxhighlight lang="xml">
<chunk>
<node>/velocities/airspeed-kt</node>
<type>float</type>
<format>\t\t<airspeed-kt>%.8f</airspeed-kt></format>
</chunk>

<chunk>
<format>\t</set></format>
</chunk>
</output>
</generic>
</PropertyList>
</syntaxhighlight>

== Analyzing the resulting binary packet format ==
A utility called ''generic-protocol-analyse'' can be found under <code>FlightGear/utils/xmlgrep</code> which can be used to analyze the resulting data packet for the binary protocol. The output would be something like:

<pre>
bintest.xml
Generic binary output protocol packet description:

pos | size | type | factor | description
-----|------|--------|------------|------------------------
0 | 4 | int | | indicated speed (kt)
4 | 4 | float | | pitch att (deg)
8 | 4 | float | | magnetic heading (deg)
12 | 4 | int | | outside air temperarure (degF)
16 | 1 | bool | | autocoord

total package size: 17 bytes
</pre>

== Generic Protocol ==
FlightGear has an inbuilt "generic" protocol to push and pull data. (todo)

To interface with FlightGear on a socket for example, the following steps need to be taken:
# Establish which "properties" you want to appear "on the wire".
# Create a <code>my_protocol.xml</code> file containing those properties.
# Start FlightGear with the generic protocol option using <code>my_protocol</code> sent through the network socket.

For this simple example say were interested in heading and altitude, and we want to "listen" ie output to a socket at port 6789, UDP and receiving 10 times a second in the format:
alt\thead\n
// ie altitude - tab - heading - newline

The first step is establishing the nodes, in this example
/position/altitude-agl-ft eg (22.4713923)
/orientation/heading-deg eg (297.966325)

Next create a file '''my_protocol.xml'''. This needs to be located at
[[$FG_ROOT]]/Protocol/my_protocol.xml

Edit the <code>my_protocol.xml</code> file and write in it:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<line_separator>newline</line_separator>
<var_separator>tab</var_separator>

<chunk>
<node>/position/altitude-agl-ft</node>
<name>altitude to go</name>
<type>float</type>
<format>%03.2f</format>
</chunk>

<chunk>
<node>/orientation/heading-deg</node>
<name>Heading</name>
<type>float</type>
<format>%03.3f</format>
</chunk>

</output>
</generic>
</PropertyList>
</syntaxhighlight>

* The '''output''' tag indicates the protocol for output. The same "protocol" file can contain an "input" section, absent in this example (more later).
* '''line_seperator''' - the end of line (todo - is this <code>\r\n</code>?)
* '''var_seperator''' - the delimiter for the properties, this could be "|", "###", any string.
* The two '''chunk''' blocks contain our data. Note that these appear in the order presented within the XML file.
** '''node''' - the node of data we want
** '''name''' - it there for a reference, its not transmitted and note necessary (like a note)
** '''type''' - the way this xml is to interpret the value. This is quite important tag. For example if its not there or a string, then "floats" go wild and end up being a string of 32 characters with two decimal places!
** '''format''' - same syntax as <code>printf</code> function in C/C++
** There's more that can be done {todo - link to a full blown example/reference}

We can now start FlightGear and listen with:
fgfs --generic=socket,out,10,localhost,6789,udp,my_protocol

[todo] - link here to the tutorial

== Alternative start using Nasal ==
It is also possible to start and stop from within the Nasal console. Start the Nasal console from the Debug menu and type the following (modify accordingly) and click Execute:
fgcommand("add-io-channel", {"config": "generic,socket,out,10,localhost,6789,udp,my_protocol", "name": "test"});
Name is optional but can be used to stop the connection using:
fgcommand("remove-io-channel", {"name": "test"});

== Related content ==
=== Wiki articles ===
* [[Logging properties]] – ''A simpler way to log properties to a file.''
* [[Howto:Record, analyze and replay multiplayer flights with network tools]] - ''Logging the network traffic between your computer and a multiplayer server.''
* [[Using FlightGear with an EFB]]

=== Readme files ===
* {{readme file|protocol}}
* {{readme file|IO}}

=== Source code ===
* {{fgdata source|Protocol/}} – ''Predefined protocols''
* {{flightgear source|src/Network/generic.hxx}}
* {{flightgear source|src/Network/generic.cxx}}

[[Category:Interfacing protocols]]
[[Category:FlightGear]]
[[Category:XML]]
[[Category:Property Tree]]

[[pl:Protokół ogólny]]

Howto:Using FlightGear with an EFB

2023-08-24T01:46:15Z

David.megginson: Add screenshots and fill in info for FltPlan Go.

An '''Electronic Flight Bag''' (EFB) is an application that includes maps, weight-and-balance, and other tools that used to exist physically in a pilot's flight bag. The best-known EFB applications available on consumer mobile devices include [https://foreflight.com/ ForeFlight] ($$, iOS only, global), [https://www.garmin.com/en-CA/aviation/garminpilot/overview/ Garmin Pilot] ($$, Android and iOS, global), [https://flttrack.fltplan.com/FltPlanInfo/FltPlan_Go-Android-iPad_Info.html FltPlan Go] (cost-free, Android and iOS, Canada/U.S./Caribbean), and [https://www.apps4av.com/ Avare] (cost-free, Android only, U.S. only). Note that U.S. coverage typically overlaps slightly into southern Canada and northern Mexico.

FlightGear can feed data to most EFB applications to replace real GPS data in plane, so you can use your tablet for a moving map and flight planner beside your computer, just like you would in a real cockpit.

The instructions in this article are tested with FltPlan Go (because it's cost-free), but have been used in the past with Garmin Pilot as well, and should also work at least with ForeFlight.

== Configuring FlightGear ==

The necessary protocol files already exist in FlightGear, so all you need to do is add the following two lines to your $HOME/.fgfsrc file or to the "Additional Settings" subsection of "Settings" in the visual launcher:

--generic=socket,out,10,255.255.255.255,49002,udp,foreflight-xatt
--generic=socket,out,1,255.255.255.255,49002,udp,foreflight-xgps

== Configuring your EFB ==

[[File:FltPlan Go settings.jpg|thumb|80px|FltPlan Go External settings to connect with FlightGear]]
[[File:FltPlan Go map page.jpg|thumb|80px|Moving map showing a FlightGear flight over a Canadian VNC (Sectional).]]

Your mobile device ''must'' be connected to the same network as the computer running FlightGear. The following instructions apply to FltPlan Go, but the process for other EFBs will be similar (follow the instructions for connecting to X-Plane).

Go to the "External" side tab for FltPlan Go, and select "X-Plane" under "Simulators". Then start FlightGear (in the same network), and wait for the altitude, latitude, longitude, course, and speed information to appear in the fields to the right: these will confirm that you have made a connection.

You can now navigate to other tabs, such as the moving map or airport diagrams and instrument procedures, and see your aircraft position live.

File:FltPlan Go settings.jpg

2023-08-24T01:38:32Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=FltPlan Go External settings to connect with FlightGear}}
|date=2023-08-23 19:09:45
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

File:FltPlan Go map page.jpg

2023-08-24T01:38:32Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Moving map showing a FlightGear flight over a Canadian VNC (Sectional).}}
|date=2023-08-23 19:09:31
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

Howto:Using FlightGear with an EFB

2023-08-23T23:31:20Z

David.megginson: Initial draft

Americas Scenery

2023-05-23T02:19:14Z

David.megginson: Remove cats

Americas Scenery

2023-05-23T02:12:24Z

David.megginson: Initial draft

File:Jasper BC Rocky Mountains.png

2023-05-23T02:07:04Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=SAR DHC-3 Otter flying through the Rocky Mountains near Jasper AB (CYJA).}}
|date=2023-05-22
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Scenery in North America]]

File:Canadian Shield lakes.png

2023-05-23T02:07:04Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The Canadian Shield is full of small lakes.}}
|date=2023-05-22
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Scenery in North America]]

File:St Louis arch.png

2023-05-23T02:07:04Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Flying towards the Gateway Arch in St Louis, MO.}}
|date=2023-05-22
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Scenery in North America]]

File:Vancouver BC evening.png

2023-05-23T02:07:03Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Downtown Vancouver BC at dusk, facing north, with Kitsilano in the foreground and Stanley Park on the left.}}
|date=2023-05-22
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Scenery in North America]]

File:Goderich ON winter.png

2023-05-23T02:07:03Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Cessna 140 approaching a frozen-over Georgian Bay (Lake Huron) in winter, near Goderich ON (CYGD).}}
|date=2023-05-22
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Scenery in North America]]

File:Miami Beach FL hazy afternoon.png

2023-05-23T02:07:03Z

David.megginson: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Piper Cub flying along Miami Beach on a hazy afternoon.}}
|date=2023-05-22
|source={{own}}
|author=[[User:David.megginson|David.megginson]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Scenery in North America]]

Howto:Use TerraGear without wanting to kill yourself

2023-01-08T15:11:31Z

David.megginson: /* Map and decode your shapefiles */ mention splitting job

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 ==

(Tip from [[User:david.megginson]]: from this point forward in the scenery-generation process, I often find problems when I try to generate an entire 10x10 degree bucket at once, so I run a script to do it 1 1x1 degree sub-bucket at a time).

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]]
[[Category:Scenery_enhancement]]

Piper J3 Cub

2018-02-26T00:19:16Z

David.megginson: /* 3D Cockpit */ link to photo of inclinometer

{{:{{PAGENAME}}/info}}
The '''Piper J-3 Cub''' is a small, simple, light [[aircraft]] that was built between 1937 and 1947 by [[:Category:Piper|Piper Aircraft]]. With tandem (fore and aft) seating, it was intended for flight training but became one of the most popular and best-known light aircraft of all time. The Cub's simplicity, affordability and popularity invokes comparisons to the Ford Model T automobile.

The aircraft's standard yellow paint has come to be known as “Cub Yellow” or "Lock Haven Yellow".

== Aircraft help ==
=== Controls ===
{| class="keytable"
! Key
! Function
|-
| {{key press|d}}
| Open/Close door
|-
| {{key press|s}}
| Start engine
|-
| {{key press|Ctrl|o}}
| Start/Stop aerotowing
|}

=== Manual ===
This section originally contained material which was suspected of not complying with the GPL and was removed.

The original Cub manual may be found by searching for "how to fly a Piper Cub" on the net. This link should also work - http://www.paragonair.com/N/70497/FLY_A_CUB.pdf

=== Pilot Check List ===
==== Pre start ====
# Chocks on
# Check fuel quantity
# Check controls movements

==== Start ====
# Switch fuel on
# Check magneto off
# Swing prop
# Switch magneto to both
# Swing prop
# Chocks away
# Check oil pressure
# Check door close
# S-taxi to runway

==== Take off ====
# Check all clear
# Throttle to 1400 rpm
# Check tachometer
# Ease throttle forward
# At 100 feet ease tail up
# Stick to neutral
# Stick back pressure to 10 feet altitude
# Stick neutral again
# Climb
# Fly

==== Landing ====
# Prepare to land
# Ease throttle back
# Check carb heater
# Glide to runway
# Clear engine with throttle
# At 15 feet back pressure
# At 2 feet stick all way back
# No need to brake
# S-taxi
# Switch magneto off

=== Flying ===

FG 2.4 Default aircraft --aicraft=Cub

Having been familiar with the Piper cub model in earlier versions of FG, I was pleasantly surprised by the improvement in detail. Overall the model seemed more accurate and the cockpit was especially pleasing.

The aircraft starts with the engine ticking over, so increasing the throttle, rudder has to be used to keep the aircraft straight, but this brings the left wing low, and attempting to correct this immediately lifts the aircraft off in a second. Climb is good, and visibility is very good, enhanced by the view of the high definition model of the tire sticking out as seem from the cockpit.

An easy aircraft to fly, the instruments, although as clear as any, take some getting used to, but then we are flying VFR. The RPM reads right to left, and there is an ASI, altimeter but no VSI at all. There are no radios or other electrical encumbrances.

Landing was particularly easy, slowing down to 50 kt or so, and landing on the grass outside of KSFO which undoubtedly will not be permitted in real life.

Probably the original LSA, the Cub will probably never lose its charm, and is well worth checking out.

--[[User:Openflight|Openflight]] ([[User talk:Openflight|talk]]) 00:42, 8 February 2014 (UTC)

=== Aerotowing ===
The J3Cub is capable of [[Howto: Do aerotow over the net|aerotowing over multiplayer]] by the glider pilot pressing {{key press|Ctrl|o}} while behind the Cub.

== Development status/Issues/Todo ==
The aircraft was fully remodelled in April 2010 and made available as the Cub. The original low resolution model is still available as the Piper J3 Cub in FGFS version 1.9.1 and older.

=== Liveries ===
As of 6/2015, a livery system and three new liveries have been added.

=== 3D Cockpit ===
* No switches and levers available
* Altimeter can't be adjusted with the mouse
* While an inclinometer (slip/skid bubble) is optional in a J3 Cub, it's highly recommended, since we can't feel uncoordinated flight through the seats of our pants in FlightGear (it's right under the mag compass in [https://i.pinimg.com/originals/75/2a/a4/752aa4b07f3b6d43ca10e9fb6b703c61.jpg this photo])

=== General ===
* Engine sound in cockpit differs only slightly from outside engine sound

=== Non-bugs ===
* Pilot door is open and partly in the the wing rods - this is accurate, and how the J3 can be flown
* Does this airplane have flaps? - no
* No electrical system, therefore no cockpit, instrument, or aircraft lights - but there is an engine start to make it easy
* No HUD

{{Piper}}

Piper J3 Cub

2018-02-26T00:15:59Z

David.megginson: /* 3D Cockpit */ mention inclinometer

{{:{{PAGENAME}}/info}}
The '''Piper J-3 Cub''' is a small, simple, light [[aircraft]] that was built between 1937 and 1947 by [[:Category:Piper|Piper Aircraft]]. With tandem (fore and aft) seating, it was intended for flight training but became one of the most popular and best-known light aircraft of all time. The Cub's simplicity, affordability and popularity invokes comparisons to the Ford Model T automobile.

The aircraft's standard yellow paint has come to be known as “Cub Yellow” or "Lock Haven Yellow".

== Aircraft help ==
=== Controls ===
{| class="keytable"
! Key
! Function
|-
| {{key press|d}}
| Open/Close door
|-
| {{key press|s}}
| Start engine
|-
| {{key press|Ctrl|o}}
| Start/Stop aerotowing
|}

=== Manual ===
This section originally contained material which was suspected of not complying with the GPL and was removed.

The original Cub manual may be found by searching for "how to fly a Piper Cub" on the net. This link should also work - http://www.paragonair.com/N/70497/FLY_A_CUB.pdf

=== Pilot Check List ===
==== Pre start ====
# Chocks on
# Check fuel quantity
# Check controls movements

==== Start ====
# Switch fuel on
# Check magneto off
# Swing prop
# Switch magneto to both
# Swing prop
# Chocks away
# Check oil pressure
# Check door close
# S-taxi to runway

==== Take off ====
# Check all clear
# Throttle to 1400 rpm
# Check tachometer
# Ease throttle forward
# At 100 feet ease tail up
# Stick to neutral
# Stick back pressure to 10 feet altitude
# Stick neutral again
# Climb
# Fly

==== Landing ====
# Prepare to land
# Ease throttle back
# Check carb heater
# Glide to runway
# Clear engine with throttle
# At 15 feet back pressure
# At 2 feet stick all way back
# No need to brake
# S-taxi
# Switch magneto off

=== Flying ===

FG 2.4 Default aircraft --aicraft=Cub

Having been familiar with the Piper cub model in earlier versions of FG, I was pleasantly surprised by the improvement in detail. Overall the model seemed more accurate and the cockpit was especially pleasing.

The aircraft starts with the engine ticking over, so increasing the throttle, rudder has to be used to keep the aircraft straight, but this brings the left wing low, and attempting to correct this immediately lifts the aircraft off in a second. Climb is good, and visibility is very good, enhanced by the view of the high definition model of the tire sticking out as seem from the cockpit.

An easy aircraft to fly, the instruments, although as clear as any, take some getting used to, but then we are flying VFR. The RPM reads right to left, and there is an ASI, altimeter but no VSI at all. There are no radios or other electrical encumbrances.

Landing was particularly easy, slowing down to 50 kt or so, and landing on the grass outside of KSFO which undoubtedly will not be permitted in real life.

Probably the original LSA, the Cub will probably never lose its charm, and is well worth checking out.

--[[User:Openflight|Openflight]] ([[User talk:Openflight|talk]]) 00:42, 8 February 2014 (UTC)

=== Aerotowing ===
The J3Cub is capable of [[Howto: Do aerotow over the net|aerotowing over multiplayer]] by the glider pilot pressing {{key press|Ctrl|o}} while behind the Cub.

== Development status/Issues/Todo ==
The aircraft was fully remodelled in April 2010 and made available as the Cub. The original low resolution model is still available as the Piper J3 Cub in FGFS version 1.9.1 and older.

=== Liveries ===
As of 6/2015, a livery system and three new liveries have been added.

=== 3D Cockpit ===
* No switches and levers available
* Altimeter can't be adjusted with the mouse
* While an inclinometer (slip/skid bubble) is optional in a J3 Cub, it's highly recommended, since we can't feel uncoordinated flight in FlightGear

=== General ===
* Engine sound in cockpit differs only slightly from outside engine sound

=== Non-bugs ===
* Pilot door is open and partly in the the wing rods - this is accurate, and how the J3 can be flown
* Does this airplane have flaps? - no
* No electrical system, therefore no cockpit, instrument, or aircraft lights - but there is an engine start to make it easy
* No HUD

{{Piper}}

List of developed airports

2017-02-15T01:58:25Z

David.megginson: /* List of airports */ fix description for CYGK

This is an incomplete '''list of developed airports''' in the FlightGear [[TerraSync]] scenery.

Airports can be listed here if these two conditions are fulfilled:
* At least one building or [[Signs|taxi signs]] have been placed
* Objects are represented in the [[FlightGear Scenery Database]].

Every improvement listed here should be possible to download using TerraSync. These improvements will also be included in the next [[World Scenery]] release.

__TOC__

== For airport developers ==
If you are currently developing an airport, please feel free to add it to [[Airports under construction]]. For a list of currently ongoing scenery related projects, please check out [[Current Scenery Projects]].

== List of airports ==
The ICAO codes link to the FlightGear mapserver, which - among other things - contains information about the current status of the [[FlightGear Scenery Database]]. On a map, you will see:
* The current airport layout with runways, taxiways and aprons
* Red dots: static objects in the scenery database made especially for this airport
* Dark red dots: shared models in the scenery database placed at this airport
* Green dots: [[Signs|taxi signs]] placed at the airport

{{inote|You can sort the table by clicking one of the [[File:Sort none.gif]] symbols in the row headers.}}

{| class="wikitable sortable" border="0" cellspacing="0"
|-
! ICAO !! Name !! Country !! Continent !! class="unsortable" | Comment

|-
| CYGK || [[Kingston Norman Rogers]] || Canada || North America || Custom objects for all major buildings, including public terminal. (Buildings may not align with taxiways in default scenery, until it starts using the newest recommended airport data from X-Plane.)

|-
| [https://scenery.flightgear.org/map/?lon=13.76716&lat=51.13277&z=13 EDDC] || [[Dresden Airport]] || Germany || Europe || Fully modeled with tower, terminal, animated hangars etc.

|-
| [https://scenery.flightgear.org/map/?lon=8.56293&lat=50.03795&z=13 EDDF] || [[Frankfurt am Main Airport]] || Germany || Europe || Fully modeled with [[Signs]] and [[Interactive Traffic]] and unique scycrapers downtown

|-
| EDDG || [[Münster Osnabrück]] || Germany || Europe || 1 static + 100 shared objects

|-
| EDDH || [[Hamburg Airport]] || Germany || Europe || Fully modeled, plus unique buildings downtown

|-
| [https://scenery.flightgear.org/map/?lon=13.40379&lat=52.47502&z=13 EDDI] ||[[Berlin Tempelhof Airport]] || Germany || Europe || Fully modeled

|-
| EDDL || [[Düsseldorf International Airport|Düsseldorf Airport]] || Germany || Europe || Fully modeled, many shared objects

|-
| [https://scenery.flightgear.org/map/?lon=11.78609&lat=48.35378&z=13 EDDM] || [[Munich Airport]] || Germany || Europe || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=12.23603&lat=51.42262&z=13 EDDP] || [[Leipzig/Halle Airport]] || Germany || Europe || Fully modelled with [[Signs]]

|-
| EDDS || [[Stuttgart Airport]] || Germany || Europe || Fully modelled based on Shared-Models, incl. [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lon=13.28992&lat=52.55917&z=13 EDDT] || [[Berlin Tegel Airport]] || Germany || Europe || Tower, terminals, [[Signs]] and unique buildings downtown

|-
| EDFB || Reichelsheim Airport || Germany || Europe || Tower done

|-
| EDFM || [[Mannheim City Airport]] || Germany || Europe || Basic models of tower, terminals and hangars

|-
| [https://scenery.flightgear.org/map/?lon=10.71706&lat=53.80496&z=13 EDHL] || [[Lübeck Blankensee Airport]] || Germany || Europe || Almost complete, home of the [[Piper PA34-200T Seneca II|Seneca]] used to model the FlightGear version. A modified tile is available at [http://www.t3r.de/fg/scenery/ Torsten's scenery site]

|-
| [https://scenery.flightgear.org/map/?lon=7.16278&lat=50.76767&z=13 EDKB] || [[Bonn-Hangelar Airport]] || Germany || Europe ||

|-
| EDLW || [[Flughafen Dortmund]] || Germany || Europe || Fully modelled

|-
| EDVE || [[Braunschweig Airport]] || Germany || Europe || Fully modelled

|-
| EEKE || Kuressaare Airport || Estonia || Europe ||

|-
| EETN || Lennart Meri Tallinn Airport || Estonia || Europe ||

|-
| EETU || Tartu Airport || Estonia || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=25.04487&lat=60.25318&z=13 EFHF] || Helsinki-Malmi Airport || Finland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=24.95253&lat=60.3206&z=13 EFHK] || Helsinki-Vantaa Airport || Finland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=22.26281&lat=60.51412&z=13 EFTU] || Turku Airport || Finland || Europe || Tower and terminal modelled

|-
| EGFF || Cardiff Airport || United Kingdom || Europe || One building: British Airways Maintenance Facility

|-
| EGGP || Liverpool John Lennon Airport || United Kingdom || Europe ||

|-
| EGGW || London Luton Airport || United Kingdom || Europe ||

|-
| EGKA || Shoreham Airport || United Kingdom || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-0.19224&lat=51.14869&z=13 EGKK] || [[London Gatwick]] || United Kingdom || Europe || Complete and fully modeled to highest level of detail with day and night textures; AI parking and ground network

|-
| [https://scenery.flightgear.org/map/?lon=-0.46095&lat=51.47139&z=13 EGLL] || London Heathrow Airport || United Kingdom || Europe || Basic development only

|-
| EGPH || Edinburgh Airport || United Kingdom || Europe || Tower, terminal, park deck, and some shared models

|-
| [https://scenery.flightgear.org/map/?lon=1.28469&lat=52.67713&z=13 EGSH] || Norwich Airport || United Kingdom || Europe ||

|-
| EH01 || [[VU University Medical Center]] || Netherlands || Europe || Complete hospital building including on-roof heli platform.

|-
| [https://scenery.flightgear.org/map/?lon=4.75487&lat=52.31296&z=13 EHAM] || [[Amsterdam Airport Schiphol]] || Netherlands || Europe || Fully modeled, bussiest AI airport currently

|-
| EHEH || Eindhoven Airport || Netherlands || Europe || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=5.51885&lat=52.45717&z=13 EHLE] || [[Lelystad Airport]] || Netherlands || Europe || Fully modeled

|-
| EHVK || [[Volkel Air Base]] || Netherlands || Europe || Shelters and detailed airport layout.

|-
| EIDW || [[Dublin Airport]] || Ireland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=6.11017&lat=62.56037&z=13 ENAL] || Ålesund Airport || Norway || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=6.10949&lat=61.83027&z=13 ENSD] || Sandane Airport || Norway || Europe ||

|-
| ENVA || Trondheim Værnes Airport || Norway || Europe ||

|-
| ESGP || Göteborg Airport || Sweden || Europe || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=-106.60912&lat=35.04021&z=13 KABQ] || Albuquerque Sunport Airport, NM || USA || America || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=-84.42809&lat=33.63672&z=13 KATL] || [[Hartsfield - Jackson Atlanta International Airport]], GA || USA || America || Terminal modeled

|-
| [https://scenery.flightgear.org/map/?lon=-81.4629595&lat=41.0421187&z=13 KAKR] || [[Akron-Fulton International Airport]], OH || USA || America || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=-81.43676804&lat=40.91510112&z=13 KCAK] || Akron-Canton Regional Airport, OH || USA || America || Fully modelled

|-
| KAUS || Austin-Bergstrom Airport, TX || USA || America ||

|-
| KBOS || Boston Logan || USA || America || Tower, Terminals done

|-
| KFNT || Bishop Intl, MI || USA || America || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=-76.66833&lat=39.17535&z=13 KBWI] || Baltimore-Washington International, MD || USA || America || Terminal modeled with jetways, parking garage, support buildings and [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lat=37.9858289&lon=-122.05529346000002&z=15 KCCR] || Buchanan Field Airport, Concord, CA || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-76.92254&lat=38.98062&z=13 KCGS] || College Park Airport, MD || USA || America ||

|-
| KCVG || Cincinnati/Northern Kentucky International Airport, KY || USA || America || Terminals, Concourses, Towers, Signs, DHL Hub, and Other Buildings (Almost Fully Modeled)

|-
| KDCA || Reagan National Airport, VA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-104.67318&lat=39.86166&z=13 KDEN] || [[Denver_International_Airport|Denver Airport, CO]] || USA || America || One terminal modelled

|-
| KDTW || Detroit Metropolitan Wayne County Airport, MI || USA || America || Basic development only

|-
| KFHR || Friday Harbor Airport, WA || USA || America ||

|-
| KIND || Indianapolis Airport, IN || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-90.07589&lat=32.31118&z=13 KJAN] || Jackson-Evers Airport, MS || USA || America ||

|-
| KJFK || [[John F. Kennedy International Airport]], NY || USA || America ||

|-
| KLAS || Las Vegas McCarran Airport, NV || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-118.40809&lat=33.9425&z=13 KLAX] || [[Los Angeles International Airport]], CA || USA|| America || Fully modeled

|-
| KLSV || [[Nellis Air Force Base]], NV || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-109.4667&lat=47.04924&z=13 KLWT] || Lewistown Municipal Airport, MT || USA || America ||

|-
| KMCI || Kansas City Airport, MO || USA || America || Basic development only

|-
| KMPI || Mariposa-Yosemite Airport, CA || USA || America || Hangars and FBO.

|-
| KMTN || Martin State Airport, MD || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-117.69181&lat=35.68565&z=13 KNID] || China Lake Naval Air Weapons Station, CA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.04918&lat=37.4162&z=13 KNUQ] || Moffett Federal Airfield, CA || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-122.22062&lat=37.7214&z=13 KOAK] || [[Oakland International Airport]], CA || USA || America || Realistic terminal, currently undergoing maintenance

|-
| KORD || Chicago [[O'Hare International Airport]], IL || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-88.55704&lat=43.98436&z=13 KOSH] || Wittman Regional Airport, Oshkosh, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-75.12398&lat=38.31045&z=13 KOXB] || Ocean City Municipal Airport, MD || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.59751&lat=45.58871&z=13 KPDX] || Portland Airport, OR || USA || America ||

|-
| KPHX || Phoenix Sky Harbor Airport, AZ || USA || America ||

|-
| KRNO || Reno/Tahoe Airport, NV || USA || America ||

|-
| KSEA || [[Seattle-Tacoma International Airport]], WA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.3749&lat=37.61897&z=13 KSFO] || [[San Francisco International Airport]], CA || USA || America || FlightGear's default airport, terminal buildings, airport lights and airport train.

|-
| KSLC || Salt Lake City International Airport, UT || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lat=33.80112251&lon=-118.34134126&z=15 KTOA] || Zamperini Field, Torrance, CA || USA || America || Fully modeled

|-
| KXTA || Edwards Airforce Base Detachment 3 (Homey Airport, or Area 51), NV || USA || America || Fully Modelled

|-
| KVUO || Pearson Field Airport, Vancouver, WA || USA || America ||

|-
| LDSP || Split Airport || Croatia || Europe || Basic development only

|-
| LEBB || Bilbao || Spain || Europe || Fully modeled

|-
| LEMD || Madrid - Barajas || Spain || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-3.19889&lat=47.32611&z=13 LFEA] || Belle-Ile || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.10167&lat=47.48139&z=13 LFEQ] || Quiberon || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.66479&lat=48.05247&z=13 LFES] || Guiscriff Scaër || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=2.35465&lat=49.04626&z=13 LFFE] || Enghien Moisselles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=4.8264&lat=45.25226&z=13 LFLR] || Saint Rambert d'Albon Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=13.76716&lat=51.13277&z=13 LFMA] || Aix - Les Milles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=0.08816&lat=49.53404&z=13 LFOH] || Le Havre Octeville Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=5.36736&lat=43.50499&z=13 LFPG] || Charles de Gaulle International Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.60632&lat=48.89629&z=13 LFPH] || Chelles Le Pin Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.622793&lat=48.822237&z=13 LFPL] || Lognes Emerainville Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.359443&lat=48.72551&z=13 LFPO] || Paris-Orly Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.073197&lat=48.810622&z=13 LFPZ] || St-Cyr-l’École Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=-4.41785&lat=48.44413&z=13 LFRB] || Brest Bretagne Airport || France || Europe || Modeled airport with static models

|-
| [https://scenery.flightgear.org/map/?lon=-4.15167&lat=48.53014&z=13 LFRL] || Lanvéoc Naval Air Base || France || Europe || Airport fitted with shared models (for helos and training)

|-
| [https://scenery.flightgear.org/map/?lon=-4.15167&lat=48.53014&z=13 LFRJ] || [[Landivisiau Naval Air Base]] || France || Europe || Modeled airport with arresting cables and [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lon=-4.167981&lat=47.97553&z=13 LFRQ] || Quimper || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.816762&lat=48.601247&z=13 LFRU] || Morlaix || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-2.736754&lat=47.717558&z=13 LFRV] || Vannes || France || Europe || Airport fitted with shared models

|-
| [https://scenery.flightgear.org/map/?lon=-3.439579&lat=47.760964&z=13 LFRH] || Lorient - Bretagne Sud || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.439579&lat=47.760964&z=13 LFSB] || [[EuroAirport Basel-Mulhouse-Freiburg|Basel Mulhouse]] || Switzerland || Europe || Nice modelling of Terminal.

|-
| LILN || Venegono Airport || Italy || Europe || Developed airport

|-
| LILQ || Massa Cinquale Airport || Italy || Europe ||

|-
| LILV || Valbrembo Airport || Italy || Europe ||

|-
| LIMC || Milano-Malpensa Airport || Italy || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=9.70741&lat=45.66952&z=13 LIME] || [[Orio al Serio Airport]], Bergamo || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=9.27521&lat=45.44776&z=13 LIML] || [[LIML|Milano-Linate Airport]] || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=7.36789&lat=45.73857&z=13 LIMW] || Aosta Airport || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=14.26&lat=50.100833&z=13 LKPR] || [[Václav Havel Airport Prague]] (Ruzyne) || Czech Republic || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=11.34397&lat=47.26023&z=13 LOWI] || [[Innsbruck Airport]] || Austria || Europe ||

|-
| LROP || Bucharest Otopeni || Romania || Europe ||

|-
| LSGG || Geneve (Cointrin) Airport || Switzerland || Europe || Fully Modelled. OSM2city available on https://github.com/FGMEMBERS-SCENERY/LSGG-fg-CustomScenery

|-
| LSGS || Sion Airport || Switzerland || Europe || Basic development only

|-
| LSZB || Bern-Belp Airport || Switzerland || Europe || Basic development only

|-
| PANC || Ted Stevens Anchorage International Airport || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=136.80541&lat=34.85841&z=13 RJGG] || [[Chūbu Centrair International Airport]] || Japan || Asia || Detailed airport buildings, taxiway layout and customized terrain.

|-
| [https://scenery.flightgear.org/map/?lon=139.78114&lat=35.5533&z=13 RJTT] || [[Tokyo Haneda International Airport]] || Japan || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=126.45051&lat=37.46909&z=13 RKSI] || Seoul Incheon Airport || South Korea || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=121.01349&lat=14.51024&z=13 RPLL] || Manila Aquino Airport || Philippines || Asia || Tower and three large terminals

|-

| SAEZ || Aeropuerto Internacional Ministro Pistarini || Argentina || America || Several static buildings

|-

| [[SVMI]] || Aeropuerto Internacional Simon Bolivar || Venezuela || America || Several static buildings

|-

| TAPA || V.C. Bird Intl Airport || Antigua and Barbuda || America ||

|-
| TDPD || Melville Hall Airport || Dominica || America ||

|-
| TFFF || Martinique Aimé Césaire International Airport || Martinique, France || America ||

|-
| TFFG || Grand Case Airport || St. Maarten, Netherlands || America ||

|-
| TIST || Cyril E. King Airport || US Virgin Islands || America ||

|-
| TJSJ || Luis Muñoz Marín International Airport || Puerto Rico || America ||

|-
| TKPK || Robert L. Bradshaw International Airport || St. Kitts || America ||

|-
| TNCM || [[Princess Juliana International Airport]] || St. Maarten, Netherlands || America || Fully modeled, customized terrain

|-
| TNCS || Juancho E. Yrausquin Airport || Saba || America || Fully modeled

|-
| TQPF || Clayton J. Lloyd International Airport || Anguilla || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-49.17201&lat=-25.53101&z=13 SBCT] || Afonso Pena International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-46.65768&lat=-23.62558&z=13 SBSP] || Congonhas Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-46.46864&lat=-23.43351&z=13 SBGR] || Guarulhos International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-48.54304&lat=-27.6685&z=13 SBFL] || Hercílio Luiz International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| SKRG || Jose Maria Cordoba International Airport, Rionegro, Antioquia || Colombia || South America || Fully Modelled

|-
| VIDP || Indira Gandhi International Airport || India || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=89.42272&lat=27.39994&z=13 VQPR] || [[Paro Airport]] || Bhutan || Asia || Terminal, Buildings, Refernce Points and other POIs

|-
| [https://scenery.flightgear.org/map/?lon=91.50917&lat=27.25961&z=13 VQ10] || [[Yongphulla Airport]] || Bhutan || Asia || Terminal, some other Buildings

|-
| [https://scenery.flightgear.org/map/?lon=113.9183&lat=22.308&z=13 VHHH] || Hong Kong International Airport || Hong Kong || Asia || Terminals, control towers, some other buildings

|-
| [https://scenery.flightgear.org/map/?lon=-81.41707414&lat=41.15689289&z=13 1G3] || Kent State University Airfield, OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-81.76281774&lat=41.13448335&z=13 1G5] || [[Medina Municipal Airport]], OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-81.24620281&lat=41.20973295&z=13 29G] || Portage Co, OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-90.13769&lat=43.83872&z=13 82C] || Mauston-New Lisbon Union Airport, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-89.02545&lat=44.50485&z=13 68C] || Iola Central County Airport, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-123.00815977&lat=43.93009927&z=13 77S] || Hobby Field, Creswell, OR || USA || America || Nearly complete: Hangars (one accidently missing), fuel pump, GA aircraft, cars, trees, bushes (shared models)

|}

== Authors ==

Airports by HerbyW in Yakutia, Irkutsk and Krasnoyarsk:
UIBB UEEE UEST UEMS UEBN UEBT UEWD UEMA UERR UEMT UEEA UEMU UIII UITT UEBB UEVV UENW UEMO UERL UERT UEMH UERO UERP UNAA UIUN UENN UIBV UNCC UEMJ

Airports by D-ABBA:
EDXW,EDFE,EDGS,EDFQ,EDFH,EDFL,EDFO,ED03

Airports by [[User:Laserman]]:
EDDG,EDLM,EDLB,EDLK,EDLN,EDLV,EDLW,LJLJ,LJAJ,LJSG,LJCE,LJPZ

== External links ==
* [http://iveze.nl/fgmap/ Builtup airports in Flightgear] – Interactive world map by KL-666. ''See also related forum topic [http://forum.flightgear.org/viewtopic.php?f=5&t=23613 Map of airports with buildings in terrasync].''

{{Suggested}}

[[Category:Lists]]
[[Category:Airports]]

List of developed airports

2017-02-15T01:57:30Z

David.megginson: /* List of airports */ added caveat for CYGK

This is an incomplete '''list of developed airports''' in the FlightGear [[TerraSync]] scenery.

Airports can be listed here if these two conditions are fulfilled:
* At least one building or [[Signs|taxi signs]] have been placed
* Objects are represented in the [[FlightGear Scenery Database]].

Every improvement listed here should be possible to download using TerraSync. These improvements will also be included in the next [[World Scenery]] release.

__TOC__

== For airport developers ==
If you are currently developing an airport, please feel free to add it to [[Airports under construction]]. For a list of currently ongoing scenery related projects, please check out [[Current Scenery Projects]].

== List of airports ==
The ICAO codes link to the FlightGear mapserver, which - among other things - contains information about the current status of the [[FlightGear Scenery Database]]. On a map, you will see:
* The current airport layout with runways, taxiways and aprons
* Red dots: static objects in the scenery database made especially for this airport
* Dark red dots: shared models in the scenery database placed at this airport
* Green dots: [[Signs|taxi signs]] placed at the airport

{{inote|You can sort the table by clicking one of the [[File:Sort none.gif]] symbols in the row headers.}}

{| class="wikitable sortable" border="0" cellspacing="0"
|-
! ICAO !! Name !! Country !! Continent !! class="unsortable" | Comment

|-
| CYGK || [[Kingston Norman Rogers]] || Canada || North America || Custom objects for all major buildings, including FBO. (Buildings may not align with taxiways in default scenery, until it starts using the newest recommended airport data from X-Plane.)

|-
| [https://scenery.flightgear.org/map/?lon=13.76716&lat=51.13277&z=13 EDDC] || [[Dresden Airport]] || Germany || Europe || Fully modeled with tower, terminal, animated hangars etc.

|-
| [https://scenery.flightgear.org/map/?lon=8.56293&lat=50.03795&z=13 EDDF] || [[Frankfurt am Main Airport]] || Germany || Europe || Fully modeled with [[Signs]] and [[Interactive Traffic]] and unique scycrapers downtown

|-
| EDDG || [[Münster Osnabrück]] || Germany || Europe || 1 static + 100 shared objects

|-
| EDDH || [[Hamburg Airport]] || Germany || Europe || Fully modeled, plus unique buildings downtown

|-
| [https://scenery.flightgear.org/map/?lon=13.40379&lat=52.47502&z=13 EDDI] ||[[Berlin Tempelhof Airport]] || Germany || Europe || Fully modeled

|-
| EDDL || [[Düsseldorf International Airport|Düsseldorf Airport]] || Germany || Europe || Fully modeled, many shared objects

|-
| [https://scenery.flightgear.org/map/?lon=11.78609&lat=48.35378&z=13 EDDM] || [[Munich Airport]] || Germany || Europe || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=12.23603&lat=51.42262&z=13 EDDP] || [[Leipzig/Halle Airport]] || Germany || Europe || Fully modelled with [[Signs]]

|-
| EDDS || [[Stuttgart Airport]] || Germany || Europe || Fully modelled based on Shared-Models, incl. [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lon=13.28992&lat=52.55917&z=13 EDDT] || [[Berlin Tegel Airport]] || Germany || Europe || Tower, terminals, [[Signs]] and unique buildings downtown

|-
| EDFB || Reichelsheim Airport || Germany || Europe || Tower done

|-
| EDFM || [[Mannheim City Airport]] || Germany || Europe || Basic models of tower, terminals and hangars

|-
| [https://scenery.flightgear.org/map/?lon=10.71706&lat=53.80496&z=13 EDHL] || [[Lübeck Blankensee Airport]] || Germany || Europe || Almost complete, home of the [[Piper PA34-200T Seneca II|Seneca]] used to model the FlightGear version. A modified tile is available at [http://www.t3r.de/fg/scenery/ Torsten's scenery site]

|-
| [https://scenery.flightgear.org/map/?lon=7.16278&lat=50.76767&z=13 EDKB] || [[Bonn-Hangelar Airport]] || Germany || Europe ||

|-
| EDLW || [[Flughafen Dortmund]] || Germany || Europe || Fully modelled

|-
| EDVE || [[Braunschweig Airport]] || Germany || Europe || Fully modelled

|-
| EEKE || Kuressaare Airport || Estonia || Europe ||

|-
| EETN || Lennart Meri Tallinn Airport || Estonia || Europe ||

|-
| EETU || Tartu Airport || Estonia || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=25.04487&lat=60.25318&z=13 EFHF] || Helsinki-Malmi Airport || Finland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=24.95253&lat=60.3206&z=13 EFHK] || Helsinki-Vantaa Airport || Finland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=22.26281&lat=60.51412&z=13 EFTU] || Turku Airport || Finland || Europe || Tower and terminal modelled

|-
| EGFF || Cardiff Airport || United Kingdom || Europe || One building: British Airways Maintenance Facility

|-
| EGGP || Liverpool John Lennon Airport || United Kingdom || Europe ||

|-
| EGGW || London Luton Airport || United Kingdom || Europe ||

|-
| EGKA || Shoreham Airport || United Kingdom || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-0.19224&lat=51.14869&z=13 EGKK] || [[London Gatwick]] || United Kingdom || Europe || Complete and fully modeled to highest level of detail with day and night textures; AI parking and ground network

|-
| [https://scenery.flightgear.org/map/?lon=-0.46095&lat=51.47139&z=13 EGLL] || London Heathrow Airport || United Kingdom || Europe || Basic development only

|-
| EGPH || Edinburgh Airport || United Kingdom || Europe || Tower, terminal, park deck, and some shared models

|-
| [https://scenery.flightgear.org/map/?lon=1.28469&lat=52.67713&z=13 EGSH] || Norwich Airport || United Kingdom || Europe ||

|-
| EH01 || [[VU University Medical Center]] || Netherlands || Europe || Complete hospital building including on-roof heli platform.

|-
| [https://scenery.flightgear.org/map/?lon=4.75487&lat=52.31296&z=13 EHAM] || [[Amsterdam Airport Schiphol]] || Netherlands || Europe || Fully modeled, bussiest AI airport currently

|-
| EHEH || Eindhoven Airport || Netherlands || Europe || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=5.51885&lat=52.45717&z=13 EHLE] || [[Lelystad Airport]] || Netherlands || Europe || Fully modeled

|-
| EHVK || [[Volkel Air Base]] || Netherlands || Europe || Shelters and detailed airport layout.

|-
| EIDW || [[Dublin Airport]] || Ireland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=6.11017&lat=62.56037&z=13 ENAL] || Ålesund Airport || Norway || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=6.10949&lat=61.83027&z=13 ENSD] || Sandane Airport || Norway || Europe ||

|-
| ENVA || Trondheim Værnes Airport || Norway || Europe ||

|-
| ESGP || Göteborg Airport || Sweden || Europe || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=-106.60912&lat=35.04021&z=13 KABQ] || Albuquerque Sunport Airport, NM || USA || America || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=-84.42809&lat=33.63672&z=13 KATL] || [[Hartsfield - Jackson Atlanta International Airport]], GA || USA || America || Terminal modeled

|-
| [https://scenery.flightgear.org/map/?lon=-81.4629595&lat=41.0421187&z=13 KAKR] || [[Akron-Fulton International Airport]], OH || USA || America || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=-81.43676804&lat=40.91510112&z=13 KCAK] || Akron-Canton Regional Airport, OH || USA || America || Fully modelled

|-
| KAUS || Austin-Bergstrom Airport, TX || USA || America ||

|-
| KBOS || Boston Logan || USA || America || Tower, Terminals done

|-
| KFNT || Bishop Intl, MI || USA || America || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=-76.66833&lat=39.17535&z=13 KBWI] || Baltimore-Washington International, MD || USA || America || Terminal modeled with jetways, parking garage, support buildings and [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lat=37.9858289&lon=-122.05529346000002&z=15 KCCR] || Buchanan Field Airport, Concord, CA || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-76.92254&lat=38.98062&z=13 KCGS] || College Park Airport, MD || USA || America ||

|-
| KCVG || Cincinnati/Northern Kentucky International Airport, KY || USA || America || Terminals, Concourses, Towers, Signs, DHL Hub, and Other Buildings (Almost Fully Modeled)

|-
| KDCA || Reagan National Airport, VA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-104.67318&lat=39.86166&z=13 KDEN] || [[Denver_International_Airport|Denver Airport, CO]] || USA || America || One terminal modelled

|-
| KDTW || Detroit Metropolitan Wayne County Airport, MI || USA || America || Basic development only

|-
| KFHR || Friday Harbor Airport, WA || USA || America ||

|-
| KIND || Indianapolis Airport, IN || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-90.07589&lat=32.31118&z=13 KJAN] || Jackson-Evers Airport, MS || USA || America ||

|-
| KJFK || [[John F. Kennedy International Airport]], NY || USA || America ||

|-
| KLAS || Las Vegas McCarran Airport, NV || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-118.40809&lat=33.9425&z=13 KLAX] || [[Los Angeles International Airport]], CA || USA|| America || Fully modeled

|-
| KLSV || [[Nellis Air Force Base]], NV || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-109.4667&lat=47.04924&z=13 KLWT] || Lewistown Municipal Airport, MT || USA || America ||

|-
| KMCI || Kansas City Airport, MO || USA || America || Basic development only

|-
| KMPI || Mariposa-Yosemite Airport, CA || USA || America || Hangars and FBO.

|-
| KMTN || Martin State Airport, MD || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-117.69181&lat=35.68565&z=13 KNID] || China Lake Naval Air Weapons Station, CA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.04918&lat=37.4162&z=13 KNUQ] || Moffett Federal Airfield, CA || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-122.22062&lat=37.7214&z=13 KOAK] || [[Oakland International Airport]], CA || USA || America || Realistic terminal, currently undergoing maintenance

|-
| KORD || Chicago [[O'Hare International Airport]], IL || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-88.55704&lat=43.98436&z=13 KOSH] || Wittman Regional Airport, Oshkosh, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-75.12398&lat=38.31045&z=13 KOXB] || Ocean City Municipal Airport, MD || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.59751&lat=45.58871&z=13 KPDX] || Portland Airport, OR || USA || America ||

|-
| KPHX || Phoenix Sky Harbor Airport, AZ || USA || America ||

|-
| KRNO || Reno/Tahoe Airport, NV || USA || America ||

|-
| KSEA || [[Seattle-Tacoma International Airport]], WA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.3749&lat=37.61897&z=13 KSFO] || [[San Francisco International Airport]], CA || USA || America || FlightGear's default airport, terminal buildings, airport lights and airport train.

|-
| KSLC || Salt Lake City International Airport, UT || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lat=33.80112251&lon=-118.34134126&z=15 KTOA] || Zamperini Field, Torrance, CA || USA || America || Fully modeled

|-
| KXTA || Edwards Airforce Base Detachment 3 (Homey Airport, or Area 51), NV || USA || America || Fully Modelled

|-
| KVUO || Pearson Field Airport, Vancouver, WA || USA || America ||

|-
| LDSP || Split Airport || Croatia || Europe || Basic development only

|-
| LEBB || Bilbao || Spain || Europe || Fully modeled

|-
| LEMD || Madrid - Barajas || Spain || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-3.19889&lat=47.32611&z=13 LFEA] || Belle-Ile || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.10167&lat=47.48139&z=13 LFEQ] || Quiberon || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.66479&lat=48.05247&z=13 LFES] || Guiscriff Scaër || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=2.35465&lat=49.04626&z=13 LFFE] || Enghien Moisselles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=4.8264&lat=45.25226&z=13 LFLR] || Saint Rambert d'Albon Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=13.76716&lat=51.13277&z=13 LFMA] || Aix - Les Milles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=0.08816&lat=49.53404&z=13 LFOH] || Le Havre Octeville Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=5.36736&lat=43.50499&z=13 LFPG] || Charles de Gaulle International Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.60632&lat=48.89629&z=13 LFPH] || Chelles Le Pin Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.622793&lat=48.822237&z=13 LFPL] || Lognes Emerainville Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.359443&lat=48.72551&z=13 LFPO] || Paris-Orly Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.073197&lat=48.810622&z=13 LFPZ] || St-Cyr-l’École Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=-4.41785&lat=48.44413&z=13 LFRB] || Brest Bretagne Airport || France || Europe || Modeled airport with static models

|-
| [https://scenery.flightgear.org/map/?lon=-4.15167&lat=48.53014&z=13 LFRL] || Lanvéoc Naval Air Base || France || Europe || Airport fitted with shared models (for helos and training)

|-
| [https://scenery.flightgear.org/map/?lon=-4.15167&lat=48.53014&z=13 LFRJ] || [[Landivisiau Naval Air Base]] || France || Europe || Modeled airport with arresting cables and [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lon=-4.167981&lat=47.97553&z=13 LFRQ] || Quimper || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.816762&lat=48.601247&z=13 LFRU] || Morlaix || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-2.736754&lat=47.717558&z=13 LFRV] || Vannes || France || Europe || Airport fitted with shared models

|-
| [https://scenery.flightgear.org/map/?lon=-3.439579&lat=47.760964&z=13 LFRH] || Lorient - Bretagne Sud || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.439579&lat=47.760964&z=13 LFSB] || [[EuroAirport Basel-Mulhouse-Freiburg|Basel Mulhouse]] || Switzerland || Europe || Nice modelling of Terminal.

|-
| LILN || Venegono Airport || Italy || Europe || Developed airport

|-
| LILQ || Massa Cinquale Airport || Italy || Europe ||

|-
| LILV || Valbrembo Airport || Italy || Europe ||

|-
| LIMC || Milano-Malpensa Airport || Italy || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=9.70741&lat=45.66952&z=13 LIME] || [[Orio al Serio Airport]], Bergamo || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=9.27521&lat=45.44776&z=13 LIML] || [[LIML|Milano-Linate Airport]] || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=7.36789&lat=45.73857&z=13 LIMW] || Aosta Airport || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=14.26&lat=50.100833&z=13 LKPR] || [[Václav Havel Airport Prague]] (Ruzyne) || Czech Republic || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=11.34397&lat=47.26023&z=13 LOWI] || [[Innsbruck Airport]] || Austria || Europe ||

|-
| LROP || Bucharest Otopeni || Romania || Europe ||

|-
| LSGG || Geneve (Cointrin) Airport || Switzerland || Europe || Fully Modelled. OSM2city available on https://github.com/FGMEMBERS-SCENERY/LSGG-fg-CustomScenery

|-
| LSGS || Sion Airport || Switzerland || Europe || Basic development only

|-
| LSZB || Bern-Belp Airport || Switzerland || Europe || Basic development only

|-
| PANC || Ted Stevens Anchorage International Airport || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=136.80541&lat=34.85841&z=13 RJGG] || [[Chūbu Centrair International Airport]] || Japan || Asia || Detailed airport buildings, taxiway layout and customized terrain.

|-
| [https://scenery.flightgear.org/map/?lon=139.78114&lat=35.5533&z=13 RJTT] || [[Tokyo Haneda International Airport]] || Japan || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=126.45051&lat=37.46909&z=13 RKSI] || Seoul Incheon Airport || South Korea || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=121.01349&lat=14.51024&z=13 RPLL] || Manila Aquino Airport || Philippines || Asia || Tower and three large terminals

|-

| SAEZ || Aeropuerto Internacional Ministro Pistarini || Argentina || America || Several static buildings

|-

| [[SVMI]] || Aeropuerto Internacional Simon Bolivar || Venezuela || America || Several static buildings

|-

| TAPA || V.C. Bird Intl Airport || Antigua and Barbuda || America ||

|-
| TDPD || Melville Hall Airport || Dominica || America ||

|-
| TFFF || Martinique Aimé Césaire International Airport || Martinique, France || America ||

|-
| TFFG || Grand Case Airport || St. Maarten, Netherlands || America ||

|-
| TIST || Cyril E. King Airport || US Virgin Islands || America ||

|-
| TJSJ || Luis Muñoz Marín International Airport || Puerto Rico || America ||

|-
| TKPK || Robert L. Bradshaw International Airport || St. Kitts || America ||

|-
| TNCM || [[Princess Juliana International Airport]] || St. Maarten, Netherlands || America || Fully modeled, customized terrain

|-
| TNCS || Juancho E. Yrausquin Airport || Saba || America || Fully modeled

|-
| TQPF || Clayton J. Lloyd International Airport || Anguilla || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-49.17201&lat=-25.53101&z=13 SBCT] || Afonso Pena International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-46.65768&lat=-23.62558&z=13 SBSP] || Congonhas Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-46.46864&lat=-23.43351&z=13 SBGR] || Guarulhos International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-48.54304&lat=-27.6685&z=13 SBFL] || Hercílio Luiz International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| SKRG || Jose Maria Cordoba International Airport, Rionegro, Antioquia || Colombia || South America || Fully Modelled

|-
| VIDP || Indira Gandhi International Airport || India || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=89.42272&lat=27.39994&z=13 VQPR] || [[Paro Airport]] || Bhutan || Asia || Terminal, Buildings, Refernce Points and other POIs

|-
| [https://scenery.flightgear.org/map/?lon=91.50917&lat=27.25961&z=13 VQ10] || [[Yongphulla Airport]] || Bhutan || Asia || Terminal, some other Buildings

|-
| [https://scenery.flightgear.org/map/?lon=113.9183&lat=22.308&z=13 VHHH] || Hong Kong International Airport || Hong Kong || Asia || Terminals, control towers, some other buildings

|-
| [https://scenery.flightgear.org/map/?lon=-81.41707414&lat=41.15689289&z=13 1G3] || Kent State University Airfield, OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-81.76281774&lat=41.13448335&z=13 1G5] || [[Medina Municipal Airport]], OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-81.24620281&lat=41.20973295&z=13 29G] || Portage Co, OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-90.13769&lat=43.83872&z=13 82C] || Mauston-New Lisbon Union Airport, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-89.02545&lat=44.50485&z=13 68C] || Iola Central County Airport, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-123.00815977&lat=43.93009927&z=13 77S] || Hobby Field, Creswell, OR || USA || America || Nearly complete: Hangars (one accidently missing), fuel pump, GA aircraft, cars, trees, bushes (shared models)

|}

== Authors ==

Airports by HerbyW in Yakutia, Irkutsk and Krasnoyarsk:
UIBB UEEE UEST UEMS UEBN UEBT UEWD UEMA UERR UEMT UEEA UEMU UIII UITT UEBB UEVV UENW UEMO UERL UERT UEMH UERO UERP UNAA UIUN UENN UIBV UNCC UEMJ

Airports by D-ABBA:
EDXW,EDFE,EDGS,EDFQ,EDFH,EDFL,EDFO,ED03

Airports by [[User:Laserman]]:
EDDG,EDLM,EDLB,EDLK,EDLN,EDLV,EDLW,LJLJ,LJAJ,LJSG,LJCE,LJPZ

== External links ==
* [http://iveze.nl/fgmap/ Builtup airports in Flightgear] – Interactive world map by KL-666. ''See also related forum topic [http://forum.flightgear.org/viewtopic.php?f=5&t=23613 Map of airports with buildings in terrasync].''

{{Suggested}}

[[Category:Lists]]
[[Category:Airports]]

List of developed airports

2017-02-15T01:55:51Z

David.megginson: Added CYGK.

This is an incomplete '''list of developed airports''' in the FlightGear [[TerraSync]] scenery.

Airports can be listed here if these two conditions are fulfilled:
* At least one building or [[Signs|taxi signs]] have been placed
* Objects are represented in the [[FlightGear Scenery Database]].

Every improvement listed here should be possible to download using TerraSync. These improvements will also be included in the next [[World Scenery]] release.

__TOC__

== For airport developers ==
If you are currently developing an airport, please feel free to add it to [[Airports under construction]]. For a list of currently ongoing scenery related projects, please check out [[Current Scenery Projects]].

== List of airports ==
The ICAO codes link to the FlightGear mapserver, which - among other things - contains information about the current status of the [[FlightGear Scenery Database]]. On a map, you will see:
* The current airport layout with runways, taxiways and aprons
* Red dots: static objects in the scenery database made especially for this airport
* Dark red dots: shared models in the scenery database placed at this airport
* Green dots: [[Signs|taxi signs]] placed at the airport

{{inote|You can sort the table by clicking one of the [[File:Sort none.gif]] symbols in the row headers.}}

{| class="wikitable sortable" border="0" cellspacing="0"
|-
! ICAO !! Name !! Country !! Continent !! class="unsortable" | Comment

|-
| CYGK || [[Kingston Norman Rogers]] || Canada || North America || Custom objects for all major buildings, including FBO.

|-
| [https://scenery.flightgear.org/map/?lon=13.76716&lat=51.13277&z=13 EDDC] || [[Dresden Airport]] || Germany || Europe || Fully modeled with tower, terminal, animated hangars etc.

|-
| [https://scenery.flightgear.org/map/?lon=8.56293&lat=50.03795&z=13 EDDF] || [[Frankfurt am Main Airport]] || Germany || Europe || Fully modeled with [[Signs]] and [[Interactive Traffic]] and unique scycrapers downtown

|-
| EDDG || [[Münster Osnabrück]] || Germany || Europe || 1 static + 100 shared objects

|-
| EDDH || [[Hamburg Airport]] || Germany || Europe || Fully modeled, plus unique buildings downtown

|-
| [https://scenery.flightgear.org/map/?lon=13.40379&lat=52.47502&z=13 EDDI] ||[[Berlin Tempelhof Airport]] || Germany || Europe || Fully modeled

|-
| EDDL || [[Düsseldorf International Airport|Düsseldorf Airport]] || Germany || Europe || Fully modeled, many shared objects

|-
| [https://scenery.flightgear.org/map/?lon=11.78609&lat=48.35378&z=13 EDDM] || [[Munich Airport]] || Germany || Europe || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=12.23603&lat=51.42262&z=13 EDDP] || [[Leipzig/Halle Airport]] || Germany || Europe || Fully modelled with [[Signs]]

|-
| EDDS || [[Stuttgart Airport]] || Germany || Europe || Fully modelled based on Shared-Models, incl. [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lon=13.28992&lat=52.55917&z=13 EDDT] || [[Berlin Tegel Airport]] || Germany || Europe || Tower, terminals, [[Signs]] and unique buildings downtown

|-
| EDFB || Reichelsheim Airport || Germany || Europe || Tower done

|-
| EDFM || [[Mannheim City Airport]] || Germany || Europe || Basic models of tower, terminals and hangars

|-
| [https://scenery.flightgear.org/map/?lon=10.71706&lat=53.80496&z=13 EDHL] || [[Lübeck Blankensee Airport]] || Germany || Europe || Almost complete, home of the [[Piper PA34-200T Seneca II|Seneca]] used to model the FlightGear version. A modified tile is available at [http://www.t3r.de/fg/scenery/ Torsten's scenery site]

|-
| [https://scenery.flightgear.org/map/?lon=7.16278&lat=50.76767&z=13 EDKB] || [[Bonn-Hangelar Airport]] || Germany || Europe ||

|-
| EDLW || [[Flughafen Dortmund]] || Germany || Europe || Fully modelled

|-
| EDVE || [[Braunschweig Airport]] || Germany || Europe || Fully modelled

|-
| EEKE || Kuressaare Airport || Estonia || Europe ||

|-
| EETN || Lennart Meri Tallinn Airport || Estonia || Europe ||

|-
| EETU || Tartu Airport || Estonia || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=25.04487&lat=60.25318&z=13 EFHF] || Helsinki-Malmi Airport || Finland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=24.95253&lat=60.3206&z=13 EFHK] || Helsinki-Vantaa Airport || Finland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=22.26281&lat=60.51412&z=13 EFTU] || Turku Airport || Finland || Europe || Tower and terminal modelled

|-
| EGFF || Cardiff Airport || United Kingdom || Europe || One building: British Airways Maintenance Facility

|-
| EGGP || Liverpool John Lennon Airport || United Kingdom || Europe ||

|-
| EGGW || London Luton Airport || United Kingdom || Europe ||

|-
| EGKA || Shoreham Airport || United Kingdom || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-0.19224&lat=51.14869&z=13 EGKK] || [[London Gatwick]] || United Kingdom || Europe || Complete and fully modeled to highest level of detail with day and night textures; AI parking and ground network

|-
| [https://scenery.flightgear.org/map/?lon=-0.46095&lat=51.47139&z=13 EGLL] || London Heathrow Airport || United Kingdom || Europe || Basic development only

|-
| EGPH || Edinburgh Airport || United Kingdom || Europe || Tower, terminal, park deck, and some shared models

|-
| [https://scenery.flightgear.org/map/?lon=1.28469&lat=52.67713&z=13 EGSH] || Norwich Airport || United Kingdom || Europe ||

|-
| EH01 || [[VU University Medical Center]] || Netherlands || Europe || Complete hospital building including on-roof heli platform.

|-
| [https://scenery.flightgear.org/map/?lon=4.75487&lat=52.31296&z=13 EHAM] || [[Amsterdam Airport Schiphol]] || Netherlands || Europe || Fully modeled, bussiest AI airport currently

|-
| EHEH || Eindhoven Airport || Netherlands || Europe || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=5.51885&lat=52.45717&z=13 EHLE] || [[Lelystad Airport]] || Netherlands || Europe || Fully modeled

|-
| EHVK || [[Volkel Air Base]] || Netherlands || Europe || Shelters and detailed airport layout.

|-
| EIDW || [[Dublin Airport]] || Ireland || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=6.11017&lat=62.56037&z=13 ENAL] || Ålesund Airport || Norway || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=6.10949&lat=61.83027&z=13 ENSD] || Sandane Airport || Norway || Europe ||

|-
| ENVA || Trondheim Værnes Airport || Norway || Europe ||

|-
| ESGP || Göteborg Airport || Sweden || Europe || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=-106.60912&lat=35.04021&z=13 KABQ] || Albuquerque Sunport Airport, NM || USA || America || Basic development only

|-
| [https://scenery.flightgear.org/map/?lon=-84.42809&lat=33.63672&z=13 KATL] || [[Hartsfield - Jackson Atlanta International Airport]], GA || USA || America || Terminal modeled

|-
| [https://scenery.flightgear.org/map/?lon=-81.4629595&lat=41.0421187&z=13 KAKR] || [[Akron-Fulton International Airport]], OH || USA || America || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=-81.43676804&lat=40.91510112&z=13 KCAK] || Akron-Canton Regional Airport, OH || USA || America || Fully modelled

|-
| KAUS || Austin-Bergstrom Airport, TX || USA || America ||

|-
| KBOS || Boston Logan || USA || America || Tower, Terminals done

|-
| KFNT || Bishop Intl, MI || USA || America || Fully modelled

|-
| [https://scenery.flightgear.org/map/?lon=-76.66833&lat=39.17535&z=13 KBWI] || Baltimore-Washington International, MD || USA || America || Terminal modeled with jetways, parking garage, support buildings and [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lat=37.9858289&lon=-122.05529346000002&z=15 KCCR] || Buchanan Field Airport, Concord, CA || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-76.92254&lat=38.98062&z=13 KCGS] || College Park Airport, MD || USA || America ||

|-
| KCVG || Cincinnati/Northern Kentucky International Airport, KY || USA || America || Terminals, Concourses, Towers, Signs, DHL Hub, and Other Buildings (Almost Fully Modeled)

|-
| KDCA || Reagan National Airport, VA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-104.67318&lat=39.86166&z=13 KDEN] || [[Denver_International_Airport|Denver Airport, CO]] || USA || America || One terminal modelled

|-
| KDTW || Detroit Metropolitan Wayne County Airport, MI || USA || America || Basic development only

|-
| KFHR || Friday Harbor Airport, WA || USA || America ||

|-
| KIND || Indianapolis Airport, IN || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-90.07589&lat=32.31118&z=13 KJAN] || Jackson-Evers Airport, MS || USA || America ||

|-
| KJFK || [[John F. Kennedy International Airport]], NY || USA || America ||

|-
| KLAS || Las Vegas McCarran Airport, NV || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-118.40809&lat=33.9425&z=13 KLAX] || [[Los Angeles International Airport]], CA || USA|| America || Fully modeled

|-
| KLSV || [[Nellis Air Force Base]], NV || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-109.4667&lat=47.04924&z=13 KLWT] || Lewistown Municipal Airport, MT || USA || America ||

|-
| KMCI || Kansas City Airport, MO || USA || America || Basic development only

|-
| KMPI || Mariposa-Yosemite Airport, CA || USA || America || Hangars and FBO.

|-
| KMTN || Martin State Airport, MD || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-117.69181&lat=35.68565&z=13 KNID] || China Lake Naval Air Weapons Station, CA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.04918&lat=37.4162&z=13 KNUQ] || Moffett Federal Airfield, CA || USA || America || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-122.22062&lat=37.7214&z=13 KOAK] || [[Oakland International Airport]], CA || USA || America || Realistic terminal, currently undergoing maintenance

|-
| KORD || Chicago [[O'Hare International Airport]], IL || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-88.55704&lat=43.98436&z=13 KOSH] || Wittman Regional Airport, Oshkosh, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-75.12398&lat=38.31045&z=13 KOXB] || Ocean City Municipal Airport, MD || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.59751&lat=45.58871&z=13 KPDX] || Portland Airport, OR || USA || America ||

|-
| KPHX || Phoenix Sky Harbor Airport, AZ || USA || America ||

|-
| KRNO || Reno/Tahoe Airport, NV || USA || America ||

|-
| KSEA || [[Seattle-Tacoma International Airport]], WA || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-122.3749&lat=37.61897&z=13 KSFO] || [[San Francisco International Airport]], CA || USA || America || FlightGear's default airport, terminal buildings, airport lights and airport train.

|-
| KSLC || Salt Lake City International Airport, UT || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lat=33.80112251&lon=-118.34134126&z=15 KTOA] || Zamperini Field, Torrance, CA || USA || America || Fully modeled

|-
| KXTA || Edwards Airforce Base Detachment 3 (Homey Airport, or Area 51), NV || USA || America || Fully Modelled

|-
| KVUO || Pearson Field Airport, Vancouver, WA || USA || America ||

|-
| LDSP || Split Airport || Croatia || Europe || Basic development only

|-
| LEBB || Bilbao || Spain || Europe || Fully modeled

|-
| LEMD || Madrid - Barajas || Spain || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=-3.19889&lat=47.32611&z=13 LFEA] || Belle-Ile || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.10167&lat=47.48139&z=13 LFEQ] || Quiberon || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.66479&lat=48.05247&z=13 LFES] || Guiscriff Scaër || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=2.35465&lat=49.04626&z=13 LFFE] || Enghien Moisselles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=4.8264&lat=45.25226&z=13 LFLR] || Saint Rambert d'Albon Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=13.76716&lat=51.13277&z=13 LFMA] || Aix - Les Milles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=0.08816&lat=49.53404&z=13 LFOH] || Le Havre Octeville Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=5.36736&lat=43.50499&z=13 LFPG] || Charles de Gaulle International Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.60632&lat=48.89629&z=13 LFPH] || Chelles Le Pin Airport || France || Europe || Fully modeled, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.622793&lat=48.822237&z=13 LFPL] || Lognes Emerainville Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.359443&lat=48.72551&z=13 LFPO] || Paris-Orly Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=2.073197&lat=48.810622&z=13 LFPZ] || St-Cyr-l’École Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [https://scenery.flightgear.org/map/?lon=-4.41785&lat=48.44413&z=13 LFRB] || Brest Bretagne Airport || France || Europe || Modeled airport with static models

|-
| [https://scenery.flightgear.org/map/?lon=-4.15167&lat=48.53014&z=13 LFRL] || Lanvéoc Naval Air Base || France || Europe || Airport fitted with shared models (for helos and training)

|-
| [https://scenery.flightgear.org/map/?lon=-4.15167&lat=48.53014&z=13 LFRJ] || [[Landivisiau Naval Air Base]] || France || Europe || Modeled airport with arresting cables and [[Signs]]

|-
| [https://scenery.flightgear.org/map/?lon=-4.167981&lat=47.97553&z=13 LFRQ] || Quimper || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.816762&lat=48.601247&z=13 LFRU] || Morlaix || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-2.736754&lat=47.717558&z=13 LFRV] || Vannes || France || Europe || Airport fitted with shared models

|-
| [https://scenery.flightgear.org/map/?lon=-3.439579&lat=47.760964&z=13 LFRH] || Lorient - Bretagne Sud || France || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=-3.439579&lat=47.760964&z=13 LFSB] || [[EuroAirport Basel-Mulhouse-Freiburg|Basel Mulhouse]] || Switzerland || Europe || Nice modelling of Terminal.

|-
| LILN || Venegono Airport || Italy || Europe || Developed airport

|-
| LILQ || Massa Cinquale Airport || Italy || Europe ||

|-
| LILV || Valbrembo Airport || Italy || Europe ||

|-
| LIMC || Milano-Malpensa Airport || Italy || Europe ||

|-
| [https://scenery.flightgear.org/map/?lon=9.70741&lat=45.66952&z=13 LIME] || [[Orio al Serio Airport]], Bergamo || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=9.27521&lat=45.44776&z=13 LIML] || [[LIML|Milano-Linate Airport]] || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=7.36789&lat=45.73857&z=13 LIMW] || Aosta Airport || Italy || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=14.26&lat=50.100833&z=13 LKPR] || [[Václav Havel Airport Prague]] (Ruzyne) || Czech Republic || Europe || Fully modeled

|-
| [https://scenery.flightgear.org/map/?lon=11.34397&lat=47.26023&z=13 LOWI] || [[Innsbruck Airport]] || Austria || Europe ||

|-
| LROP || Bucharest Otopeni || Romania || Europe ||

|-
| LSGG || Geneve (Cointrin) Airport || Switzerland || Europe || Fully Modelled. OSM2city available on https://github.com/FGMEMBERS-SCENERY/LSGG-fg-CustomScenery

|-
| LSGS || Sion Airport || Switzerland || Europe || Basic development only

|-
| LSZB || Bern-Belp Airport || Switzerland || Europe || Basic development only

|-
| PANC || Ted Stevens Anchorage International Airport || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=136.80541&lat=34.85841&z=13 RJGG] || [[Chūbu Centrair International Airport]] || Japan || Asia || Detailed airport buildings, taxiway layout and customized terrain.

|-
| [https://scenery.flightgear.org/map/?lon=139.78114&lat=35.5533&z=13 RJTT] || [[Tokyo Haneda International Airport]] || Japan || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=126.45051&lat=37.46909&z=13 RKSI] || Seoul Incheon Airport || South Korea || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=121.01349&lat=14.51024&z=13 RPLL] || Manila Aquino Airport || Philippines || Asia || Tower and three large terminals

|-

| SAEZ || Aeropuerto Internacional Ministro Pistarini || Argentina || America || Several static buildings

|-

| [[SVMI]] || Aeropuerto Internacional Simon Bolivar || Venezuela || America || Several static buildings

|-

| TAPA || V.C. Bird Intl Airport || Antigua and Barbuda || America ||

|-
| TDPD || Melville Hall Airport || Dominica || America ||

|-
| TFFF || Martinique Aimé Césaire International Airport || Martinique, France || America ||

|-
| TFFG || Grand Case Airport || St. Maarten, Netherlands || America ||

|-
| TIST || Cyril E. King Airport || US Virgin Islands || America ||

|-
| TJSJ || Luis Muñoz Marín International Airport || Puerto Rico || America ||

|-
| TKPK || Robert L. Bradshaw International Airport || St. Kitts || America ||

|-
| TNCM || [[Princess Juliana International Airport]] || St. Maarten, Netherlands || America || Fully modeled, customized terrain

|-
| TNCS || Juancho E. Yrausquin Airport || Saba || America || Fully modeled

|-
| TQPF || Clayton J. Lloyd International Airport || Anguilla || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-49.17201&lat=-25.53101&z=13 SBCT] || Afonso Pena International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-46.65768&lat=-23.62558&z=13 SBSP] || Congonhas Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-46.46864&lat=-23.43351&z=13 SBGR] || Guarulhos International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [https://scenery.flightgear.org/map/?lon=-48.54304&lat=-27.6685&z=13 SBFL] || Hercílio Luiz International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| SKRG || Jose Maria Cordoba International Airport, Rionegro, Antioquia || Colombia || South America || Fully Modelled

|-
| VIDP || Indira Gandhi International Airport || India || Asia ||

|-
| [https://scenery.flightgear.org/map/?lon=89.42272&lat=27.39994&z=13 VQPR] || [[Paro Airport]] || Bhutan || Asia || Terminal, Buildings, Refernce Points and other POIs

|-
| [https://scenery.flightgear.org/map/?lon=91.50917&lat=27.25961&z=13 VQ10] || [[Yongphulla Airport]] || Bhutan || Asia || Terminal, some other Buildings

|-
| [https://scenery.flightgear.org/map/?lon=113.9183&lat=22.308&z=13 VHHH] || Hong Kong International Airport || Hong Kong || Asia || Terminals, control towers, some other buildings

|-
| [https://scenery.flightgear.org/map/?lon=-81.41707414&lat=41.15689289&z=13 1G3] || Kent State University Airfield, OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-81.76281774&lat=41.13448335&z=13 1G5] || [[Medina Municipal Airport]], OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-81.24620281&lat=41.20973295&z=13 29G] || Portage Co, OH || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-90.13769&lat=43.83872&z=13 82C] || Mauston-New Lisbon Union Airport, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-89.02545&lat=44.50485&z=13 68C] || Iola Central County Airport, WI || USA || America ||

|-
| [https://scenery.flightgear.org/map/?lon=-123.00815977&lat=43.93009927&z=13 77S] || Hobby Field, Creswell, OR || USA || America || Nearly complete: Hangars (one accidently missing), fuel pump, GA aircraft, cars, trees, bushes (shared models)

|}

== Authors ==

Airports by HerbyW in Yakutia, Irkutsk and Krasnoyarsk:
UIBB UEEE UEST UEMS UEBN UEBT UEWD UEMA UERR UEMT UEEA UEMU UIII UITT UEBB UEVV UENW UEMO UERL UERT UEMH UERO UERP UNAA UIUN UENN UIBV UNCC UEMJ

Airports by D-ABBA:
EDXW,EDFE,EDGS,EDFQ,EDFH,EDFL,EDFO,ED03

Airports by [[User:Laserman]]:
EDDG,EDLM,EDLB,EDLK,EDLN,EDLV,EDLW,LJLJ,LJAJ,LJSG,LJCE,LJPZ

== External links ==
* [http://iveze.nl/fgmap/ Builtup airports in Flightgear] – Interactive world map by KL-666. ''See also related forum topic [http://forum.flightgear.org/viewtopic.php?f=5&t=23613 Map of airports with buildings in terrasync].''

{{Suggested}}

[[Category:Lists]]
[[Category:Airports]]

Using OSM Vector Data in FlightGear

2016-12-27T18:19:52Z

David.megginson: /* Power Lines (vanosten, owenpsmith, Soitanen) */

{{OSM Navigation}}

== Background ==
This is referring to procedural/autogen scenery generation/enrichment (buildings, cities, roads, bridges and power lines) via OSM data.

Actually, using OSM data isn't really conflicting with "autogen" at all - it just requires the built-in autogen component to expose an interface, so that the placement heuristics can be affected according to the OSM vector data.

After looking at the website, I do understand that the approach taken by OSM2XP is a little different, in that it creates the buildings externally and then provides precompiled scenery for use by XP (?) - obviously, that is because OSM2XP is an external tool, written in Java.

That's actually similar to how FlightGear uses precompiled scenery which is created using TerraGear. XPlane on the other hand, creates airports, runways and taxiways procedurally at runtime.

We previously talked about exposing the placement heuristics, so that a Nasal script could affect the placement algorithm in some way - once that is supported, a Nasal script could place buildings while honouring OSM vector data.
The probem is that (as usual) people pull into different directions.

Actually, we've seen a number of related developments - such as IntelQube's "Instant City" addon, or the more recent effort by Rickbritto. So people are clearly interested in this.
Like Thorsten also rightly pointed out, people are pulling into different directions, which are unfortunately somewhat conflicting. But overall, it's pretty obvious that people are interested in extending the scenery and populating it with buildings in particular.

Stuart has a 'random with certain moderately simple rules' algorithm with the aim to be as fast as possible without generating nonsense like overlapping or floating buildings. This probably means you can't have fancy night illumination, too much individual configuration or realistic arrangements beyond a point, and all placement info is encoded in the texture sheet (that's not a bad feature, because that means random buildings stay in sync with the underlying sheet!)

We've seen quite a few people working on this independently in 2013 and making very promising progress in different fields.
Many of them being contributors able to build from source, and able to write C++ code.
TorstenD mentioned a while ago, that he was also considering porting PixelCity to use Stuart's random buildings system (and thus, OSG) for these purposes.
Now, we also have osgEarth as a secondary scenery engine, so it makes sense to coordinate things accordingly.

Besides, we also have guys working on improved generation of procedurally-created vegetation, road networks, bridges and buildings/cities, which are other areas that could greatly benefit from a little coordination with osgEarth support in FlightGear, to ensure that a generic approach is found over time and to avoid a "technology lock-in", like some people are complaining about related to Rembrandt.

Please see thee ongoing discussion at: http://wiki.flightgear.org/User_talk:F-JJTH#Implement_an_OSM_client_in_FG

The main point being that we should work out a way to expose the underlying APIs to FG, so that these can be used as the common back-end for OSM vector data access (probably via Tom's cppbind) - so that related efforts can benefit without having to duplicate work, and without having to use approaches that are not native to FG (such as python code).

As could be seen in 2013, we have an unprecedented number of people interested in this currently, who are able to contribute to the code - so if we could coordinate this a little, this could work out as well as the NavDisplay effort, which had a similar amount of people interested in related things.

We now have so many people doing work related to this, that the wiki is the only sane place to coordinate things - because some use the devel list, others only the forum - and others only IRC ... so better use the wiki for now.

Also, the wiki is the only future-safe method to organize things, in case we need to drop the effort for a "while" (weeks, months or years).

== Objective ==

Any OSM-processing should ideally be exposed via FG APIs, so that OSM data can be processed by other subsystems (either via fgcommands, extension function or cppbind), to ensure that we cannot just visualize OSM data using the Canvas, but also use it affect the placement heuristics in [[Random Buildings]] according to Stuart's plans [http://forum.flightgear.org/viewtopic.php?f=5&t=17598#p166794] or interface OSM with osgEarth.

== Status (01/2015) ==

{{FGCquote
| I've been working on a tool that combines all the static models within a .stg file into a single .osgb file using quadtrees, texture atlases etc. to make it as efficient as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229623#p229623
|title=<nowiki>stgmerge</nowiki>
|author=<nowiki>stuart</nowiki>
|date=<nowiki>Tue Jan 13</nowiki>
}}
}}

{{FGCquote
|I've written a little tool that<br/>
does the following:<br/>
1) Loads all the .ac files in the STG file passed in as an argument<br/>
2) Runs the osgUtil::Optimizer to merge all the textures together, build a<br/>
quad tree and optimize the meshes<br/>
3) Outputs the result as a native osg format (.osgb)<br/>
4) Writes a new STG file with the .ac model references removed, and the<br/>
.osgb file added.<br/>
<br/>
The idea is that this could be used within our scenery generation toolchain<br/>
to generate a more efficient set of static tile objects.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33230184/
|title=<nowiki>[Flightgear-devel] STG model merge tool</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2015-01-13</nowiki>
}}
}}
{{FGCquote
|The main benefit of this is that it would allow the output of osm2city to be uploaded into the scenery object database and distributed via Terrasync. At the moment this isn't possible because the database requires models to be uploaded individually, and the large number of individual models produced by osm2city (unless various combine options are enabled) has too much performance impact.<br/>
<br/>
This would also allow random buildings to be generated offline and stored in the scenery object database as well, which was the original trigger for writing the tool.<br/>

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229623#p229623
|title=<nowiki>stgmerge</nowiki>
|author=<nowiki>stuart</nowiki>
|date=<nowiki>Tue Jan 13</nowiki>
}}
}}

{{FGCquote
|The idea is that this tool would be run on the scenery server itself so the data downloaded via terrasync would already be merged. <br/>
<br/>
It would probably be fast enough to run at runtime, but doing so is complicated by the deferred loading we have in place within FlightGear which means that not all models are loaded at once.<br/>
<br/>
Doing it on the scenery server also saves some CPU time on the user's computer.<br/>
<br/>
osm2city would then revert to creating individual models, and get them added to the scenery DB. I think we'd want to tag them so they can be easily replaced by subsequent runs of osm2city.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229644#p229644
|title=<nowiki>Re: stgmerge</nowiki>
|author=<nowiki>stuart</nowiki>
|date=<nowiki>Tue Jan 13</nowiki>
}}
}}

{{FGCquote
|There's still a place for random buildings, but I think they would be generated offline and similarly placed in the scenery DB. PostGIS has the function available that would allow us to easily generate building locations based on the OSM street data. We'd probably move away from the shader-based instantiated buildings and instead just have big meshes. This has the advantage of allowing collision detection, helicopter landing etc. but obviously uses more memory.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229644#p229644
|title=<nowiki>Re: stgmerge</nowiki>
|author=<nowiki>stuart</nowiki>
|date=<nowiki>Tue Jan 13</nowiki>
}}
}}

{{FGCquote
|I'd like to try to initiate a strategy discussion about how we should handle cities in the future. Right now, there's tools like osm2city.py, there's the urban shader, there are random buildings, there are static buildings (Paris...), there's streets painted on the texture, streets as part of the vector mesh and (experimental) streets draped onto the terrain....
Which is fine as long as these approaches aren't mutually exclusive, but unfortunately we left that state, so I think we should eventually have a strategy how to proceed.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33054935/
|title=<nowiki>[Flightgear-devel] Future city terrain strategy (see full posting)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-11-19</nowiki>
}}
}}

{{FGCquote
|Moving to ‘real’ OSM data for this seems the best plan - for all the reasons you list. It also have a very nice ‘user upgrade path’ - not enough buildings in your area? Submit them to OSM!<br/>
<br/>
I would prefer to avoid hardcoding a distinction at scenery creation time - actually I’d be looking to go the other way, and have road data and building data be fetched at runtime + cached directly. So if you disable buildings, they aren’t fetched. This would bring the tile complexity (vertex count) right down, since we also have to do flattening of the terrain for buildings / roads at runtime. (We could still include the road/building data in the scenery dirs, but separate from the BTG).
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33055284/
|title=<nowiki>Re: [Flightgear-devel] Future city terrain strategy (see full posting)</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2014-11-19</nowiki>
}}
}}

If you are interested in pre-processing and enriching vector data, you'll probably want to get in touch with some of the other folks who have done similar things, such as the osm2xp project.
Also, if that's definitely your main interest, you may also want to look at TerraGear, which is the "FG scenery compiler suite" to build scenery.

That said, a "pre-processor" could also be implemented as a native FG component, i.e. within the main fgfs executable - quite probably even as a fully threaded component, so that pre-processing could take place in a simple worker thread using exclusive read/write access.

I'm just saying this because "compiling" scenery from scratch is generally understood not to be a simple task for most people here. In other words, even if you should come up with such an OSM-pre-processor to enrich FG scenery, the resulting data may not be usable by most people - not without an official scenery rebuild at least.

Thus, having a component that would be running inside (or next to) FG would be easier from a deployment point of view.

== Efforts ==
=== Random Buildings (Stuart) ===
Stuart is the developer of the random buildings code (and the random trees), so he's got plenty of experience with procedural creation of scenery elements.
To understand the C++ side of things, you'll definitely also need to be familiar with OpenGL and preferably OSG, i.e. 3D graphics and 3D maths.
But even if that's not your thing, reusing Stuart's code to the largest possible degree would definitely be a good idea, because he's already tackled many of the difficult issues - and creating an interface (scripting or property tree) is definitely simpler than writing such a system from scratch.

FlightGear's random building code is implemented as part of the SimGear library, in the tgdb folder: {{simgear source|path=simgear/scene/tgdb}}
The most important file is SGBuildingBin.cxx: {{simgear source|path=simgear/scene/tgdb/SGBuildingBin.cxx}}

Probably the best way to do this would be to separate the "random" from the "buildings" in the curent random buildings, and use the OSM data as an alternative data source for the latter.

However, before we do that I need to get the PageLOD working well enough that I can replace the (relatively) memory efficient instantiation approach with the original memory-heavy implementation of random buildings which allows better control over each individual building.

I'd suggest to get in touch with TheTom or Zakalawe and use TheTom's cppbind framework (see simgear/nasal/cppbind) to expose the building generation hooks to scripting space, that would then allow arbitrary input data to be used.

=== Random Buildings Scripting Interface (Hooray, Thorsten) ===
{{FGCquote
|let's assume that downloading the footprint of an airport terminal building from OSM/overpass turbo is fast enough.<br/>
Can Nasal create an object and put into the scenery in RAM/on the fly without writing an .ac file to the filesystem ?
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=228150#p228150
|title=<nowiki>create terminal buildings with Nasal ?</nowiki>
|author=<nowiki>pommesschranke</nowiki>
|date=<nowiki>Fri Dec 26</nowiki>
}}
}}

This would require some form of interface, so that stuart's random buildings can be aligned using networks of roads, rivers, railway tracks - like Gijs said, the randomness would be gone then

'''Hooray:''' we have had a fair share of discussions related to this. Stuart's work has certainly paved the way for even more improvements.
Like I mentioned, I would be interested in exposing the creation of procedural scenery to scripting space (or even just the property tree) so that customizing this aspect of FG is no longer possible purely from C++ space.

it would be great to have a way to dynamically assemble buildings and blocks of buildings and then combine them into a single geometry, so that the performance hit is decreased. But that would obviously require exposing some more hooks to Nasal scripts.

Now, what Stuart has done already addresses the needs in C++ space.
Adding a Nasal interface to existing C++ code is much easier that way, and certainly easier than creating the whole thing from scratch.

And have better access to the placement heuristics, or rather the underlying criteria would be great. That's not just related to "materials" anymore, but also access to "ground networks", such as roads, rivers, railways.

The good thing is, adding a Nasal interface to make existing C++ code accessible is fairly trivial and much simpler than writing the original backend code. And this is clearly not a task that needs to be done by the developer of the original C++ code, as can be seen by all the existing Nasal extension functions, most of which were added by people who didn't really write the corresponding backend code.

A Nasal script that may query a scenery tile and get detailed information on these properties, could come up with the heuristics to place models realistically.
Coming up with the models procedurally would be a different matter.
But it seems, Stuart has addressed this already in OSG space. So the really difficult work has probably already been done.
Coming up with an interface to access his code from scripting space should be simpler than writing his code from scratch.

Hooray and Thorsten have some more involved dynamical city-building scheme in mind - finding an algorithm which dynamically generates a street pattern and places a plausible mockup of a city dependent on its knowledge of the underlying terrain. Much of the performance here depends on what models are placed - if models without an xml wrapper are used, it's going to be relatively fast, if not, then not. That's different from the situation with weather where we could never use models without xml wrapper, because the rotation effect needed to be declared there (merging the models to a whole block is also important though).

How about instead of texturing urban areas and towns, generating "fake roads" with modular blocks of buildings and trees?

For instance, in the western USA you could generate a grid pattern for cities and towns and populate the grids with buildings using a formula.

* it is possible to use various landclasses to distinguish parts of a city in custom scenery
* that a prototype for autogenerating a city based on these landclasses in Nasal is feasible
* that both myself and Hooray would help with the coding
* i.e. that there's a clear and well-defined path from a wish to reality here at the simple expense of doing it

In Nasal, one could:

* use random geodinfo(); calls across the terrain to find spots where the terrain is urban (or otherwise interesting
* call an autogeneration algorithm from that point to fill the whole urban region by
** first creating a street pattern by means of an algorithm (European cities are not much more difficult - you just take a grid and allow for random distortions of the intersections and curvature of the streets, that should be pretty good already)
** sample terrain while you do this - elevation and especially the presence of rivers alter the pattern
** then determine what kind of quarter you're trying to build
** then place buildings next to your streets, orienting them properly
** throw parks, gardens and so on for good measure
* do this till you hit the edge of the urban region
* then go looking for the next
* have a housekeeping routine in the background which deletes models which are too far away

Too large modular blocks are actually a problem, because they create floating buildings wherever the terrain isn't level. So ideally you'd design the autogeneration with just single buildings as blocks and put the information which buildings are typically adjacent and how they typically arrange into your algorithm (it's a lot like clouds actually - Local Weather could create you a slightly randomized m x n grid of buildings clipped where the urban terrain ends with a higher city center region and lower surroundings with less than 100 lines of additional code, provided you have the models - the real work would be to get it to do European placement patterns, but the functions to do that are probably not as complicated as credible undulatus patterns).

=== PixelCity (Hooray, TorstenD) ===
Once you do take a look, you'll also find a number of threads related to the open source PixelCity project, which uses a fixed rendering pipeline (i.e. no shaders) - but which is nonetheless extremely impressive. Like Torsten mentioned a while ago, this would need to be ported to OSG (and shaders) to be usable in FG, but this could probably be done by merging it with Stuart's code, because that's a very good (and
working!) example of how the FlightGear/SimGear side of things works.

It really looks cool from the distance and close up.
Implementing it into FlightGear requires porting the OpenGL calls to be OpenSceneGraph compatible, probably by implementing osgDrawable.
The current implementation only shows night-time views, so this has to be tweaked, too.
Another issue to take care of is interaction with existing scenery models, so the generated buildings do not interfere with our scenery models. The same is true for our landcover, roads and elevation data.
Definitely worth some thinking. Probably as a google summer of code

Also see [[AutoGen Scenery for FlightGear]].

=== osgEarth (poweroftwo & stuart) ===

'''stuart:'''Random object generation. osgEarth provides OSM building data, which
it makes sense to leverage, but for other areas of the planet it would be
good to be able to use our random buildings/objects, and I'd really like
to be able to generate random trees.

=== OSM & Canvas (TheTom) ===
TheTom is also working on something to show tilemaps inside a canvas. I've now pushed a function to fgdata ({{gitorious source|proj=fg|repo=fgdata|commit=41b6c9c688ce78d8c907a07c42b9ea4d8290da0c|view=commit}}) which allows building templates for the tile urls.

Also see [https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38354.html Canvas & Tiled Maps ] Note that osgEarth will probably soon be linked into FG by default according to [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAP3ntysiT0x-Fd_xN%2BS4qqSV%2BDwh7FNk%2BMj7BeHhmz-FB%2B5y9w%40mail.gmail.com/#msg31901878], which means that GDAL/OGR can be relied upon, i.e. supporting GeoTIFF processing would be another useful option for any mapping/charting needs implemented via Tom's Canvas system.

=== Procedural Airports (psadro_gm, zakalawe, papillon81) ===
As was said previously, X-Plane has been doing that for years - and meanwhile we may have the computing power (and idle cores!) to actually sonsider doing that in FG, too. So it would be a great addition and would quite certainly lower the entry barrier for people doing scenery development if airport changes became directly visible without having to go through the hassle of running TG tools.

fully dynamically created airports is another really long-standing scenery related idea, that's been discussed among core developer on and off for over a decade already, including David Megginson and Andy Ross

http://forum.flightgear.org/viewtopic.php?p=176132#p176151
<pre>
What about a purely symbolic representation? Store just centerline
and width for each taxiway, and keep the existing polygonal
representation for "tarmac" areas. Throw out the "pre-cut" airport

This means that the tile loader will be forced to do some
computational geometry at load time to decide on the actual polygons
to be rendered by OpenGL. But that's not likely to be too much --
even the biggest airpots have no more than 30 taxiways with no more
than ~4 curves on each. Figure an individual curve has no more than
10 segments, with 6 polygons for each segment (two yellow paint, four
pavement). So that's a few thousand polygons generated and intersect
per airport loaded. Not so bad, really -- note that because it can
happen in the loader thread, and therefore make good use of the
multi-dispatch multi-core CPUs that are becoming so popular these
days.

The biggest advantage is that (if you do it with the runways too) it
means that the airports can be generated at runtime and edited by the
user without doing a terragear scenery regeneration.
</pre>

we already have all the data to generate the ground polygons, inside FlightGear - that's exactly how the airfield chart / ground-radar work. And we can do it adaptively (more bezier interpolation on faster machines) and also get airports editable in mostly-realtime (unless the airport boundary changes).

The trick is to make an OSG 'loader' which creates the airport geometry from the apt.dat definitions, which of course is exactly what genapts does - this is why I was working with Chris to make it fast enough to run inside the loader thread, in FG.
I'd love to fully generate the apts at runtime. LEMD is probably the most complex layout, and genapt currently takes about 2.5 seconds to generate. I imagine it could be generated in 2 stages for LOD. 1 for runways and taxiways, which are really quick, the 2nd stage for the line data which is slower.

'''psadro_gm:'''Although I haven't written a line of code in SimGear for draping, yet - I'm getting a pretty good idea on how it will work. I think we could speed up the OBJECT_STATIC_AGL using the envisioned draping code.

Currently, when a tile loads, it first gathers the type of objects in the tile. If there is a draped object, I plan on keeping raw btg data (nodes and triangles) around. I need the Geodetic nodes, unfortunately for proper draping, so I'm going to have to create a parallel node list Cartesian ->Geodetic. The triangles are all index based anyway, so we'll just refer to the Geodetic nodes when using these triangles.

A draped object's 2D bounding box will be used to quickly find the relevant triangles (using the geodetic nodes long/lat) that need to be considered, then I plan to use barycentric interpolation to find node heights at specific lat/long coordinates. This node will then be converted back to Cartesian space.

=== Procedural Buildings & Cities (radi & vanosten) ===
Also see [[Osm2city.py]]

'''Zakalawe:'''A thought occurs - this is much more blue-sky, could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sized (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread.

So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time.

'''Radi:''' focused on OSM buildings/bridges in the past, but is now interested in procedural city generation in general. OSM xml data for LOWI region alone is 50 MB. Might be a bit heavy a download for some users. Radi discussed this with James at FSweekend last year: we could pre-process OSM data, extract what's useful for us, and ship the outcome with our scenery. OSM buildings for LOWI would then add perhaps 1MB or so. OTOH, if this is generated at run-time (and then cached), users could decide themselves if/what OSM features they wish/can afford.

I like the idea of having this generated at run-time, and I'm quite sure a c++ version could be fast enough. Raw OSM input data is too big (50 MB for LOWI), but that a) includes *everything* and b) is xml.

But storing pre-processed data could be an option. A typical scene now easily contains 50k buildings. Reducing that to, say, 10k, should fit into well under 1MB. And of course I could modify the script to generate that outline data. Perhaps we can come up with a spec of the outline data at FSweekend.

I wrote a similar script recently, using python. Got Dresden (EDDC) area populated with some 20,000 buildings from OSM. There is some frame rate impact, but I still get ~20fps on an i5-2500k/GeForce 650TI/Ubuntu.

I put all buildings in one .ac file. Loading time is pretty quick, maybe some 5 seconds more than the default scenery. I pre-calculate the elevation: I extract the elevation on a rectangular grid (10m step size) from FG in the relevant area once using a slightly modified version of http://wiki.flightgear.org/Howto:Get_a_number_of_elevation_offsets_for_a_number_of_objects. Then the script loads the elevation data, and linearly interpolates elevation at the buildings positions.

Some facade texturing is also done. Roof geometry and texturing is still work in progress

'''vanosten:'''
So the idea would be to procedurally generate buildings based on OSM data (not uploading to OSM!) based on other OSM data like streets, area classifications, ... I thought of enriching offline OSM data with buildings - which could then in a later step be used to actually generate buildings in Flightgear (or X-Plane with http://osm2xp.com/). Due to differences in landuse patters between e.g. cnetral Europe and USA the algorithm would naturally have to be configurable - however somewhere we need to start.

Would that be a good idea? Has this already been attempted (I mean based on OSM data, not generic procedural cities)?

I first let bob.pl generate all *.ac files and *stg entries. Then I parse the *.stg files for lines starting with OBJECT_STATIC, get out the lat and long, set the properties, wait 1 second and then get /position/ground-elev-m, which I write back to the file (instead of -9999).

I understand there are advantages to do stuff on the fly - it might be even faster to do calculations than reading detailed info like ac-files from the file system. However I wonder whether it really is the same thing that people try to accomplish. Together with Radi I want with osm2city make a plausible world, which satisfies also someone on sightseeing with a helicopter, who knows the area. The other is generating a plausible world. The first one needs a lot of parametrization and logic on a per object level. If the first one can be satisfied with on-the-fly processing, then I would look into porting code to C++ and learning C++. If not, then potentially we should leave the initiatives apart?

I agree that we might have to go with less details and a few / couple of buildings - maybe even replacing existing OSM floorplans in place. It is not about matching reality - it is about making something that looks realistic.
I have built some paper based algorithms and the next thing is to try the stuff in programming. I will most probably go for a Java based prototype using the JTS Topology Suite library.
If the prototype prooves sucessful and estimates for the next step do not look too bad, then I need to take a decision with your input, whether to port it to C++ / GEOS or C++ / Simgear. However this would mean that i need to learn C++.

I finally got bob.pl working using a custom Java program, which also reads the height to place the buildings (I will share the java program once it works outside Eclipse without hassle). Basically I now have 9000 objects around LSZR at the lake of Constance in Switzerland. See following image (which looks good, but which I think still shows a case for intelligently generating all those buildings, which are not yet in OSM datasource).

9000 objects means 9000 *.ac files - a lot of which could be reduced to a few, if objects would be intelligently replaced by shared objects (e.g. for residential houses, not so much for other buildings). Which leads to the following questions:
* Right now startup is very slow due to scenery loading. Would the startup be significantly (linearily) be faster, if e.g. 60-70% of the buildings were shared buildings?
* At night all the buildings generated by bob.pl are without lights. Could that be changed or would that again be a case for using shared buildings?
* bob.pl is written in Perl FG is written in C++. Is there a policy against writing some of the scenery tools in e.g. Java, if one would like to contribute?
* A previous post by Soitanen in this thread used OBJECT_STATIC_AGL to dynamically get the height over sea level for the buildings. However I guess that precalculating during scenery generation is worth the hassle in order to reduce CPU?

=== cppbind & Nasal ===
I think C++ is not the problem, we have some really experienced C++ developers interested in working with OSM data,
such as psadro_gm, zakalawe, papillon81 and TheTom. And these guys not only know C++ already, but are also familliar with SimGear ,FlightGear and TerraGear.

So the C++ part can be handled by them - these guys want to use the same data in FG for similar purposes.
So it makes sense to let them handle the C++ side of things.

Now, what could be done instead of requiring use of Perl, Python or Java is this: We now have a new framework which is called "cppbind". This was added by TheTom, as part of the Canvas effort.
This framework can be used to expose C++ code to Nasal, so that you can do the same things in Nasal that you would normally use Perl, Python or Java for.

A similar method is used by Thorsten's weather system: all the important (performance-critical stuff) is handled by C++ developers and code that they have written, and there are just some special, new, commands/classes added that can be called from Nasal, and which will directly call the C++ code, to speed up things.

This could be also done here - the C++ guys would handle the C++ side of things, and merely expose these functions and classes via Nasal scripting - in FG, we could then directly use Nasal code to access OSM vector data, and use it to procedurally modify and add to the scenery - no matter if it's buildings, cities, rivers, roads, powerlines or bridges.

So we really only need cppbind bindings to expose some OSM specific stuff to scripting space (Nasal) - to procedurally add/modify buildings and cities, we should probably reuse Stuart's existing code.

This would mean that people could directly focus on their domains (C++ vs. scripting - and procedural scenery generation)

Also, Nasal itself is actually designed to be thread-safe - so carefully-written Nasal code could in fact interact with the OSG pager thread, or even be running there directly, i.e. we could be running high-performance C++ code there, which is only parameterized via Nasal calls.

===Populate FG world with OSM data (F-JJTH) ===
F-JJTH's idea here is to populate FG world with OSM data. OSM provides some API for HTTP request ( [http://overpass-turbo.eu] )
Once data are downloaded we could be able to draw them on-the-fly in FG. In other words: it's similar to the osm2fg but in-live.

BTW, this feature is not at the top of my priority and I would wait the osgEarth integration before all.

Using the HTTP APIs is a bit overlapping with the recent work on HTTP bindings for Nasal via cppbind, but also with poweroftwo's osgEarth integration, which uses curl to provide fully threaded access to this kind of data. Also, Stuart repeatedly mentioned on the forums that he would be supportive of exposing the placement heuristics for his random buildings code-seconded by Zakalawe [http://forum.flightgear.org/viewtopic.php?f=5&t=16083&p=192393&hilit=osm2city#p192393], so that these can be affected via corresponding APIs - we've had quite a bit of progress regarding procedural scenery generation in 2013, including buildings & cities (radi, Soitanen/osm2fg) [http://forum.flightgear.org/viewtopic.php?f=5&t=19625] [http://forum.flightgear.org/viewtopic.php?f=5&t=16083&p=192393&hilit=osm2city#p192393], roads, rivers - even railways (vivian) and procedural bridge generation (radi) [http://forum.flightgear.org/viewtopic.php?f=5&t=21061&hilit=bridges], but also procedural power lines (vanosten) [http://forum.flightgear.org/viewtopic.php?f=5&t=20665&hilit=osm2city]. In other words, there's some serious -and unprecented manpower- to be leveraged and coordinated here, including quite a few folks who are able to build from source and able to write C++ code. So this deserves being coordinated among all interested parties. And it would clearly make sense not to just expose things to the Canvas system, but to expose the corresponding APIs so that other subsystems and users can access these and use these for the purposes outlined above.

Here is an example: [http://www.youtube.com/watch?v=TK85iSeLrGY]

=== OSM2FG (Soitanen) ===
This is script, which helps to automate convert landuse, lines, waterway etc data from OSM to FG.
Git repository located here: [https://github.com/soitanen/osm2fg]
Also it needs to have custom materials for textured roads and railroads from Project Russia: [https://github.com/soitanen/Project-Russia]
Currently, this converter works only for Russia and CIS countries.

Workflow:
Converter must be run from commandline. No GUI is presented. In commandline bounding box for generation is set. Then it automatically download heights (from the same source, as World Scenery 2.0), automatically downloads freshest X-Plane airport base, downloads full world coastlines and regional shapes for different regions of Russia, depending on BBOX. So, if select to generate some terrain outside of Russia, then scenery will be generated as land with normal coastlines and airports. No roads, no landuse.
In case of acceptable region it automatically makes textured roads and railroads. Mostly number of lines on roads will match real one (if presented in OSM data). Forests, water polygons, water lines - all will be converted good. Also, some simplification will be done for shapes to reduce number of polygons and generating time. If scenery tile is too complex and bugs are appearing, LOD level can be set for generating to reduce number of generated features (on low LOD levels roads with low majority level are not generated, the same for low majority landuse).
And after all automatic preparations it just runs standard Terragear routine to generate final scenery.

In earlier version there was building generator, that generates each building as single object, but that was too bad for FPS.
Better way to use osm2city from radi, but I can't automate it because of need to run FG and get elevations for the tile.

using OBJECT_STATIC_AGL gives big slowdown in FG working. So precalculation is much better. How you program gets elevation? Does it use the same data, as TerraGear use for terrain generation?

http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38134.html

=== Power Lines (vanosten, owenpsmith, Soitanen, David.megginson) ===

'''vanosten:'''It is meant to be to support pylons from the shared objects library be placed based on OSM data in Python (extending osm2city).

'''f-ojac:'''Have a look at {{gitorious source|proj=fgscenery|repo=tools|full=1}} too to avoid duplicate work. Power lines are showing in OSM, for instance http://osm.org/go/WJHUyw34-
For mapserver, yes we'll have to wait a little as there are some prioritary works on. Automated power line object generation from OSM data has already been tested a few years ago. Right now we're trying to make this process rework, with other objects (windturbines, watertowers...) before going into more complicated stuff. Aligning the pylons is also doable, Jon wrote a script on that a few years ago. Now the webforms are done and terrain generation is quite finished, we'll focus on some other nice features.

'''Soitanen:'''data can be taken from OSM - if two power pylons are connected with line tagged power=line, that means there are wires in the air. I think wires can be modeled with one 3D model. It must be some kind of parabolic function, when viewing on it from side. But, if power line is turning, length of wires on one and other side will not be the same. So, script, that will place pylons, must compute attaching point for wires and place 3D model in needed place with needed scale.

'''Hooray:'''You can do that procedurally even without touching TerraGear or 3D modeling - e.g. by using a Nasal script that uses the OSM data to add those lines to the scenery - you would look up height/elevation, distance and connection points - and then use a technique like the one demonstrated in the glideslope tunnel script to add lines

'''owenpsmith:'''When flying VFR in the heavily forested areas of western Canada, it is never the power lines you look for, it is the clearing through the trees made for the power lines. They stick out like a sore thumb. Terrain and auto-generated trees are not my domain by any means, but I would think that it would be easier to make a script to omit trees under the lines that it would be to generate the lines themselves. If you could say draw a line between any two models in a set of models (various transmission tower models) that are closer than a certain distance apart, then omit the trees within a given distance of that line? Just my 2 bits. If we can clear the trees, this might come along as a bonus with winter ground textures

'''Johan G:'''Goes for Sweden as well. In the about 60% of Sweden's area covered by forest no other line features, except for rivers and highways, sticks out like a 25-50 m (80-160 ft) wide clear cut that stretches for mile after mile. It just struck me that the power line clearings is not really a problem related to the random tree placement algorithms, but rather a land classing problem. The area in the clearings are in essence a different land class than the surroundings.

'''Hooray:'''You would need to get in touch with Thorsten and/or Stuart to see if omitting trees based on heuristics is currently possible or not, I have no idea - otherwise I agree, that it would seem like a straightforward improvement.

'''owenpsmith:'''Setting the elevation offsets is a bit tricky and is done in several steps. First I add the towers on either side of the span if they do not already exist. Once they are uploaded and their terrain elevations have been set, I plug the lat/long/terrain elevation/tower height into a spreadsheet. Each spreadsheet is tweaked based on the number and layout of markers. The spreadsheet is set up to calculate the lat/long of each marker, and the absolute elevation based on a catenary curve. The coefficient of the curve is set for each span based on the length and adjusted until it "looks right". I then create all the objects locally and fire up the sim. I find the terrain elevation below each marker and subtract this from the absolute elevation to get the elevation offset. Once uploaded, I reload scenery in the sim and do a flypast to double check. This work is on hold right now because the mapserver site is acting up, and I can't access the object properties from the map. This is preventing me from getting the information for the towers on each end of the span. In the meantime I'm adding more towers so hopefully I can do a marker blitz once the mapserver is working properly again. On the subject of implementing the clearing through the trees, I've been thinking about this a bit. It occurred to me that the roads in FG use OSM line data and in the simulator, we get a grey line on the terrain, on which the trees have been omitted. So if we could implement a line type for power lines for which the trees will be omitted, but not draw the grey line, then we'd have the clearing we want. The line data could be derived from existing power pylon object positions. The line type may already be defined, we just need to set positions and process it appropriately in FG. Will dig into OSM when I get a chance. It would be nice to get automated power line object generation complete with tree clearing. Object heading might be a bit tricky. Adding power pylons is not that exciting but it is pretty quick work. I'd settle for OSM based tree clearing provided it aligns accurately with existing FG power pylons. It would seem that the power line data in OSM is just line data, similar to the roads for which we already clear the trees in FG. So if we can add the pylon objects based on this line data, can't we clear the trees the same way we currently do for roads? How is the line data (roads, power lines) defined? Are they not just a series of "waypoints" defined by lat/lon? If they are then couldn't the line data in the btg files, and the pylon positions in the stg files be based on the same set of lat/lon points? Then they would align in the rendered scenery? My development experience is in the C family (C, C++, C#), Perl, SQL databases, mostly "backend" development, very little GUI work. About 15 years ago I did some work on ATC systems, and ISS robotics using Ada :-/ Most of my career has been spent in aerospace/defence which grew out of my first career choice which was to be a commercial pilot. I got my commercial licence and my parents and a few other relatives have had various Cessna's over the years. So I pretty much grew up at small airports along the west coast of Canada. My favorite times in the cockpit have been on Cessna 180/185 floatplanes. So with this backwoods VFR experience, power lines have always been far more available than navaids for navigation. So is this how the roads are generated then? The road line data gets "baked" into the terrain files by giving these areas their own land class? So FG knows nothing about line data when it renders scenery at runtime? So if we have some power line line data, it would be similarly "baked" into the terrain using a land class which would ideally have the same terrain texture as the surrounding land classes with the exception that no trees would be generated. I see how it could get more complicated if you consider the impact on all terrain types, and the type of random objects on each (trees, buildings etc). Obviously for certain types of landclass the effects could be ignored, ie water, grassland, tundra, dessert etc. Others would require trees to be cleared. The urban effects are still a mystery to me but everything is slowly becoming less mysterious! I guess each landclass would have to be analyzed and grouped into categories based on impact of power lines. Then sibling/child land classes introduced based on that analysis, to be substituted for the base landclass.

'''psadro_gm:'''ow that World Scenery 2.0 is rolling out, we're looking for new ideas to sketch out a roadmap for scenery features that require changes to the terragear tools and the .btg file format. I think one of the largest requests is from shader developers to get more into the .btg file. I'm currently looking at adding vertex attributes, and alternate texture coordinates. The biggest concern is backwards compatibility. Any new additions to the .btg should (hopefully) be ignored by older simgear versions. This will be an exciting time for experimentation to see what sticks.. I am unsure what we could do to 'clear out' tree generation on existing landclasses, as I am unfamiliar with how the trees are positioned. If there's anything that could be done with added info for the shader, let me know.

'''Hooray:'''Having runtime access to certain vector data would be useful for a number of other subsystems in FlightGear. Time has shown, that the more data is available, the more people are going to use it come up with novel features. And then, being able to dynamically place/replace scenery textures easily has been requested several times (see the runway skid marks discussions for example). Also, it would be awesome if TG development could be closely coordinated with the ongoing random buildings/OSM efforts (by radi et al). These are two areas that are clearly overlapping in various ways - despite the fact, that FlightGear's random buildings are less static than TG scenery compilation historically is. But you guys once mentioned that you were looking into creating more and more stuff procedurally at runtime anways - so given that both efforts seem to be alive and kicking currently, it would be great to see some form of JV for the greater good (i.e. final outcome)regarding random trees/buildings, Stuart is the right person to talk to - he should be able to explain how everything works currently. But if I remember correctly, he announced a while that he was reworking the whole subsystem, and considering to decouple the "randomness" aspect a little more, so that other placement heuristics could be used, too.

'''david.megginson:'''As an Eastern Canadian pilot, I agree with @owenpsmith — unless you're flying very low level (e.g. landing, taking off, pipeline inspection, etc) it's mainly the clearing that you see, not the pylons and wires themselves. I'd suggest that we need a material for "DefaultClearing" that can vary by region: for example, it would be grass in wet, temperate parts of North America, but we wouldn't want a strip of lush grass running through the desert under a power line.

== Related ==
* http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/9E39B0CA-5417-45EB-8683-C99DB3AB67B3%40web.de/#msg32324151
* http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/E495A106FF5F31448739E79D34138C193C8DBAE1%40mbs2.ad.jyu.fi/#msg32325675

[[Category:Developer Plans]]

Using TerraGear

2016-12-08T21:52:31Z

David.megginson: Note ogr-decode => poly-decode

{{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 TerraGogrear 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 later is the easiest and advised for starters.

* '''Option 1a - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear build from the [http://build.flightgear.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip FlightGear Build Server].
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package and move the files from <code>archive/install/msvc100/TerraGear/bin</code> into a sub-directory named <code>Terragear/</code> in the base directory.

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

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

* '''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://dds.cr.usgs.gov/srtm/version2_1/. 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-1/</code> (or SRTM-3/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 ====
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]]
* 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: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]]

Starting in the Air

2016-04-22T01:42:27Z

David.megginson: Added section on setting up an approach

To start FlightGear in the air, you need at a minimum to set the following:

* the [[altitude]] in feet [[MSL]], using the [[altitude]] option
* the [[calibrated airspeed]], using the vc option (or alternately, the [[Mach number]], using the mach option)

You can also set the heading using the heading option, but note that the heading is in degrees true rather than degrees magnetic, so in some parts of North America it can be more than 30 degrees different than runway alignment. Here's a simple [[command line]] to start flying true north at 110 kcas (typical cruise speed for a [[Piper Cherokee Warrior II|Warrior]] or [[Cessna C172]]) at 5000 ft northbound:

fgfs --altitude=5000 --heading=0 --vc=110

Often, you will want to start flying in a position relative to an airport, navaid, or intersection. In that case, you can specify the reference position using the normal airport, vor, ndb, or fix options. You then use offset-distance to specify your distance from the starting point (in statute miles, which needs to be fixed), and offset-azimuth to specify the bearing to the reference point (again, in degrees true). This command line starts at 5000 ft 5 statue miles to the east of the Oakland [[VOR]]:

fgfs --altitude=5000 --heading=270 --vc=110 --vor=OAK --offset-distance=5 --offset-azimuth=270

Note that you do not have to be flying towards the reference point: you can pick any heading you want.

==Setting up an approach==

To set up an ILS approach realistically, you should start the plane in the air, outside the final approach fix, below the glideslope, on a 30° or 45° intercept. You will normally intercept the localiser first, hold altitude until the glideslope comes down, then reduce power to stay on the glideslope. Here are the steps to set up in the air for the ILS 32 approach into Ottawa (CYOW):

# Determine the final approach fix (in this case, the Greeley NDB, YRR) and the glidepath crossing altitude (1,800 ft MSL)
# Determine the magnetic heading for the approach path (320°), then adjust by the magnetic variation (-14°) to get the true heading (306°)
# choose a starting altitude 500–1,000 ft above the crossing altitude (2,500 ft)
# choose an appropriate approach speed for your aircraft (90 kt for the Piper Warrior or Cessna 172, though in real life, you might push it to 110 kt at a busy airport)
# choose an offset azimuth angle from the final approach fix that is 10° greater or lesser than the approach path (316°)
# choose a true heading that is 30° greater or lesser than the approach path, in the same direction as the azimuth angle (336°)
# preset your frequencies (110.3 mhz for the ILS 32 localiser; 377 khz for the Greeley NDB)

Resulting command line (using the Warrior II, which launches with the engine running by default):

fgfs --aircraft=pa28-161 --prop:/controls/engines/engine/throttle=0.7 --ndb=YRR \
--altitude=2500 --offset-azimuth=316 --heading=336 --nav1=320:110.3 --dme=nav1 --adf=377 --offset-distance=5 --vc=90

Be prepared to make rapid throttle and trim adjustments on startup. Fly straight and level until the LOC needle comes alive, then turn left on intercept; maintain 2,500 ft until the GS needle comes alive, then reduce power to keep it centred. Decision height is 571 ft.

[[Category:FlightGear feature]]