Yeah, these apps are one of the reasons why we have been advocating, and encouraging, MFD/MapStructure developers to encapsulate all navdb accesses using a helper class/hash - especially people wanting to use the latest navdata, will appreciate having a way to simply reconfigure their MFDs to use an alternate navdb source, so that they can use actual FIXES/VORs.
This was also highlighted by some people during the G1000/FG1000 discussion that took place a while ago on the devel list, i.e. people wanting to use FlightGear for actual flight training/proficiency purposes, do need a way to use alternate/custom nav data:
http://wiki.flightgear.org/FG1000#NavdataAt least for the US, it would seem relatively straightforward to get access to AIRAC data via the NGS:
http://wiki.flightgear.org/FG1000#Airpo ... -_only_.29This is the data that is used by CAD programs to actually create the dTPPs, i.e. the terminal procedures for all US airports.
Speaking in general, there is an increasing trend among aircraft developers to move away from hard-coded systems that have these constraints, so that it does make sense to encapsulate accesses to such systems (navdb, autopilot, route manager), so that alternate implementations can be more easily adopted and used. Which is actually what the Emesary framework is all about - but all these existing FG systems pre-date the Emesary implementation in FlightGear by many years obviously.