简介：这份加拿大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, nrows=5, encoding="utf-8-sig") print(os.path.basename(fp), list(df.columns))这段代码的思路是只读前 5 行，快速确认每个文件的编码和列名，避免把 GBK 或 UTF-16 的文本直接读成乱码。参数说明：encoding="utf-8-sig"是为了兼容带 BOM 的文件；nrows=5控制读取行数，在文件很多时能明显减少内存压力。跑完这步，你就能看到某个轨迹文件里到底是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_xy=True) lon, lat = -113.5, 53.5 x, y = transformer.transform(lon, lat) print(x, y)逻辑说明：always_xy=True确保输入顺序是经度、纬度，而不是默认的纬度、经度，否则算出的坐标会直接飞到大洋彼岸。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.xml：<tlsLogic id="whitemud_1" type="actuated" programID="1" offset="0"> <phase duration="30" state="GGGggrrrGGGggrrr"/> <phase duration="5" state="yyyggrrryyyggrrr"/> </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 数据集的完整价值正是在这里：它逼迫你把仿真从「好看的路网」推进到「能和检测器对上账」的阶段。希望这篇拆解能帮你少走一段弯路。本文还有配套的精品资源，点击获取
简介：这份加拿大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, nrows=5, encoding="utf-8-sig") print(os.path.basename(fp), list(df.columns))这段代码的思路是只读前 5 行，快速确认每个文件的编码和列名，避免把 GBK 或 UTF-16 的文本直接读成乱码。参数说明：encoding="utf-8-sig"是为了兼容带 BOM 的文件；nrows=5控制读取行数，在文件很多时能明显减少内存压力。跑完这步，你就能看到某个轨迹文件里到底是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_xy=True) lon, lat = -113.5, 53.5 x, y = transformer.transform(lon, lat) print(x, y)逻辑说明：always_xy=True确保输入顺序是经度、纬度，而不是默认的纬度、经度，否则算出的坐标会直接飞到大洋彼岸。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.xml：<tlsLogic id="whitemud_1" type="actuated" programID="1" offset="0"> <phase duration="30" state="GGGggrrrGGGggrrr"/> <phase duration="5" state="yyyggrrryyyggrrr"/> </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 数据集的完整价值正是在这里：它逼迫你把仿真从「好看的路网」推进到「能和检测器对上账」的阶段。希望这篇拆解能帮你少走一段弯路。本文还有配套的精品资源，点击获取