导读：每当打开一幅地图数据，比如高德、美团、滴滴或者快的打车，你头脑中一定会浮现出一个问题，这些几何数据是怎么设计的呢？要如何设计才能快速显示或者导航呢？所以本文将讲述LBS应用的数据设计方法。

与LBS有关的数据多种多样，大致可以分为：用户数据、地图数据和显示文字数据。其中，用户数据由不同的应用来定义，如用户的聊天记录或对战记录；文字数据往往是和兴趣点相关的，如商铺信息或用户的微博。用户数据和文字数据架构的构建不是LBS数据构建的难点，LBS数据的难点在于对地图数据的理解。

一幅地图数据的大致样子如图1所示。

可以看出，地图数据去除附加的一些属性（如属性、名称等），从几何的设计构成上说，主要由点、线、面组成，比如：

• BMD（基本显示模块）：主要是线、面；
• 3D（三维建筑物）：主要依赖于点；
• POI（兴趣点）：主要是点和文字；
• ROUTE（道路）：主要是线（道路）、点（道路的拓扑点）、线点线（交规）；
• JV（路口指示）：主要是线点线（路口指示）；
• ADMIN（行政区划）：主要是面；
• VOICE（语音）：属于附加属性；
• ORTHO（卫星正交影像）：属于面；
• DTM（数字高程图）：属于面；
• TMC（实时交通信息）：主要是点、线、面三种类型的TMC。

点的设计，本质上属于一种索引或者排序，我们已经在“兴趣点和名称搜索”一文中详细描述过。面的设计，就是要保证形状的最简，没有什么可说的。LBS中三维物体的设计，与其他应用中的三维设计相同，都是一种通用设计，也没有必要详述。本期主要介绍线的设计分为道路的设计、路口的设计两大类。在路口的设计中，将讲述简单路口的设计、复杂路口的设计、交规的设计、和路口附属设施的设计。

道路的设计

道路是由一连串形状点组成的，如P1，P2，P3，P4，…，Pn。这从P1→Pn所定义的顺序实际上就是导航引擎在渲染形状点时的顺序，即画线方向。

行驶方向是用画线方向来定义的。如果行驶方向为正，意味着行驶方向与画线方向相同，即行驶方向是从画线方向的第一个点到最后一个点。如果行驶方向为负，意味着行驶方向与画线方向相反，即行驶方向是从画线方向的最后一个点到第一个点。

道路的基本特性如下。

• 道路的名称；
• 道路的等级；
• 道路的通行能力等级等。

在这些属性中，最常见的属性是道路的等级和道路的通行能力等级。

道路的等级一般有：高速公路、国道、省道、县道、乡道、县乡村内部道路（村道）、城市快速路、主要道路、次要道路、普通道路、小路。

道路的通行能力等级是一个数字（范围为0～10），与道路等级有一定的相关性。其最重要的作用有两个：路径计算时用以设置启发式搜索的权重；保证道路的拓扑连通性。

在进行线的设计时，主要考虑其几何形状特性。由于上面的这些属性往往是附属在道路的几何形状上的，所以，在道路的几何建模上，没有特殊之处。

在进行道路的几何建模时，是通过道路的构成来构建几何道路的。道路的构成具体分为：上下线分离、交叉点内、JCT（高速连接路）、环岛、服务区的道路、引路（高速与一般道路、一般道路之间的道路）、辅路、引路+JCT、出口、入口、右转车道A/B、左转车道A/B、左右转车道、普通道路、服务区+引路、服务区+JCT、服务区+引路+JCT。

一般来说，每种道路的构成是以其在交通中的实际用途而定的。但是，在设计中大致分为以两种类型的路。

• 一般路口的道路；
• 复杂路口的道路，是指具备上下线分离特点的道路。

一般路口的道路设计没有什么特别，每条道路用一条几何线来表示。在一般路口中，以最复杂的环岛为例，设计如图2所示。

复杂路口的道路设计往往是和上下线分离的道路相关联的。上下线分离的道路如图3所示，是指由中央隔离带分隔为上行及下行的两条道路。

上下线分离的道路在路口的地方一般会用交叉点来表示。这种上下线分离的道路的建模过程如图4所示。

路口设计

路口的设计，本质上就是线、点、线的关系。我们上文已经介绍，在LBS地图中，线、点、线的关系根据路口的类型来分，主要可以分为两种关系：简单路口和复杂路口。

考虑到从某条道路（或道路上的某条车道）可以驶向的道路（或车道）并不相同，所以设定了第三种关系：交规（导航线）。

