高精地图数据模型与交换格式

高精地图数据模型与交换格式

附赠自动驾驶学习资料和量产经验：链接

1. 前言

**本文主要内容是《**高精地图数据模型与交换格式入门》，旨在阐述“将高精地图的数据抽象化，并组织成高精地图的标准格式”的方法，会结合高精地图的标准来展开，但也不限于讲解标准。

当前各地图厂商纷纷将工作重心转移到了面向自动驾驶的高精地图上。而为方便自动驾驶产业内地图数据的交互，高精地图的标准是必须考虑的。所谓“标准”包含数据采集、地图制作的流程标准；数据存储、交换共享的模型标准；以及应用层面的**接口标准。本文主要讨论HDMap的存储模型以及交换格式，**关于其他标准可以参考高精地图白皮书。

高精地图的标准框架

国外的标准建设起步较早，如OpenDrive早在2006年就开始建设，经过多轮版本迭代，当前已经相对完善，NDS亦是如此。国内的HDMap标准建设处于起步阶段（由于标准形成后的马太效应，估计基本也起不了步，以我有限的视角看，基本都是魔改OpenDrive），大部分的厂商如高德、四维在内部都有着自己的一套标准，这些厂商近年会拉国家部门做背书，发布几个“推荐性标准”，但依我看来不会对业界产生什么影响。

此类标准的特点是：仅有一两个干巴巴的文档，地图要素表达模型考虑的并不周全、没有后续的维护更新、没有任何Demo和API，因此也基本不具备任何实际的工程价值，如果严厉一点，甚至不能称之为一份《标准》，不排除制定者出于商业价值而藏私的可能性。不过，此类标准用以对HDMap标准的入门却是极好的。

本文会包含对国内外标准文件进行介绍，旨在使读者理解“HDMap数据模型”，但不会对这些标准进行详细的拆分解读。若想深入了解，可见下方的**一级参考源，相关标准文档已做好归类。**然后，我后面也会写一份OpenDrive的解读文档（但知乎格式实在受限，我很难编辑）。

1.1 一级参考源：

1. Opendrive：ASAM OpenDRIVE® OpenDRIVE: Concept Document (asam.net) ASAM OpenDRIVE

2. ADASIS：Adasis website

3. NDS：NDS Open Lane Model Navigation Data Standard (NDS)

4. GBT：《智能驾驶电子地图数据模型与交换格式 第1部分：高速公路（征求意见稿）》

5. CHT：中国测绘地理信息标准网 (csms.org.cn)

6. GBT：交通运输标准化信息平台 (mot.gov.cn)

7. T/CSAE 185-2021：《自动驾驶地图采集要素模型与交换格式》CSAE标准报批稿

以上大部分链接都可以下载对应标准文档。

1.2 二级参考源：

1. 《GB5768.2-2009——道路交通标志和标线 第２部分：道路交通标志》

2. 《GB5768.3-2009——道路交通标志和标线 第3部分：道路交通标线》

3. 《地理信息系统导论》——Kang-tsung Chang-科学出版社

4. 《中国智能网联汽车产业发展报告 2020》

5. Navigation Data Standard - Wikipedia

6. OpenDRIVE (specification) - Wikipedia

7. Apollo进阶课程 ⑧ | 高精地图的格式规范 (qq.com)

8. (10条消息) ADASISv3简述，自动驾驶怎么进行地图数据传输？_frank 的专栏-CSDN博客

2. 最简HDmap数据模型

常听到的一句话就是：高精地图包含了比普通地图更多的信息：如更详细的道路信息、车道线、交通标志和标牌、路旁建筑等元素。那么，这些元素是以何种格式存储的，这些元素包含的信息又当该如何表达？

举个例子，某个位置有一个圆形限速牌，中间写着该路段的限速值：40km/h**，**我们该如何存储这个限速牌？如将标牌以带有颜色信息的3D栅格模型存储显然是个不太好的主意。一来会占据很大的存储空间，自动驾驶系统也难以从中直接提取语义信息。因此在建图的阶段，应当对“这个路牌”抽象化处理。

2.1 数据抽象举例

2.1.1 限速牌

对上述限速牌的抽象，一个很自然的思路就是：以一个外接圆来代表这个路牌，路牌的精确位置就是圆心坐标（X, Y, Z）或者（经度、纬度、高程）。事实上，路牌的抽象表达还可以用一个点、或一个外接矩形来代表，路牌的位置可以是地图坐标系下的点的位置、或外接矩形的左上角点的位置——这其实对于路牌的详细语义表达都是没有妨碍的。

圆形要素的三种表达

这还不够，我们还需要给这个矢量图形添加一些附属的语义信息，使自动驾驶系统能够直接读取关于这个限速牌的所有关键信息。那么，这些Tag可以有：

