目录 Catalog

0 本文希望解决的问题
1 现有的地图数据以及数据格式
- 1.1 现有的地图数据
- 1.2 数据格式
2 数据获取方式
3 一种中间数据格式
4 路采的指导方针
5 案例
6 展望
参考文献

原文：Deploying guidelines and a simpliﬁed data model to provide real world geodata in driving simulators and driving automation
原文标题太长了，博客标题都打不下了……

本博客不是翻译原文，只是把原文讨论的一些要点记录下来。部分文段不知道如何翻译成中文，暂时保留原文。

0 本文希望解决的问题

随着自动驾驶系统愈发复杂，对自动驾驶系统的验证方式也愈发复杂。此时驾驶模拟器在自动驾驶系统的开发与验证中起到关键作用。然而，模拟器中的路网是需要通过建模生成的，手动地建模是非常费时费力的。因此，我们希望能把specific surveying转换为domain-specific formats，然后从domain-specific formats地图数据自动地转换为路网模型。本文作者想着重解决的，就是把specific surveying转换为domain-specific formats的过程费时费力的问题。本文提出了一种简化的数据格式，以及一些路采的指导方针，希望能让地图供应商的路采数据（geodata）更加丰富而不失便捷，同时又能很容易地转换为如OpenDRIVE的地图数据格式，即domain-specific formats。

1 现有的地图数据以及数据格式

1.1 现有的地图数据

现有的许多官方的地图数据以数字化的方式管理（如通过INSPIRE initiative，即Infrastructure for Spatial Information in the European Community），对地籍信息的管理有很强的针对性。这些地图数据被用于数字城市模型的生成、solar potential analysis以及computation of noise propagation. 基础设施以及城市绿化的信息也以数字的方式管理，空中的测绘不仅可以生成图像，还可以生成衍生的数字城市模型。

不同的地方机构测绘得到的地图数据的质量和用途是各式各样的的，这取决于他们有多少资源去维护地理信息系统（GIS）. 如Braunschweig, Germany对基础设施就以记录空间信息、设施类型、朝向等信息的方式管理。Stuttgart, Germany就用georeferenced CAD tile system管理，这种以图形方式存在的数据难以转化为离散的数字化基础设施数据。

多年来，驾驶领域用地图数据作为导航数据。这类数据通常以图（graph）的形式附加车道、关键点的信息存在。然而，受限于全球导航卫星系统（GNSS）的精度，这些数据难以用于进行高精度的建模。

在动力传动应用中，包含高度信息或详细路线信息的数据常常被使用。这些数据专注于车道平面的建模，只考虑了车道线与边界的信息，而没有考虑人行道等信息。此外，目前这类信息只包含了现实中的少数道路，无法进行大规模的使用而只能用于测试。

谷歌则使用汽车的传感器信息手动生成他们用于自动驾驶的地图。

OpenStreetMap这类来自群众的数据包含了许多有用的信息，包括车道线数量、道路限制以及基础设施信息。可惜精度有限，而且数据的表示不适用于自动驾驶以及模拟器建模。

1.2 数据格式

通常，驾驶模拟器会使用自动驾驶模拟相关的路网描述格式。这种数据格式会用一系列数学模型来表示道路的几何特征，以及严格的道路间关系与关联属性。具体的格式如OpenDRIVE, RoadXML, IPGRoad.

然而，公共的地籍信息通常以纯粹的视觉表征表示真实世界的特征。如道路表面简单地以离散的边界线或者泛华的多边形表示，与精确的交通基础设施没有直接的关联。这类数据通常从analogue maps转换而来，精度受限，转换为domain-specific的模拟器格式时，需要综合额外的几何信息（如车道边界的几何表示），以及道路与基础设施的逻辑关联。

交通流模拟以及导航应用是基于如OpenStreetMap的可路由路网，这类数据通常以图的方式表示，可以用于提取逻辑信息。这类信息以GPS Exchange Format（GPX）的格式，或二进制格式的数据库提供。

由不同数据源组合形成可用于交通模拟的数据是可行的，而为了减轻这些数据对模拟应用带来的限制，我们需要运用成体系的地理数据的移动测绘方式。

2 数据获取方式

数据获取任务可以分为测量任务与数据格式化任务。用于驾驶模拟和自动驾驶的数据比地籍数据复杂得多，而大部分测绘公司并不熟悉数据格式化的流程。OpenDRIVE和RoadXML定义的道路信息与基础设施信息是非常数学化的，以及关联性强的，Navigation Data Standard（NDS）则是公众无法访问的，以二进制格式实现的数据格式。

把测量数据转换为目标格式的任务是费时费力的，因为提供者需要手动处理与标注原始的测量数据。城镇交汇区域有非常复杂的道路逻辑关系，标注非常容易出错，这提高了编辑标注的难度与消耗。由于提供者的测量方式各不相同，提供者们需要制定各自的数据格式化的工作流，因此他们之间没什么竞争关系。各自的数据转换为目标格式都是非常耗时的，而近年来，NDS用于自动驾驶的需求即将到来，这些数据转换为NDS格式的需求也逐渐诞生。