考虑到道路上与通行有关的标志或警告，所以设定了第四种关系：道路设施或指示。

简单路口的设计

简单路口的关系是一种典型的道路拓扑，其拓扑结构大体如图5所示。

关于拓扑结构的设计，大体有如下两种方式。

目前主流的MIF方式

建立两个表：Roadsegment和Roadnode。以L1为例，各表中存储的内容如下。

Roadsegment的内容如表1所示。

Roadnode的内容如表2所示。

以拓扑点为中心建立拓扑关系的方式

建立三个表：Roadsegment、Roadnode和Roadnoderelation。以L1为例，各表中存储的内容如下。

Roadsegment的内容如表3所示；

Roadnode的内容如表4所示。

Roadnoderelation的内容表5所示。

上述两种方式都是可以使用的。下面以一个拓扑应用为例，来说明两者的区别。

应用：如果我们现在要从所有的数据中找到所有的三叉路口，有以下两种设计方法。

设计1：需要建立中间表，类似Roadnoderelation。之后再从中找到连接的一个node，有三条link的node。

Select * from roadnoderelation group by node having count() =3;

设计2：无须建立中间表，因为已事先建立了。这说明在涉及拓扑应用的时候，第二种设计有很大的优势，效率很高。

复杂路口的设计

复杂路口是很典型的一种线、点、线关系，也就是前文所述的上下线分离的道路路口。

复杂路口的拓扑图如图6所示。

复杂路口的拓扑特点是：四个交叉点。这种路口有以下两种设计方法。

目前通用的MIF设计方法

将node分为两种：普通的node和交叉路口的node。即建立两个表：roadnode和roadcross。在这两个表中同时包含了node的名称字段。

此外，为了实现导航线（交规），还建立了两种导航线的表：roadnodemaat和roadcrossmaat。

主辅路在某种情况下不需要导航线等情况，则需要人为建立的一套规则。

为了能更清晰地表明每条lane（车道）之间的通行关系，还单独有lane的关联表：laneconnectivity。

复杂路口和普通路口的node合一的设计

复杂路口和普通路口的node合为一种node，所以只建立一个node表：an_nod。

为了区分node为交叉路口的情况，或者交叉路口的名称，可在roadnode中添加交叉路口的node类型和名称，也可成立专门的表：an_ndn(node’s name)。

由于lanecconnectivity是必须有的，所以将导航线也放在其中，只是一个子集而已。

交规的设计

交通规则即车辆在路网上可以通往的道路（或车道），主要是指一种车道连接的设计。

如果了解了复杂路口的设计，车道连接就容易得多。

一种车道连接的设计

an_lac：道路的连接关系，从进入道路（from chain）到退出道路（to chain）。

an_lat：道路连接内的车道的交通连接关系，包含lac中的连接，以及对应的车道间的连接关系，即从进入车道（LaneIdFrom）到退出车道（LaneIdTo）。

an_lch：一个道路连接关系中的从第一个到最后一个道路的序列。

再对比复杂路口图（见图7）来看，整体上看起来还是很清晰的。

具体设计如下。

an_lac：道路连接表如表6所示。

an_lat：道路连接内的车道连接关系如表7所示。

an_lch：道路连接中包含的所有道路的序列如表8所示。

注意：an_lch存储的顺序为从第一个到最后一个道路的序列，比如：一个道路连接的Id是1，对应的link是从道路1途经道路2，到达道路3，则存储如表9所示。

如果途经道路有多条，比如：途经道路2、3，到达道路4，则在an_lch只需要从始发道路到途经道路、到达道路依次存储即可。

为了深入了解这种数据规格的设计，下面通过一个问题对上述设计进行深入分析。

在这种设计中，an_lat应该包含node吗？

在现在的设计中，没有node，主要是因为复杂路口的情况有四个node，所以没法定义lane的拓扑的node。这时须要得到复杂路口的四个拓扑点，可以通过an_lat和node的复杂路口的属性（或由“an_lat中的LaneIdFrom与LaneIdTo不连接”来定义复杂路口）编译出复杂路口的四个拓扑点。

在这种设计中，如果交叉路口有虚拟的lane（如下文第二种设计所述）需要填入到数据中，可以在an_lat中添加node，因为这时“复杂路口的定义”在虚拟车道的威力下已经没有什么意义了，有用的就是an_lat中所表达的那种道路、拓扑点、虚拟车道的拓扑关系。

另一种更精细的车道级别的连接设计

具体的精细车道的设计图如图8所示。