属性	说明
路牌的编号	代表该路牌的唯一身份ID；就是路牌的身份证；
路牌的属性	它是限速牌，还是禁停牌，还是指示牌？
值	如果是限速牌，那么限速值又是多少?
所属路段	这个路牌是G18高速的，还是北京三环的？
etc…

矢量化图形表示 + 世界 or 局部坐标系中的位置 + 表达语义属性的Tags，沿着这个思路这就完成了对一个限速牌的抽象过程。下图就是OpenDrive标准中，对限速牌的抽象格式：

OpenDrive限速牌的抽象化表达案例

2.1.2 道路的表示

那么一条道路应当如何表示？首先想到的是，用一条空间3D的直线或曲线来表示，曲线可以由采集到道路上的数据点按照一定规则拟合（如弧线、螺线、三次方程曲线），一段道路可能具有多种形态，**可以由多种拟合曲线进行拼接，**OpenDrive就是这么做的。

多种矢量图形的拟合，来自OpenDrive

或者，我们还可以用一个3D平面/ 曲面(Polygon or Nurbs)来表示该路段，相对的，3D面能比3D曲线提供更多的信息：如道路的宽度，道路任意位置的曲率、坡度、倾斜程度(道路超高)。

不同的道路逻辑表达

当然，还有的做法是直接用一堆散点来代替线/面，如此更有利于后续的决策规划算法。（实际拟合过程中，曲线曲面可能会出现曲率极为夸张的尖角，会让规划算法失控，详细可见该UP主的规控算法课程）

忠厚老实的老王的个人空间-忠厚老实的老王个人主页-哔哩哔哩视频​space.bilibili.com/287989852?spm_id_from=333.337.0.0

将以上抽象化的思路扩展到道路中所有与驾驶相关的要素，在一套统一的规则下，将这些要素进行抽象化表达，然后按照一定的层次、结构存储起来。**最终形成的这个模型，也就是所谓的高精地图存储模型。**如果上述语言还不够直观的话，下面我们来自己构建一个简单的HDmap模型。

2.2 建立十字路口高精地图

下图是一个十字路口的实际道路场景。

实际的道路场景：十字路口

该道路场景包含但不限于的元素有：

1. 交叉的道路；

2. 上下行的车道、路面上印刷的车道分界线，转弯、直行、掉头的标志；

3. 路旁的交通标志，如红绿灯、限速牌、禁停标志；

4. 道路两旁的路灯、树木、绿化栏、房屋建筑等不属于道路但又紧挨着道路的实体。

然后，我们按照一定规则对这些元素进行抽象，如下图：

高精地图：实际道路所有元素的抽象化表达

1. **道路：道路（包含交叉路口）可以用一个多边形表示（Polygon）, 即一串封闭的数据点 。给该段道路打上相应的属性Tag：**该段道路在朝阳还是在海淀？道路是高速路还是快速道路还是普通道路？采集时间是什么时候？

再给道路建立**拓扑关系：**道路首尾分别与哪条道路或者哪个路口连接？

2. **车道：**道路还可以拆分为车道，车道可以用多段线（polyline）来表达，即一串不封闭的数据点 。给它打上的属性Tag可以是：该车道是直行车道还是转弯车道？宽度是多少？

拓扑关系可以是：隶属的道路是那一条？首尾连接的车道是哪一条？

3. 路面标线：路面上刷的标线都可以用Polyline表达。其属性Tag可以是白色 or 黄色、虚线 or 实线、 单线 or 双线 等属性，分别对应了不同的交通规则。其拓扑关系可以是隶属的道路或车道，以及标线首尾与其他标线的连接关系。

而路面上的人行道，指示箭头可以用Polygon表示，其Tag可以是其种类（如左拐、右拐、直行等定义）。其拓扑关系可以是关联的车道，以及首尾连接的标线ID。

4. **道路交通标志：**红绿灯、限速牌、让行标志等一切路旁的标牌都可以用Polygon表示。其Tag可以有：颜色、种类编码（比如数字1代表红绿灯，数字2代表限速牌…）、数值（即标牌上的数字，比如限速数值）。

其拓扑关系可以是：隶属的道路所属的路口。

5. **道路附属物：**路灯杆可以用Polyline表示，房屋、龙门架可以用Polygon表示。属性Tag可以有，路灯的直径、房屋的高度，离路边的距离等。

其拓扑关系可以是：临近的道路。

那么，通过这个穷人版的“高精地图”，我们能够想象到：一份抽象化的地图数据，其数据包可以被压缩到很小。事实上也是如此：某新势力汽车2022所使用的高精地图，全国高速公路数据加起来也不超过8G，如果加上城市高架，也不过20G。

在HMI中，计算机通过这些点、线、面数据，可以对高精地图的各种要素进行渲染还原，进行实景导航，以达成更好的用户体验（尽管HDmap主要并不是给“人”看的）。

基于HDmap的实景导航

3. 地图标准的基础体系

下面我们对这个粗陋的高精地图模型进一步规范化，详细化。

3.1 时空参考系

