简介本资源为 nuScenes 地图扩展数据集 v1.3 版本面向自动驾驶感知、预测与地图构建方向的研究者与算法工程师用于补充和增强 nuScenes 原有地图信息支撑定位、路径规划与行为预测等任务。压缩包共 10 个文件约 380.07MB包含 5 个 json 与 4 个 png 及 1 份 LICENSEjson 文件覆盖 prediction 预测场景与波士顿、新加坡多个城区的地图数据png 则提供对应区域的基础地图可视化便于快速核对空间结构。已有 305 人学习下载说明其在自动驾驶研究社区中具备一定参考价值。借助这些扩展地图与预测信息读者可将其接入现有训练或仿真流程用于验证模型在复杂城市场景下的环境理解与轨迹预测表现同时 LICENSE 文件明确了使用条款方便合规引用与二次开发。1. 拿到 nuScenes-map-expansion-v1.3.zip 之后先别急着解压搞清楚它到底补了什么如果你正在做自动驾驶感知或高精地图相关的项目大概率被 nuScenes 原版地图的覆盖范围坑过。原版 nuScenes 数据集虽然提供了 1000 个场景的传感器数据但它的地图标注只覆盖了新加坡和波士顿两个城市的部分区域而且很多路口的车道线、人行横道、停止线标注并不完整。当你训练一个依赖地图先验的模型时比如 MapTR、HDMapNet 或者 BEVFormer 的 map head就会发现有些场景的地图 GT 是缺失的模型在这些区域的表现直接崩掉。这个 nuScenes-map-expansion-v1.3.zip 就是冲着这个痛点来的——它是对 nuScenes 地图标注的扩展版本补充了原版中缺失或标注不完整的部分让地图覆盖率和标注密度都有明显提升。适合谁用做 BEV 感知、在线建图、地图先验融合的算法工程师以及需要完整地图 GT 做评测的研究人员。如果你只是跑跑 3D 检测 baseline这个资源可能不是刚需但一旦你的模型输出和地图有交互它就是绕不开的一块拼图。2. 地图扩展包的结构拆解json 字段、坐标系与版本差异2.1 解压后你会看到什么拿到 zip 之后先别一股脑丢进训练脚本。我一般会先解压到一个独立目录然后 tree 一下看结构。常见的组织方式是按城市和地图块划分每个块对应一个 json 文件里面存的是矢量化的地图元素。下面是一个典型的目录结构示意unzip nuScenes-map-expansion-v1.3.zip -d ./nuscenes_map_expansion cd nuscenes_map_expansion find . -maxdepth 2 -type d | head -20执行后会看到类似singapore/、boston/这样的城市目录下面再按 map block 分文件。每个 json 文件里通常包含lane_segments、ped_crossings、stop_lines、road_boundaries这几类元素。注意不同版本的地图扩展包在字段命名上可能有细微差异v1.3 这个版本号意味着它是在之前版本基础上做了修正和补充所以如果你之前用过 v1.0 或 v1.1不要直接混用字段对不上会静默出错。2.2 坐标系与 nuScenes 原版的对应关系这是最容易翻车的地方。nuScenes 原版地图用的是全局坐标系单位是米原点在某个参考点。地图扩展包一般会沿用同一套坐标系但你需要确认它是否做了局部平移或旋转。验证方法很简单挑一个原版地图里也有的路口把两边的车道线坐标画出来对比。如果偏差在厘米级说明坐标系一致如果差了几米甚至几十米那就要找扩展包附带的 transform 参数。import json import numpy as np # 读取扩展包中某个 map block 的车道线 with open(./nuscenes_map_expansion/singapore/block_001.json, r) as f: expansion_data json.load(f) # 读取 nuScenes 原版地图对应区域 with open(./nuscenes_map_v1.0/singapore/block_001.json, r) as f: original_data json.load(f) # 取第一条车道线的第一个点做对比 exp_pt np.array(expansion_data[lane_segments][0][polyline][0]) ori_pt np.array(original_data[lane_segments][0][polyline][0]) print(扩展包坐标:, exp_pt) print(原版坐标:, ori_pt) print(偏差:, np.linalg.norm(exp_pt - ori_pt))这段代码的逻辑是从两个来源各取一条车道线的起始点算欧氏距离。如果偏差小于 0.1 米基本可以认为坐标系对齐如果偏差在 1 米以上就需要检查是否有额外的变换矩阵。参数方面polyline字段通常是一个 N×2 或 N×3 的列表N 是采样点数量2 或 3 代表二维或三维坐标。有些扩展包只给二维 BEV 坐标有些会给高程取决于标注方式。2.3 版本差异v1.3 相比早期版本改了什么从版本号推断v1.3 主要做了三件事一是补充了原版中标注为空的 map block二是修正了部分车道线的拓扑连接关系比如之前断开的车道现在接上了三是统一了字段命名减少了下游解析的歧义。如果你手头有旧版建议直接切到 v1.3不要试图写兼容层因为拓扑修正这类改动是没法用代码自动合并的。常见做法是先用 v1.3 跑一遍地图可视化确认你关心的区域确实被覆盖到了再决定是否替换训练管线里的地图路径。3. 把扩展地图接进训练管线从 json 到 BEV 栅格3.1 地图元素转栅格分辨率与范围怎么定大多数 BEV 感知模型不直接吃矢量地图而是需要栅格化的地图先验。这一步的核心参数是resolution和pc_range。resolution 决定每个像素代表多少米常见取值是 0.1 米到 0.5 米pc_range 决定 BEV 特征图覆盖的物理范围nuScenes 常用的是 [-51.2, -51.2, -5.0, 51.2, 51.2, 3.0] 这个范围。地图扩展包里的矢量元素需要按同样的参数栅格化否则和激光雷达点云、相机 BEV 特征对不上。import numpy as np import cv2 def rasterize_map(elements, pc_range, resolution, canvas_size): 将矢量地图元素栅格化为 BEV 图 elements: 列表每个元素包含 type 和 polyline pc_range: [x_min, y_min, z_min, x_max, y_max, z_max] resolution: 米/像素 canvas_size: (H, W) H, W canvas_size canvas np.zeros((H, W), dtypenp.uint8) for elem in elements: pts np.array(elem[polyline])[:, :2] # 只取 xy # 物理坐标转像素坐标 px ((pts[:, 0] - pc_range[0]) / resolution).astype(np.int32) py ((pts[:, 1] - pc_range[1]) / resolution).astype(np.int32) # 注意 y 轴翻转BEV 图通常原点在左下 py H - 1 - py for i in range(len(px) - 1): cv2.line(canvas, (px[i], py[i]), (px[i1], py[i1]), 255, 2) return canvas逻辑说明先把物理坐标减去 pc_range 的最小值再除以 resolution得到像素索引。y 轴翻转是因为图像坐标系原点在左上而 BEV 通常原点在左下。cv2.line的线宽设为 2 是为了避免细线在降采样时丢失。参数方面resolution 越小地图越精细但显存占用越大pc_range 要和你的模型配置完全一致差一点就会导致地图和感知结果错位。3.2 多类地图元素的分通道处理实际训练时不同地图元素要分开成不同通道比如车道线一个通道、人行横道一个通道、路边界一个通道。这样模型才能学到类别间的差异。做法很简单对每类元素单独调一次 rasterize_map然后 stack 起来。map_types [lane_segments, ped_crossings, road_boundaries] channels [] for mt in map_types: elems [e for e in expansion_data[mt]] ch rasterize_map(elems, pc_range, resolution, (H, W)) channels.append(ch) map_tensor np.stack(channels, axis0) # shape: (3, H, W)这里有个坑有些扩展包里ped_crossings用的是多边形而不是折线直接按折线画会变成一团乱线。遇到这种情况需要先用cv2.fillPoly填充多边形而不是画线。判断方法很简单看 polyline 的首尾点是否重合重合就是闭合多边形。3.3 和 dataloader 的对接方式最稳妥的做法是把栅格化后的地图存成 npy 或者 pkl按 sample_token 索引然后在 dataloader 里直接读。不要在__getitem__里实时栅格化那样 IO 和计算都会拖慢训练。我一般会写一个预处理脚本遍历所有 sample生成地图栅格缓存。import os import pickle from nuscenes import NuScenes nusc NuScenes(versionv1.0-trainval, dataroot./data/nuscenes, verboseTrue) cache {} for sample in nusc.sample: token sample[token] # 根据 sample 的 location 找到对应的 map block # 这里需要你根据扩展包的索引逻辑来匹配 map_block find_map_block(sample) cache[token] rasterize_map(map_block, pc_range, resolution, (H, W)) with open(./map_cache.pkl, wb) as f: pickle.dump(cache, f)参数说明find_map_block需要你自己实现逻辑是根据 sample 的 ego pose 位置去查扩展包的索引。常见做法是扩展包会附带一个map_index.json里面记录了每个 map block 的经纬度范围或全局坐标范围。如果没有索引文件那就只能按最近邻匹配但要注意边界情况。4. 避坑与排查地图扩展包最容易翻车的五个地方4.1 现象地图和点云对不上偏了几米原因坐标系不一致或者 pc_range 设置和模型配置不匹配。扩展包可能用了不同的原点或者你在栅格化时忘了做 y 轴翻转。解决先用 2.2 节的对比脚本确认坐标系偏差再检查 pc_range 是否和模型 config 里的完全一致。y 轴翻转是最容易被忽略的建议在栅格化函数里加一个断言检查画出来的线是否在 canvas 范围内。4.2 现象某些场景地图全黑一个元素都没有原因扩展包虽然补充了很多区域但不可能覆盖 100% 的 map block。有些 sample 落在扩展包未覆盖的区域或者索引匹配失败。解决在 dataloader 里加一个 fallback 逻辑如果扩展包没有对应地图就回退到原版地图如果原版也没有就用全零地图并记录 warning。不要直接报错中断训练。4.3 现象车道线拓扑断裂模型学出来的路网不连通原因扩展包修正了部分拓扑但如果你用的是旧版解析代码可能把新增的连接字段忽略了。解决检查你的解析逻辑是否读取了prev和next字段这些字段记录了车道段之间的连接关系。如果扩展包用了新的字段名比如predecessor和successor那就需要更新解析代码。4.4 现象训练 loss 突然飙升地图通道全是 255原因栅格化时线宽设得太大或者 resolution 太小导致地图通道几乎全被占用模型无法区分 foreground 和 background。解决把线宽降到 1或者把 resolution 调大到 0.2 米以上。另外地图通道的值建议归一化到 0 到 1 之间不要直接用 255。4.5 现象多卡训练时地图缓存读取报错原因多个进程同时读同一个 pkl 文件或者缓存文件太大导致内存不够。解决用torch.distributed的 rank 做分片每个进程只加载自己负责的那部分缓存或者把 pkl 转成 lmdb支持并发读。如果缓存超过内存就改成按需读取 npy 文件不要一次性全加载。5. 进阶技巧用扩展地图做在线建图评测的 mAP 提升验证5.1 评测指标怎么对齐如果你用扩展地图做在线建图任务的 GT评测时要注意一点原版 nuScenes 的 map 评测协议只覆盖了部分区域直接用原版协议评扩展地图指标会虚高。正确做法是只在你补充了地图的区域上算指标或者重新生成一份评测掩码。我一般会写一个脚本对比扩展包和原版的地图覆盖范围生成一个 binary mask评测时只算 mask 内的像素。def compute_map_mask(expansion_data, original_data, pc_range, resolution, canvas_size): exp_map rasterize_map(expansion_data, pc_range, resolution, canvas_size) ori_map rasterize_map(original_data, pc_range, resolution, canvas_size) # 扩展包有而原版没有的区域 mask (exp_map 0) (ori_map 0) return mask这个 mask 的作用是在评测时只关注那些扩展包新增的区域避免原版已经覆盖的区域拉高整体指标。参数方面canvas_size要和你的模型输出分辨率一致否则 mask 对不上。5.2 可视化验证把地图叠在 BEV 特征上训练过程中我习惯每隔几个 epoch 做一次可视化把地图 GT 和模型预测的 BEV 特征叠在一起看。具体做法是取一张地图栅格用红色表示 GT用绿色表示预测重叠部分显示黄色。如果红色和绿色大面积错位说明地图先验没被正确利用或者坐标系有问题。import matplotlib.pyplot as plt def visualize_overlay(gt_map, pred_map): gt_map: (H, W) 二值图 pred_map: (H, W) 二值图 overlay np.zeros((H, W, 3), dtypenp.uint8) overlay[gt_map 0] [255, 0, 0] # GT 红色 overlay[pred_map 0] [0, 255, 0] # 预测绿色 overlap (gt_map 0) (pred_map 0) overlay[overlap] [255, 255, 0] # 重叠黄色 plt.imshow(overlay) plt.show()这个可视化脚本我几乎每个项目都会改一版核心逻辑不变。黄色区域越多说明模型对地图的拟合越好。如果黄色很少但红色和绿色都有那就要检查是不是偏移了半个像素或者一个像素这种亚像素级别的错位在 BEV 里很常见调一下 pc_range 的偏移量就能解决。5.3 一个我踩过的坑地图扩展包和原版混用导致 token 错位有一次我图省事把扩展包的地图直接按 sample_token 覆盖到原版缓存里结果训练时发现有些 sample 的地图变成了另一个场景的。排查了半天才发现扩展包的 token 索引方式和原版不完全一样有些 token 在扩展包里对应的是相邻的 map block。从那以后我每次接新地图包都强制走一遍 token 对齐检查随机抽 100 个 sample把扩展包地图和原版地图都画出来人工确认是不是同一个路口。这个习惯帮我省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取