道路交叉口出入口方向判定看着像是个小问题实际拆开全是细节车从哪条路进来、从哪条路出去、中间拐的是左还是右这三件事直接决定了导航转向提示准不准、交通流量统计对不对、驾驶行为画像像不像。我第一次认真碰这个需求是在做一个驾驶行为分析模块时——要判断司机在路口是正常转弯还是急打方向前提就是先把这个路口到底连接哪些道路、车辆走的是哪条进哪条出算清楚。后来它又出现在路线规划验证、交叉口流量统计、车道级导航回放等场景里。这篇文章把我踩过的坑、验证过的方法、以及可以复用的判定流程完整梳理一遍适合刚接触轨迹数据处理、地理信息分析、智能交通系统的朋友参考。1. 这个需求到底在解决什么问题1.1 一句话说清判定目标先给个明确的定义道路交叉口出入口方向判定就是在已知车辆轨迹和交叉口路网结构的前提下回答三个问题——车辆从哪个方向驶入交叉口、从哪个方向驶离交叉口、以及在这个交叉口内完成了什么转向行为。听起来像是导航软件自动会做的事情但真上手做就知道没那么简单。导航自带的地图匹配是闭环场景它有完整的道路拓扑知道这条路通向哪条路只需要把GPS点投影到最近的link上。而当你拿到的只是一堆裸轨迹没有高精度地图甚至路网数据也是一个简化的节点和边集合时你就得自己想办法。更麻烦的是GPS轨迹在交叉口附近往往乱成一团低速漂移、航向抖动、来回绕圈单靠看轨迹形状根本不可靠。业务上对这个问题的需求通常分两种口径。一种是行为口径我想知道车辆在路口左转、右转还是直行用于驾驶行为分析、安全预警另一种是路网口径我想知道车辆是从哪条路进入、哪条路出去的用于流量统计、路径还原。好的判定方法必须同时回答这两个口径因为转向行为和出入口方向本身是强关联的——左转意味着入口方向与出口方向大概相差90度直行意味着入口与出口方向基本一致。1.2 哪些业务场景会用到它这个能力的应用面比我最初预想的宽很多。做导航和路径规划的人需要它来验证转向引导与真实行驶轨迹是否一致做交通流量统计的人需要它来岔路口分流比例做保险和车队管理的人需要它来判断司机在路口是否有违章行为比如连续变道、急转弯做轨迹数据清洗的人也需要它——当一条轨迹在某交叉口出现异常跳变时先判出门和入口是什么方向才能决定是保留还是修正。还有一个偏冷门但很常见的场景交叉口延误分析。交通工程师要算车辆在路口平均停多久、排队多长前提是知道这个路口边界在哪里、车辆从哪个进口进来、从哪个出口离开。如果没有出入口方向判定只凭GPS速度变化很难区分这辆车是在这个路口等红灯还是它在路口前面就因为拥堵停了下来。我举一个实际遇到的例子。某项目里要给一个十字路口的四个进口分别统计左转、直行、右转比例用来优化信号配时。原始方案是人工对着视频数车后来想用浮动车GPS轨迹来算。结果第一批数据就出了问题因为路口南北向道路和东西向道路交角不是标准的90度而是接近105度和75度用固定角度阈值去判断转向一大批左转车被误判成直行统计出来的分流比例完全不能用。这就是典型的理论方法听着对一到真实路口就翻车的场景。2. 核心思路先建路网模型再谈方向判定2.1 交叉口拓扑与出入口方向的定义在讲算法之前必须先统一一个语言体系什么叫入口方向什么叫出口方向。我自己习惯用一种简化的路网模型也就是 link-node 模型。Node 是交叉口中心点Link 是连接两个 node 之间的道路段每条 link 都带有几何走向和方向角。这里有个关键点一条实际道路可能是双向的。所以在建模时我通常会把它拆成两条有方向的 link一条代表北向南方向一条代表南向北方向。这样每个交叉口的进口道和出口道就有了清晰的天然定义指向交叉口的 link 是进口道从交叉口指向外部的 link 是出口道。节点的方向角我一般取这条 link 在接近交叉口那一段的走向角而不是整条 link 的平均方向角。这是因为道路在接近交叉口时往往有渠化、拓宽、弯道过渡如果用整条路的平均方向角去匹配 GPS 航向角误差可能拉到十几度。尤其在弧形引道的路口这个误差足以导致错配。出入口方向的判定本质上就是回答车辆轨迹在进入交叉口之前航向角最接近哪条进口道 link 的方向角这条 link 就是入口车辆轨迹在离开交叉口之后航向角最接近哪条出口道 link 的方向角这条 link 就是出口。所以整个方法有两个前置条件一是你要有一套至少是粗略的交叉口路网拓扑二是你要有足够干净、频率足够的 GPS 轨迹。两者缺一个后面都做不稳。2.2 转向行为与出入口的映射关系转向行为不是额外信息它是出入口方向派生的。只要算出了入口方向角和出口方向角转向行为就能用两者之间的角度差来定义。我采用的方法是取车辆驶入交叉口前的稳定航向角 h_in再取车辆驶离交叉口后的稳定航向角 h_out然后计算角度差delta_h normalize(h_out - h_in)这里的 normalize 要把角度差映射到 [-180°, 180°] 区间。然后按下面的规则判断角度差区间转向行为|delta_h| 直行阈值如 25°直行delta_h 转向阈值如 30° 且 delta_h 掉头阈值如 150°左转delta_h -转向阈值 且 delta_h -掉头阈值右转|delta_h| 掉头阈值如 150°掉头注意这里的方向约定航向角定义为正北为 0 度、顺时针增大那么角度差为正值是逆时针旋转对应左转角度差为负值是顺时针旋转对应右转。这个约定必须在整个工程里一致不然左右就反了。为什么用驶入前/驶离后的稳定航向角而不是用交叉口内某个时刻的瞬时航向角因为交叉口内部轨迹极具迷惑性。车辆在等待左转时可能先向右打了一点方向让行对向直行车这时瞬时航向是向右的或者在路口中心绕了一个大弧线才转过去轨迹根本不是教科书里的直角。用稳定段航向角相当于只关心进来时朝哪、出去时朝哪把路口内部的摆动全都滤掉了。3. 轨迹数据预处理3.1 GPS 数据质量的门槛在真实工程里轨迹预处理花费的时间往往比算法本身还多。GPS 原始数据在普通城市道路环境下定位精度大约在 3 到 10 米高速环境下误差更大在楼宇密集区、高架桥下、树荫路段可能出现十几米甚至几十米的跳变。航向角精度也受速度影响严重——车速低于 2 米/秒的时候GPS 计算出的航向角基本不可信因为定位点抖动导致的方向变化远大于车辆真实行驶方向变化。所以合格的输入轨迹我一般要求满足三个基本条件采样频率不低于 1Hz最好能到 5Hz 以上否则交叉口内的转向过程可能只有一两个点看不出完整轨迹单条轨迹在交叉口范围内至少要有 3 到 5 个有效定位点少于这个数量就判不了轨迹点要带时间戳和速度字段这两个字段在后面的交叉口范围识别和航向筛选里都是必需的。如果你的数据源不满足其中任何一条不要急着写算法先想办法补数据。我用过低频率30秒一个点的轨迹硬做路口识别准确率惨不忍睹最后老老实实换数据源。另一个需要提前处理的坑是轨迹中的伪静止点。车辆在路口停车等红灯时GPS 点并不会停在一个固定的位置而是围绕某个位置随机漂移漂移半径能达到 5 到 15 米。这些漂移点不会自己标记自己是漂移必须靠速度阈值过滤。我习惯把速度低于 0.5 米/秒的点标记为静态点并在计算航向时把它们排除掉。3.2 航向角平滑与角度环绕处理即使在高频率采样下GPS 航向角依然有噪声。尤其是低速段噪声幅度可以到正负 20 度以上。直接拿原始航向角求稳定值结果波动很大。我常用的平滑方案是滑动窗口平均窗口大小视采样频率而定5Hz 数据用 10 个点2 秒的窗口1Hz 数据用 5 个点5 秒的窗口。但平滑有个绕不过去的坎角度环绕。航向角是环形量0 度和 360 度是同一个方向。如果一段轨迹的航向从 355 度平滑过渡到 5 度直接求平均会得到 180 度完全错误。处理方式有两种一种是先把角度转换成单位向量求向量平均后再转回角度另一种是做角度差分时用 atan2(sin(delta), cos(delta)) 强制归一化。我推荐第二种因为它不只解决了平均问题在后续计算角度差、判断转向时都能用。import math def angle_diff(a1, a2): # 计算 a2 - a1并归一化到 [-180, 180] diff a2 - a1 while diff 180: diff - 360 while diff -180: diff 360 return diff def mean_angle(angles): # 角度平均处理环绕 s sum(math.radians(a) for a in angles) return math.degrees(math.atan2(s, len(angles)))这里有个经验之谈平滑窗口不是越大越好。窗口过大会把真实的转向动作一起平滑掉。车辆在交叉口完成一次左转从打方向到车身摆正通常只要 3 到 6 秒如果平滑窗口超过这个时间航向角变化幅度会被严重压缩左转可能被压成疑似直行。所以平滑窗口必须远小于转向持续时间5 到 10 个点是比较安全的范围。平滑之外还有一个容易忽略的预处理步骤轨迹压缩。如果原始轨迹点非常密集比如某些设备能达到 10Hz路口范围内可能有几十个点直接把所有点拿去算角度会引入大量冗余计算和噪声。我一般用道格拉斯-普克算法做压缩阈值取 2 到 3 米。这能把轨迹抽稀成关键拐点和直行段端点后面识别转向就清爽很多。4. 出入口方向判定算法4.1 交叉口进出范围识别判定出入口的第一步是确定交叉口范围在轨迹上对应哪一段。这里我不会直接用路网 node 的坐标做圆半径判断因为不同等级的交叉口尺寸差别很大支路交叉口两条路加起来可能只有十几米宽而主干道交叉口有渠化岛、展宽段影响范围能到上百米。固定半径必然有的路口圈不全有的路口圈了太多无关路段。更靠谱的做法是利用轨迹特征反推。车辆通过交叉口时通常会有两个明显信号速度剖面出现一个低谷进路口前减速、路口内或停止线前低速、出路口后加速航向角发生持续且稳定的变化直行除外转向车辆在短时间内航向角累计变化超过 30 度。所以我先扫描整条轨迹找速度低谷区间再在低谷区间里检查航向角变化量。如果两者同时满足就初步认定这是一次交叉口穿越事件。然后再把这个事件区间向外扩展向前扩展到进入减速段之前、向后扩展到驶离加速段之后作为交叉口的影响范围。def detect_intersection_events(track, v_low2.0, heading_change_min30.0): events [] # step 1: 找到速度低谷区间 low_segments [] in_low False for i, p in enumerate(track): if p.speed v_low and not in_low: start i in_low True elif p.speed v_low and in_low: low_segments.append((start, i - 1)) in_low False # step 2: 在低速区间中检查航向变化 for seg in low_segments: idx range(seg[0], seg[1] 1) total_change 0 for j in range(len(idx) - 1): total_change abs(angle_diff(track[idx[j]].heading, track[idx[j1]].heading)) if total_change heading_change_min: events.append(seg) return events注意这个检测方法对在路口停车等待但最终直行的情况同样适用因为直行车辆在排队等红灯时航向角变化不大。如果检测到低速区间但航向角变化很小说明这辆车只是在路口排队并没有转向也不算穿越了交叉口——严格来说它只是在进口道上等待。这种情况在排队长度分析里有用在转向判定里需要特殊标记不参与后续入口出口匹配防止把同一段直行道误判成两个方向。4.2 入口方向和出口方向提取确定交叉口影响范围后接下来要做的是提取 h_in 和 h_out。h_in 的取法是取影响范围起点后一段足够长的稳定行驶段通常取 3 到 5 秒的轨迹点计算这些点的航向角中位数。用中位数而不是平均值是因为中位数对个别离群点更稳健。如果有人在这个区间内变道、轻微避让障碍物个别航向离群点不会把结果带偏。h_out 的取法是对称地取影响范围结束点前一段 3 到 5 秒的轨迹点同样计算航向角中位数。这里有几个在实践里验证过的重要细节。第一一定要用离开交叉口后的稳定行驶段来提取 h_out而不能用交叉口内部最后一个轨迹点的航向。因为车辆在路口内的转向是逐渐完成的最后一个点可能还在弧线中间航向角离真正的出口方向差十几度很常见。第二提取稳定段时要检查该段是否有明显的速度波动。如果车辆刚出路口就遇到前方拥堵又减速这段时间的航向可能因反复刹车而抖动需要往后延一段取更稳定的部分。第三如果车辆出路口后立即进入另一个交叉口在路网密集的城市中心很常见会导致 h_out 提取区间混入第二次转向的起始部分。这种情况要把提取窗口压缩取更接近第一次影响范围结束点的 2 秒数据。稳定段的提取逻辑可以写成这样def extract_stable_heading(track, start_idx, window_pts): headings [] for i in range(start_idx, min(start_idx window_pts, len(track))): if track[i].speed 2.0: # 排除低速不可信点 headings.append(track[i].heading) if len(headings) 3: return None # 用中位数抗离群 headings.sort() return headings[len(headings) // 2]4.3 转向行为识别与方向映射拿到 h_in 和 h_out 后转向行为的判定公式已经在上文写过了实际代码就是delta_h angle_diff(h_in, h_out) if abs(delta_h) 25: behavior straight elif delta_h 30 and delta_h 150: behavior left elif delta_h -30 and delta_h -150: behavior right else: behavior uturn但判定出转向不等于判定出出入口方向。转向是行为层面出入口是路网层面。要得到出入口对应的 link需要把 h_in 和 h_out 与交叉口邻接的 link 方向角做匹配。匹配算法很直接遍历所有与交叉口 node 相连的 link对每条 link 计算其方向角与 h_in 的角度差取绝对值最小的那条作为入口对 h_out 做同样的操作取出口。要特别注意的是一条双向道路会拆成两条有向 link比如南北向道路有北向南和南向北两条。它们的方向角相差正好 180 度所以匹配时不会混。def match_link(heading, links): best_link None best_diff float(inf) for link in links: diff abs(angle_diff(heading, link.direction_angle)) if diff best_diff: best_diff diff best_link link return best_link这个方案看起来简单实际有一个隐藏的大坑路网拓扑的错误或缺失。如果路网数据里漏了一条 link或者某条 link 的方向角定义错误匹配结果会直接指向错误的方向。所以在工程落地时我会在匹配后加一道合理性校验入口 link 和出口 link 必须是同一个 node 的邻接 link且它们之间不能跨越其他未经过的 node。如果校验不过说明轨迹可能根本不是在这个 node 处完成的转向需要回溯检查事件分割是否出错。还有一个常见的工程问题h_in 和 h_out 不是哪个环节都能保证同时存在。如果车辆的轨迹起点就在交叉口内部例如设备在路口中心开机h_in 缺失那这条记录只能做出口判定入口标为未知。这种部分缺失情况不要强行补值宁可标未知也不能猜一个入口方向否则流量统计里会平白多出一条幻影路径。5. 复杂路口与特殊场景的识别5.1 环形交叉口的出入口判定环形交叉口转盘是出入口方向判定里的一个硬骨头。车辆进入环岛后会沿着环形道路绕行航向角持续变化直到找到出口驶离。如果按普通交叉口的逻辑取 h_in 和 h_out看起来就像车辆在环岛转了一个大弯角度差可能是 90 度、180 度甚至接近 360 度。这时问题来了环岛内行驶到底算一个交叉口穿越事件还是只是一个连续转弯过程我的处理方式是把环岛单独建模。环岛作为路网中一个 node它的进口道和出口道并不像普通十字路口那样面对面对齐而是通过环岛内的环形 link 连接。在判定时我不依赖环岛内部轨迹的航向角度差而是直接看两个东西进入环岛前的稳定航向 h_in以及离开环岛后的稳定航向 h_out。然后用这两者去匹配环岛的进口 link 和出口 link按 link 之间的拓扑连接关系来确定这是第几个出口驶出。要注意的是环岛场景下不能再用普通的左转右转阈值去给行为定性。一个车辆从南进口进入环岛可能是右转出第一个出口、直行出第二个出口、左转出第三个出口而它在环岛内的航向变化可能是顺时针转了 45 度、135 度、225 度。如果硬套普通路口的角度差规则结果就全乱套了。所以环岛场景一定要走进口 link 出口 link 环岛内连接关系的完整判定链路而不是简化成角度差。5.2 掉头行为的识别难点掉头在普通交叉口发生的频率不高但一旦发生识别失败的代价很大因为它会直接破坏后续的路径还原逻辑。掉头的航向角变化约 180 度看起来像左转又像右转具体看驾驶员操作习惯。有人是先向左打方向再倒一把有人是绕一个大 U 型弯。单靠航向角差很难区分掉头和连续左转加左转两条轨迹的 h_in 和 h_out 可能完全一样。我用的是两个补充信号。第一个是时间掉头通常需要 10 到 20 秒比一次普通左转3 到 6 秒长很多。第二个是轨迹形状掉头轨迹在交叉口内会形成一个明显的 U 型或鱼钩型中间段的航向角变化是单调的、连续的不会出现左转后恢复直行再左转那种中间稳定段。实操中我会在判定掉头时加上一个约束检查交叉口影响范围内是否存在一个中间点使得到这个点的累计航向变化超过 150 度且从这点到影响范围结束还有一个方向相反的持续变化。满足这个条件就标成掉头不满足就拆成两次转向。5.3 多岔路口与不规则交叉口的动态阈值我前面给出的角度阈值直行 25 度、转向 30 度、掉头 150 度是基于标准十字路口的经验值。但真实路网里有大量不规则的交叉口五岔路口、Y 型路口、斜交路口每条分支之间的夹角可能差异很大。一个 Y 型路口三个分支方向分别是 0 度、45 度、120 度车辆从 0 度分支进来从 45 度分支出去角度差只有 45 度按标准阈值会被判成左转但从路网拓扑看它可能是直行方向的分叉语义上更接近直行。解决思路是让阈值跟着路网走。在匹配出候选出口 link 后不直接用全局角度差判断转向而是先计算所有候选出口 link 与入口 link 的方向角差集合再根据集合分布动态确定直行应该对应什么角度。例如入口 link 方向角是 0 度邻接出口 link 的方向角集合是 [45 度, 120 度, 180 度]那么 45 度出口的语义就相当于这条路上的直行或近直行120 度出口对应左转分支180 度出口对应另一个方向。这是我在处理不规则路口时的一个核心体会不要死守左转 90 度、右转 90 度的教科书假设要基于实际路网结构重新定义每个出口的转向语义。黄线标线、导流岛、渠化车道这类信息如果路网数据里有也可以用来辅助确认但初级工程先靠 topology 本身就能解决大多数问题。6. 常见问题与排查技巧实录6.1 航向突变导致转向误判有一种非常典型的误判轨迹明明是一路直行通过路口却被判定成一次转向。排查后发现问题通常出在航向平滑不足。车辆在高速直行时GPS 航向角本身就有 3 到 8 度的随机噪声如果恰好遇到卫星信号遮挡个别点的航向误差能到 20 度以上。这些噪声叠加在低速段的抖动上可能让 h_in 和 h_out 出现 30 到 40 度的假偏差刚好超过转向阈值。解决方法是两层的。第一层是数据层面把航向平滑窗口适当放宽并在计算 h_in 和 h_out 时排除速度低于 2 米/秒的点。第二层是算法层面增加一个转向连贯性校验要求交叉口影响范围内存在连续 3 个以上轨迹点其航向变化方向与判定结果一致。直行误判成左转的情况往往路口内航向变化是杂乱无章的连贯性校验能直接拦下。6.2 低速漂移把路口范围撑大另一个高频问题是车辆在交叉口等红灯时GPS 漂移点会散落在路口中心甚至对面车道上把交叉口影响范围撑得很大导致 h_in 提取段跑到上一段路h_out 提取段跑到下一段路最后角度差莫名其妙变成 180 度判成掉头。这个问题的排查思路很简单把轨迹点和路网叠加画出来你会看到漂移点明显偏离道路中心线形成一个扇形散点群。处理方式有两种。一种是基于道路缓冲区的点过滤把距离最近 link 超过 20 米的点剔除不参与任何计算。另一种是基于密度的聚类在交叉口范围内把所有点按位置聚类取主簇作为有效轨迹次簇和离群点剔除。我用得比较多的是第一种因为实现简单且稳定。6.3 相邻交叉口距离过近时的误分割城市里经常出现两个交叉口之间只隔几十米的情况比如一个 T 型路口后面紧接一个十字路口。车辆刚完成第一个路口的转向还没把车身摆直就又进入了第二个路口。这时事件分割算法很容易把两个路口的轨迹合并成一次穿越导致 h_out 取到第二个路口内的航向匹配结果完全错误。我的处理经验是在做事件分割时不要只用速度低谷和航向变化还需要引入路网距离约束。具体做法是在确认一个交叉口事件后以当前 node 为中心检查事件结束点是否已经超出该 node 的一定范围比如 80 米。如果已超出说明轨迹可能已经进入下一个 node 的邻接范围此时要主动拆分成两个事件并重新分别在两个 node 上做入口出口匹配。这个距离阈值需要根据当地路网密度调整路网密集区域设小一点稀疏区域设大一点。6.4 常见问题速查表现象可能原因处理方案直行被判成左转航向噪声叠加平滑不足扩大平滑窗口剔除低速点加转向连贯性校验左转被判成直行平滑窗口过大转向过程被压平缩小窗口确保窗口远小于转向持续时间掉头频繁漏检只用了角度差没看时间和轨迹形状增加 U 型轨迹形状检测和时间约束出入口 link 匹配反了双向道路被当成单向 link 的语义错误核对 link 方向角定义确认有向 link 拆分环岛场景一团乱用直线路口阈值套环岛单独建模环岛按进出口 link 拓扑判定停车等待被当成穿越低速段航向变化小却仍触发事件增加最小航向变化量阈值排队等待不判穿越两个路口距离过近事件分割把两段轨迹合并按 node 范围主动拆分重新匹配7. 工程落地的一点经验最后分享几条我在实际项目里沉淀下来的经验不算系统性方法论但能帮你少走很多弯路。第一阈值不要拍脑袋定。直行阈值、转向阈值、路口范围半径都应基于实际路网和轨迹数据标定。最直接的办法是选两三个典型路口人工标注一批通过轨迹的真值数据然后用网格搜索找最优阈值组合。我见过有人直接用网上文章里的阈值到了高架下、隧道口就大量误判原因就是没有用本地数据重新标定。第二把未判定当成一个合法的输出。不是所有轨迹都能被可靠判定GPS 信号丢失、极端驾驶行为、路网数据缺失这些情况总会存在。与其硬给一个错误结果不如输出unknown让下游环节决定怎么处理。这在统计场景里会留下明确的误差记录而不是污染数据集。第三路网数据质量是上限。算法再精细也补不了路网的洞。如果你发现大量出入口匹配失败先怀疑路网数据而不是怀疑算法。多花时间在 link 几何修正、方向角纠错、node 合并上收益远比优化角度阈值大得多。第四可视化是调试的第一工具。我写算法时会把轨迹、link、判定结果、交叉口范围全部画在地图上标签标出 h_in、h_out、匹配的 link id。任何一次误判画出来看一眼基本就能定位原因。纯看日志调试这种空间数据问题效率太低。这个方法后续还能往几个方向扩展如果轨迹里有车载陀螺仪或方向盘转角数据转向行为的置信度会大幅提升如果路网升级为车道级出入口判定还能细到从哪个车道进入、从哪个车道驶离。基础方法搭好之后往上加能力都是水到渠成的事情。