Board index FlightGear Development

Announcing FFGo: a new FlightGear launcher

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Oct 25, 2015 6:05 am

I didn't want to fork... It is just that I haven't received any reply/mail, seen any release nor forum message from FGo!'s author in a looong time (and I'm worried). It was such a pity to always read “FGo! is compatible only with Python 2.x.” on its home page while Robert had ported to Python 3 himself! (plus the conditional config support which was working but only usable by Robert and me, since it was not published as part of any FGo! release to this date). But I'd be happy to continue working with him, especially if that can be done via a Git repo (because staying up-to-date and in sync. exchanging only patch files is time-consuming and error-prone gymnastics IMHO...). That is why I use the {prg} placeholder in translated strings and a PROGNAME variable as much as possible in the Python code, so that if someone has to fork and rename or if we have to rename FFGo to FGo! one day, it won't be too painful. ;)
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby chris_blues » Sun Oct 25, 2015 1:14 pm

I see. Yes, he told me a while ago, that he was going to port to python3. But didn't wanted to do it until all distributions have migrated to python3. That seems the case now, as far as I know. He seems to be very busy...
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1535
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Wed Oct 28, 2015 9:09 pm

Yup, that is the case. AFAIK, Python 2.x is being phased out progressively upstream, with reason.

I have released FFGo 1.6.0 with your translation (thank you!) and a few other changes:
  • New parser for apt.dat/apt.dat.gz. Should be compliant with the v1000 spec. Currently, it is only used to lookup fallback parking positions for a given airport, as described below.
  • Read parking positions from apt.dat.gz as a fallback. If the standard lookup from the groundnet files gives no result, look up the parking data in apt.dat.gz. This is slow, but the last 50 results are cached in memory to mitigate the inconvenience.

    With the apt.dat.gz file distributed with current FlightGear 3.7 (which is identical to the latest file distributed on http://data.x-plane.com/get_data.html, and very outdated with respect to contributions by FlightGear users), the number of airports having at least one startup location declared in apt.dat.gz is 3437. This means that FFGo can offer parking positions/startup locations for at least this number of airports (the parking data from FlightGear groundnet files is used preferentially to this data from apt.dat.gz, but it is maybe possible that some airports have parking positions declared in a groundnet file but not in apt.dat.gz).

    I may extend the format of FFGo's apt file in future releases to speed this up (storing some kind of index for apt.dat.gz).
  • Small color changes.
  • Cleanup of code related to the METAR widget (most notably, threading code). Apart from possible more or less random crashes which should not happen anymore, the most user-visible result of these changes is that the widget contents is automatically updated whenever the state of the “Decoded” checkbox is changed (and every such update is the result of a new HTTP request).
  • Various InfoWindow improvements.
  • Update the German translation. (thanks to chris_blues)
A few airports you can try to see the new parkings not known to FlightGear but still available via FFGo (passing --lat, --lon and --heading to FlightGear): LFMN, LFBD, KHPY, YSSL (nothing special about them except they have startup positions defined in apt.dat.gz but no parking position defined in a groundnet file).
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Nov 05, 2015 8:49 am

Hello,

I have uploaded FFGo 1.6.1. The main change since version 1.6.0 is a fix for a bug preventing FFGo from starting on Windows when the HOME environment variable wasn't defined, introduced in version 1.3.0. It would be nice if Windows users could report whether the latest version works for them. I have fixed the bug without being able to test---except on Linux, which was not affected by this bug fix---but I don't know if there are other Windows-specific bugs (or, more generally, bugs affecting non-Linux platforms).
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Nov 08, 2015 2:14 pm

rominet wrote in Wed Oct 28, 2015 9:09 pm:I may extend the format of FFGo's apt file in future releases to speed this up (storing some kind of index for apt.dat.gz).

I now have something like that working:
  • old apt.dat.gz parser entirely replaced with a new one;
  • new format for the apt digest file ~/.ffgo/apt (%APPDATA%/FFGo/apt on Windows), containing an index to allow fast access to the full airport data for any airport in apt.dat.gz;
  • Airport and Runway classes to conveniently store all this metadata.
The creation of the apt digest file is a bit slower than before (about 25 seconds on my system, as opposed to 10 or 11 before), but this should only be necessary when apt.dat.gz changes (the current version in FG 3.7 dating from 2013) or if I have to change again the format of the apt digest file. The slowdown is caused by tell() from the gzip module being slow, however this is necessary to create an efficient index (using line numbers is faster when creating the index, but then accessing the indexed data is much slower, which is clearly undesirable).

Benefits:
  • Access to all metadata from apt.dat.gz is now very fast (airport type and elevation, startup locations for 3437 airports, runway metadata such as length and type, etc.);
  • FFGo can now display this metadata in tooltips or other relevant places (cf. screenshots below for a preview of this).
  • Startup may be a bit faster since the runway names are not in the apt digest file anymore but loaded on demand (I haven't tried to measure this yet).
  • The new apt.dat parser is compliant with the APT1000 spec.
I have uploaded a preview of this code with already some metadata in airport tooltips to the 'testing' throw-away branch of the Git repo (cf. screenshots below). This means it is not quite as polished as what I usually upload to 'master', but interested people can test: it is working and should not eat your hard drive. “Throw-away branch” means the branch will not be continuously updated like normal public Git branches: it may be necessary to do 'git checkout testing' to get the latest version of this branch; 'git pull' is not guaranteed to work in this branch.

How to test: go to the root of FFGo's Git repo and run:
Code: Select all
git fetch
git checkout testing
make

EDIT: added the 'git fetch' command, in case your clone of the repo was done before the 'testing' branch was created.

Now, you may run FFGo as usual. It should automatically create a new apt digest file for you in the new format on the first run, unless you have chosen the non-default Manual setting for “Airport database update” (instead of Automatic). If for some reason you are using Manual, you'll have to rebuild the airport database, otherwise it won't work because of the new format.

If something goes wrong, please backup your ~/.ffgo folder before rebuilding the airport database, otherwise it will be difficult to understand the cause of the problem. Please also keep a copy of FG_ROOT/Airports/apt.dat.gz for the report, although it is obviously never modified by FFGo. I have once seen the program get stuck doing a seek() in apt.dat.gz, so I am wondering if there might be a problem in the Python gzip module. However, I was too quick rebuilding the airport database, and haven't been able to reproduce the problem afterwards. So, if you encounter this, I am interested in your files. :wink:

When you want to return to the master branch, simply do:
Code: Select all
git checkout master
make
rm ~/.ffgo/apt

At this point, running FFGo should rebuild the apt digest file in the old format (the one from FGo!).

Screenshots:
  • a land airport:
    Image
  • a seaplane base:
    Image
  • a heliport:
    Image
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Sun Nov 08, 2015 11:33 pm

A tip concerning helipads:
  • Normally, helipads defined in apt.dat.gz are a kind of runway, and are thus listed in the airport tooltip (for those using the 'testing' branch I uploaded today) as well as in the runway popup menu (available in all versions);
  • Helipads defined in a groundnet file appear in the parking popup menu;
  • When the groundnet file for the selected airport defines no parking position, recent FFGo versions read the startup locations for this airport defined in apt.dat.gz and show them in the parking popup menu. It might be that some helipads are among these (defined as an apt.dat startup location as opposed to a record of type 102, aka “helipad”). In my opinion, that would not be in the spirit of the apt.dat specification, but it just depends how people have filled apt.dat.gz...
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Wed Nov 11, 2015 7:38 pm

rominet wrote in Sun Nov 08, 2015 2:14 pm:I now have something like that working:
  • old apt.dat.gz parser entirely replaced with a new one;
  • new format for the apt digest file ~/.ffgo/apt (%APPDATA%/FFGo/apt on Windows), containing an index to allow fast access to the full airport data for any airport in apt.dat.gz;
  • (...)
I have uploaded a preview of this code with already some metadata in airport tooltips to the 'testing' throw-away branch of the Git repo

This is now pushed to the 'master' branch. The airport tooltip also shows latitude and longitude now.

If you have used the 'testing' branch, I suggest to run 'git checkout master', save any changes you might have done on the 'testing' branch (maybe rebasing them onto 'master'), and finally delete 'testing' with 'git branch -D testing'. This way, you'll be ready for the next time I recreate this branch.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Mon Nov 23, 2015 11:29 am

Hello,

I am pleased to announce the release of FFGo 1.7.0. For a change, let's start with a few screenshots:
  • Example of decoded METAR data for those who didn't know this feature (+ Bordeaux-Mérignac airport tooltip, and a parking position taken from apt.dat.gz, that doesn't currently exist in a groundnet file):Image
  • Airport tooltip at Hamburg (EDDH):Image
  • Tooltip for runway 23 at Hamburg:Image
  • Airport tooltip for the Beaver Dam Lake seaplane base (1WI5):Image
  • Tooltip for water runway 23 of this seaplane base:Image
  • Tooltip for a grass runway (Caumont, LFMV):Image
  • Tooltip for a dirt runway (Dobbiaco, LIVD):Image
  • Tooltip for the 1001 Fourth Avenue Plaza (sic) heliport (WA54):Image
  • Tooltip for the only helipad at this heliport:Image

Now, a list of the main changes in this release:
  • New apt.dat.gz parser; new format for the apt digest file[1] with an index for very fast access to all the data present in apt.dat.gz.
    • Replace the old apt.dat.gz parser with a new parser. This new parser should be compliant with the APT1000 specification, provide better error reporting and fix a few small bugs (see below). It also extracts more information about airports and runways, unifies recently added extraction of parking metadata from apt.dat.gz with this airport metadata, and generates an apt digest file in a new format bringing the following improvements:
      • more robust (proper header including magic number, encoding declaration and format version; fields separated by the NUL char ('\0') instead of '=');
      • contains only the information FFGo must read on startup in order to make this startup as fast as possible; in particular, runway names for all airports are not read anymore on startup and held into memory, they are loaded on demand when needed for the selected airport;
      • since runway and parking metadata are loaded on demand from apt.dat.gz (after trying the groundnet file in the case of parkings), the new format includes an index for each airport allowing to quickly find its data in apt.dat.gz. Of course, this requires keeping the apt digest file in sync with apt.dat.gz, which should not be much of a problem since the default for Airport database update is Automatic since version 1.3.0.
      [1] Also known as “airport database”: ~/.ffgo/apt everywhere except on Windows, where it is %APPDATA%/FFGo/apt.

      Note: migration from the old file format of the apt digest file is automatic. However, if you already have this file in the new format and for some reason want to run a version of FFGo older than 1.7.0, you'll have to remove the apt digest file before.
    • The creation of the apt digest file is a bit slower than before (about 25 seconds on my system, as opposed to 10 or 11 before), but this should only be necessary when apt.dat.gz changes---which does not happen very often, the current version in FG 3.7 dating from 2013---or if I have to again change the format of the apt digest file.

      Note: the slowdown is essentially caused by gzip.GzipFile.tell() being slow, however this is necessary to create an efficient index. So, it's a bit slower once in a while when rebuilding the airport database, but pays off the rest of the time when using FFGo and looking at the airport, runway or parking tooltips, or simply choosing among the newly-available startup locations read (since version 1.6.0) from apt.dat.gz.
    • Startup and config reloading should now be significantly faster when the airport list is “filtered” (the configuration option that causes FFGo to only show the airports you already have scenery for).
  • Add a colored, disabled (i.e., not clickable) and empty header to the runway popup menu. This makes it more visible, visually similar to the parking popup, and avoids it disappearing in a flash with the first entry being accidentally selected if the user just clicked without holding the button down.
  • Add tooltips to the airport list giving basic information about the airport under the mouse pointer (type of airport [land airport, seaplane base or heliport], latitude, longitude, elevation and, if applicable, the lists of land runways, water runways and helipads).

    The magnetic variation (also called magnetic declination) at the airport is also displayed in the airport tooltip if GeographicLib's MagneticField program is available. If this program is not in your PATH, you can indicate its location using the Preferences dialog.

    Note: MagneticField requires a particular dataset to be installed in order to work properly. In Debian, it is part of the geographiclib-tools package, which also provides a script called 'geographiclib-get-magnetic'. Running a command such as '/usr/sbin/geographiclib-get-magnetic minimal' with root privileges will automatically download and install a minimal dataset under /usr/share/GeographicLib/magnetic, where it can be found by MagneticField (not registering the added files with dpkg, which is a bit ugly, cf. Debian bug #687253).
  • Fix slightly incorrect calculations of v810 airport coordinates (two opposite runway ends counted as one). This bugfix comes with the new apt.dat.gz parser.
  • Fix computation of runway names from v810 data (“6” instead of “06” for the “other runway” opposed to “24”). This also comes with the new apt.dat.gz parser.

    Note: these fixes are untested, as there is no single runway in v810 format in my apt.dat 2013.10, build 20131335.
  • Display magnetic heading in parking tooltips when 'MagneticField' is available (see above for details concerning 'MagneticField').
  • Tooltip for each runway in the runway popup menu, giving: latitude, longitude (of the runway end), heading (true and magnetic if 'MagneticField' is available, otherwise only the true heading), length, width, surface type, shoulder surface type, type of markings, smoothness.

    Helipads also have a line specifying whether they have edge lighting. Water runways have less fields because things such as shoulder surface type and smoothness are obviously not applicable. They have all the data that is present for them in apt.dat.gz, except for the “perimeter buoys” flag. The code to handle this flag is ready, but the way it is used in apt.dat.gz is completely bogus and in contradiction with the APT1000 specification. I'll activate the code when this is fixed.

    Since they are not directly available in apt.dat.gz, the length and heading of runways are computed from the latitude and longitude of opposite runway ends. FFGo ships with an implementation of Vincenty's formula to do this with better than 1 mm precision (assuming the coordinates of the runway ends are that accurate in apt.dat.gz!), as well as a few more things to deal with the cases that Vincenty's formula doesn't handle well.

    If GeographicLib's Python implementation is installed, it will be used in preference to these methods, because it is even more accurate (about 5 nanometers according to its website), was written by an expert in geodetic calculations (Charles F. F. Karney), and apparently handles all cases of the geodetic inverse problem, contrary to Vincenty's formula.
  • Correct calculation to find the nearest METAR station. The previous code didn't behave properly for points located on either side of the ±180° meridian, or close to one of the poles. Use a fast method (GeodCalc.modifiedFccDistance()) that gives reasonably correct results to find the best 15 candidates for the title of “closest station”, then find the closest among these using GeodCalc.inverse() (which is an FFGo abstraction layer for the algorithms mentioned above: Karney's algorithm from GeographicLib if available, otherwise Vincenty's formula plus a few others for the cases that Vincenty's formula doesn't handle well).
  • Always write the timestamp file after rebuilding the apt digest file (i.e., after “rebuilding the airport database”). With the previous code, if the airport database was manually rebuilt and afterwards the Airport database update setting was changed from Manual to Automatic, then the database would be unnecessarily rebuilt. This should be fixed now.
  • Improve some tooltips of the Preferences dialog.
  • Update the German translation (thanks to chris_blues).

As usual, Debian packages are available from FFGo's home page.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby chris_blues » Mon Nov 23, 2015 1:02 pm

Wow, what a list!

I'll go researching, I think I have misinterpreted this shoulder surface type. I'll let you know, when I got an update. :)

Thanks for your hard work!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1535
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Mon Nov 23, 2015 5:59 pm

You own the latest commit in the repo, chris. Thanks for your nice comment and translation! :)
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Dec 03, 2015 12:15 am

