Introducing gis2fg🔗

I have always been a fan of flight simulation. As a child I used to fly on the (still) notorious Flight Simulator 3 from Microsoft, one of rare products from Microsoft I can say I have enjoyed. After a brief hiatus from flightsim adventures (because of real life!), I returned to it 10 years ago with free software.

The software is now called Flightgear and is a really old project (about 20 years) of flight simulation mainly coded in C++ but surprisingly full of features. It is not on par with the commercial flightsims (visually I mean) but as a community maintained free software it is really good.

Flightgear project is focused on a lot of different parts like flight models, navigation data, terrain modeling, plane modeling, radio communications, network, ATC, joysticks and commands, etc. Flightgear even have a dedicated script language (Nasal) and also embed some Javascript/HTML/CSS for external web rendering (Phi). But production of scenery shaped around real worl details is a specific job and requires specific tools and also a reliable and available data source.

As a GIS developer/engineer, using and transforming geographic data that try to describe the world is part of my daily job! As a flightsim enthusiast, I thought I could build tools to improve Flightgear sceneries, combining my knowledge in the two domains of flightsim and GIS.

Yet, I have build a free software (GPLv3) who is able to build data files for Flightgear. I called it gis2fg for GIS to Flighgear. It takes GIS data and transforms them into scenery files or navigation data files ready to be consumed by Flightgear.

After 3 years of work, I believe this pet project has matured enough to publicly talk about it. In this article I aim to build some kind of a general introduction to gis2fg.

gis2fg is mainly an ETL (Extract Transform and Load). It takes GIS files and transform them into other files ready to be consumed by Flightgear.

Here is a summary of the features:

• Extract data from OSM to generate roads, railways, pylons and cables, buildings and scenery point objects. Like osm2city.py but with a lower quality on the results.
• Extract data from AIXM4.5 and AIXM5.1 for navigation data, fixes, airways and airports.
• Extract navigation data from/for X-Plane 10 and 11 formats.
• Generate an orthophoto tile from raster file, usable in Flightgear from version 2020.4.
• Import/Clean/Export BTG files which is a mesh file for terrain.

All of the mentionned file formats can be imported into a Spatialite database and modified by desktop GIS software (QGIS for example). BTG files can also be exported as mesh files.

Old navigation data from 2013 (LGL: VOR@115.0 Mhz)

Updated navigation data from 2022 (LGL: VOR-DME@112.70 Mhz)

As a free software, anybody can use gis2fg, but if you don't know about Flightgear internals (particularly about scenery stuff), it will be a bit complicated for you to achieve something with it.

gis2fg is much more a tool for Flightgear hackers with some knowledge in GIS software, particularly how scenery tiles are stored. You also have to know that I only have used gis2fg under GNU/Linux Debian. There are probably a lot of bugs under MS Windows. But it's a choice I have made to only support GNU/Linux and not anything else: I don't have enough time to test every operating system.

gis2fg is stored on my personal forge. It is coded in Python3 and it's very simple to install it with pip:

pip3 install git+https://medspx.fr/cgit/gis2fg.git

The requirements are limited to some python libraries:

• Python 3.6
• lxml>=4.0.0
• GDAL>=2.4.4
• Pillow>=8.0
• pyyaml
• argcomplete

man gis2fg

There is a great manual published in man pages. If you are under MS Windows, well, you'll have to figure how you can read them.

Here are some examples excerpted from the documentation:

# Import OSM data from PBF files to the work database
gis2fg osm_import -d ./data/vector/pas_de_calais.osm.pbf ./data/work.sqlite

# Import BTG data from Flightgear to the work database
gis2fg btg_import -d ~/.fgfs/Terrasync/Terrain/e000n50/e002n50/2990888.btg.gz ./data/work.sqlite

# Export basic scenery point objects to a Scenery
gis2fg scenery_point_export -f ./data/work.sqlite ./Scenery 2990888

I know, there is the osm2city.py project which aims to use OSM data and generate roads/buildings and other scenery objects. It is really cool and is used has an official way to produce Flightgear scenery. But I wanted to build something else, something I would have been more comfortable with.

At the beginning, I was mainly focused on orthophoto and didn't plan to code something for vector data. The very first versions of gis2fg were dedicated to modify BTG files to add a specific material on triangles to be able to refer to an orthophoto. It was purely experimental and far from what osm2city does.

Then, I started to add stuff to handle OSM data. Then I wanted to add orthophoto raster to building roofs to test if it was better for realism (just a bit). Well, gis2fg expanded.

osm2city requirements were huge for me: you need to have a postgresql/postgis database, and I wasn't able to understand how to generate stuff with it. I do not say that osm2city.py isn't a good project and software. I have digged in the code and I found a lot of real good features for generating house roofs, or creating electric lines. It does so much. But I wanted something easy to use and to understand and lighter on the database side. Furthermore, geometry library in osm2city.py is based on shapely which I don't use. I am more fluent with OGR.

Then, I also wanted to add real world data about navigation which are produced from public services and often released for free. This is not covered by osm2city.py. In Flightgear, the navdata have been extracted from X-Plane 10 and are dated from 2013. They are a bit outdated. Now, you can improve them. Still complicated but much more easier than doing it by hand.

When you want to deal with GIS file formats, you use GDAL/OGR. That's the rule and the defacto standard. GDAL/OGR is a library aimed to be able to read/write to gazillions of different GIS formats.

Furthermore, it already have an SQL langage based on SQLite/Spatialite to do basic transformations and of course, stuff to handle individual geometries.

Then I used Spatialite only with OGR to store data in a pivot format. This is still a database but you don't have to install anything. As long as you have GDAL/OGR, you are safe. No need to install another software, to deal with rights and accounts and security. Just a file wich can be huge of course, depending on what you import in it.

The pivot database (work database) can be used under desktop GIS software like QGIS, so you are able to make data transformations in it or just view data on a map which is convenient when you want to verify if there is a problem in data or in the import/export soft.

Tons of stuff. gis2fg is a pet project but as my goal was to be able to generate good scenery and using real navigation data in Flightgear, I was really comitted to produce good stuff.

In python:

• Unit tests in Python.
• Python decorators.
• Python context managers.
• Python iterators.
• yield stuff.
• pylint.
• Emacs pylsp.

In math:

• I rediscovered basic vector math. It was really cool and not so complex.
• An algorithm to find if a polygon is clockwise oriented or not.
• a way to deal with arc based geometry. Real difficult stuff even with OGR.

In GDAL/OGR:

• Details about the difference between GPKG and Spatialite.
• OGR is really easy to use in Python.
• But you always have to clean stuff whenever you use vector Features.
• Otherwise, it segfaults a lot.

In Flightgear:

• Internal stuff like the navdata parser.
• How orthophotos are managed under Flightgear.
• How mesh terrain data are read and used.

I also changed my mind about YAML. I was forced to use yaml in configuration files for some software and as Yaml is very strict on spaces and tabs, I often pest about it because there was a problem in the configuration file and the program was crashing. In gis2fg I reconsidered using Yaml for storing data rather than JSON or directly under Python and it simply does the trick. If you want to store a bit of structured data, easily readable and editable by humans and easily consumed under Python, use Yaml.

gis2fg is still a work in progress and I think it will always be. I do not plan to build a community with it because there is already the flightgear community which I am not a part of. I really don't have the time for social stuff and promoting or organizing coding and contributions. Remember that gis2fg is my pet project and I intended to code it only for my use cases.

But you can try gis2fg and if it suits you, well, that will be good.