Proposals:NavDB related

This article is a stub. You can help the wiki by expanding it.

This is meant to become a summarized list of all feature requests/suggestions related to the FlightGear navdb, it is largely based on Feature Requests / Proposals / Ideas (where all related items were deleted) and may not be up to date with the most recent developments in CVS, your help in updating and maintaining this list is appreciated!

• the navdb should eventually become a true SGSubsystem, it needs some serious revamping
• allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
• strictly enforce usage of enum fg_nav_types in all FG code to isolate/protect other code from changes in the underlying navdb format
• the navdb & airports wrappers might eventually be better moved to simgear, there are meanwhile various programs (i.e. atlas,taxidraw,fgsd,fgrun) relying on the very same code-using the copy&paste approach. It would be much cleaner and better if simgear could provide the corresponding functionality. That way, we would also only have to fix any issues (i.e. changes in Robin Peel's db format) on ONE central place, rather than having to edit multiple code bases to fix bugs or add features (this discusses a different approach, factoring out the navdb component to become a standalone system to be used by multiple clients-also see [1])
• It would be very useful if there was an option to fail certain types of ground equipment at runtime, for example navaids such as NDBs, VORs, ILS (LOC/GS) as well as things like runway/taxiway or approach (PAPI/VASI) lighting. That way it would for example become possible to have an instructor station fail certain things, or even implement interactive scenarios where ground based equipment will fail during a certain segment of the flight. Such an option would definitely add even more realism to FlightGear. Also, I think that this is a feature that only very few (if any) simulators model at all, even though the procedures to actually deal with such ground based failures are a crucial part of the training for any professional pilot's license (also see [2]).
• for the development of more advanced avionics [3] [4] [5] [6] we will require a terminal procedures database (i.e. SIDs & STARs), this should be added to the base package, so that we can provide the corresponding data within FlightGear, its availability (memory consumption!) could be made optional using a corresponding property or new special instrument type.
• it would be very useful if there was a spatial wrapper provided on top of the navdb, so that spatial queries can be easily used to efficiently search the navdb [7]
• implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
• the navdb API should be fully exposed to Nasal scripts, so that contributors can easily work with navigational data (also see Proposals:Nasal related.
• add support for the Route Manager feature to the Interactive Map - this will hopefully arise from the proposed work on the Virtual Co-Pilot - (link required)