murderbybox wrote in Wed Dec 02, 2015 10:52 pm:
Code: Select all
[david@dvd FFGo-1.7.0]$ ./ffgo-launcher.py
Traceback (most recent call last):
  File "./ffgo-launcher.py", line 12, in <module>
    import ffgo.main
  File "/home/david/Downloads/FFGo-1.7.0/ffgo/main.py", line 22, in <module>
    import tkinter
  File "/usr/lib/python3.5/tkinter/__init__.py", line 35, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: libtk8.6.so: cannot open shared object file: No such file or directory

Wat do i do? I dont have root access btw

Erm, it's not very reasonable to expect software to work when you haven't installed the documented mandatory dependencies. Please read the docs/INSTALL/INSTALL_en file that comes with the tarball or zip file you have downloaded (also available online, but this is for the Git version, and you should better read what corresponds to the version you are trying to use).

It seems your Python installation is missing Tkinter (python3-tk package on Debian), which is the library used by FGo! and FFGo (at least so far) to build all graphical widgets... It is pretty standard, shipped with Python itself, but distributions tend to put it in a separate package in order to allow some users to save a few kilo or megabytes... but sometimes, the library is actually needed, and this is the case here...

The other mandatory dependency, CondConfigParser, can be installed without root access, but for this, you need to either set up a virtual environment (explained in INSTALL_en) or install it in a Python installation where you have write access (for instance, downloaded and compiled under your user account)---or play with setup.py options and PYTHONPATH, which I wouldn't recommend in your case. The virtual environment way is relatively easy and has become standard for Python packages, but there also, you need to have the software that makes this possible. If you can run:
Code: Select all
python3 -m venv /tmp/foo-venv

