在上一部分的内容中，我们对RAD附件的内容和用途进行了大致介绍，今天来给大家介绍下如何识读数据内容。为了数据的规范严谨，RAD对其中的内容进行了严格的定义，甚至其中的换行和空格都有具体的含义，并且为了避免歧义，增加了部分AIP中从来不会出现的内容，如逻辑关系、使用方式等。下面举个AIP的例子，如果仔细分析，会有很多不确定的内容，如：这个数据指的是TUMAK-ALMOK之间还是L602整条航路？如果是整条航路，为什么不放在中间位置？只能用于飞越DAVUS点离开OBBB并且飞越OKAC且飞越ORBB?还是说仅指飞越DAVUS时候，如果不飞越DAVUS，后续就没有要求？等等……设想下，如果RAD没有一套完整的标准，那么上万条数据就必然会出现海量的不确定因素，这对于用户理解和使用简直就是一场灾难。
惯例，在正式开始之前，需要说明一点，由于RAD其对数据的方方面面都进行了定义，这里不太可能介绍的面面俱到。所以只是结合自己的经验，针对个人认为比较重要的和容易出错的内容进行介绍。分割线下正式开始。
RAD绝大部分数据都是有编号的，这个编号是干什么用的呢？很简单，便于数据维护。同时在IFPS验证出现问题时，提示用户具体是没有满足哪条数据的要求，方便用户查询分析。在RAD附件中，编号由域代码+数字构成，如LF3441。其中区域代码一般是国家、情报区、管制单位缩写(还会包含空域类型，如TSA)，当数据涉及多个区域时，部分数据会将涉及的区域全部写出来，LF即表示法国；数字由1-54999中的任意数字构成，其中每一区间对应不同的附件和用途，例如1-99表示附件4中的不涉及跨区域的直飞部分，8000 - 8999表示附件6中的飞行剖面部分，其中日常涉及最多的Pan-European附件对应的区间为1000-1499和2000-3999，详细说明可参阅APPENDIX1中的说明。
细心的小伙伴可能会发现一个现象，在IFPS验证返回的错误提示数据编号中，除了上述内容外，后面还会有A,B,C之类的字母后缀。出现这些字母后缀的原因是这样的，IFPS系统中存储的数据并不一定会按照文本描述进行存储，对于复杂的数据，会将一条数据拆分成若干条数据，所以仅区域和数字就无法区分了，因此系统会用增加后缀的方式进行描述（即使不拆分，也会默认增加后缀A)。举个例子：
H2105这条数据，我们在PAN EUROPEAN中看到的形式如上，但是在其系统中是被存储成了3条，即
LH2105A=1. Via pt:NEKUL if via pt:INVED；
LH2105B=2. DEP ad:LOWW except via pt: ARSIN and then (pt:BABIT,BAREB)，
LH2105C=3. ARR BUDAPEST_GROUP。
所以当提交验证的航路如果没有满足第3条数据，错误提示返回的编号即为对应的LH2105C。同理，当数据更复杂一些，甚至一种限制方式都不能描述清楚时，系统存储时除了会拆分不同的数据，在文本描述时，也会用虚线加以区分，如下图所示。
H2105这条数据，我们在PAN EUROPEAN中看到的形式如上，但是在其系统中是被存储成了3条，即
LH2105A=1. Via pt:NEKUL if via pt:INVED；
LH2105B=2. DEP ad:LOWW except via pt: ARSIN and then (pt:BABIT,BAREB)，
LH2105C=3. ARR BUDAPEST_GROUP。
所以当提交验证的航路如果没有满足第3条数据，错误提示返回的编号即为对应的LH2105C。同理，当数据更复杂一些，甚至一种限制方式都不能描述清楚时，系统存储时除了会拆分不同的数据，在文本描述时，也会用虚线加以区分，如下图所示。
各位小伙伴在使用系统验证的时候，一定还会遇到返回的提示中不包含数据编号的情况，这又是什么原因呢？因为IFPS验证的数据不局限于RAD数据，最典型的如航路的可用高度，航路是否联通，CDR航路关闭等等。
前面我们反复提到，RAD的数据比较复杂，可能会涉及多个相同或不同类型的要素，即航路点、航段、空域、飞机设备、航班等内容会同时出现在一个数据中。为串联这些要素，就必然需要引入这些要素之间的逻辑关系。举个例子，如果经过A点且经过B点，则C点不可用。“且”就是A和B的逻辑关系。在RAD中，最常见也是最好理解的逻辑关系是：AND/OR/EXCEPT，除了这三种，还有其他的类型，这里就不做逐一的介绍了。如何判断逻辑关系呢？
1. 同一行中的逻辑关系
同一行中的逻辑关系使用明语进行表示。其中大部分数据会用“AND/OR/EXCEPT”来直接说明关系（注意部分数据中会有“AND THEN”的描述，其表示“顺序”关系，并不是“且”的关系）。此外，出现频率较高的词汇是“WITH”，这也表示为AND的关系。而部分相同类型的要素，还会使用“/”或逗号就行连接，这表示“OR”的关系。如下图所示，UL607和UM738之间是OR的关系，LFGA/JL/SC/SG/SN/SO/ST之间也都是OR的关系（PS:在表述机场时候，如果机场四码有相同的字母，RAD会习惯将相同的字母不重复列出，情报区也是如此，还此外会使用通配符“*”）。
2. 不同行间的逻辑关系
如果行与行间没有任何的字母或数字索引及EXCEPT，则行与行间为AND的关系，反之则为OR的关系。如果行间有EXCEPT字样，则表示行与行间为EXCEPT关系。如下面的3个例子：
需要注意的是部分复杂的数据，可以会出现多个层级的情况，即子逻辑关系。这时就需要按照层级关系及上面提到的索引和关键字进行判断了。下面这个例子中，“DEP ad:EDDF”和后面所有内容整体上是AND关系，而“1”和“2”是OR的关系，“1”中的三行间是AND的关系。
翻译过来即为当从EDDF起飞时，满足“1”中或“2”中的条件，即条件为满足。如下图所示：
时间作为重要的数据要素，在RAD中很多和NOTAM相同，这里只针对默认的规则和特殊的表示进行下介绍。
1. 没有单独说明的情况下，RAD中的时间均为UTC时间；
2. 起飞和落地时间的计算是按照预计撤/挡轮挡时间+预计滑行时间计算的。比如A UN888 B Not available for traffic DEP EDDF between 06:00-12:00。假设EDDF的平均滑行时间是10分钟，那么即使预撤轮挡时间为05:51,UN888航路也是不能用于EDDF起飞的。但机场的平均滑行时间并不在RAD中公布，需要另行查询，尴尬不尴尬？-__-
3. 欧洲部分国家实施冬令时和夏令时的转换，所以如果数据中的时间冬令时和夏令时不相同，会用括号进行区分，括号外为冬令时，括号内表示夏令时。欧洲夏令时为每年3月的最后一个周日的01：00开始至每年10月最后一个周日01：00。
4. 和通告类似，如果结束时间是在23：59之后，那么顺延至之后的一天。比如数据中生效时间为：MON-TUE 23:00-01:00，则实际表示为MON 23:00-23:59 TUE 00:00-01:00和TUE 23:00-23:59 WED 00:00-01:00。
5. 个别数据会使用“AIRAC”和“SKI”的描述，即用生效日和滑雪季。如First AIRAC APR-First AIRAC SEP，即表示4月的第一个生效日的第一天到9月的第一个生效日的最后一天。而滑雪季固定指12月的第一个生效日的第一天到3月的最后一个生效日的最后一天。FIRST和LAST的存在也是为了避免歧义，因为一个月当中可能存在多个生效日（如没有修饰，则表示该月不存在这种情况）。
RAD中的很多数据只是针对特定的高度进行限制，而高度也一定会跟随特定的要素，如航路、空域等，不会出现单独的高度要求，如要求飞越空域要求FL300以上，在某个航路点FL300以上等等。但在实际的RAD文档中，没有要素的高度限制却是存在的，这主要是两种情况。
1.该高度指限制对象的高度，并非条件中的高度。如下面的例子，BELOW FL275描述的是GOVEN L735 POGAB航路的高度。原则上，对象和条件中的内容不会重复描述，所以这里省略了对象的重复描述。
2.RFL（Requested FL），即小伙伴中在FPL中希望使用的高度。当数据中出现RFL并且没有具体的要素时，则表示该数据所在整个区域的高度。如下面这个例子，即表示LT区域BELOW FL285。但根据经验，虽然是这样规定的，但是在实际数据后台存储时候，欧控也会把数据存储到特定的航路和航路点上。此外，在IFPS验证时，也会出现命名RFL的高度满足了数据要求，但是验证不能通过的情况。这主要是由于在IFPS系统后台存储了一套简单的性能数据，在判断的高度的时候并不会单纯的按照FPL中的高度来判断。比如说，FPL中A点FL100,B点FL500,而AB两点间距离只有50KM,那么IFPS系统可能会按照B点高度FL110或FL120验证。
面就是个人认为在RAD中比较容易混淆的一些定义和概念，就像文章开头说的，为了数据的严谨，RAD对数据每项内容都会有定义，如空域使用的方式、航段在不同限制下的含义等等，由于篇幅的原因就不做一一的介绍了。RAD是欧洲运行FPL规划的主要限制数据，参阅《欧洲空域使用介绍---RAD部分PART1》 链接 ，其主要内容是PAN EUROPE和7个附件，但这并不是所有RAD的内容，它还包括增量文件（increment file）、EU/EURO限制以及详细的FRA限制，这可能也是为什么有时大家查不到错误数据编号对应的数据的原因。
FPL在欧洲区域正确无误（至少不被拒）需要FPL中的各项内容符合欧控的要求，欧控的要求包含导航基础数据、RAD数据、AUP/UUP等数据，这些数据不但数据量大、结构复杂，变化频繁（定期更新与不定期更新均存在），单纯的依靠人工的方式是不可能确保FPL正确的，这可能也是为什么欧控提供了IFPS验证工具。从另一角度看，欧控之所以设定如此复杂多样的规定，其目的也是为了在保障安全的基础上，最大程度的利用现军民空域资源以满足航班运行的需求。而这实现这一切都是以标准、完整、准确的数据作为基础，可见数据发挥了多么重要的作用。而作为数据维护的主力军，伴随这咱们国家民航的发展，数据的重要性也会逐步提高，空管和公司的情报员小伙伴们肩上的担子也必将更重，任重道远。
欧洲区域的介绍告一段落了，如果各位小伙伴对该区域有其它想了解的内容，可以在我们的公众号下留言。全球其它区域是否也有类似的要求呢？答案是：
未完待续，敬请待续其它区域介绍！
其它区域可能会包含下面内容：
1. 各区域特殊要求
2. 非欧洲区域CDR
3. 编组航路和UPR
……
