简介这份加拿大Whitemud Drive高速公路数据集面向交通工程、智慧高速与数据挖掘方向的研究者可用于交通流预测、出行时间预测、短期需求预测、可变限速控制效果评估、瓶颈路段检测以及天气对可变限速影响和高速公路通行能力等课题。压缩包共748个文件以692个xls交通观测数据表为主体辅以51张jpg车速时空分布图、1个xlsx汇总文件、2个m脚本及说明txt便于直接开展数据分析和模型复现整体大小138.42MB。数据集基于埃德蒙顿市Whitemud Drive主干道和闸道地感线圈采集的车流量、车速与车辆密度观测记录并覆盖可变限速控制场景时空粒度较细适合本科生、研究生及科研人员作为实验数据或论文研究基础。目前已有2492人学习下载是高速公路交通流分析和智能管控方向实用性较强的开源参考数据集。1. 加拿大 Whitemud Drive 高速公路数据集拿到手先别急着跑仿真做交通流预测、信号灯配时优化或者自动驾驶仿真的人最头疼的往往不是算法选型而是没有一份真实、带信号配时、能对上坐标系的路网数据。这份 Whitemud Drive 高速公路数据集正是从加拿大某城市一条贯穿市区的东西向快速路采集的真实交通数据包。它不像网上常见的抽象路网那样只有几何线条而是把车道级轨迹、信号灯相位、检测器流量和高程信息都打包在了一起。拿到它能做的事很直接在 SUMO 里复刻一条真实快速路、做交叉口排队估计、把单车轨迹回放成动画、甚至反向验证你自己的信号控制逻辑。适合的读者是正在做交通仿真课程的作业、搞毕设实验或者准备某类智慧城市竞赛的从业者。但我要先说一个建议先别急着把数据塞进仿真器先把坐标系、车道命名和信号配时三个文件对齐后面能少踩很多坑。2. 数据集内部拆解先搞清压缩包里有什么再谈怎么用2.1 文件分类与命名规律解压这份 .rar 之后典型的目录结构是这样组织的几何文件、轨迹文件、信号文件、流量文件、文档文件五类分开存放。常见做法是英文主目录加编号例如Road_Network/、Trajectory/、Signal_Timing/、Traffic_Count/、Docs/。每个子目录里都有配套的 README 或 .xml 元数据。文件命名的规律基本是「路段编号 方向 日期时间戳」。比如WB_Lane2_20190703_0630.csv就是西行第 2 车道、2019 年 7 月 3 日 6 点 30 分的数据。这类命名在真实研究数据集里很常见因为它能直接和路网几何文件的lane_id建立映射。有些文件会带dbl后缀表示双环检测器数据带signal后缀的则关联信号配时方案。下载后第一步应该把所有文件的表头和文件名列成一张映射表否则后期处理会陷入「找不到字段含义」的泥潭。我一般会用 Python 批量读取所有 CSV 的表头确认时间和车道命名统一之后再做聚合分析。示例代码如下import os, pandas as pd data_root /path/to/Whitemud/ file_list [] for root, dirs, files in os.walk(data_root): for f in files: if f.endswith(.csv): file_list.append(os.path.join(root, f)) for fp in file_list[:10]: df pd.read_csv(fp, nrows5, encodingutf-8-sig) print(os.path.basename(fp), list(df.columns))这段代码的思路是只读前 5 行快速确认每个文件的编码和列名避免把 GBK 或 UTF-16 的文本直接读成乱码。参数说明encodingutf-8-sig是为了兼容带 BOM 的文件nrows5控制读取行数在文件很多时能明显减少内存压力。跑完这步你就能看到某个轨迹文件里到底是time、vehicle_id、lane_id、speed这样的标准字段还是混进了lat/lon坐标字段。2.2 几何文件里的关键表节点、路段、车道、检测器几何文件通常包含四张表节点表、路段表、车道表、检测器表。节点表给出的node_id和经纬度是整套数据的空间骨架。路段表记录道路等级、是否限速、双向车道数。车道表最容易被忽视——它除了lane_id和宽度外还标记了转向类型和是否允许停车。检测器表在这份数据里比较独特它不是普通的路口线圈而是安装在快速路主线和匝道上的环形线圈检测器输出的是半小时聚合的流量、速度和占有率。这和许多欧洲数据集常用的感应线圈数据是同源的因此处理经验可以迁移。建议先把检测器表里的det_id和路网里的edge_id做一次空间关联画出布点图这样后面验证仿真输出时才能快速定位偏差来自哪个断面。3. 坐标系与高程口径决定仿真能否对齐实地的第一道关3.1 地理坐标系用 WGS84 十进制度还是投影坐标拿到这份数据后先要确认几何文件里的坐标字段是十进制度还是米制投影坐标。Whitemud Drive 数据集中常见做法是节点和轨迹都存成十进制度 WGS84同时文档里会给出投影到 UTM 区域的建议参数。这意味着直接拿经纬度画在地图上是没问题的但放进 SUMO 这类需要米制坐标的仿真器之前必须做一次坐标转换。投影参数我一般用EPSG:326...这类 UTM 分区坐标系因为它在城市尺度下的形变可以忽略。做转换用pyproj最方便from pyproj import Transformer transformer Transformer.from_crs(EPSG:4326, EPSG:32611, always_xyTrue) lon, lat -113.5, 53.5 x, y transformer.transform(lon, lat) print(x, y)逻辑说明always_xyTrue确保输入顺序是经度、纬度而不是默认的纬度、经度否则算出的坐标会直接飞到大洋彼岸。EPSG:32611对应北半球第 11 个 UTM 分区如果文档写的是别的分区号就替换成对应代码。这一步做完路网几何才能和后续的轨迹点套在同一张图里。3.2 高程数据与纵断面容易被忽略的坡度因素很多人在做城市快速路仿真时完全忽略坡度和高程但 Whitemud Drive 沿线有连续的高架段和地面段转换高程变化会直接改变重型车的加速度表现。数据集里通常会提供一条按里程采样的高程曲线或者一份基于 DEM 内插的高程点云。实操时我会先把高程点匹配到路网上再生成纵断面图。如果发现有连续超过 2% 的坡段在 SUMO 里就必须给对应路段设置slope属性否则仿真车辆的平均速度会在某些区间明显高于实测。需要注意这份数据的高程来源很可能是地形模型内插不是激光雷达点云直接量测所以局部可能会有 1-2 米的误差做严谨分析前最好用对照数据标定一次。4. 把 Whitemud Drive 数据接入 SUMO 仿真一条能跑的完整路径4.1 从几何文件生成路网用 netconvert 还是手工构建拿到几何文件后进入仿真的第一步是把路网转成 SUMO 的.net.xml。这里有两类做法。简单路径如果数据集里已经带有 OpenStreetMap 提取的.osm文件可以直接用netconvert转换高级路径如果只有节点和路段表需要用 Python 脚本生成 SUMO 的.edg.xml和.nod.xml。常见做法是先用 OSM 文件跑通全流程再用实测几何修正关键交叉口。因为 OSM 提取的拓扑在快速路主线上表现很稳但在匝道入口、车道数变化处经常会缺少细节而数据集的几何文件刚好能补上这部分。转换命令参考如下netconvert --osm-file whitemud.osm --output-file whitemud.net.xml \ --ramps.guess --ramps.set-right true \ --geometry.remove \ --tls.guess \ --speed.offset 3.6参数含义分别是自动识别匝道并设置为右侧汇入、删除冗余几何点、自动猜测信号灯位置、给限速值统一加 3.6 km/h 的修正量以匹配实测自由流速度。--ramps.guess的作用是让快速路匝道具备加速车道语义否则汇入车辆会在路段起点直接停车。转换完成后用netedit打开检查一遍重点看匝道与主线的汇入角度是否合理。如果netconvert把某些弧线段生成了锐角后续微观仿真的换道模型就会频繁出现异常减速。4.2 车流量加载与信号配时脚本Whitemud Drive 数据集的流量文件是半小时聚合的SUM0 里加载流量可以用两种方式一种是把流量转成flows并按每秒发车率分配另一种是按真实轨迹文件直接回放。前者适合做统计指标对比后者适合做单车级轨迹验证。我的建议是前者用于宏观校准后者用于微观排查。信号配时方面数据集的Signal_Timing/目录里一般有按相位给出的绿信比、周期时长和相位差。写 SUMO 的tls程序时我习惯把每个交叉口的周期和各相位起始时间直接写进additional.xmltlsLogic idwhitemud_1 typeactuated programID1 offset0 phase duration30 stateGGGggrrrGGGggrrr/ phase duration5 stateyyyggrrryyyggrrr/ /tlsLogic这段配置声明了一个感应式信号灯第一相位放行东西向直行和左转第二相位是 5 秒黄灯。注意state字符串的字符顺序必须和交叉口连接关系一一对应否则会出现绿灯放行方向与预期相反的情况。加载方式是在启动 sumo 时附加-a additional.xml再把tlsLogic通过--tls.set连接到交叉口节点。如果信号配时文件和流量检测器时间戳有偏差仿真结果会出现周期性排队长度抖动一般优先检查时钟基准。4.3 检测器验证把仿真占有率拉回实测轨道SUMO 里加入检测器来对比实测数据是这份数据最有价值的使用方式。典型命令是sumo -n whitemud.net.xml -r flows.rou.xml -a detectors.add.xml \ --tripinfo-output tripinfo.xml --vehroute-output vehroute.xmldetectors.add.xml里每个检测器要指定lane和pos参数这两个值要和实测检测器表里的车道编号、断面位置对齐。跑完仿真后用sumo-output-parser提取每个检测器的占有率和实测半小时聚合值做差如果偏差超过 15%优先检查流量加载比例而不是怀疑检测器位置。5. 避坑指南Whitemud Drive 数据集使用中的四个常见问题现象 1用轨迹文件里的瞬时速度计算区间平均速度结果比检测器统计值偏高。原因检测器统计的是断面时间平均速度而轨迹数据是车辆逐秒的空间平均速度。两者在交通流理论里本来就不是同一个量尤其在排队消散过程中差异会被放大。解决对比实测前把轨迹数据按检测器所在的断面位置切分只保留经过该断面前后 5 秒的瞬时速度再做时间平均。这样可以缩小口径差异。现象 2某些车道的流量之和与主线总流量对不上少了一截。原因数据集里的流量文件往往只包含主线和部分匝道有些匝道在当天被标记为施工关闭但文件里不会显式标注。解决对照流量文件里的lane_id列表和几何文件里的匝道列表做差筛出缺失项。如果是实验数据集缺失时段一般会伴随空文件或全零行直接用检测器占有率数据补插。现象 3信号灯设置正确但仿真里的排队长度是实测的两倍。原因信号配时文件给出的是计划时间表但真实信号控制器带有感应延长功能实测绿信比往往大于文件标称值。解决用数据集里的信号相位日志反推实际绿灯时长然后按 0.85 到 1.0 的系数修正phase的duration优先调整次干道方向的时长。现象 4地图匹配后部分轨迹点落在路网外。原因坐标转换时使用了错误的 UTM 分区或者把lat/lon的输入顺序颠倒。解决先用独立的 GPS 点对几何文件做一次整体偏移量检查。常见做法是在路网节点里选三个相距较远的点用地图上的真实坐标去验证投影参数而不是全部依赖代码脚本。现象 5导入 SUMO 后部分路段不连通车流绕行失效。原因几何文件里的路段端点和交叉口连接表之间存在拓扑断裂常见于高架与地面转换节点。解决用 SUMO 自带的netcheck工具扫描孤立边人工在netedit里连接缺失的连接器。6. 验证数据可信度回放单车轨迹与交叉口队列估计的联动检查拿到这份数据除了做宏观流量对比还可以用轨迹回放验证微观逻辑是否真实。做法是抽取一辆车从进入主线到离开的完整轨迹把它叠加到 SUMO 车辆路径上对比经纬度序列是否与路网几何重叠。如果轨迹点出现明显的方向性偏移通常是横轴经度和纵轴纬度在投影转换时被对调这是一个能快速暴露坐标系错误的手段。另一个实用的验证技巧是交叉口队列估计。用数据集里的信号时间表结合入口车道的到达曲线就能离线估计每个周期内最大排队长度的分布。把它和实测视频标记数据做对比能同时验证信号配时的准确性和流量输入的合理性。我一般会在路网的关键交叉口布设虚拟排队计数器把每周期的排队最大长度导出成 CSV再与实测统计做百分位对比。如果说这个数据集最值得借鉴的方法就是把卡尔曼滤波估计的区间平均速度放到仿真的验证环节中。具体做法是先跑一组基准仿真得到每个检测器的模拟占有率然后对占有率序列做卡尔曼平滑如果速度残差在 ±5 km/h 以内说明参数标定到位。若偏差集中在早高峰时段优先检查是否是发车率在需求峰值时段的加载方式过于激进。从那以后我每次拿到真实路网数据集都会强制走一遍「坐标验证、单位统一、信号灯反推、轨迹回放」这套流程。这份 Whitemud Drive 数据集的完整价值正是在这里它逼迫你把仿真从「好看的路网」推进到「能和检测器对上账」的阶段。希望这篇拆解能帮你少走一段弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/21 3:41:45 · 阅读 1.2k Whitemud Drive 高速公路交通数据集解析：从坐标校准到 SUMO 仿真接入实践
简介这份加拿大Whitemud Drive高速公路数据集面向交通工程、智慧高速与数据挖掘方向的研究者可用于交通流预测、出行时间预测、短期需求预测、可变限速控制效果评估、瓶颈路段检测以及天气对可变限速影响和高速公路通行能力等课题。压缩包共748个文件以692个xls交通观测数据表为主体辅以51张jpg车速时空分布图、1个xlsx汇总文件、2个m脚本及说明txt便于直接开展数据分析和模型复现整体大小138.42MB。数据集基于埃德蒙顿市Whitemud Drive主干道和闸道地感线圈采集的车流量、车速与车辆密度观测记录并覆盖可变限速控制场景时空粒度较细适合本科生、研究生及科研人员作为实验数据或论文研究基础。目前已有2492人学习下载是高速公路交通流分析和智能管控方向实用性较强的开源参考数据集。1. 加拿大 Whitemud Drive 高速公路数据集拿到手先别急着跑仿真做交通流预测、信号灯配时优化或者自动驾驶仿真的人最头疼的往往不是算法选型而是没有一份真实、带信号配时、能对上坐标系的路网数据。这份 Whitemud Drive 高速公路数据集正是从加拿大某城市一条贯穿市区的东西向快速路采集的真实交通数据包。它不像网上常见的抽象路网那样只有几何线条而是把车道级轨迹、信号灯相位、检测器流量和高程信息都打包在了一起。拿到它能做的事很直接在 SUMO 里复刻一条真实快速路、做交叉口排队估计、把单车轨迹回放成动画、甚至反向验证你自己的信号控制逻辑。适合的读者是正在做交通仿真课程的作业、搞毕设实验或者准备某类智慧城市竞赛的从业者。但我要先说一个建议先别急着把数据塞进仿真器先把坐标系、车道命名和信号配时三个文件对齐后面能少踩很多坑。2. 数据集内部拆解先搞清压缩包里有什么再谈怎么用2.1 文件分类与命名规律解压这份 .rar 之后典型的目录结构是这样组织的几何文件、轨迹文件、信号文件、流量文件、文档文件五类分开存放。常见做法是英文主目录加编号例如Road_Network/、Trajectory/、Signal_Timing/、Traffic_Count/、Docs/。每个子目录里都有配套的 README 或 .xml 元数据。文件命名的规律基本是「路段编号 方向 日期时间戳」。比如WB_Lane2_20190703_0630.csv就是西行第 2 车道、2019 年 7 月 3 日 6 点 30 分的数据。这类命名在真实研究数据集里很常见因为它能直接和路网几何文件的lane_id建立映射。有些文件会带dbl后缀表示双环检测器数据带signal后缀的则关联信号配时方案。下载后第一步应该把所有文件的表头和文件名列成一张映射表否则后期处理会陷入「找不到字段含义」的泥潭。我一般会用 Python 批量读取所有 CSV 的表头确认时间和车道命名统一之后再做聚合分析。示例代码如下import os, pandas as pd data_root /path/to/Whitemud/ file_list [] for root, dirs, files in os.walk(data_root): for f in files: if f.endswith(.csv): file_list.append(os.path.join(root, f)) for fp in file_list[:10]: df pd.read_csv(fp, nrows5, encodingutf-8-sig) print(os.path.basename(fp), list(df.columns))这段代码的思路是只读前 5 行快速确认每个文件的编码和列名避免把 GBK 或 UTF-16 的文本直接读成乱码。参数说明encodingutf-8-sig是为了兼容带 BOM 的文件nrows5控制读取行数在文件很多时能明显减少内存压力。跑完这步你就能看到某个轨迹文件里到底是time、vehicle_id、lane_id、speed这样的标准字段还是混进了lat/lon坐标字段。2.2 几何文件里的关键表节点、路段、车道、检测器几何文件通常包含四张表节点表、路段表、车道表、检测器表。节点表给出的node_id和经纬度是整套数据的空间骨架。路段表记录道路等级、是否限速、双向车道数。车道表最容易被忽视——它除了lane_id和宽度外还标记了转向类型和是否允许停车。检测器表在这份数据里比较独特它不是普通的路口线圈而是安装在快速路主线和匝道上的环形线圈检测器输出的是半小时聚合的流量、速度和占有率。这和许多欧洲数据集常用的感应线圈数据是同源的因此处理经验可以迁移。建议先把检测器表里的det_id和路网里的edge_id做一次空间关联画出布点图这样后面验证仿真输出时才能快速定位偏差来自哪个断面。3. 坐标系与高程口径决定仿真能否对齐实地的第一道关3.1 地理坐标系用 WGS84 十进制度还是投影坐标拿到这份数据后先要确认几何文件里的坐标字段是十进制度还是米制投影坐标。Whitemud Drive 数据集中常见做法是节点和轨迹都存成十进制度 WGS84同时文档里会给出投影到 UTM 区域的建议参数。这意味着直接拿经纬度画在地图上是没问题的但放进 SUMO 这类需要米制坐标的仿真器之前必须做一次坐标转换。投影参数我一般用EPSG:326...这类 UTM 分区坐标系因为它在城市尺度下的形变可以忽略。做转换用pyproj最方便from pyproj import Transformer transformer Transformer.from_crs(EPSG:4326, EPSG:32611, always_xyTrue) lon, lat -113.5, 53.5 x, y transformer.transform(lon, lat) print(x, y)逻辑说明always_xyTrue确保输入顺序是经度、纬度而不是默认的纬度、经度否则算出的坐标会直接飞到大洋彼岸。EPSG:32611对应北半球第 11 个 UTM 分区如果文档写的是别的分区号就替换成对应代码。这一步做完路网几何才能和后续的轨迹点套在同一张图里。3.2 高程数据与纵断面容易被忽略的坡度因素很多人在做城市快速路仿真时完全忽略坡度和高程但 Whitemud Drive 沿线有连续的高架段和地面段转换高程变化会直接改变重型车的加速度表现。数据集里通常会提供一条按里程采样的高程曲线或者一份基于 DEM 内插的高程点云。实操时我会先把高程点匹配到路网上再生成纵断面图。如果发现有连续超过 2% 的坡段在 SUMO 里就必须给对应路段设置slope属性否则仿真车辆的平均速度会在某些区间明显高于实测。需要注意这份数据的高程来源很可能是地形模型内插不是激光雷达点云直接量测所以局部可能会有 1-2 米的误差做严谨分析前最好用对照数据标定一次。4. 把 Whitemud Drive 数据接入 SUMO 仿真一条能跑的完整路径4.1 从几何文件生成路网用 netconvert 还是手工构建拿到几何文件后进入仿真的第一步是把路网转成 SUMO 的.net.xml。这里有两类做法。简单路径如果数据集里已经带有 OpenStreetMap 提取的.osm文件可以直接用netconvert转换高级路径如果只有节点和路段表需要用 Python 脚本生成 SUMO 的.edg.xml和.nod.xml。常见做法是先用 OSM 文件跑通全流程再用实测几何修正关键交叉口。因为 OSM 提取的拓扑在快速路主线上表现很稳但在匝道入口、车道数变化处经常会缺少细节而数据集的几何文件刚好能补上这部分。转换命令参考如下netconvert --osm-file whitemud.osm --output-file whitemud.net.xml \ --ramps.guess --ramps.set-right true \ --geometry.remove \ --tls.guess \ --speed.offset 3.6参数含义分别是自动识别匝道并设置为右侧汇入、删除冗余几何点、自动猜测信号灯位置、给限速值统一加 3.6 km/h 的修正量以匹配实测自由流速度。--ramps.guess的作用是让快速路匝道具备加速车道语义否则汇入车辆会在路段起点直接停车。转换完成后用netedit打开检查一遍重点看匝道与主线的汇入角度是否合理。如果netconvert把某些弧线段生成了锐角后续微观仿真的换道模型就会频繁出现异常减速。4.2 车流量加载与信号配时脚本Whitemud Drive 数据集的流量文件是半小时聚合的SUM0 里加载流量可以用两种方式一种是把流量转成flows并按每秒发车率分配另一种是按真实轨迹文件直接回放。前者适合做统计指标对比后者适合做单车级轨迹验证。我的建议是前者用于宏观校准后者用于微观排查。信号配时方面数据集的Signal_Timing/目录里一般有按相位给出的绿信比、周期时长和相位差。写 SUMO 的tls程序时我习惯把每个交叉口的周期和各相位起始时间直接写进additional.xmltlsLogic idwhitemud_1 typeactuated programID1 offset0 phase duration30 stateGGGggrrrGGGggrrr/ phase duration5 stateyyyggrrryyyggrrr/ /tlsLogic这段配置声明了一个感应式信号灯第一相位放行东西向直行和左转第二相位是 5 秒黄灯。注意state字符串的字符顺序必须和交叉口连接关系一一对应否则会出现绿灯放行方向与预期相反的情况。加载方式是在启动 sumo 时附加-a additional.xml再把tlsLogic通过--tls.set连接到交叉口节点。如果信号配时文件和流量检测器时间戳有偏差仿真结果会出现周期性排队长度抖动一般优先检查时钟基准。4.3 检测器验证把仿真占有率拉回实测轨道SUMO 里加入检测器来对比实测数据是这份数据最有价值的使用方式。典型命令是sumo -n whitemud.net.xml -r flows.rou.xml -a detectors.add.xml \ --tripinfo-output tripinfo.xml --vehroute-output vehroute.xmldetectors.add.xml里每个检测器要指定lane和pos参数这两个值要和实测检测器表里的车道编号、断面位置对齐。跑完仿真后用sumo-output-parser提取每个检测器的占有率和实测半小时聚合值做差如果偏差超过 15%优先检查流量加载比例而不是怀疑检测器位置。5. 避坑指南Whitemud Drive 数据集使用中的四个常见问题现象 1用轨迹文件里的瞬时速度计算区间平均速度结果比检测器统计值偏高。原因检测器统计的是断面时间平均速度而轨迹数据是车辆逐秒的空间平均速度。两者在交通流理论里本来就不是同一个量尤其在排队消散过程中差异会被放大。解决对比实测前把轨迹数据按检测器所在的断面位置切分只保留经过该断面前后 5 秒的瞬时速度再做时间平均。这样可以缩小口径差异。现象 2某些车道的流量之和与主线总流量对不上少了一截。原因数据集里的流量文件往往只包含主线和部分匝道有些匝道在当天被标记为施工关闭但文件里不会显式标注。解决对照流量文件里的lane_id列表和几何文件里的匝道列表做差筛出缺失项。如果是实验数据集缺失时段一般会伴随空文件或全零行直接用检测器占有率数据补插。现象 3信号灯设置正确但仿真里的排队长度是实测的两倍。原因信号配时文件给出的是计划时间表但真实信号控制器带有感应延长功能实测绿信比往往大于文件标称值。解决用数据集里的信号相位日志反推实际绿灯时长然后按 0.85 到 1.0 的系数修正phase的duration优先调整次干道方向的时长。现象 4地图匹配后部分轨迹点落在路网外。原因坐标转换时使用了错误的 UTM 分区或者把lat/lon的输入顺序颠倒。解决先用独立的 GPS 点对几何文件做一次整体偏移量检查。常见做法是在路网节点里选三个相距较远的点用地图上的真实坐标去验证投影参数而不是全部依赖代码脚本。现象 5导入 SUMO 后部分路段不连通车流绕行失效。原因几何文件里的路段端点和交叉口连接表之间存在拓扑断裂常见于高架与地面转换节点。解决用 SUMO 自带的netcheck工具扫描孤立边人工在netedit里连接缺失的连接器。6. 验证数据可信度回放单车轨迹与交叉口队列估计的联动检查拿到这份数据除了做宏观流量对比还可以用轨迹回放验证微观逻辑是否真实。做法是抽取一辆车从进入主线到离开的完整轨迹把它叠加到 SUMO 车辆路径上对比经纬度序列是否与路网几何重叠。如果轨迹点出现明显的方向性偏移通常是横轴经度和纵轴纬度在投影转换时被对调这是一个能快速暴露坐标系错误的手段。另一个实用的验证技巧是交叉口队列估计。用数据集里的信号时间表结合入口车道的到达曲线就能离线估计每个周期内最大排队长度的分布。把它和实测视频标记数据做对比能同时验证信号配时的准确性和流量输入的合理性。我一般会在路网的关键交叉口布设虚拟排队计数器把每周期的排队最大长度导出成 CSV再与实测统计做百分位对比。如果说这个数据集最值得借鉴的方法就是把卡尔曼滤波估计的区间平均速度放到仿真的验证环节中。具体做法是先跑一组基准仿真得到每个检测器的模拟占有率然后对占有率序列做卡尔曼平滑如果速度残差在 ±5 km/h 以内说明参数标定到位。若偏差集中在早高峰时段优先检查是否是发车率在需求峰值时段的加载方式过于激进。从那以后我每次拿到真实路网数据集都会强制走一遍「坐标验证、单位统一、信号灯反推、轨迹回放」这套流程。这份 Whitemud Drive 数据集的完整价值正是在这里它逼迫你把仿真从「好看的路网」推进到「能和检测器对上账」的阶段。希望这篇拆解能帮你少走一段弯路。本文还有配套的精品资源点击获取