高精地图中所有的元素最终都会归为：坐标系下的矢量化数据（点、线、面）；而在生产和使用高精地图时候，也需要给采集的要素打上时间戳。那么问题来了，应当采用哪种空间坐标系和时间坐标系？

3.1.1 惯性坐标系

关于空间坐标，我们自然会想到采用地球坐标系，即用经度longitude、纬度latitude、高程altitude表达数据点的位置。0°纬线是赤道，0°经线是经过格里尼治天文台的本初子午线。高程如何定义，第一个想到的自然是**“海拔”**。但海拔在此场景下并不是一个合格的参照。

地球并非完美的圆形，而是近似一个椭球体。由于地球引力和板块的原因，各处的水平面距地心的距离并不一致。因此，更合理的方式是找到一个与地球最为相近的椭球体**——基准椭球体作为高程参照。该椭球体的要求是：**

1. 中心 = 地球质心，

2. 短轴 = 地球自转轴，

3. 表面由水平面线性回归求得（水平面的最小方差）。

基准椭球体ellipsoid - 海平面 Geoid - 高程

所谓国际通用的WGS84（World Geodetic System 1984），中国通行的CGCS2000（China Geodetic Coordinate System 2000）大地坐标系，通俗讲就是对这个“**基准椭球体”**不同的拟合结果。

地心地固坐标系ECEF

两个坐标系之间的参数主要体现在短半轴b的长度不同，以及所采用的历元不同（自转轴、赤道面会存在微小差异），拟合的差异会造成两种坐标系下对同一点测量之差达到分米级。这一差异主要由历元差异造成，短半轴的差异造成的测量差值并不大，当然两个坐标系间的换算也并不算复杂。

也有的地图标准会采用EGM96（the Earth Gravitational Model from 1996），1985国家高程来表示高程，其采用了近似海拔高度。

坐标系	基准长半轴a	基准短半轴b	极扁率f	历元
WGS84	6378137.0m	6356752.3142m	1/298.257223563	ITRF2008
CGCS2000	6378137.0m	6356752.31414m	1/298.257222101	ITRF97

关于大地坐标系的详细解释，可参考：组合导航原理：GNSS-RTK+IMU第二节部分。

3.1.2 Frenet坐标系：

在自动驾驶领域，为了简化计算，往往还会引入Frenet坐标系：以车辆自身为原点，坐标轴相互垂直，分别是：

a. **纵向s：**沿着参考线的方向；

b. **横向t：**参考线的法向。

OpenDrive的局部ST坐标系

想像某一车道的中心线被定义为参考线。那么：

• s：坐标沿参考线，由道路参考线起点开始测量，在xy平面中计算（不考虑道路的高程）；

• t：侧面，在x/y平面里正向向左；

• h：右手坐标系中垂直于st平面；

车辆在ST坐标系下就如同行走在一条直道上，从而简化算法的计算过程。

3.1.3 时间坐标系：

一般采用协调世界时（UTC，Universal Time Coordinated）。

补充1：协调世界时是以原子时秒长为基础，在时刻上尽量接近于世界时的一种时间计量系统。中国大陆采用ISO 8601-1988的《数据元和交换格式信息交换日期和时间表示法》（GB/T 7408-1994）称之为国际协调时间。

原子秒：当铯-133原子位于海平面处于非扰动基态时两个超精细能级间跃迁对应的辐射频率ΔνCs以Hz(即等于s-1)为单位表达时选取固定数值9192631770倍来定义秒。

世界时：格林尼治平太阳时间，以地球自转为基础的时间计量系统。由于原子时与地球自转无关，因此需要闰秒靠近世界时。

参考资料：

1. World Geodetic System - Wikipedia

2. BeiDou - Wikipedia

3. 2000国家大地坐标系_百度百科 (baidu.com)

4. 协调世界时_百度百科 (baidu.com)

3.2 数据的组织方式

一大片区域的地图数据如何管理？这涉及到了地图的分幅和分层。

数据的分幅（分区）：按一定方式将广大地区的地图划分成尺寸适宜的若干小幅地图，便于地图制作、使用和更新（尤为重要）。高精地图可以采用经纬分幅，还有一些标准选择采用行政区划对地图进行分区，正如我们的邮编，车牌，以及身份证的前6位那样。

数据的分层：如前面提到的，将道路、车道、道路表面印刷的标线、道路两旁的交通标志、道路之外的其他实体分开表达的方式，就是典型的数据分层。道路中包含的元素相当多，将特性相近的元素组织起来形成多个数据层，也可以使得地图逻辑更加清晰，方便使用和更新。

数据的分幅度与分层

还有一些比较有特色的分区方式，按照场景的特性进行（高速路、城市道路、普通公路、停车场场景），这些场景的驾驶要素的都有较大的不同，将不同的场景进行拆分是一个不错的主意，尽管这严格意义上算不上是分幅、分层，而是类似于独立做了两张地图。

下面是几份标准的分层逻辑：