you should be fine. Otherwise, you have to install venv.py (matching the Python version in use) one way or another.

Concerning the optional dependencies:
  • Pillow (python3-pil.imagetk package on Debian) can be installed with pip in a virtual environment, as CondConfigParser, but under Linux this requires compiling C code, and therefore you need a C compiler and certainly one or two specific libraries in order for the (automatic) compilation to succeed.
  • GeographicLib for Python 3 can be installed with pip in a virtual environment exactly as CondConfigParser (no compilation required);
  • GeographicLib's MagneticField program requires the GeographicLib C++ library to be installed, as well as a dataset. It can certainly be compiled without root access, but in order to use the MagneticField program with the resulting library, you would need to set LD_LIBRARY_PATH and GEOGRAPHICLIB_MAGNETIC_PATH or similar (as documented in MagneticField's man page) -> Linux compilation and installation skills required.
Now, I am having a hard time believing that you can play FlightGear on a computer but not at least ask its admin to install a few packages for you. Because most of these complications vanish once you have the basic packages installed with your distribution package manager...
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby murderbybox » Thu Dec 03, 2015 1:01 am

My "admin", is my brother. He is not very nice, to say it nicely, so even if i asked he would probably just say "no, **** you :D"
Last edited by Johan G on Mon Dec 07, 2015 4:34 am, edited 1 time in total.
Reason: No useless quoting please. No need to repeat the entire preceeding post.
murderbybox
 
