2、NDS格式详解：NDS标准介绍、NDS数据结构（Tile、Level、Layer）、NDS存储格式（SQLite）
2.1 NDS标准到底是什么？
NDS，全称Navigation Data Standard，导航数据标准。说白了，它就是一套让地图数据在不同车厂、不同导航系统之间能互相流通的“通用语言”。
我最早接触NDS是在2016年，当时一个德国项目要求必须用NDS格式。说实话，第一眼看到那套规范文档——800多页，我头都大了。但啃下来之后发现，它的设计思路确实很清晰。
NDS不是某个公司的私有格式，而是一个由宝马、大众、戴姆勒等车厂联合推动的行业标准。它的核心目标就三个：
- 数据可交换：不同供应商的地图数据能拼在一起用
- 更新灵活：只更新变化的部分，不用全量替换
- 性能优先：嵌入式设备上也能跑得飞快
嗯，这里要注意：NDS目前主流版本是NDS 2.5和NDS 2.7。2.7版本增加了不少自动驾驶相关的属性，比如车道级连接、高精度曲率等。如果你做L3以上的项目，建议直接上2.7。
2.2 NDS的数据结构：Tile、Level、Layer
NDS把地图数据切成了三个维度来管理。我习惯叫它“三维切片模型”。
2.2.1 Tile——空间上的最小单元
Tile就是瓦片。NDS把地球表面切成一个个正方形的小块。每个Tile大约覆盖几百米到几公里的范围。
为什么要切Tile？你想想看，如果整张北京地图一次性加载，车载芯片根本扛不住。切成Tile后，系统只需要加载当前车辆所在的那几个Tile就行。
我在项目中遇到过一个问题：Tile的大小怎么选？切太小，文件数量爆炸，查询时频繁IO；切太大，内存占用高。我们最终的经验是：城市道路用256m×256m，高速用1km×1km。这个经验值你可以直接拿去用。
2.2.2 Level——不同比例尺的层级
Level就是层级。NDS把地图分成多个缩放级别，从L0到L15不等。
- L0：最底层，包含最详细的数据，比如车道线、路沿石
- L5-L7：中间层，包含道路级数据
- L10以上：顶层，只包含主要道路和城市轮廓
导航时，系统会根据当前缩放级别自动切换Level。比如你在地图上缩小看全局，它加载的是L10的数据；放大到路口，它自动切到L0。
我曾经踩过一个坑：Level之间的数据一致性。有一次我们更新了L0的一条车道，但忘了同步更新L5的道路属性，结果导航规划出来的路径和实际显示的路网对不上。后来我们加了一个自动化校验脚本，每次更新都检查上下级Level的拓扑一致性。
2.2.3 Layer——按主题分类的数据层
Layer是数据层。每个Layer存储一类特定的地图要素。
常见的Layer有：
| Layer名称 | 存储内容 | 典型数据量 |
|---|---|---|
| Routing | 道路拓扑、转向限制 | 中等 |
| MapDisplay | 背景地图、POI图标 | 较大 |
| Lane | 车道级数据 | 很大 |
| ADAS | 曲率、坡度、限速 | 中等 |
| POI | 兴趣点信息 | 较小 |
每个Layer内部又分成多个Feature Table。比如Lane Layer下面有LaneGeometry表、LaneConnectivity表、LaneAttribute表等。
我个人习惯把Layer比作“抽屉”。你需要什么数据，就打开哪个抽屉。不需要把所有抽屉都打开，这样查询效率高很多。
2.3 NDS的存储格式：为什么选SQLite？
NDS的存储格式是SQLite。很多人第一次听到这个会觉得奇怪：地图数据用数据库存？
其实原因很简单：
- 嵌入式友好：SQLite不需要独立服务进程，一个文件就是一个数据库
- 支持SQL查询：可以用标准SQL查地图数据，开发效率高
- 事务支持：更新数据时保证原子性，不会出现半拉子更新
- 跨平台：Linux、QNX、Android都能跑
一个典型的NDS数据库文件结构是这样的：
my_map.nfs
├── Tile 1001
│ ├── Level 0
│ │ ├── Routing Layer
│ │ │ ├── RoadSegment表
│ │ │ ├── Junction表
│ │ │ └── TurnRestriction表
│ │ ├── Lane Layer
│ │ │ ├── LaneGeometry表
│ │ │ └── LaneConnectivity表
│ │ └── ADAS Layer
│ │ ├── Curvature表
│ │ └── Slope表
│ └── Level 5
│ └── Routing Layer
│ └── RoadSegment表（简化版）
├── Tile 1002
│ └── ...
└── Metadata
└── 版本信息、坐标系定义等每个Tile是一个独立的SQLite数据库文件。这样做的好处是：更新某个Tile时，只需要替换对应的文件，其他Tile不受影响。
我记得有一次做OTA升级，客户要求只更新某个路口的车道数据。如果用传统格式，得重新打包整个地图。但NDS只需要替换那个Tile的SQLite文件，大小才几百KB，几分钟就搞定了。
2.4 实战：如何读取一个NDS文件？
光说不练假把式。我们来看看怎么用Python读取NDS文件。
import sqlite3
import os
def read_nds_tile(tile_path):
"""
读取一个NDS Tile文件
"""
if not os.path.exists(tile_path):
print(f"文件不存在: {tile_path}")
return None
conn = sqlite3.connect(tile_path)
cursor = conn.cursor()
# 查看有哪些表
cursor.execute("SELECT name FROM sqlite_master WHERE type='table';")
tables = cursor.fetchall()
print(f"该Tile包含的表: {tables}")
# 读取Routing Layer的道路数据
cursor.execute("SELECT * FROM RoadSegment LIMIT 5;")
rows = cursor.fetchall()
for row in rows:
print(row)
conn.close()
# 使用示例
read_nds_tile("tile_1001.nfs")这段代码很简单，就是连接SQLite、查表、读数据。但实际项目中，你还需要处理坐标系转换、二进制Blob解析等复杂操作。
嗯，这里要提醒一下：NDS中的几何数据通常以Blob形式存储，里面是压缩后的二进制格式。你需要用NDS SDK提供的解码函数来解析，不能直接当文本读。
我曾经犯过一个低级错误：直接用SQLite的文本模式打开Blob字段，结果看到一堆乱码，还以为是数据损坏了。后来才发现需要调用专门的解码接口。
2.5 小结
NDS格式的精髓在于“分而治之”。通过Tile、Level、Layer三个维度的切分，把庞大的地图数据拆解成可管理的小块。再加上SQLite这个轻量级数据库作为存储引擎，让数据的读写、更新、查询都变得高效可控。
下一章我们会深入NDS的另一个重要概念——Building Block，看看它是如何把不同Layer的数据组织成完整的地图要素的。