不同的分层组织方式

将高速公路与城市公路分开建模的方式

数据的分层方式是《高精地图标准》的核心点，其需求是：

1. 最全面的驾驶相关要素 与 拓扑信息覆盖；

2. 最全面、清晰的数据分层逻辑；

3. 尽量少的信息冗余；

而想要满足上面三条需求，也的确是件很困难的事情。

• 全面性需求

仅在第一个“全面性需求”上，国内发布的几份标准基本就全体阵亡，基本无法覆盖到所有的路面要素。当然一些标准也具备其独到之处，比如《汽车工业协会标准》，就将**“智能路侧设备”也考虑了进去，也是个具有前瞻性的好想法。但如果一味看重全面性，将所有的事情考虑的特别周末，那么就会不可避免陷入了极为晦涩难懂的“超重文档”**陷阱（典型案例NDS）。

• 逻辑清晰需求

数据分层的逻辑无对错但有优劣。比如，上图左侧的分类标准中，将所有道路要素拆分为**“道路级路网”、“车道级路网”、“路面标识线”、“道路附属物”** 四个图层，其整体分类较为清晰。《交通运输部标准（意见稿）》将高速公路与普通公路拆分建图，是不错的想法。但其道路分层却太过简单，只有**“道路”、“路内路侧参考对象”两个图层，**而后者中填充了过多的信息，显得过分臃肿。

• 少信息冗余

思考以下案例：

**举例1：**某一路段有限速牌，自然可以将其作为一个元素纳入HDMap。给其打上时间、位置，限速数值等Tag。而其实，道路本身也有一个附带的Speedlimit属性，于是两种表达其实产生了一定的冗余。当然这种冗余是可以接受的，但如果一份标准内存在过多的重复性表达，则是不合理的。

举例2：如果道路图层使用基准面来表达，其自动包含了道路的宽度、边界、超高、截面形态等信息。而如果采用道路基准线来表达，则需要额外对这些信息进行表达。

3.3 地图要素来源

从质量把控角度和安全角度出发，高精地图应当需要保证数据的可追溯性，在出现问题的时候能够 “责任到车”。**《自动驾驶地图采集要素模型与交换格式》**这份标准中提到：对每一个要素的数据来源进行记录，无论数据是来源于专业采集车、专业众包、或者是非专业众包车辆，这是一个不错的建议。

3.4 存储的格式

a. XML（Extensible Markup Language）——显然XML格式的地图是十分轻量化、方便解析的表达方式，OpenDrive和OpenDrive-Apollo都采用了此种表达。当然，JSON和Google Protocol Buffer等数据交换格式其实也是可以的；

b. SHP（ESRI Shapefile 3D）——采用矢量化GIS格式同样能够存储HDMap数据；

c. SQlite——直接用数据库，NDS是如此。

Ref：

1. Shapefile - 维基百科，自由的百科全书 (wikipedia.org)

2. XML - Wikipedia

3. SQLite - Wikipedia

4. 现有HDMap标准

看完上面，应当对HDmap的组织标准有了一定的概念，那么下面来简要介绍现有的标准：

4.1 国内外标准现状

1、高精地图相关组织机构:

国际：NDS协会、OpenDrive协会、ADASIS AISBL协会、ISO-TC22工作组、SENSORIS平台、OADF开放式自动驾驶论坛等。

**国内：中国智能网联汽车产业创新联盟（CAICV，工信部主导）、**全国智能运输系统标准化技术委员会（SAC/TC 268）、交通运输信息通信及导航标准化技术委员会等。

2、高精地图标准：

国外：NDS-Navigation Data Standard标准 (欧洲-德国)、ASAM-OpenDrive标准（欧洲-德国）、ADASIS标准**（欧洲-比利时）**、KIWI标准（日本）和Open LRTM。

**国内：**见4.3节

Source：中国智能网联汽车产业发展报告（2020）.pdf (可以没事翻翻)

4.2 国外高精地图标准简介

4.2.1 NDS标准

NDS是面向汽车生态系统的地图数据全球标准，由NDS协会起草。NDS协会是由汽车生产厂商、系统商以及图商合作建立的组织，总部位于德国Wolfsburg。

NDS标准是导航电子地图数据格式标准，由于该标准规格具有较好的兼容性和可扩展性，目前高精地图也可以采用其标准规范及数据格式。**NDS标准的文档非常的厚重，最新2.5.4版本文档已经达到1100多页，**理解文档内容要花费很大精力，参考资料较少。笔者看了一会儿就放弃了。

NDS在数据更新、数据安全度、数据可靠性上拥有一定的优势，所以普遍应用于车规级导航产品。

NDS标准包含元素

NDS的设计模型特点：

一份NDS数据可以称为是一个Database，它是一个规范化的数据库。这意味着，只要按照这个标准规格去生产NDS数据，得到的数据格式将是一致的。一个NDS Database可由多个Product Database组成，这些PD可以来自不同的供应商，且可以进行独立版本更新。每一个PD都可以被进一步的划分成多个Update Region。