Posts: 109
Joined: Mon Aug 10, 2015 4:50 pm
Location: ESNO
Callsign: Padawan
Version: 2018.2.2
OS: Windows 10

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Thu Dec 03, 2015 8:22 pm

Ah, life can be tough... Your best bet, I believe, is to get in better terms with your brother. Indeed, even if you managed to run FGo! or FFGo, he could very easily uninstall FlightGear, or schedule a periodic task that semi-randomly kills it, etc. I am afraid there is not much we can do here to help you in such situations.

P.S.: you should not quote whole messages, especially when the message you are quoting is right before yours.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Dec 11, 2015 5:44 pm

Hello,

Those using the Git repository can try out the new Airport Finder dialog accessible under the Tools menu:
Image

The Airport Finder dialog:
Image

This dialog allows one to find all airports located in a given area specified with maximum and minimum distances to a reference airport. The direction of the path (from or to the reference airport) can be chosen. For each result, the dialog gives the orthodromic distance (i.e., the length of the shortest path following the Earth curvature) between the two airports as well as the initial and final bearings of the course, according to the chosen direction. It is also possible to choose between magnetic and true bearings, nautical miles and kilometers (for display of the results), Vincenty and Karney calculation methods. Finally, a button allows one to choose the airport selected in the results table and automatically close the dialog.

