飞过FG的都知道，FG的导航数据是个大坑。。SID，STAR神马的统统是default，根本不能愉快地飞行。但是，其实FG是自带读取LD767导航数据中进离场数据的功能的，本帖我就来介绍一下如何将LD767部分导航数据导入FG。

首先，你需要自备LD767导航数据，相信大家都知道从哪里买对吧
有了导航数据之后你需要找到ICAO.xml，即以机场ICAO代码命名的xml文件。（eg.若要导入北京首都国际机场的数据，找到ZBAA.xml即可）
找到之后，改名为ICAO.procedures.xml，并放入地景目录/Airports/I/C/A/下，如ZBAA就是 地景目录/Airports/Z/B/A/ZBAA.procedures.xml。

以上部分皆为我对fgwiki上的内容改编翻译而成，接下来就是高潮部分了。如果你们按照我的例子，ZBAA来做的话，怀揣着激动的心情打开FG后会发现，**怎么只有这么点数据？这是FG自带数据缺少ZBAA的01/19跑道造成的。往FG数据里添加一条跑道需要用到TerraGear（这部分我也不是很了解），就不多说了，我只说治标的方法：将导航数据里所有关于01/19跑道的数据删除即可。
这个工作量比较大，为了节省大家的时间我会在楼中楼里分享一个我改好的1708的文件。
完，谢谢阅读

另外透露一下，FGPRC正在对FG中777的cdu进行改进，具体情况小李子会在近期向大家发帖说明
另外，虽然说解决了进离场的问题，导航数据依旧是FG的一个大坑。所以，就让我们期待冰姐的bd700来从根本上解决这个问题吧！

悄悄发一张图

厉害了哦

李子搞了好久。

雨后天晴的北京，真美。

围观大佬

坐等hold

dalao

BD700 不用Route Manager。所以BD700的代码只能被BD700使用。但是BD700使用的是比较容易理解，而且具有一定独立性的脚本语言，所以比较容易模仿、借鉴、和移植。
即使在现实中，同一款FMS、GPS，都会有不同的功能得到认证，而且不同认证并不兼容。我飞过一台使用传统机械仪表，没有自动驾驶，但是机载GPS有SID/STAR/APP，而且APP有RNAV/LPV的赛斯纳172飞机。我也飞过一台看着很高大上，但什么屁都没有DO228（唯一的导航设备是VOR和一款具有RMI的磁航向仪）。还有一个例子就是有RNP的767并不表示它就可以使用忽略MDA的程序，也并不表示它的FMC能在RNP进近时自动忽略高度选择。
还有就是上面提到的HOLD。我以前甚至看到这个贴吧里面居然有人说，HOLD必须使用FMC来按，如果使用HDG或者手动驾驶，则是不准确的。我看到之后非常震惊，并且这还是由一个比较资深的飞友提出的。HOLD是基于时间的，而且无论飞机大小速度，统一使用RATE ONE TURN，而且根据程序和转弯方向的不同，还有不同的进入方法，比如直接进入法，平行进入法等等。在现实中，其实是FMS的自动驾驶模仿了***作，***作是FMC操作的超集，而不是子集，所以人当然可以手动驾驶HOLD。而HOLD要编写进FMC中，也不是那么简单的事情。类似的程序转弯，程序转弯的故事，我在另一个帖子中提到过，大家可以去看，是一个讲VOR/DME的精华贴，目前还在首页上，过几天估计就挖不到了。程序转弯和HOLD类似，也是有好几种进入方法。我尝试的一台具有GNS430 GPS的赛斯纳，它只有一种方法，自动使用S型进入法，这是合法的，但不一定合理，如果要把FMS编写更多的程序转弯方法，那也需要一些灵活的算法和代码。
基于以上，我认为Route Manager是模块化和抽象化比较差的一个FlightGear的功能。我从FlightGear的一些以前hard coding的C++代码来看，可能是一些不了解IFR和ATPL的人制作的。如果你制作一个飞机插件，希望能够真实地加入不同认证的功能，应该使用更加灵活的程序设计方法。而遗憾的是，FlightGear Mailing List, Forums里面的管理员和内核程序员经常鼓励飞机插件的开发者使用Route Manager。这样的不正确的指导和误会，使得FlightGear的基于计算机存储数据的区域导航和星基导航等一直处于黑暗年代。
所以，我使用了模块化和抽象化比较好的Canvas和Object Vector来制作。我这样的程序设计理念不仅仅是基于计算机程序设计的基础结构来考虑，还根据了我对IFR的技术、法规、考核的理解。
最后非常感谢楼主在自己的帖子中提到BD700。我希望将来BD700的横空出世，除了能让大家愉快的飞行，还能让今后的开发者带来一些正确的引导和灵感。

FG跟LD有什么py交易