NDS数据库中，导航数据按照不同的功能，被组织成不同的Building Block。Building Block的Type定义了储存在其中的数据的功能，为满足不同使用场景，导航应用需要对不同Type的Building Block进行过滤和组合，比如，需要计算一条路径并显示在车机屏幕上，就需要同时调用Routing和Basic Map Display这两个Building Block。

ref：

1. 高精地图数据格式NDS了解一下_搜狐汽车_搜狐网 (sohu.com)

2. NDS：一种适于更新的导航电子地图数据存储标准_导航电子地图的专栏-CSDN博客_nds地图

3. SQLite_百度百科 (baidu.com)

4.2.2 Opendrive 标准（重要，需要深入了解）

OpenDrive属于Open X自动驾驶仿真测试标准中的一环，由德国_ASAM_ (Association for Standardisation of Automation and Measuring Systems, 自动化及测量系统标准协会)发布，用于描述仿真场景的静态路网，采用XML格式存储。

另外，在ASAM-Open X系列标准中，道路的表面细节由OpenCRG描述，动态场景由OpenScenario描述，三者构成了对一个场景的建模。

OpenX 系列标准的关联

OpenDrive标准下的旧金山高精地图 XML格式

OpenDrive是自动驾驶行业内一个相当重要的标准。作为HDMap的标准只能算是OpenDrive的“副业”，该标准研发的最初目的是用于自动驾驶的仿真场景描述，这也使得OpenDrive可以作为现实的高精地图和虚拟的仿真静态场景之间的桥梁。也因此，该标准在自动驾驶领域应用极为广泛，主流的高精地图厂商、以及自动驾驶开发工具链条的厂商基本都支持该标准。

并且，与NDS相比，OpenDrive就要平易近人许多，其文档结构十分易懂，扩展性也更好。每一个自动驾驶的从业者，都有必要对OpenDrive进行详细的解读

4.2.3 高精地图的车内传输：ADASIS V3

ADASIS标准接口定义了地图在ADAS和自动驾驶应用程序中的数据模型和传输方式，主要是针对地图与车载应用之间的标准接口，该标准使ADAS和自动驾驶应用程序能够访问描述车辆前方道路网络的地图数据。

具体地讲：目前高精地图在车端的存放位置一般是放在单独的Map Box内，或者放在自动驾驶/辅助驾驶的域控制器内，比如当前小鹏、蔚来采用的都是Map Box。在自动驾驶车辆运行时，通过车载LiDAR、Camera采集道路数据并进行处理，与高精地图进行匹配后即可获得车辆的精确位姿，最终地图信息以及位姿信息会一同以**电子地平线（EHP）**的形式给到自动驾驶域控制器。此过程需要以一套标准数据传输协议，而ADASIS v3就是为此而制定。

ADASIS V3的作用：车内的数据交互

因此，Adasis V3并非一种专门的高精地图的模型，**而是一种高精地图在汽车内部的传输标准。**ADASIS协议包括了：

￮ **ADAS Horizon Provider：**此处Horizon可理解为是基于原始地图分析计算而得到的一种数字地图模型，并非狭义的视野或地平线；

￮ **ADAS Protocol：**ADAS通信协议；

￮ ADAS Application：ADAS应用，负责数据的接收和应用（例如ADAS Reconstructor：ADAS应用中用于接收、解析数据的组件）

4.3 国内高精地图标准

4.3.1 《智能驾驶电子地图数据模型与交换格式》

**该标准由交通运输部组织，全国智能运输系统标准化技术委员会归口，四维、高德、百度、中海庭（上汽）、北建大主导编写。申请非强制性国家标准GB\T，**早在2019年6月即发布征求意见稿，但此后没有更新消息。

征求意见稿发布源网页、各起草单位分工

就是该标准将道路分成了“高速公路” ，“城市公路”两个场景，其逻辑表达框图在4.1节有展示。高速公路建设更为标准，包含的驾驶要素更少，而且具备良好的封闭属性。因此，其逻辑可以被独立设计的更为简单。这是一种不错的分层思路，对潜在的业务落地也有好处。

该标准对交通要素的涵盖很全面，给出了具体的数据模型，包含了要素的 “几何特征” “拓扑关系” “固有属性” 。但其缺点是其图层划分较为简单，仅拆分成了 “道路” 与 **“路内与路侧驾驶参考对象”**两个图层，致使单个图层包含的信息量过大。尤其是城市道路要素更多的情况下。

数据模型案例："道路"的数据模型与存储信息

4.3.2 《道路高精度电子导航地图数据规范》

该标准由自然资源部组织，武汉大学主导编写，北建大、同济、中海庭、华为、四维、高德、百度、腾讯、上海测绘院都参与了编写。于2019年12月发布征求意见稿，申请CHT测会行业推荐标准。