This dialog was written with the following use case in mind: suppose you found on Lenny's site or on the FlightGear multiplayer map that there is an ATC session at some airport and would like to land there. For example, let's assume the ATC session is taking place at MHTG (Toncontin Intl, Tegucigalpa, Honduras). So, you need to find an airport that is neither too close nor too far from MHTG given the time you are ready to spend for this flight (in general, when an airport is under ATC control, you should be either on ground or at least 70-80 nautical miles away from the controlled airport at the time you connect to the multiplayer network, in order to let the controller(s) enough time to properly insert you into the existing traffic).

With the multiplayer map, estimating distances between airports is not easy. This can be done by trial and error with FlightGear of course, but using FFGo's new Airport Finder dialog is much quicker and more convenient. You just have to enter MHTG as the “reference airport”, check that the minimum and maximum distance fields have values you are satisfied with and click on the Search button, or use the Alt-S keyboard shortcut. You will then obtain a list of airports in the given range, with for each of them its distance to the reference airport, as well as the initial and final bearings for the course using the shortest path. If you have installed the MagneticField program that comes with GeographicLib, you will have the choice to display magnetic or true headings.

This use case is why the reference airport is considered as the destination of your flight by default. However, if you want to start from a particular airport and find which airports are in a given range of this airport, all you have to do is to change the “Direction” radio button to “from reference airport” and all bearings will be updated accordingly in the list of results.

