CN115966095A

CN115966095A - 基于车辆的交通数据融合处理方法、装置、设备及介质

Info

Publication number: CN115966095A
Application number: CN202211541479.0A
Authority: CN
Inventors: 崔洪清
Original assignee: Yunkong Zhixing Technology Co Ltd
Current assignee: Yunkong Zhixing Technology Co Ltd
Priority date: 2022-12-02
Filing date: 2022-12-02
Publication date: 2023-04-14

Abstract

本说明书实施例公开了一种基于车辆的交通数据融合处理方法、装置、设备及介质，方法包括：获取数据源采集设备采集的多个交通数据；交通数据包含车辆的位置信息；根据车辆的位置信息，确定各个交通数据对应的网格；网格是预先根据数据源采集设备采集车辆的位置信息的采集误差划分的；对于每一网格对应的交通数据和与网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理。本实施例预先根据数据源采集设备采集车辆的位置信息的采集误差划分网格，然后确定各个交通数据对应的网格，再对每一网格和该网格相邻的网格之间的非同源数据进行融合处理，减少了数据处理的计算量，提高了数据处理效率。

Description

基于车辆的交通数据融合处理方法、装置、设备及介质

技术领域

本申请涉及网联自动驾驶技术领域，尤其涉及一种基于车辆的交通数据融合处理方法、装置、设备及介质。

背景技术

在网联自动驾驶领域，路侧计算单元会向云端发送车辆数据，具体而言是路侧计算单元(Roadside Computing Unit，RCU)，通过摄像机、激光雷达、毫米波雷达等设备，感知道路上车辆的车辆数据，将车辆数据上传云端，云端根据车辆数据生成辅助车辆完成自动驾驶的指令。

而现实生活中，两个相邻的路侧计算单元或者道路路口的多个路侧计算单元会有重叠的感知区域，存在多个路侧计算单元对某一车辆都进行感知，进而将该辆车的多份车辆数据上传到云端的情况，而这多份车辆数据，会由于定位精度、信息上传时间等差异，并不会完全一致，因此，云端需要对车辆数据进行处理，以判断哪些车辆数据是属于同一辆车的车辆数据。

现有的车辆数据处理方法适用于车辆数据较少的情况，而在车辆数据较多时，现有数据处理方法的计算量会成倍增长，数据处理效率严重降低。

发明内容

本说明书实施例提供一种基于车辆的交通数据融合处理方法、装置、设备及介质，以解决现有的交通数据处理效率低问题。

为解决上述技术问题，本说明书实施例是这样实现的：

本说明书实施例提供的一种基于车辆的交通数据融合处理方法，包括：

获取数据源采集设备采集的多个交通数据；所述交通数据包含车辆的位置信息；

根据所述车辆的位置信息，确定各个所述交通数据对应的网格；所述网格是预先根据所述数据源采集设备采集车辆的位置信息的采集误差划分的；

对于每一所述网格对应的交通数据和与所述网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理。

可选地，所述数据源采集设备位于预设地理区域内；所述网格按照以下方式进行划分：

基于所述预设地理区域的位置信息，做包含所述预设地理区域的矩形；

根据所述数据源采集设备采集车辆的位置信息的采集误差，将所述矩形划分为多个网格。

可选地，所述根据所述车辆的位置信息，确定各个所述交通数据对应的网格，具体包括：

根据所述网格的尺寸，确定所述多个网格在所述预设地理区域中的行数和列数；

根据所述车辆的位置信息、所述预设地理区域的位置信息，以及所述多个网格在所述预设地理区域中的行数和列数，利用时间复杂度为O(1)的算法，计算各个所述交通数据在所述多个网格中的网格行数和网格列数；

基于各个所述交通数据在所述多个网格中的网格行数和网格列数，确定各个所述交通数据对应的网格。

可选地，在步骤所述对于每一所述网格对应的交通数据和与所述网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理之前，所述方法还包括：

对于每一所述网格对应的交通数据中的非同源交通数据，进行基于车辆的融合处理。

可选地，所述数据源采集设备具体包括：路侧计算单元；

或者，所述数据源采集设备具体包括：路侧计算单元和路侧单元；

或者，所述数据源采集设备具体包括：路侧计算单元和车载终端；

或者，所述数据源采集设备具体包括：路侧单元和车载终端；

或者，所述数据源采集设备具体包括：路侧计算单元、路侧单元和车载终端。

可选地，所述数据源采集设备采集车辆的位置信息的采集误差为5米。

可选地，所述交通数据还包括车辆的航向和速度中的至少一种数据。

本说明书实施例提供的一种基于车辆的交通数据融合处理装置，包括：

数据获取模块，用于获取数据源采集设备采集的多个交通数据；所述交通数据包含车辆的位置信息；

网格确定模块，用于根据所述车辆的位置信息，确定各个所述交通数据对应的网格；所述网格是预先根据所述数据源采集设备采集车辆的位置信息的采集误差划分的；

融合处理模块，用于对于每一所述网格对应的交通数据和与所述网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理。

本说明书实施例提供的一种基于车辆的交通数据融合处理设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

本说明书实施例提供的一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现上述所述的一种交通数据融合处理方法。

本说明书一个实施例实现了能够达到以下有益效果：通过预先根据数据源采集设备采集车辆的位置信息的采集误差划分网格，然后确定各个交通数据对应的网格，再对每一网格和该网格相邻的网格之间的非同源数据进行融合处理，即可融合数据源采集设备采集的多个交通数据，减少了数据处理的计算量，提高了数据处理效率。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书实施例提供的一种基于车辆的交通数据融合处理方法流程图；

图2为本说明书实施例提供的一种基于车辆的交通数据融合处理装置示意图；

图3为本说明书实施例提供的一种基于车辆的交通数据融合处理装置架构图；

图4为本说明书实施例提供的一种基于车辆的交通数据融合处理设备结构图。

具体实施方式

为使本说明书一个或多个实施例的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书一个或多个实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本说明书一个或多个实施例保护的范围。

以下结合附图，详细说明本说明书各实施例提供的技术方案。

现有技术中，两个相邻的路侧计算单元或者道路路口的多个路侧计算单元会有重叠的感知区域，存在多个路侧计算单元对某一辆车都进行感知，进而将该辆车的多份车辆数据上传到云端的情况，而这多份车辆数据，会由于定位精度、信息上传时间等差异，并不会完全一致，因此，云端需要对车辆数据进行处理，以判断哪些车辆数据是属于同一辆车的车辆数据。

单个路侧计算单元(Roadside Computing Unit，RCU)进行数据融合时，会先将其采集的交通数据的采集时间预测到指定时间戳，比如单个路侧计算单元上的摄像机和激光雷达采集的交通数据的采集时间，然后两两计算不同采集源(路侧计算单元一般包含摄像机、激光雷达以及毫米波雷达等设备)下的车辆之间的距离，使用匈牙利匹配计算代价，进行车辆去重，得到去重处理后的交通数据。

假设摄像机采集的交通数据对应的车辆为a、b和c，激光雷达采集的交通数据对应的车辆为o、p和q，两两车辆之间的距离如下表所：

	a	b	c
				o	1.0	5.2	8.1
p	5.1	0.9	4.2
				q	8.2	4.3	1.2

通过匈牙利算法，可以计算出车辆a与车辆o、车辆b与车辆p、车辆c与车辆q匹配的代价最小，分别为1.0、0.9以及1.2，故可得出车辆a与车辆o是同一辆车，车辆b与车辆p是同一辆车，车辆c与车辆q是同一辆车。

如果使用上述数据融合的方法，融合多个路侧计算单元采集的多个数据时，会由于数据量的增多，严重降低数据处理效率。比如有100个路侧计算单元，有10000辆车在路上行驶，每个路侧计算单元采集100辆车的交通数据。按照之前的算法，每个路侧计算单元采集的100辆车的交通数据都需要跟其余路侧计算单元也就是99个路侧计算单元采集的9900辆车的交通数据进行距离计算，每个路侧计算单元的计算量为100*9900＝990000，而100个路侧计算单元的计算量就是990000*100＝99000000。可以看出，数据处理效率极低。

为了解决现有技术中的缺陷，本方案给出了以下实施例：

本实施例提供了一种基于车辆的交通数据融合处理方法，从程序角度而言，该流程的执行主体可以为搭载于服务器的程序或者云端。图1为本说明书实施例提供的一种基于车辆的交通数据融合处理方法流程图，如图1所示，基于车辆的交通数据融合处理方法，可以包括如下步骤：

步骤110：获取数据源采集设备采集的多个交通数据；所述交通数据包含车辆的位置信息。

在步骤110中，数据源采集设备可以为路侧计算单元，路侧计算单元将采集的多个交通数据发送给云端，进而云端获取到多个交通数据。其中，交通数据还包括车辆的航向和速度中的至少一种数据。

步骤120：根据所述车辆的位置信息，确定各个所述交通数据对应的网格；所述网格是预先根据所述数据源采集设备采集车辆的位置信息的采集误差划分的。

在步骤120中，可以预先将预设地理区域划分网格。预设地理区域为预期实施本方法的区域，比如某县、某市等，也可以理解为本方法的服务范围，数据源采集设备位于预设地理区域内。

进一步地，可以按照以下方式对预设地理区域划分网格：

比如，可以根据预设地理区域的平面图做一个直角坐标系，获取预设地理区域的平面图在直角坐标系中的最小横坐标minX，最大横坐标maxX，最小纵坐标minY，最大纵坐标minY，根据点(minX，minY)、点(minX，maxY)、点(maxX，minY)以及点(maxX，maxY)做包含预设地理区域的矩形，此矩形四个顶点的坐标分别为(minX，minY)、(minX，maxY)、(maxX，minY)以及(maxX，maxY)。

在一个实施例中，还可以基于预设地理区域的位置信息，做预设地理区域的最小外接矩形，得到包含预设地理区域的矩形。

包含预设地理区域的矩形做好之后，根据数据源采集设备采集车辆的位置信息的采集误差，将此矩形划分为多个网格。

在本实施例中，采集误差为5米，那么每个网格就可以为边长为5米的正方形。

网格划分好之后，需要把各个交通数据对应的车辆定位到各网格中，即根据所述车辆的位置信息，确定各个所述交通数据对应的网格，具体包括：

根据所述网格的尺寸，确定所述多个网格在所述预设地理区域中的行数和列数。

根据所述车辆的位置信息、所述预设地理区域的位置信息，以及所述多个网格在所述预设地理区域中的行数和列数，利用时间复杂度为O(1)的算法，计算各个所述交通数据在所述多个网格中的网格行数和网格列数。

首先确定多个网格在预设地理区域中的行数和列数。将网格的边长比如5米换算成经纬度，得到5米表示的经度差、纬度差。根据每个网格的边长表示的经度差、纬度差，以及预设地理区域的经纬度，就可以计算出多个网格在预设地理区域中的行数和列数。

然后将各个交通数据对应的车辆定位到各网格中。本实施例采用了时间复杂度为O(1)的算法，算法的时间复杂度是一个函数，它定性描述该算法的运行时间，这是一个代表算法输入值的字符串的长度的函数。时间复杂度为O(1)是最低的时空复杂度，也就是对于时间资源或者空间资源的消耗与输入数据大小无关，无论输入数据增大多少倍，对于时间资源或者空间资源的消耗都不变。哈希算法就是典型的O(1)时间复杂度，无论数据规模多大，都可以在一次计算后找到目标(不考虑冲突的话)。计算步骤可以为：

计算交通数据所在的行数：row＝(车辆经度-X)/经度差

计算交通数据所在的列数：col＝(车辆纬度-Y)/纬度差

计算交通数据所在的网格：grid＝row*colNums+col

row为交通数据对应的车辆所在网格的行数，车辆经度为车辆的位置信息中的经度，X为预设地理区域的平面图在直角坐标系中的最小横坐标所表示的经度，经度差为网格的长表示的经度差，col为交通数据对应的车辆所在网格的列数，车辆纬度为车辆的位置信息中的纬度，Y为预设地理区域的平面图在直角坐标系中的最小纵坐标所表示的纬度，纬度差为网格的宽表示的纬度差，grid为交通数据对应的车辆具体所在的网格，colNums为多个网格在预设地理区域中的列数。

步骤130：对于每一所述网格对应的交通数据和与所述网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理。

在步骤130中，针对交通数据对应的车辆所在的每一网格，将此网格对应的交通数据和此网格相邻的网格对应的交通数据，这两个交通数据之间的非同源交通数据，进行基于车辆的融合处理。

本实施例中的非同源交通数据，表示不同数据源采集设备采集的交通数据。当数据源采集设备具体包括路侧计算单元时，不同路侧计算单元采集的交通数据就是非同源交通数据。

对非同源交通数据进行基于车辆的融合处理时，可以根据交通数据中车辆的位置信息、航向或者速度进行融合处理。比如根据车辆的位置信息进行融合处理，针对交通数据对应的车辆所在的某一网格，将该网格中车辆的位置信息，与该网格的相邻网格中车辆的位置信息进行匹配，如果匹配成功，则说明该网格中的车辆与该网格的相邻网格中的车辆是同一辆车，则将这两个网格中该车辆对应的交通数据进行融合，如果匹配不成功，则说明该网格中的车辆与该网格的相邻网格中的车辆不是同一辆车，则不进行数据融合。

在一个实施例中，为了保证交通数据融合处理的准确性，在步骤120之后，步骤130之前，基于车辆的交通数据融合处理方法还包括：

这是由于，某一网格内也可能存在非同源交通数据。比如某一路口设立有多个路侧计算单元，这些路侧计算单元采集的交通数据对应的车辆可能就处于一个网格，又或者两个路侧计算单元之间有重叠区域，而这个重叠区域存在车辆的话，这个车辆所在的网格内就有两份这个车辆的交通数据。为了进一步提高交通数据融合处理的准确性，所以对于每一所述网格对应的交通数据中的非同源交通数据，进行基于车辆的融合处理。

可以理解的是，为了提高交通数据融合处理的准确性，也可以在步骤130之后将每个网格内的非同源交通数据进行融合处理，即在步骤130之后，基于车辆的交通数据融合处理方法还包括：

还有，现实活动中，路侧单元和车载终端也会将车辆的交通数据上传到云端。其中，路侧单元(Road Side Unit，RSU)通过V2X(vehicle to everything，车对外界的信息交换)功能接收具备V2X功能的网联车发送的交通数据，然后将接收到的交通数据上传到云端。车载终端(OnBoardUnit，OBU)通过4G/5G通信将自身车辆的交通数据上传到云端。

可以看出，同一辆车，其交通数据还可能被其他数据源采集设备上传到云端。而现有的数据处理方法，一般是对少量的路侧计算单元上传的数据进行处理，无法处理路侧计算单元、路侧单元和车载终端，其中的两种或三种数据源采集设备上传的数据。

而本实施例提供的基于车辆的交通数据融合处理方法，将数据源采集设备所在的预设地理区域进行网格划分，然后根据车辆的位置信息，确定各个交通数据对应的网格，最后对于每一网格对应的交通数据和与网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理，可以处理不同数据源采集设备采集的交通数据，即路侧计算单元、路侧单元和车载终端，其中的两种或三种数据源采集设备上传的交通数据，也就是说本实施例提供的交通数据融合处理方法，所述数据源采集设备具体包括：路侧计算单元；

基于同样的思路，本实施例还可以处理不同路侧计算单元采集的行人数据，即路侧计算单元采集的多个交通数据中包括行人数据。基于本实施例提供的方法，根据行人数据中的位置信息、速度信息以及方向信息中的至少一种信息，即可进行基于行人数据的融合处理，在此不作赘述。

本实施例中，由于网格是预先根据数据源采集设备采集车辆的位置信息的采集误差划分的(假如采集误差为5米，那么每个网格就可以为边长为5米的正方形)，这样一来，可以使得采集的交通数据对应的车辆所在网格和实际车辆所在网格最多相差一个网格，而针对交通数据对应的车辆所在的每一网格，将此网格和此网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理，便可以忽略数据源采集设备的采集误差，更准确地处理基于车辆的交通数据。

另外本实施例针对交通数据对应的车辆所在的每一网格，将此网格和此网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理，相比现有的针对交通数据对应的车辆中的两两车辆的融合处理方式，本实施例的处理方式更简捷、快速。

而且本实施例还可以处理路侧计算单元、路侧单元和车载终端中至少两个数据源采集设备采集的交通数据，实现交通数据快速、准确处理的技术效果，应用更广泛。

基于同样的思路，本实施例还提供了一种基于车辆的交通数据融合处理装置，如图2所示，基于车辆的交通数据融合处理装置包括：

数据获取模块210，用于获取数据源采集设备采集的多个交通数据；所述交通数据包含车辆的位置信息。

网格确定模块220，用于根据所述车辆的位置信息，确定各个所述交通数据对应的网格；所述网格是预先根据所述数据源采集设备采集车辆的位置信息的采集误差划分的。

融合处理模块230，用于对于每一所述网格对应的交通数据和与所述网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理。

进一步地，如图3所示，本实施中的融合处理模块230可以包括多个融合单元，融合单元可以处理某一网格和与该网格相邻的网格对应的交通数据之间的非同源交通数据。

具体而言，如果该网格对应的交通数据和与该网格相邻的网格对应的交通数据之间具有非同源交通数据时，融合处理模块230可以将该网格的相邻网格对应的交通数据加入到该网格对应的交通数据中，作为一个融合数据分组。融合处理模块230遍历每一包含交通数据的网格，就可以得到多个融合数据分组，进而融合单元处理多个融合数据分组中的数据。

为了降低数据处理延迟，多个融合单元可以并行处理数据。另外，当需要处理的非同源交通数据较多时，多个融合单元可以部署在多台服务器之间的分布式处理进程，这样可以快速处理较多的非同源交通数据。当需要处理的非同源交通数据较少时，多个融合单元也可以部署在一个进程内部的多个处理线程，占用较小内存的同时实现快速处理较多的非同源交通数据的效果。

还可以理解的是，通过扩充融合单元的数量，可以降低每个融合单元的计算处理量，也可以降低融合单元的处理延迟。

数据进行融合处理后，会被发送到融合数据应用服务。数据应用服务为应用融合处理后的数据的应用，比如场景计算应用，交通分析应用。场景计算应用基于融合处理后的数据可以使车辆完成自动驾驶功能，交通分析应用基于融合处理后的数据可以完成云端的交通管理功能等。

在一个实施例中，如图3所示，融合处理模块230还将每一网格对应的交通数据中未进行融合处理的交通数据发送到融合数据应用服务，也就是将不需要融合处理的交通数据发送到融合数据应用服务。该发送过程可为异步操作，也就是不影响融合处理模块230对交通数据进行基于车辆的融合处理过程。

在本实施例中，融合处理模块230进行基于车辆的融合处理的频率还可以根据融合数据应用服务使用数据的频率设置，如果融合数据应用服务使用数据的频率较高，则可以给融合处理模块230设置一个较高的数据融合频率，如果融合数据应用服务使用数据的频率较低，则可以给融合处理模块230设置一个较低的数据融合频率。本实施例中该频率可以设置为10赫兹，即融合处理模块230可以每100毫秒进行一次基于车辆的融合处理。

基于同样的思路，本说明书实施例还提供了上述方法对应的设备。图4为本说明书实施例提供的一种基于车辆的交通数据融合处理设备结构图，如图4所示，设备400可以包括：

至少一个处理器410；以及，

与所述至少一个处理器通信连接的存储器430；其中，

所述存储器430存储有可被所述至少一个处理器410执行的指令420，所述指令被所述至少一个处理器410执行，以使所述至少一个处理器410能够：

基于同样的思路，本说明书实施例还提供了上述方法对应的计算机可读介质。计算机可读介质上存储有计算机可读指令，所述计算机可读指令可被处理器执行时实现如本申请中任一实施例所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于图4所示的于车辆的交通数据融合处理设备而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field ProgrammableGateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字符***“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(AdvancedBoolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell UniversityProgramming Language)、HDCal、JHDL(JavaHardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby HardwareDescription Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegratedCircuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、AtmelAT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字符多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带式磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种基于车辆的交通数据融合处理方法，其特征在于，包括：

2.根据权利要求1所述的交通数据融合处理方法，其特征在于，所述数据源采集设备位于预设地理区域内；所述网格按照以下方式进行划分：

3.根据权利要求2所述的交通数据融合处理方法，其特征在于，所述根据所述车辆的位置信息，确定各个所述交通数据对应的网格，具体包括：

4.根据权利要求1所述的交通数据融合处理方法，其特征在于，在步骤所述对于每一所述网格对应的交通数据和与所述网格相邻的网格对应的交通数据之间的非同源交通数据，进行基于车辆的融合处理之前，所述方法还包括：

5.根据权利要求1所述的交通数据融合处理方法，其特征在于，所述数据源采集设备具体包括：路侧计算单元；

6.根据权利要求1所述的交通数据融合处理方法，其特征在于，所述数据源采集设备采集车辆的位置信息的采集误差为5米。

7.根据权利要求1所述的交通数据融合处理方法，其特征在于，所述交通数据还包括车辆的航向和速度中的至少一种数据。

8.一种基于车辆的交通数据融合处理装置，其特征在于，包括：

9.一种基于车辆的交通数据融合处理设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

10.一种计算机可读介质，其特征在于，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现权利要求1至7中任一项所述的交通数据融合处理方法。