在92页的标准对地图的组织模型、道路图层、元素表达、数据存储都做出了详细的规定，**完备性较高，可以读一下。该标准的一个特点是要素的属性较为全面，**例如桥隧、停车场都给出了很细致的属性表，这一点在其他标准上没有见到（当然，也需要判断，这些属性里面是否存在大量与驾驶无关的属性，或者重复表达的属性）。

桥隧、停车场属性全面

4.3.3 《电子公路图地理要素高精度表达规范》

该标准由交通运输部组织，中国交通通信信息中心主导起草。目前处在征求意见阶段。拟申请推荐性国家标准。

该标准的特点是：按照矩形分幅或者经纬分幅0方式，对高精地图分块。而并非采用行政区划的方式。

该文档内容较少，仅给出了地理要素的 “点线面” 表达方式，通俗点说，就是通篇只讲了 “道路应该用Polygon表达，龙门架应该用Point表达 Blablabla” 这一个问题。而对 **要素属性、图层划分、拓扑关系、数据存储与交换没有任何说明，**暂不认为其具备实际的指导意义。

仅有：要素的“点线面”表达规范

4.3.4 《自动驾驶地图采集要素模型与交换格式》

中国汽车工程学会组织，易图通，高德，东软，晶众，VGC等参与编写。于2021年5月批准发布：T/CSAE 185-2021。是当前唯一的已发布的标准，为团体标准。

该标准将道路分成了**“基本场景”、“道路交通标志”、“道路交通标线”、“其他道路安全设施”、“智能路侧设备” “扩展与自定义”** 6个图层。其特点是，“基本场景”图层里包含了 “道路” 和 “停车场” 两种场景，可为自动泊车提供高精地图服务；另一方面，加入了“智能路侧设备”的图层，对用于信息采集、感知、计算、传输的自动化的设备也进行了抽象化表达。

下一章就以该标准为例，详细解读一下高精地图标准文档，其他标准的解读方式也大体类似。

_个人意见：_国内这几个所谓高精地图标准，似乎都是国内图商为抢占高精地图标准的话语权的产物，各家都在申请标准拉一个官方部门站台背书。不过，当前的标准都是推荐性标准，而非强制性标准，厂商们可以互相参考，并非必须遵守（GB/T，CH/T，CSAE/T）。甚至，个别标准就是赶鸭子上架的产物，完全不具备前面提到的“囊括所有驾驶相关的道路要素” 的准则，与NDS,Opendrive等迭代了数个版本的标准更是相去甚远。

5. CSAE/T 185 2021标准解读

5.1 基本信息

该标准采用了CGCS2000国家大地坐标系，经纬度坐标值精确到0.000,000,01度，高程坐标精确到0.001m，时间采用协调世界时（UTC）。

分区采用行政区划来划分地图的区域。地图存储格式未明确，仅说明 **“采用通用的地理信息数据存储格式”。**对“专业采集”、“众包采集”的要素来源做出了规定。

下图是该标准的采集要素构成。该图清晰给出了5个图层分别包含的要素，以及各要素之间的连接关系。比如，其他图层中几乎所有元素都会连接同一个内容——道路路面。

采集要素的构成

5.2 采集场景基本信息

采集场景分为室外道路与停车场两种。是一切道路对象的载体，也是所有图层的中心。

5.2.1 室外道路：

几何：

道路几何用3D面表达。

属性：

a. **路面编号：**当前道路的ID，道路的唯一“身份证”

b. **类型：**路段还是路口

c. **采集时间：**如2021.11.23 11：00，反映地图新鲜度

d. **数据来源：**来源激光 or Camera，来源于专采 or 众包?

e. **分区编码：**行政区划编码，如：北京110000

最终可以形成一个道路路面属性表如下：

序号	字段名称	字段说明	字段类型	属性值说明	空值说明
1	Road_Area_ID	道路编号	Int	-	非空必填
2	Type	类型	Int	1：路段 2：路口	非空必填
3	Collection_time	采集时间	Str	格式为：YYMMDD	非空必填
4	Data_Source	数据来源	Int	1：激光 2：影像 3：其他	非空必填
5	Belong_Area	分区编码	Int	-	非空必填

可以看到，这个属性表是相对简略的，而且还没有表达与其他道路的连接关系，那我们参考其他标准，尝试为它添加一些更详细的信息：

序号	字段名称	字段说明	字段类型	属性值说明	空值说明
6	Direction	交通流方向	Int	1：双向 2：矢量同向 3：矢量反向	非空必填
7	Length	道路长度	Float	-	非空必填
8	FC	道路等级	Int	1：一级 2：二级 以此类推	非空必填
9	NR	管理等级	Int	1：高速 2：国道 3：城快 4：省道 （后略）	非空必填
10	FW	道路形态	Int	1：辅路 2：环岛 3：掉头专用道 4：左转专用 5：右转专用 后略	非空必填
11	RSTRUCT	特殊结构	Int	1：桥梁 2：高价 3：隧道	非空必填
12	SR_Node_ID	起点道路编号	Int	表达道路的连接关系	type=2不填
13	ER_Node_ID	终点道路编号	Int	表达道路的连接关系	type=2不填
14	SG_Node_ID	起点路口编号	Int	起点与路口连接，则填写	type=2不填
15	EG_Node_ID	终点路口编号	Int	终点与路口连接，则填写	type=2不填
16	Max_Speed	最高限速	Int	该项实际上与路牌重合