Both tables (multicolumn lists) can be sorted in ascending or descending order using any column as the sort criterion by simply clicking on the column header, as usual with this type of interface. By specifying a maximum distance that is greater than the half-length of the equator (10820 nautical miles should be enough), you can list all airports known to FlightGear, and sort them for instance by distance from the reference airport (this is the default). Looking at the maximum distances, you can find nearly-antipodal airports relatively to the airport of your choice, which you may find amusing. For instance, using Paris Orly (LFPO) as the reference airport, one can find that the farthest airport from it is NZCI, which is located on an island east of New-Zealand. But you can also sort the lists by ICAO, airport name, initial or final bearing, of course (sorting by bearing can be useful if you want your flight to go roughly north-west, for instance).

Particular care has been taken to make sure the reference airport selection interface is as convenient as possible. It is similar to what already exists in the main window, but with a few improvements: real multicolumn widget (allowing proper alignment as well as sorting); small delay before updating the list (as in FGo! and in previous versions of FFGo, implemented in a CPU-efficient way); smarter selection. Let's explain the last one a little bit. When you know the ICAO code of an airport and type it in the search field, it's a bit annoying if the default selection, after you have typed the ICAO in the search field, goes to an airport that by “chance” contains the ICAO code in its name. So, this new airport selection mechanism selects an exact (case-insensitive) match on the ICAO field by default if such a match exists. If not, it tries to keep the selection on the airport that was selected before the last change in the search field. And if the search was refined in such a way that makes this impossible, the default selection goes to the first result, which is what the widget in the main window does in all cases. This interface will probably replace the one in the main window in a future release.

This may be easier to understand with an example: typing "lfpo" in the search field automatically selects Paris Orly (LFPO), not any airport containing this string in its name (such as Gulfport Biloxi Intl or Gulfport Jail)---those are still listed and available for selection, though. This is particularly convenient for airports such as Turtle Island, whose code "TTL" is contained in the name of many other airports (most of which containing the word "little").

