From FlightGear wiki
Revision as of 05:58, 15 October 2017 by Hooray (Talk | contribs) (Status)

Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.


1rightarrow.png See Canvas_News#Moving_map.2FRNAV_discussion for the main article about this subject.

The enormous variety in current glass flight decks means we really need to think of a new way of defining glass cockpit layouts.[1]

The airspace system is in the process of changing drastically [...] this isn't just a matter of throwing up a canvas showing some GPS waypoints and a magenta line. Modern navigators are astoundingly-complex devices — probably an order of magnitude more lines of code than FlightGear itself — and even their basic flight planning algorithms and databases (e.g. fly-by waypoints vs fly-over waypoints, open vs closed approach procedures, transitions into RNAV approaches, etc.) are far beyond the scope of anything we've tried, and we'd also need an up-to-date database far more complex than the ones we have now. Once you get to the extra features, like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS (terrain alerting), we're probably in way over our heads trying to emulate even the simplest general-aviation IFR GPS.

This may help folks understand what the G1000 is all about: http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf Writing a G1000 isn't that hard. Writing a feature complete G1000 is a ton of work. [2]

Depending on how we deal with this challenge, the question is whether that means that the usefulness of FlightGear will also gradually taper off. [3]

Instead of just making one-off tweaks like the consumer sims did, we (as a team) emulated entire systems like the vacuum, pitot-static, and electrical systems, so that failures would be realistic. In the RNAV age, we need to do the same thing; it's just that it's a bigger job. FlightGear will still be great for people who want to practice the mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but will slip further and further behind for people who want to use it for real IFR practice.[4]


it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.[5]

we need to be realistic here: The G1000 is a fairly significant piece of computer hardware that we're going to emulate. It's not going to be "free" particularly for those on older hardware that's already struggling. However, hopefully we can offload a chunk of the logic (route management, autopilot/flight director) to the core, and do things like offline generation of terrain maps to minimie the impact.[6]


1rightarrow.png See Complex Canvas Avionics for the main article about this subject.



we need some better data sources, especially with direct routing replacing airways in many areas, and having airspace data would help the map displays, but the current API is specifically designed to support G430, G1000 and similar class devices. Adding RNAV approaches is eminently doable, see the the RNavController base class which the GPS/FMS layer uses to allow new waypoint / route segments to define how they are flown and drive CDIs [7]

Getting the algorithms right, and keeping the data up to date every 7 weeks (we have only a tiny sliver of that data currently), is going to be much more of a challenge. I expect that it's probably an order of magnitude more complicated than our current flight dynamics (etc.), so we'd have to grow our contributor base, and find funding to pay at least Curt (and maybe a couple of others) full time to manage the project. Note that that's what has happened for other complex FOSS projects, like office suites and browsers, which generally end up working through a foundation, rather than our current relaxed circle-of-friends arrangement. The reason it's so much harder now is that the software *is* the product for GPS navigators, FMSs, etc. (unlike with older avionics, where the hardware was the main thing). That means that emulating even a simple unit like the GTN 650 or GNS 430W is almost difficult as building one, so we're trying to keep up with armies of full-time software developers at Garmin, Avidyne, etc.[8]

According to the Route Manager wiki page, we already have support for SID/STAR data provided from Navigraph, which is released on the AIRAC cycle, and costs a pretty small amount (9 EUR for a single download of FMS data, or 90 EUR per year) Given the relatively low cost, I don't think that we as an organiation want to get into trying to digitize data ourselves just to make it open-source or public domain. Particularly given the low cost of a download. We might want to digitize the STAR/SIDs for the default airport with each release so there are some approaches available for those who don't want to purchase the data.[9]


Stuart has been in contact with the author (Sébastien MARQUE) of the ZKV-1000. While he himself doesn't plan to implement a G1000, he's very happy for it to be developed in that direction. Stuart's broad plan is to make a copy of this in fgdata or fgaddon, and use it as the basis for a G1000, taking the opportunity to use Richard's MFD code and making as generic pages as possible for other glass cockpit applications.[10]


1rightarrow.png See Canvas_News#G1000_.26_MapStructure_improvements for the main article about this subject.

Stuart wants to build a set of layers for a G1000 implementation - the canvas map UI is really just a way to display it. [11]

October 2017

Stuart committed some changes to update the Select Airport dialog to use Canvas MapStructure Layers to display airport information, rather than the now deprecated map layers. The change should be largely transparent to end users - the only significant change is that your can display navigation symbols. This is all part of a long-term effort to provide the building blocks for a Garmin G1000 - these layers could be used for the airport display on the MFD, and could easily be combined with the APS layer to show a moving aircraft.[12]

September 2017

Stuart added some new Nasal Canvas MapLayers to support Slippy Maps, as used by most web-based mapping services such as openstreetmap. This allows us to display sectional charts (for the US - vfrmap.com), and airspace information (courtesy of openaip.org), as well as a openstreetmap data. The canvas Map dialog has been updated to support these layers. Map data is retrieved over http and cached locally.[13]

Existing work




  1. Robin van Steenbergen  (Oct 2nd, 2007).  Re: [Flightgear-devel] Glass cockpit and external gauges. .
  2. geneb  (Jul 3rd, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  3. David Megginson  (Jul 3rd, 2017).  [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  4. David Megginson  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  5. Thorsten Renk  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  6. Stuart Buchanan  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  7. James Turner  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  8. David Megginson  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  9. Stuart Buchanan  (Jul 4th, 2017).  Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
  10. Stuart Buchanan  (Aug 1st, 2017).  [Flightgear-devel] G1000 (was Re: Nasal property lookup performance) .
  11. Stuart Buchanan  (Oct 1st, 2017).  Re: [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .
  12. Stuart Buchanan  (Oct 13th, 2017).  [Flightgear-devel] Updated Select Airport dialog .
  13. Stuart Buchanan  (Sep 28th, 2017).  [Flightgear-devel] Canvas MapLayer for OpenStreetMap, OpenAIP, VFR Sectionals .