政府机构常常需要新增或更新地籍数据，这种情况下，目标格式依然可能离散化、通用化，不方便简单后处理之后就提供给模拟领域应用。为此，本文制定了扩展属性的常规地理数据测量指南，该指南可支持更简单和自动化地处理为上述模拟格式。

3 一种中间数据格式

German Aerospace Center（DLR）和很多OEM拥有很多复杂数据的获取与转换经验。然而，大部分由他们出版的作品都是手工进行，或者通过Google的方法解决的，参考价值不高。

高精地图通常需要考虑的用途与受众有驾驶模拟、政府机构、道路公司、自动驾驶应用，它所管理的信息需要满足这些需求。本文的解决方案是一种满足潜在用户需求的道路测量与原始数据预处理方案。该方案以一种简化的数据格式提供路测数据，这种数据格式可以进一步地转换为其他复杂的domain-specific数据格式。这样的数据格式并非是新的标准化格式，但是可以作为一种中间的数据格式，搭建中间层数据中心。

这种中间格式为具体的domain-specific数据格式之间提供了无信息损失的转换枢纽。该格式用OGC simple features和定制化GIS进行可视化。数学拟合与变换可以解耦所有的数据格式转换，使得每种格式转换都可以独立调整。转换过程如图1所示。

Fig. 1. Schematic representation of the conversion process.jpg

指导方针的基本思想是通过第三方移动测量的供应商的简单测量，在用户端（如模拟器中）进行数据格式的自动转换。在中间层的简化数据模型的帮助下，转换会变得便利。简化的数据模型具有路网生成需要的、由目标格式泛化的附加的元数据。该中间格式参考了OpenDRIVE格式，因为OpenDRIVE在模拟领域中地位突出（所有Road2Simulation项目伙伴都使用），且使用OpenDRIVE是royalty-free的，和其他格式也有相似之处。简化的数据模型的关键元素与关系如图2所示。

Fig. 2. Simpliﬁed data model of the guidelines with key elements (blue) and hierarchical elements (grey)

该模型的基本方针是使用各种不同密度的指定点构成的折线描述道路结构。高密度的采样点用于对曲线等几何构型的高精度建模，低密度采样点用于直线建模。如果在转换为domain-specific的格式时需要进行插值，高密度的采样有利于保持精度。

车道线和标线、路障以及其他线型物体（linear objects）构成了道路的主要部分。单点的坐标描述基础设施，如道路标志、交通灯、特殊标线、路灯等道路物体。一些类似安全岛（traffic islands）在已提及的模拟器格式属于较难构造的物体，目前他们的处理方式均为把他们描述成多边形区域，所以中间格式也这么处理。所有建模features都用储存为常用二进制或基于OGC Simple Feature Access的文本格式的3D简单features，这为大部分GIS工具提供了可访问性。

所有这些元素都含有附加的元数据，包括父元素的信息、元素的类型与外观属性，以及与数据源的描述的连接。比如，车道线边界元素包括父元素、几何描述、数据源信息、车道线轮廓的类型（可以为driving, parking, restricted, sidewalks等）以及材质（可以为asphalt, concrete, pavement, cobble等）。

每个元素的数据源描述包括绝对与相对误差、日期，以及质量描述（包括数据源的natural description，如地籍簿文件名、创建日期、传感器固件版本、数据处理、融合的记录）。这样一来，用户可以对数据进行评估，从而确定他们的用途。

4 路采的指导方针

对于德国来说，道路结构通常包括单车道（one-lane roads）、多车道（multi-lane roads）、单行道（one-way roads）、高速公路（motorways）、具有物理隔离的路（roads with physical separation）、具有复杂交叉路口的路（complex intersections）以及环岛（roundabouts）。我们需要关注的是，哪些信息、特征是路测的时候需要采集的。

核心元素应该以支持各种数据转换的具体方式构建。比如，道路的建设总是在交叉路口之间，这样一来道路元素不会两两相连。如果道路中不存在物理隔离，那么描述道路走向的折线应该位于道路中心。如果有物理隔离，那么在右手交通（right-handed traffic，同中国）的情况下描述道路走向的折线应该是最左侧车道线。例子如图3所示。

Fig. 3. Different road situations with marked course of the road (green) and lane borders (cyan).

交叉路口的车道线连接关系需要特殊处理，并非所有需要连接的通路都是现实存在的，但却是模拟器建模需要的。图4展示了路口中所有主方向的连接关系。U型弯被构建了出来，这个路线在现实中可能是不存在的，但是在模拟器中，我们需要通过建模的方式体现道路的物理隔离。

复杂路口被分解为小而简单的路口，如图5所示。这个方法也被用于处理环岛与高速公路出入口（如图3右下角所示）。

基础设施和其他物体的定点信息只用包含位置、旋转和类型，以及外观、文字、朝向等可视化相关信息。（如图6所示）

Fig. 4. Intersection with connections for each cardinal direction.

Fig. 5. Decompiled complex intersection.