是不是这样就比较全了？其实还没有。我们应当对城市交通规则的复杂性有所预期，有很多意料不到的道路特征需要去描述。比如，仅道路的限制属性还可以有：道路的限重信息（e.g. 20t）、道路的限制车型信息（如重型车专用车道）、道路的限制时间信息（XX路段在24：00-6：00对重型车开放）。

5.2.2 停车场基本信息：

停车场分为**“停车场基本信息”与“停车场背景”**两部分表达。前者在HDmap中表达为一个点，后者则表达为一个具体的3D面。有点类似于游戏中进入副本（停车场背景）时候要通过传送门（基本信息）。

基本信息——属性：

a. **停车场编号：**停车场的ID，“身份证”

b. **停车场名称：**停车场的具体名字，如：“XX商业中心地下停车场”

c. **类型：**室外停车场还是室内停车场？

d. **楼层数：**停车场的层数

e. **采集时间、数据来源、分区编码：**同前

背景——属性：

a. 停车场背景编号：

b. 停车场背景名称：

c. 类型：

d. 所在停车场编号：

e. 限高信息：

f. **采集时间、数据来源、分区编码：**同前

最终可以形成两个停车场的属性表如下(共同项已省略)：

序号	字段名称	字段说明	字段类型	属性值说明	空值说明
1	Parkinglot_ID	停车场编号	Int	-	非空必填
2	Type	类型	Int	1：室外 2：室内 3：综合	非空必填
3	Floor_Num	楼层数	Int	-	非空必填
4	Name_CS	中文名称	Str	-	非空必填

5.3 道路交通标志

道路交通标志是以颜色、形状、字符、图形等向道路使用者传递信息、管理交通的设施。交通标志可以辅助车辆定位系统进行匹配定位，其语义信息也可以为后续的驾驶决策提供道路属性。

典型的道路交通标志

几何：使用3D面表达，如使用标志的外接多边形表示。

属性：

a. **交通标志编号：**交通标志的ID；

b. **形状：**矩形、正三角形、倒三角、圆形、八角形等等；

c. **类型：**警告标志、禁止标志、指令标志、指路标志、旅游区标志、作业区标志、告示标志、辅助标志等；

d. 可变信息标识：标志牌是否可提供动态信息；

e. **标志牌底色：**红、黄、蓝、绿、棕、黑、白、橙 etc；

f. **照片编号：**对每个道路交通标牌单独存储照片；记录照片ID；

g. **采集时间、数据来源、分区编码：**同前

如此一来：又可以形成一张属性表：

序号	字段名称	字段说明	字段类型	属性值说明	空值说明
1	Traffic_Sign_ID	交通标志编号	Int	-	非空必填
2	Collection_time	采集时间	Str	格式为：YYMMDD	非空必填
3	Data_Source	数据来源	Int	1：激光 2：影像 3：其他	非空必填
4	Road_Area_ID	所属道路编号	Int	-	非空必填
5	Shape	形状	Int	1：矩形 2：圆形 后略	非空必填
6	Type	类型	Int	1: 警告 2: 禁止 3:指示 后略	非空必填
7	Variable_Sig	可变信息标识	Int	1: 可变 2：不可变	非空必填
8	Color	标牌颜色	Int	1: 红 2：黄 3：蓝 后略	非空必填
9	Photo_ID	照片ID	Int	-	非空必填

但上表有一个严重的问题：它没有给出标牌的具体语义信息，”Type类型”给出的信息不够明确。如“限速80”、“禁止停车”。其寄希望于提供Photo给自动驾驶系统，让其自行识别。这对于一份HDmap而言是不称职的。因此需要来解决一下这个问题，给这个表增加两行：“标牌种类编码”，“标牌显示值”。

序号	字段名称	字段说明	字段类型	属性值说明	空值说明
10	OBJCode	标牌种类编码	Int	-	非空必填
11	OBJValue	标牌显示值	Int	-	非必填

我们首先收集全国所有的交通标志，然后将其归类、编码。每一种交通标志都有唯一的类型码和编号码，如果上面有值，就再加一个Value（比如，限速标对应的Value可以是120）。如此三个码，就完成了语义信息的简化传输。下面是一些交通信号标志的编码案例：

交通标志的编码表案例

交通标志的编码表案例

5.4 道路交通标线

