GTFS站内资料中的两种关系：父子位置与通道连边为何要分开

GTFS Schedule Reference在stops.txt中列出站点或站台、车站、出入口、通用节点和登乘区等位置类型。parent_station表达这些位置的父子层级：出入口和通用节点以车站为父项，登乘区则以站台为父项，车站本身没有父项。这套层级先说明某个位置属于哪个上层对象，并没有逐条列出人从一个位置走向另一个位置的通道。[1]

pathways.txt与levels.txt的说明转向另一种表示法：位置是节点，通道是边。出入口、站台和通用节点因此可以出现在连接关系中，通用节点还可把不同通道衔接起来。一个登乘区属于某个站台，回答的是层级归属；一条通道从何处开始、到何处结束，回答的则是两端的连接关系。两项资料可同时描述同一车站，但它们保存的关系不同。[1]

具有登乘区的站台尤其体现这种区别。原文把这类站台当作父对象，而非通道中的一个点；通道分别归到它的登乘区。站台仍然在位置层级中存在，其作用却不是代替所有登乘区成为一个共同端点。这样，资料能保留“同属一个站台”和“具体连到哪个登乘位置”两个层次，而不是把较细的位置在父项名称下抹平。[1]

通道也有自己的身份。pathway_id识别一条通道，from_stop_id和to_stop_id分别识别起点和终点。参考文档明确允许不同通道拥有相同的一对端点，并举出两部并列、方向相反的扶梯，以及连接相同位置的楼梯和电梯。端点相同说明它们连接相同位置，并不说明它们就是同一条通道；通道标识保存了端点组合之外的区别。[1]

端点定义又限制了哪类位置可出现：站台、出入口、通用节点或登乘区可被引用，车站本体则被排除；标为stop_access=1的站点也不属于这里的通道端点。父项可以是车站，而一条边的起终点不取车站本体，这正说明父子引用与通道引用各有自己的对象范围，不能只因它们都引用位置标识便混为一类。[1]

方向信息还被分成通行方向与标识文字。is_bidirectional记录通道是单向还是双向；signposted_as是沿起点到终点方向看到的标识文字，reversed_signposted_as则对应反向。两端的位置标识未变，行进方向改变时，可见的导向文字却是另一项资料。这些字段描述的是数据中的方向与名称关系，并非对现实通道开放状态的现场核验。[1]

层信息同样保留了身份与名称的差别。位置中的level_id关联层条目；level_index表示层的相对位置，level_name记录乘客在建筑或车站中看到的层名。原文还说明，同一层条目可供不相连的多个车站使用。因此，共用一个level并不额外产生一条站间通道，层名也不能代替pathways中的边。本文只解释本次采用的静态资料定义，不提供代码、导乘路线或现实无障碍与安全判断。[1]