道路交叉口出入口方向判定：拓扑几何与转向关系工程实践-北京尧图网络

1. 先把问题定义清楚道路交叉口出入口方向判定到底在判什么做路网数据处理的人大概都遇到过这种尴尬时刻导航在路口播报“请靠左行驶”实际该往右拐交通仿真跑出来的左转流量和现场人工调查差了将近一倍明明是个规规矩矩的十字路口脚本却识别出了六个进口道。这些问题追到根上十有八九都指向同一件事——道路交叉口出入口方向判定没有做对。说得直白一点这个活干的就是把“某条路段从哪个方向接入某个交叉口、又是从哪个方向离开”这件事从一堆坐标和拓扑关系里给推出来然后标成机器能读懂的字段进口道有几条、分别是哪个方位、每条进口道对应哪几个出口道、每一次穿越是直行、左转还是右转、掉头。听起来是个纯几何问题画个圆、量个角度就完事。真上手做过的都知道难度不在公式在数据和场景。路网的拓扑表达和实际道路几何经常打架双向分离的主干路在数据里画成两条单行线环形交叉口在拓扑上可能是七八个节点串起来的环立交匝道在地面投影上和主路重叠渠化岛的偏移量能让方位角整体偏出十几度。这些细节一个处理不好后面所有的转向统计、信号配时、路径播报全部跟着歪。这篇内容面向三类人一是做路网数据生产与质检的手上有海量矢量路网要批量标注交叉口属性二是做交通仿真和交通分析的需要把转向流量和路段流量对上三是做路径规划、导航播报、自动驾驶地图的需要精确到车道的进出方向语义。不管你手上是几万条的市级路网还是几十条的重点片区精细路网判定逻辑是同一套只是参数和容差要跟着调。下面我按“先讲清概念、再拆拓扑、再算几何、然后给一套能跑的流程、最后扒疑难场景和坑”的顺序往下走。参数怎么定、半径为什么取这个数、公式为什么这么写我都会把理由说透方便你按自己的数据规模和精度要求去改。1.1 进口道、出口道、转向关系三个必须拆开的概念很多人第一版代码写歪就是把这几个概念揉在一起了。它们的数据结构、计算方式和用途完全不同必须先拆开。进口道approach指的是车辆驶向交叉口的那一侧分支。放在有向图里就是“终点指向交叉口节点”的那条边。一条双向道路在交叉口处会产生两条方向相反的边其中一条是进口道另一条是出口道。出口道departure指的是车辆驶离交叉口的那一侧分支对应“起点是交叉口节点”的边。转向关系turn movement是进口道和出口道之间的一对组合比如“东进口左转至北出口”。一个标准的四路交叉口理论上能产生 4×312 个合法转向不包含掉头如果算掉头就是 16 个。工程上统计转向流量、做信号相位设计用的就是这一层的粒度。三者关系可以用一张表摆清楚概念拓扑定义关键属性典型用途进口道to_node 为交叉口节点的边方位角、车道数、车道功能进口道流量、排队长度分析出口道from_node 为交叉口节点的边方位角、车道数、下游路段容量通行能力校核、溢流判断转向关系进口道与出口道的配对转向类型、转角、冲突点数信号相位、转向流量矩阵拆开之后你会发现前两个是“单体属性”第三个是“组合属性”。工程上翻车最多的往往是第三个进口道和出口道都标对了但配对规则写错了最后把右转配成了左转流量统计整个反掉。提示转向关系一定要有唯一标识建议用“进口道ID_出口道ID”的复合键不要用方位角命名否则方位角一改历史数据全对不上。1.2 一个判定结果会影响到哪些下游环节方向判定不是一个孤立的标注任务它在整条数据链上属于“中间层”。上游是路网几何和拓扑下游是一大批业务场景判定结果一旦偏了下游全部跟着偏而且很难反查。第一类是转向流量统计与流量分配。交通调查拿到的往往是路段断面的流量要拆成转向流量必须知道每条进口道能去哪几个出口道以及各转向的比例。这里方向判定是分母错了之后流量矩阵不守恒下游的 OD 反推会直接崩。第二类是信号配时与渠化设计。左转保护相位的设置前提是识别出真实的左转进口道如果某条进口道被判成了直行相位方案就会漏掉这一股现场表现就是左转排队溢出、直行空放。第三类是路径规划与导航播报。这里用的是“相对方向”而不是“绝对方向”。同样一条出口道从东进口过来是左转从西进口过来就是右转。播报出错的根本原因往往是把进口道方位角当成了转向方向而不是用相对转角去算。第四类是交通仿真与安全分析。仿真软件要建连接器connector进口道和出口道的连接关系错了车流就会穿墙事故黑点分析要统计冲突点方向判定错了冲突点的数量和类型全是假的。第五类是自动驾驶与高精地图。这一层对精度的要求高一个量级因为它要的是车道级的进出方向不是路段级的。路段级判定的结果只能作为先验车道级的还得再做一轮。看明白这个影响范围你就知道为什么值得在这件事上花时间把参数和边界情况抠细——它不是一个可以“差不多就行”的环节。1.3 判定结果的两种输出口径工程上最终交付的结果通常有两种口径选哪种取决于下游怎么用。第一种是绝对方位口径每条进口道标一个 0 到 360 的方位角外加一个八方位标签北、东北、东……。这种口径简单适合做可视化和快速检索但有个明显缺陷——斜交路口会归错档。一个偏北偏东 40 度的进口道归到“东北”还是“北”不同的阈值会给出完全不同的结果。第二种是相对序列口径把某个交叉口的所有分支按方位角顺时针排序然后给每条分支标一个序号。转向关系直接用序号差来计算。这种口径对畸形路口友好得多五岔路口、六岔路口都能处理代价是不能跨交叉口直接比较。我的建议是两个都存。绝对方位角用于展示和初筛相对序号用于计算转向。存两份的成本很低但省掉的返工时间非常多。2. 路网拓扑视角方向信息到底藏在哪一层几何算角度是最直观的思路但如果你手上的数据是有向图很多信息其实在拓扑里已经写好了先从拓扑里取比先算几何要稳得多。这一节讲清楚拓扑层能给出什么、给不出什么、以及和几何冲突时该信谁。2.1 有向图建模的四条基本约定在动手之前必须把数据模型的约定固定下来后面所有代码都依赖这四条。第一节点和边的方向定义要说清楚。一条边从 from_node 指向 to_node这在数学上是“车辆可以从 from 开到 to”。这个方向必须和实际通行方向一致不能是“绘制方向”。我见过不少数据里绘制方向和通行方向是反的单行道的方向属性没有同步结果进口道和出口道整体反号。第二交叉口节点的判定标准要明确。最朴素的判据是节点度degree大于等于 3也就是至少有三条边相连。但这个判据会漏掉一类情况两条道路在同一个位置交汇但没有连通比如高架和地面拓扑上会表现为两个独立的二度节点叠在一起看起来不像交叉口实际是个立交。反过来一条道路中间因为分段被打断会造出一个虚假的二度节点。第三双向道路的表达方式要统一。到底是“一条边加双向属性”还是“两条方向相反的边”这两种表达在数据处理上的差别非常大。前者省存储但转向计算时要临时展开后者直观但容易在匹配时把两条边当成两条不同的路。建议在判定阶段统一展开成双向边算完再合并回去。第四特殊节点的处理规则要事先定。环岛节点、掉头节点、匝道分流点、收费站节点这些在多处逻辑里都需要特判最好在数据模型里用一个类型字段标出来别指望算法自己去猜。这四条约定确定下来之后“方向”这件事在拓扑层就有了明确含义一条边是进口道还是出口道看它的端点和交叉口节点的连接关系就行不需要算角度。这是最可靠的一层判据几何计算只是用来补充方位信息的。2.2 拓扑方向与几何方向打架的三种典型场景理论上拓扑和几何应该是一致的实际上不一致的比例比想象中高。以下三种是出现频率最高的。第一种边被截断或拉长。为了表示渠化段或者转向车道一条边可能在交叉口内部就开始了也可能延伸到交叉口中心很远的位置。前者会导致方位角算出来偏向内部后者会导致方位角算出来偏向外部。判定时如果直接从边的起终点算角度就会引入系统偏差。第二种分离式道路的两条边距离不一致。主干路上下行分离两条边相隔十几米但它们接入交叉口的节点可能是同一个也可能是两个。如果是两个节点那这个位置其实是个“微型环”两条边各自形成一个独立的小交叉口转向关系要跨节点才能连起来。第三种辅路、匝道与主路的并行段。主辅路在同一条走廊上并行几百米几何上方位角几乎完全一样只有几度的差异靠角度阈值根本分不开。这种情况必须靠拓扑的父子关系或者车道数、限速等属性来辅助区分。遇到冲突时我的处理原则是以拓扑为准几何只做补充和校验。拓扑告诉你“能不能走”几何告诉你“往哪个方向走”。前者是硬约束后者是软信息。宁可方位角偏几度也不能把连接关系搞错。2.3 双向分离、主辅路与上下线的拓扑表达这三类结构是路网数据里最容易出问题的值得单独说。双向分离的典型处理方式是把上下行画成两条独立的单行边各自有自己的节点。这种情况下交叉口实际上是两组节点中间隔着一个较宽的中分带。判定时如果按“节点度大于等于 3”来找交叉口会找到两个各带三四个分支的节点而不是一个完整交叉口。解决办法是用空间聚类把距离小于阈值一般取中分带宽度10 到 20 米的节点合并成一个“交叉口实体”然后把两个节点的分支都挂到这个实体下面。主辅路并行的处理关键是分清主路分支和辅路分支。方法有几个看车道数和限速的差异看两条边与交叉口中心距离的差异辅路一般更靠外看是否有连接匝道。我一般会先按距离把靠内的判为主路靠外的判为辅路再用属性做交叉验证两者不一致的挑出来人工看。上下线高架与地面在二维平面上完全重叠纯几何方法无解。必须依赖高程字段或者数据里的层级字段level/layer。如果这两个字段都没有那就只能靠连通性推断高架和地面之间连通的节点只有上下匝道其余位置虽然平面相交但不能通行所以拓扑上是不连通的。用连通分量分析能大致把两者分开。这三类结构处理完之后你会发现“交叉口”这个概念在数据里其实是一个聚合实体不是单个节点。后面所有的角度计算都建议在这个聚合实体的层面上做而不是在单个节点上做能避免一大半的重复分支问题。2.4 先拓扑后几何的互校流程我给一个我常用的互校流程比较土但管用。第一步按拓扑关系把每个交叉口实体的所有进口道和出口道列出来形成候选分支集合。这一步不看角度只看连接关系。第二步对每条候选分支算方位角下一节讲怎么算然后顺时针排序。第三步检查排序结果是否符合“相邻夹角大致均匀”的预期。标准的十字路口四个分支的理想夹角是 90 度。如果出现两个分支夹角小于 8 度几乎可以断定是同一条路的重复表达如果出现一个超过 180 度的空档说明可能漏了分支。第四步把不符合预期的交叉口挑出来落到一个人工核查清单里。数量一般不会超过总量的 5%是可以接受的。这个流程的好处是把问题暴露在早期。很多人的做法是直接跑完整套判定最后发现某类数据有问题再回头查成本高得多。3. 几何计算方位角算准的关键细节几何这一层看着简单实际上参数没定好误差会一路放大。这一节把坐标系、公式、半径、阈值这几个关键点挨个说透。3.1 坐标系与局部投影的取舍附一个误差估算方位角计算的第一件事是决定在什么坐标系下算。三个选项地理坐标系经纬度、投影坐标系平面米制、局部等距近似。直接在经纬度上算 atan2(dlon, dlat)在中高纬度会出明显偏差。原因很简单经度一度的实际长度随纬度变化纬度 φ 处经度一度约为 111320×cos φ 米纬度一度约为 110574 米。在北纬 40 度附近cos40 约为 0.766经度方向被压缩了约 23%。举个具体的例子。一条真实方向为 45 度的边在平面上 dxdy。如果用经纬度差直接算dlon 的数值会比真实值大 1/cos40 约 1.306 倍算出来的角度变成 atan2(1.306, 1)约为 52.6 度偏了 7.6 度。这个偏差已经接近甚至超过左转和右转的判定边界绝对不能用。正确的做法是投影到平面坐标系或者做等距化修正。等距化修正很简单把经度差乘以 cos(中心纬度)纬度差保持不变直接得到以米为单位的近似平面坐标。在几公里的范围内这个近似的误差可以忽略。import math def lonlat_to_local_xy(lon, lat, lon0, lat0): 局部等距近似以 lon0/lat0 为原点返回米制平面坐标 R 6378137.0 x math.radians(lon - lon0) * R * math.cos(math.radians(lat0)) y math.radians(lat - lat0) * R return x, y如果数据量不大直接用正式的投影坐标系更省心。选投影时注意两点一是投影带的中央经线要接近数据范围的中心二是在同一个工程内不要混用多个投影带否则跨带拼接时会出现断裂。对于城市级数据一个投影带基本够覆盖。顺便提一句数据本身的精度。如果坐标精度是正负 1 米在 50 米的计算半径上角度误差约为 arctan(1/50)也就是 1.15 度左右。这个误差是可接受的。但如果计算半径只有 10 米同样的坐标精度会带来约 5.7 度的角度误差这时候左转和直行的边界就变得很模糊了。这就是为什么计算半径不能取得太小的核心原因——半径越小坐标精度带来的角度不确定性越大。3.2 方位角与转角公式的推导先把定义固定下来方位角从正北起顺时针为正范围 0 到 360。这和水文、气象里的方位角一致也和大多数导航数据的约定一致。给定一条从点 A 到点 B 的边方位角公式def bearing(x1, y1, x2, y2): dx x2 - x1 dy y2 - y1 return (math.degrees(math.atan2(dx, dy)) 360.0) % 360.0注意这里 atan2 的参数顺序是 (dx, dy)不是 (dy, dx)。写反了得到的角度会整体旋转 90 度而且不会报错是最容易埋雷的地方。建议写成函数后拿四个方向各测一次正北 dx0, dy0 应得 0正东 dx0, dy0 应得 90正南应得 180正西应得 270。测过一遍再往下走。再定义每条分支的方位角 b_i含义是“从交叉口中心指向该分支远端的方位角”。转向角的推导基于一个关键认识车辆从分支 i 驶入时它的行驶方向是 b_i 180因为它是朝中心开的车辆从分支 j 驶出时它的行驶方向是 b_j因为它是背离中心开的。所以转向角就是turn (b_j - (b_i 180)) 归化到 (-180, 180]稍微整理一下turn normalize180((b_j - b_i) - 180)。其中 normalize180 把任意角度归化到 (-180, 180] 区间。这个公式值得用四向十字路口验算一遍我按北、东、南、西四个分支方位角分别为 0、90、180、270 来推从南分支驶入b_i 180车辆实际朝北开。若驶向北分支b_j 0turn (0-180)-180 -360归化后为 0判为直行正确。若驶向东分支b_j 90turn (90-180)-180 -270归化后为 90判为右转 90 度正确。若驶向西分支b_j 270turn (270-180)-180 -90判为左转 90 度正确。若在同一条分支掉头b_j 取 b_i180 的等效值turn 为 180 或 -180判为掉头正确。公式验证通过。这个推导看着啰嗦但写清楚之后后面所有的转向归类都是它的一行判断不会再有歧义。def normalize180(a): return (a 180.0) % 360.0 - 180.0 def turn_angle(b_in, b_out): b_in/b_out 为分支方位角返回 (-180,180]正为右转负为左转 return normalize180((b_out - b_in) - 180.0)3.3 计算半径 R 怎么定以及一个自适应的取法半径 R 决定了从哪里取点算方位角。取小了坐标误差被放大取大了会把交叉口外的道路弯曲也带进来。这个参数没有通用最优值得按道路等级定。经验区间是这样的城市主干路交叉口渠化段长度一般在 30 到 60 米R 取 40 到 60次干路 R 取 25 到 40支路 R 取 15 到 25。这些数字不是凭空来的红色渠化段的长度本身就由交叉口的设计车速和车道数决定R 取在这个区间内取到的点基本还在交叉口的直线段上不会跑到弯道上。固定值有局限我更推荐一种自适应取法从交叉口中心做一个 60 米的缓冲区对每条分支取它落在缓冲区内、距中心最近的那个点作为候选点记下这个距离 d。正常情况下 d 应该在几米到十几米之间。如果某条分支的 d 超过了 40 米说明这条边在缓冲区内的部分离中心很远可能是渠化段外侧才开始画或者这条边本身就不属于这个交叉口需要标记出来核查。还有一种更稳的做法是取每条分支上“距离中心最近点”再往外延伸一段固定长度比如 20 米作为第二个点用它和中心点连线的方位角作为分支方位角。这样即使最近点落在交叉口内部方位角也不会被内部几何带偏。注意无论用哪种取法都要保证同一个交叉口的所有分支用同一种取法。混用会产生系统性偏差而且很难在结果里看出来。3.4 排序、聚类与重复分支合并拿到所有分支的方位角之后先按从小到大排序得到一个顺时针的角度序列。这个序列是后面所有判定的基础。排序之后要检查两件事。一是相邻分支的最小夹角。如果两个分支的夹角小于 8 度大概率是同一条路的重复表达或者是主辅路的并行段。处理方式有两种直接合并成一条保留车道数更多的那条或者都保留但在属性里标上父子关系。我倾向于后一种因为主辅路在转向关系上确实算两股不同的车流合并了会丢信息。二是最大空档。如果两个相邻分支之间的夹角超过 200 度说明这个方向可能漏了分支。常见原因是数据里有一条边没有正确连到这个节点或者某条路在数据里是断头路。这种情况要回拓扑层去查不能交给几何算法硬补。除了排序还要考虑一种特殊结构同一个方向有两条分支但角度差在 20 度以内又确实存在。这是畸形的锐角交叉比如两条支路以 15 度的夹角接入主干路。这种路口在实际中不少见尤其是老城区。处理的时候不能简单合并得保留两条把转向阈值相应放宽或者干脆把这类交叉口标记为“需人工处理”走人工校正流程。4. 一套可复现的判定流程前面讲的是原理这一节给可执行的流程。我按数据准备、节点识别、分支筛选、方向计算、转向归类、批量落库的顺序走每一步都给字段要求和判断标准。4.1 输入数据的最小字段集不管数据源是哪种格式判定阶段至少需要以下字段字段类型必要性说明edge_id字符串必需边的唯一标识from_node字符串必需起点节点IDto_node字符串必需终点节点IDgeometry线要素必需边的几何含起终点坐标oneway布尔必需是否单向决定是否展开反向边road_class枚举建议用于选半径和阈值lane_count整数建议用于主辅路区分和流量分配level整数建议用于立交分层没有就靠连通性推断speed_limit整数可选辅助判断主辅路这份字段表里最容易被忽略的是 level。很多团队在建库时不存这个字段等到处理立交时才发现无解只能回头补采。如果数据源本身没有分层信息建议在入库阶段就人工标注一遍成本远低于后期修补。数据准备阶段还要做一次方向校验随机抽 20 条单行道检查它的几何起终点方向和通行方向是否一致。不一致的比例如果超过 1%说明整批数据的方向属性都不可靠必须先做全局校正否则后面全白干。4.2 交叉口节点的识别与聚合识别分两步先按节点度数找出候选再做空间聚合。候选识别比较简单统计每个节点的度数度数大于等于 3 的进候选集。同时把度数等于 1 的节点断头路端点和度数等于 2 但几何有急转弯的节点单独标记这两类经常是数据截断的产物不是真交叉口。聚合这一步是重点。把距离小于阈值的候选节点聚成一簇作为一个交叉口实体。阈值怎么定按道路宽度估。两条双向四车道主干路相交中分带加两侧车道两套节点的间距在 15 到 25 米之间。所以阈值取 25 米比较保险但要注意副作用如果两条独立的支路在这个距离内有各自的交叉口会被误合并。为了避免误合并可以加一个连通性校验只有聚合后两个节点之间确实存在可通行的连接才认为是同一个交叉口实体。如果两个节点之间没有任何边相连它们就是两个独立设施只是空间上离得近。聚合完成后每个交叉口实体有一个中心点用所有节点的坐标取均值或者用几何重心和一组挂载的分支。后面的角度计算都以这个中心点为基准。4.3 分支代表点提取与候选集精简拿到交叉口实体和它的所有分支之后要对每条分支提取一个代表点用来算方位角。我的做法是沿分支的几何从交叉口端向外走取第一个距离中心超过最小阈值比如 12 米的点作为代表点。取 12 米这个下限是为了避开交叉口内部的转弯圆弧和渠化岛上限则用 3.3 节讲的自适应规则控制。提取完之后还要做一次精简。有几类分支需要剔除或特殊处理长度极短的分支小于 5 米大概率是数据切分产生的碎片不参与方向计算。连接关系不完整的分支比如 to_node 指向自身或者指向一个不存在的节点。明确标注为内部连接的分支比如环岛内部的绕行段、立交内部的连接匝道。精简之后剩下的分支集合就是一个干净的、可供计算的输入。这一步的精简日志要保留下来方便后面追查某个分支为什么没被识别出来。4.4 方位角计算与进口道/出口道标注这一步就是套公式。对每条分支用中心点和代表点算方位角同时根据 to_node 是否等于交叉口节点来判定进口还是出口。有个细节要处理如果一条双向道路在数据里只有一条边没有展开成两条那么这条边对交叉口来说既是进口又是出口。这种情况下要给两个方位角进口方位角是 b_i 180出口方位角是 b_i两者相差 180 度。很多人在这里搞错把同一个方位角同时用于进出结果转向角全错。另一个细节是自环边from_node 等于 to_node。这类边在掉头节点上很常见方位角算出来可能是任意值必须单独标记不能进入常规的转向计算流程。计算完之后每个交叉口实体应该有一张表长这样分支ID方位角类型车道数道路等级E102312.4进口道3主干路E104198.7出口道3主干路E1055186.2进口道2次干路E1070271.5出口道2次干路拿来和实际情况对一遍如果北侧进口道方位角在 0 附近、东侧出口道在 90 附近基本就对了。4.5 转向归类与左右转映射拿到方位角表之后转向归类就简单了。对每一对“进口道 i 出口道 j”的组合算出转角然后按阈值分类。阈值推荐用下面这一套适合城市道路的常规交叉口转角范围度判定备注-180 至 -150 或 150 至 180掉头极少数路口允许需单独标-150 至 -30左转含大角度左转-30 至 30直行含小角度偏转30 至 150右转含大角度右转接近 ±180对向掉头需结合掉头规则判断是否合法这套阈值对正交路口很好用但斜交路口会有问题。斜交路口的“直行”实际转角可能到 40 度而“左转”可能只有 120 度。这时候如果用固定阈值就会把直行判成右转。解决办法是改用相对序列判断把该交叉口的所有分支按方位角排序对进口道 i它顺时针方向的下一个分支是“最左”的出口逆时针方向的下一个分支是“最右”的出口。然后按序号差来判断。序号差为 1 或 -1 的是相邻转向序号差为 2 或 -2 的是跨越一个分支的转向。这套逻辑对任意分支数的交叉口都成立不依赖绝对角度。实际工程中我一般两种方法都算然后比对。不一致的挑出来人工看往往是畸形路口本来就需要人工确认。4.6 批量执行与结果落库流程跑通之后要考虑工程化的事情。性能方面千万级别以上的边直接两重循环会跑到天荒地老。核心优化是用空间索引R-tree 之类的结构先把每条边可能归属的交叉口筛出来把复杂度从 O(N×M) 降到接近 O(N)。另外方位角的计算是可以向量化的用数组运算比逐条循环快一个数量级。存储方面建议分三张表交叉口实体表、分支方向表、转向关系表。交叉口实体表存中心点、分支数、类型分支方向表存每条分支的方位角和进出标识转向关系表存进口道和出口道的配对。三张表用外键关联查询和更新都方便。版本管理方面每次全量重算都要打一个版本号并且记录下本次用的参数半径、阈值、聚合距离。这一点很容易被忽略但当你三个月后发现某批数据有问题、需要回溯是哪次改动引入的时候没有版本记录就只能全部重跑。5. 疑难场景专题这几类路口最容易翻车标准十字路口占不到全部交叉口的一半真正耗时间的是剩下的那些。这一节挑五类高频场景逐一说清楚处理思路。5.1 环形交叉口拓扑是一个环不是一个点环岛的问题在于它没有传统意义上的交叉口节点。车辆驶入环岛、绕行、驶出整个过程在拓扑上是一串节点和边构成的环而不是一个汇聚点。判定的思路分三层。第一层识别环岛。特征是存在一个闭合的边序列每条边的长度都不长通常 10 到 50 米整体形状接近圆形或椭圆且周边的道路都只和这个环相连不穿过环。第二层把环岛外部的分支挂到环上。每个外部接入点就是一股进环或出环的车流。方位角取的是外部道路的方向不是环上切线的方向。这一点特别容易搞错——取环上切线的话所有分支的角度都会偏向环的方向算出来的转向全是错的。第三层转向关系不能用直接的进口到出口配对必须经过环。逻辑是“进环分支 → 环上绕行 → 出环分支”。判定时要看绕行方向顺时针还是逆时针取决于当地通行规则再根据进环点和出环点的相对位置判断是第几个出口。环岛的转向统计和普通交叉口完全不同不能共用一套表结构。我建议给环岛单独建一类实体用“进环分支数”和“出口序号”来描述别硬塞进普通转向表里。5.2 斜交与五岔以上畸形路口斜交路口的困难在于固定角度阈值失效。四条分支但夹角是 60/120/60/120 的路口用标准阈值去判会有相当一部分转向被归错类。处理办法前面提过用相对序列代替绝对角度。具体做法是对进口道 i从它的方位角开始顺时针扫描遇到的第一个出口道标为“右转首选”第二个标为“直行首选”第三个标为“左转首选”。这个映射在任意形状的路口上都成立因为它只依赖分支的相对顺序不依赖角度绝对值。五岔以上的路口还要多一层判断分支数超过 5 时序号差为 2 的两个分支之间可能隔着两条路实际驾驶时这未必是“直行”。这时候需要结合车道功能数据来判断——如果某条进口道的车道功能标注为“直行右转”那它的直行出口就在相邻的两个方向里挑不能机械地按序号差算。对于分支数超过 6 的路口我建议直接进入人工处理流程。这类路口数量很少自动化收益极低硬做算法的性价比不高。5.3 立交、匝道与主辅路交织段立交是二维几何彻底失效的地方。上跨和下穿在平面上完全重叠方位角一模一样靠几何完全分不开。处理的关键是分层。如果数据里有 level 字段按层把边分组同层之间才算连通跨层只通过匝道连通。如果没这个字段用连通性分析把整个路网按“是否可达”切成连通分量上跨和下穿的连通分量不同能自然分开。匝道的处理要特别注意方位角的意义。匝道在入口处通常以很小的角度汇入主路在出口处以很小的角度分流。这种小角度会让匝道和主路分支在角度序列里挨得非常近容易被误判成重复分支。建议给匝道单独一个类型标记在合并重复分支时跳过它。主辅路交织段的难点在前面提过方位角差异只有几度。我见过一个比较实用的判断方法看这两条分支在交叉口外 100 米处的距离如果小于 8 米大概率是同一条路的两条车道被错误拆分如果是 10 到 20 米是主辅路超过 20 米可能是两条平行但独立的道路。5.4 掉头、渠化岛与路内车道掉头在判定上有两个层次拓扑上的掉头沿着同一条边反向行驶和几何上的掉头经过一段专用掉头车道。前者靠方向属性就能识别后者必须靠车道数据。很多路口设有专门的掉头车道位置在进口道的最左侧绕过渠化岛。这种车道的几何是一小段圆弧加一小段直线方位角在 180 度左右。判定时要把它单独拎出来标成掉头分支不能混进左转分支里否则左转流量会偏高。渠化岛的影响在于它会改变道路的实际走线。有渠化岛的路口进口道会在靠近交叉口时向右偏移一到两个车道宽导致方位角整体偏转。如果代表点取在渠化段内部方位角会偏 5 到 15 度。解决办法是把取点位置推到渠化段之外或者用渠化段前的直线段做方位角估计。路内车道比如公交专用道、潮汐车道在判定阶段一般不单独处理但如果要做车道级的转向分析就必须考虑它们的通行限制。潮汐车道的方向会随时间变化静态路网数据表达不了只能靠时间属性字段判定时要跳过或者做特殊标注。5.5 数据版本与坐标偏移这一类问题不来自算法来自数据本身但杀伤力最大因为它会污染整批结果。最常见的是坐标系混用。同一批数据里有的用地理坐标有的用投影坐标有的甚至是加密偏移后的坐标。混在一起算方位角结果会全线错乱。检查方法很简单看坐标值的量级经纬度在正负 180 以内投影坐标通常是六到七位数。量级不对的直接筛出来。第二种是数据版本不一致。路网数据更新了但交叉口属性表还是旧的边 ID 对不上。这种情况下判定结果会挂到已经删除的边上看起来一切正常实际全是错的。建议每次重算前做一次 ID 交集校验缺失率超过 1% 就停下来查。第三种是几何精度。低精度数据在交叉口处的坐标抖动可能达到 3 到 5 米这会让方位角在小半径下严重失真。前面算过10 米半径下 1 米误差带来 5.7 度偏差3 米误差就是 16 度。所以低精度数据必须把半径调大或者干脆放弃自动判定转向人工。6. 质检、排查与实操心得流程跑完不等于活干完了最后一公里在质检。这一节给一张排查表、几个验收指标以及我这些年踩过的坑。6.1 常见问题速查表现象可能原因排查方法处理方式所有方位角整体偏移约 90 度atan2 参数顺序写反用正北方向测试改成 atan2(dx, dy)南北方向的角度偏差明显大于东西直接在经纬度上算角度检查是否做了等距修正投影或乘 cos(纬度)某路口识别出 6 条以上分支节点未聚合或主辅路重复看分支间的夹角分布聚类合并或标父子关系左转全部被判成右转转角符号定义反了用标准十字路口验证校正 normalize 的符号部分进口道没有对应出口道单向边或截断边查 to_node/from_node展开反向边或补数据环岛转向全乱用了环上切线角度看是否取了切线方向改用外部接入道路方向立交附近角度重叠无分层字段做连通分量分析补 level 或按连通性分层结果时好时坏数据版本不一致做边 ID 交集校验统一数据版本后重跑这张表覆盖了我在实际项目里遇到的大多数问题遇到异常的可以先对照着查。大部分问题的根因都在最基础的两三个点上不是算法本身的复杂度。6.2 三个可以量化的验收指标判定结果好不好不能只靠肉眼抽查。我一般看三个指标。第一分支数分布。统计全部交叉口的分支数直方图。正常情况下四岔路口应该占大头60% 到 75%三岔次之15% 到 25%五岔以上应该是个位数百分比。如果三岔占比超过 40%说明数据里断头路太多或者节点聚合没做好。第二转向覆盖率。对每个交叉口算出“实际识别出的转向数”和“理论应有转向数”的比值。理论值是 n×(n-1)n 是分支数。健康的数据应该在 0.85 以上。低于 0.7 说明连接关系缺失严重。第三抽样一致率。随机抽 200 个交叉口人工核对转向关系算一致率。这个指标最实在一般做到 92% 以上就可以上线剩下的走人工修订流程。低于 85% 说明参数或流程有问题得回头查。这三个指标是互补的第一个看整体结构第二个看连接完整性第三个看最终准确性。三个都过线结果基本可以放心用。6.3 踩过的坑和几条不那么显然的经验说几条文档里不会写、只有真跑过才知道的东西。第一别在第一天就追求全自动。我第一版做的是全自动判定跑了三天出了一堆看似合理实则错误的结果排查花了更久。后来改成“自动判定置信度打分低分人工核查”总工时反而少了一半。置信度可以用几个简单规则算分支数是否在合理范围、相邻夹角是否均匀、是否有孤边、是否在同一个连通分量里。规则越多的路口分数越低送人工。第二方位角一定要存成浮点数别存成方位枚举。很多人为了省事直接把方位角归成八方位存进库。等后面要做精细化分析时发现只有“东北”这个标签转角度数没了只能重头算。存浮点数的成本几乎为零收益很大。第三给每个交叉口算一个“畸形度”指标。我用的是分支夹角的方差方差越大说明越不规整。这个指标一算出来立刻就能把需要人工关注的那批路口筛出来。我们当时用这个指标把人工核查量从全量的 30% 压到了 6%效果非常明显。第四参数要跟着道路等级走别一刀切。主干路用 60 米半径支路用 15 米这是常识但真写代码时很多人图省事全用 30 米。结果是主干路的方位角被交叉口内部的渠化段带偏支路的方位角被坐标噪声带偏两头都不准。分类处理多写十行代码准确率能差出五到八个百分点。第五留一份“手工修正表”。不管算法多好总有一批路口是算法搞不定的。做法是建一张覆盖表记录哪些交叉口用了人工修正、修正后的值是什么、修正人是谁、什么时间。下次重算时把这张表读进去覆盖掉算法结果。这张表的存在能让你的数据在长期迭代中保持稳定不会因为重跑一次就出现大量回退。我自己在这个方向上做了几轮迭代最大的体会是这类问题的难点从头到尾都不在算法而在对数据本身的理解。同样一套公式对数据质量好的路网能跑到 95% 以上对拼接来源混乱的数据可能连 70% 都不到。所以真正值得投入时间的是数据摸底、参数分组、异常检测和人工核查流程的建设而不是把公式写得多花哨。当你能用一张排查表在十分钟内定位一个线上问题的时候这套东西才算真的落地了。

道路交叉口出入口方向判定：拓扑几何与转向关系工程实践

相关推荐

INCA ProF脚本四类文件与主控制流：从布局参数到刷写跳转

AI事业大使收益模型与推广策略全解析

财务会计（下）难点突破：从核算思维到判断思维的转换

更多资讯

CFileDialog 模板嵌入自定义控件：机制、实现与排查

t3code：本地代码片段管理与模板生成命令行工具实践

t3code 项目实战：T3 技术栈全栈 TypeScript 开发与部署指南

FPGA驱动双目OV5640并通过HDMI显示：DVP接口与TMDS编码实战

ECC三义辨析：纠错码、椭圆曲线密码与SAP系统全解析

t3code 编码实践：先跑通、再组合、后规范的三层演进思路

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？