Fig. 6. Punctual information (magenta) about signage, street lighting and road furniture.

为了适应多种希求的预处理，本文的方案把建模方式分为标准方式与扩展方式。标准方式只需要构建道路与关键的基础设施，此时道路的表示停止于路边（kerbside），就像NDS格式描述的那样。扩展方式包括所有其他事物，描述了整个交通区域的外观（包括道路之外的事物）。物体的增删取决于目标格式。

总地来说，本文的方案为测量得到一种简化的、中间的道路模型，以满足地籍机构与复杂模拟数据格式的需求（后者可以由一系列处理工具链转换得到）。如何得到这样的中间格式的数据并不重要（可以是移动路测、航空影像或从地籍数据得到）。该方法包括一个元数据目录，包括几何精度信息、获取程序的技术细节以及（如适用）已经应用的处理步骤。

5 案例

案例为找到多加供应商对14km长的位于Stuttgart, Germany的测试道路，从2016年Q2季度开始，到2016年Q4季度结束。路网结果被转换为OpenDRIVE和OpenCRG（用于描述路面细节信息）格式。用于模拟器的3D模型由不同的地籍数据源通过"Virtual World"方法

（还没有好的途径访问到这篇论文 _(:з」∠)_）
生成为OpenSceneGraph格式。图7为GIS可视化的预处理后的测量数据与Stuttgart地籍数据（例如数字地形模型以及数字城市模型和树形地籍）的比较。

路测的过程略。结果大概是：供应商对这一套方案的理解没有明显的分歧，而且因为中间格式的构建不需要复杂的数学建模，中间的小问题很容易就解决了。只是他们自己的转换到OpenDRIVE的工具链需要改进（没有详细说明）。

Fig. 7. Surveyed and pre-processed data in combination with cadastral data.

6 展望

该方案在验证与测量的经验后得以更新，之后会be published for free（不知道现在有没有），以便其他公司、机构使用。这对于自动驾驶领域、地籍信息更新、大规模路网数据的管理来说至关重要。

此外，该方案也将对未来可能出现的domain-specific格式进行扩展，也将针对道路旁边如建筑、道路绿化等地带进行描述。这将会是一个挑战。

参考文献

[1]. Richter, A. and M. Scholz, Deploying guidelines and a simplified data model to provide real world geodata in driving simulators and driving automation. Transportation Research Part F: Traffic Psychology and Behaviour, 2019. 61: p. 305-313.

Deploying guidelines and a simpliﬁed data model ...文献笔记相关推荐

ExtJS教程（5）---Ext.data.Model之高级应用
1.Model的数据验证这里借助官方的一个例子来说Model数据验证的基本用法 Ext.define('User', {extend: 'Ext.data.Model',fields: [{ nam ...
FlowableException: Error initialising dmn data model报错问题
flowable war包启动失败,报错Caused by: org.flowable.common.engine.api.FlowableException: Error initialising ...
An eventually consistent data model for Erlang (and Riak)
CAP理论指出:一个分布式系统不可能同时满足一致性(Consistency).可用性(Availibility)和分区容忍性(Partition Tolerance)这三个需求,最多只能同时满足其中的 ...
vs2010下使用ADO.NET Entity Data Model
使用vs2010中的mvc3创建项目,同时想使用ADO.NET Entity Data Model来做数据库访问,可是创建项目后中不到 ADO.NET Entity Data Model. 一下是解决 ...
ADO.NET Entity Data Model入门实例
ADO.NET Entity Data Model入门实例快速开发一个网站,最繁琐的地方可能要算数据库访问和ORM了,还好.net中这个很强大,可以省去好多体力劳动. 这里就给个快速使用ADO.NE ...
四、物理数据模型PDM(Physical Data Model )
一. PDM 介绍物理数据模型(Physical Data Model)PDM,提供了系统初始设计所需要的基础元素,以及相关元素之间的关系:数据库的物理设计阶段必须在此基础上进行详细的后台设 ...
SAP Cloud SDK‘s Virtual Data Model
官网链接 SAP S/4HANA Cloud 和 On-Premise 公开的大部分服务都是 OData 服务. OData 是一种 RESTful API 协议,具有两个关键特性: 每个服务都由元数 ...
Entity Data Model (EDM) 深入分析, Part 3
EntityClient 实体框架(Entity Framework)在ADO.NET 3.5 提供程序的基础上引入新的 ADO.NET 提供程序 EntityClient.Entity-Client ...
大数据入门9：半结构化数据模型（Semi-structured Data Model)
文章目录半结构化数据模型(Semi-structured Data Model) 1. 几种数据模型 2. 半结构化模型特征 3. XML和JSON 4. 树状数据结构(Tree Data Stru ...
图解图库JanusGraph系列-一文知晓“图数据“底层存储结构（JanusGraph data model）
图解图库JanusGraph系列-一文知晓"图数据"底层存储结构(JanusGraph data model) 大家好,我是洋仔,JanusGraph图解系列文章,实时更新图数据 ...

Deploying guidelines and a simpliﬁed data model ...文献笔记