这里的道路交通标线是指：道路上的各种线条、箭头、文字、图案及立面标记、实体标记、突起路标和轮廓标等等。通俗理解，标志是在空中的，标线是刷漆在路面，或者安装在路面的。起作用无非还是传递语义，辅助定位。

我们可以将道路标线拆分为：线状和面状 两种。线状就是车道线那一类，面状就是左转、右转箭头那一类。

5.4.1 线状

**几何：**3D线，根据表达的线状标识的种类，有所分别：

a. **车道分界线：**颜色、虚实、单双线

b. **潮汐车道线：**两条黄色虚线表达

c. **左转待转区：**平行的两条曲线

d. 路口导向线：白色实线

e. 导向车道线：

f. 公交专用车道线：

g. 停止线：

h. 停车让行线：

i. 减速让行线：

j. 后略

属性：

a. 线状标线编号：ID

b. 类型：即上面的线状标识的“种类”

c. **形态：**单实线 or 双实线 or 单虚线 or 双虚线

d. **颜色：**一般为白、黄、也有其他颜色

e. **长度：**标线长度，米

f. **标线宽度：**米

g. 照片编号、采集时间、数据来源、分区编码：同前

评论：比较有意思的是，这个标准并没有将“车道网”建设为一个显性的图层，而是将其逻辑隐含到了“车道分界线”内。这样看似节省空间，但这并非一个好方法。车道级定位、路径规划在ADAS、自动驾驶领域十分重要，使用频率极高，将其信息建设为一个单独的图层很有必要。

5.4.2 自建车道级图层

那么，我们就按照这份标准的逻辑来自建一个简易的车道级网络。

车道级路网示意图

车道属性：

几何：使用3D线Polyline表达，和OpenDrive几乎一样

属性：

a. **车道编号：**车道的唯一身份ID

b. **车道类型：**一般车道、路口虚拟轨迹车道、加速车道、减速车道、上坡车道、路口直行车道、路口左转车道、路口右转车道、ETC专用道、潮汐车道、应急车道、紧急停车带、公交港湾车道、掉头车道、避险车道、非机动车道 etc.

c. **车道号码：**右侧道路从里向外按-1,-2,-3,…编号；左侧道路从里向外按1,2,3,…编号；注意！与前面的车道编号不是一回事。

d. 车道长度：

e. **车道起点编号：**与该车道起点相连接的另一条车道的编号。

f. **车道终点编号：**与该车道终点相连接的另一条车道的编号。

g. **道路编号：**该车道隶属于哪一条道路？

h. **所属路口编号：**针对路口车道。路口车道连接关系中发挥作用

i. **左侧纵向标线编号：**即车道前进方向的左侧边界

j. **右侧纵向标线编号：**车道前进方向的右侧边界

k. **采集时间、数据来源、分区编码：**同前

车道的编号规则，参考opendrive

那么根据上面的属性，我们就可以作出一张属性表（省略）。

路口车道的连接关系：

**几何：**无

图层属性：

a. 路口车道连接关系编号：ID

b. 所属路口编号：

c. 起始车道编号：

d. 结束车道编号：

e. 起始道路编号：

f. 结束道路编号：

g. 路口内行驶轨迹路链：

h. **采集时间、数据来源、分区编码：**同前

车道连接关系样例，参考OpenDrive

5.4.3 面状

**几何：**3D面

a. **导向箭头：**外接矩形；

b. **导流线：**轮廓多边形；

c. **减速带：**外接矩形；

d. 人行道：外接矩形；

e. **人行道预警：**菱形轮廓；

f. 紧急停车区（高速）：轮廓多边形；

g. **网状线：**外接矩形；

h. **路面数字/文字/符号标识：**外接矩形；

i. **减速让行线：**外接矩形；

j. 后略；

属性：

a. 面状标线编号：ID；

b. **类型：**即上面的面状标识的“种类”；

c. **颜色：**一般为白、黄、也有其他颜色；

d. **箭头类型：**是否为方向箭头；

e. 照片编号、采集时间、数据来源、分区编码：同前；

交通标线的属性表在此就略去不写了，应该不难推测其写法。

注：停车场有不少专用的标线，都可以归类在停车场场景中，在此不做叙述；

5.5 其他道路安全设施

这一部分的内容相对比较琐碎。其种类包含但不限于：

a. 交通信号灯：外接矩形；

b. **支撑结构：**路灯杆、标牌杆、红绿灯杆等。可用3D线表达。限高横杆、龙门架这类横向的结构也可以用3D线表达；

c. 路侧防护设施：金属围栏，水泥围栏，警示柱，路牙子，自然边界、排水渠都可以用其最高处的轮廓线来表达；

d. 停车场的墙体、其他停车场的安全设施等；

属性表省略不写。

5.6 智能路侧设备

这部分简要提下

a. **点状要素：**安防相机、雷达、RSU等智能设备；

b. **线状要素：**智能道钉；

c. **面状要素：**3D智能路灯；

最后，我们再来看一下这份标准的导图：

CSAE/T 185 2021图层划分