从表面上看，这种设计中的关系与上文的设计很不一样。因为其中的很多车道关联关系是建立在junction（车道连接的结构体）上的。此外，junction中还有虚拟link。

但是实际上，这个设计图与复杂路口的第一种设计所表达的一样，都是复杂路口的情况，图8更精确，因为其将road 10与road 70相连接的关系中加入了虚拟link：road 30。同理，road 20 、road 40也都属于这一类，即为了使车道连接表达更精确而设定的link。

实际上，这种车道连接的关系可以叫车道连接，也可以叫junction。所以这种junction没有什么神秘之处，只是将所有的车道连接关系建立了一个junction来存储而已。为了使存储更精确，又把一个车道的连接关系分成了三段lane：出发、目标和中间（这是虚构的lane）。

上面描述了关于虚拟的road与虚拟的junction的关系。在这个虚拟的junction中，虚拟的road的前后继关系是写上相应的road的。

最后，在这种设计中，利用复杂路口生成了四个新的junction，也就是上文所述这种设计的实现（为了更好地说明数据结构间的关系，用XML来表示具体的车道设计）如下：

<road name="＂＂" length="＂2.4788652606678024e+01＂" id="＂13＂" junction="＂27＂">
<link>
<predecessor elementtype="＂road＂" elementid="＂10＂" contactpoint="＂end＂">
<successor elementtype="＂road＂" elementid="＂70＂" contactpoint="＂end＂">

<lanes>
<lanesection s="＂0.0000000000000000e+00＂">
<left>
</left>
<center>
<lane id="＂0＂" type="＂border＂" level="＂0＂">
<link>

</lane>
</center>
<right>
<lane id="＂-1＂" type="＂driving＂" level="＂0＂">
<link>
<predecessor id="＂-2＂/">
<successor id="＂1＂/">

</successor></predecessor></lane>
</right>
</lanesection>
</lanes></successor></predecessor></road>

另外，对应原先已有的四条道路（如road 10）的情况，其实现如下：

<road name="””" length="”2.0000000000001661e+00″" id="”10″" junction="”-1″">
<link>
<predecessor elementtype="”road”" elementid="”99″" contactpoint="”end”">
<successor elementtype="”junction”" elementid="”25″">
</successor></predecessor></road>

这里注意以下两个细节：

• road junction=“-1”
• successor elementType=“junction”elementId=“25”

道路上的引导指示或设施

道路设施包含：红绿灯、限速牌、各种警告、天桥、隧道等。道路上的指示特指交叉路口的道路指示。

道路设施如图9所示，图中的A、B即为道路设施，道路设施的存储方法一般为与相应的link关联，并存储设施本身的经纬度。

只有红绿灯与众不同，在一般的导航地图数据中，由于并不是ADAS（自动驾驶）地图，所以对精度的要求相对较低，会把红绿灯当作一个路口拓扑点的属性来存储。 
道路指示（这里指一般路口中三叉路口的实景路口指示图）如图10所示。

在实际的导航地图中，图10中的34A-B并不会实际存储，是由导航软件的判断来实现的，比如：在高速三叉路口前200m发出提示。

34A、34B则会实际存储，具体的存储方法用一个示例来表示。

• 建立三个表，用来表示交叉路口的拓扑关系；
• 建立一个多媒体表，用来存储方向看板的多媒体信息；
• 建立一个表，用来存储道路的指引信息。
• 交叉路口的拓扑关系如下。
• an_isi：交叉路口本身的标识；
• an_isc：交叉路口对应的出入道路表；
• an_isv：交叉路口与方向看板的多媒体的对应关系；
• 多媒体表：用来存储对应的方向看板的图片信息；
• 道路指引：用来存储在道路引导时，地图导航需要发出道路指示声音时所需的对应出入道路（含名称）的信息。

需要实景路口放大图的情况一般都是三岔路口。非三叉路口的情况不太常见，这种路口的情况如图11所示。

图11中，进入道路：m；退出道路：a、b、c。

一般情况下，会在道路m或整个交叉路口上存储“路口背景图”，会在退出道路上存储箭头图。这样，当用户导航选择道路m（当前道路）和a（目的道路）后，对应的导航图像如图12所示那样完美地呈现了。

综上所述，我们已经建立了一幅地图中的所有关键要素数据。我们在下一期将会介绍LBS应用的显示技术。

关于：中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务，十年研发经验，上百成功案例，中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值，致力于为用户提供很好的软件解决方案。联系电话400-0316-532，邮箱sales@zhongkerd.com，网址www.zhongkerd.com