It would be possible to add other elements to the search criteria and display them in dedicated columns in the tables. The most interesting candidates that come to mind are:
  • max./min. number of land runways;
  • max./min. number of water runways;
  • max./min. number of helipads;
  • maybe the length of the longest runway in the airport, too.
These are not difficult to add but require including the corresponding data into the apt digest file (aka airport database), otherwise reading them for more than 34000 airports would be dreadfully slow. I don't see any major problem for the first three points above. The last one would require computing the length of each runway in the world whenever the airport database is rebuilt, which is certainly doable but will make it last a bit longer (not sure how much yet, I would say on the order of 3 to 15 seconds approximately using Vincenty's formula on my computer).

Note: the Treeview widget used to implement the multicolumn lists should be part of Tk since version 8.5. Debian jessie already has Tk 8.6, so I don't think this requirement should be a problem in practice (i.e., normally, things should work without installing anything else than what you already have for FFGo). Tested on Debian wheezy and unstable, no problem found.

Finally, for those wondering why the table of results gives an initial and a final bearing for each airport, think about this: imagine you are very close to the North or South pole, moving with true bearing (azimuth) 90°. You are following a line of constant latitude, i.e. a circle whose axis is the North-South axis of the Earth. Clearly, this shows that a path with constant bearing (azimuth) is neither straight (if close to the North pole, you are constantly turning left in this example) nor a shortest path between two points on the Earth surface. Curves on the Earth's surface corresponding to “straight” walking or flying are called orthodromes or geodesic lines (at each point, the projection of the curve on the plane that is tangent to the Earth's surface at the point in question has zero curvature). Curves with constant azimuth at each point are different beasts called loxodromes, rhumbs or rhumb lines. And flying your plane with constant altitude and magnetic heading in the absence of any wind doesn't even follow a loxodrome, because the magnetic declination changes all along your path, therefore your true heading can't be constant...
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: Announcing FFGo: a new FlightGear launcher

Postby rominet » Fri Dec 18, 2015 10:58 pm

I have finally upgraded the apt digest file format (“airport database”) to version 2, adding enough information to allow quick searches over all 34000+ airports from apt.dat.gz using the following criteria:
  • maximum and minimum number of land runways;
  • maximum and minimum number of water runways;
  • maximum and minimum number of helipads;
  • length of the shortest runway in the airport;
  • length of the longest runway in the airport;
  • presence of at least one land or water runway (which is mainly useful to remove all airports/heliports having only helipads when one wants to focus on runway length, and therefore on real runways).
Of course, the already existing criteria “maximum and minimum distance to the reference airport” are still available and can be combined with all of the above.

Migration to the apt digest file format version 2 should be automatic. Gathering the new data in this version costs 3 seconds out of the 28 needed to rebuild this file on my computer---only when apt.dat.gz changes or when this file format is updated.

I have also added the corresponding data in new columns of the tables displayed in the Airport Finder dialog, which allows users to sort according to any of these criteria (except for the last one, which is not worth the space needed IMHO) by simply clicking on the corresponding column header. Clicking several times on the same column header reverses the sort order every time.

The sizes of each part of the dialog can be adjusted by clicking and dragging at the boundary between two adjacent parts. I have also added this capability to FFGo's main window.

Examples:
  • list all airports with at least one land runway, located within 800 nautical miles around Clermont-Ferrand Auvergne (LFLC, approx. in the “middle” of France), sorted by length of the longest runway:
    Image
    (displaying here the parts showing the longest runways)
  • similarly, show the airports that have the longest runways in the world:
    Image
  • airports with the highest number of land runways in the world:
    Image
  • airports with the highest number of helipads in the world (where people tend to go shopping with their helicopter rather than their car):
    Image
  • Want to do some seaplane trip around Cuba? -> list all airports with at least one water runway in a 250 nm range around Abel Santamaría (MUSC, Cuba), sorted by distance from MUSC:
    Image

It's all in the Git repository!
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest