技术教程 | 百度鹰眼历史轨迹查询:轨迹绑路功能应用

本篇教程主要介绍如何通过鹰眼历史轨迹的绑路(道路匹配)的能力,使轨迹更加符合车辆的实际行驶情况,同时也能使得里程计算更加精确。

 

在鹰眼历史轨迹查询API中,通过process_option中的need_mapmatch子选项,设置是否开启绑路功能。下面我们继续通过上一篇教程中的那条轨迹,详细地演示need_mapmatch子选项开启后,对轨迹点不在车道上的情况的优化效果。

首先看一下在经过去噪后,但未开启绑路选项时,轨迹的情况:

 

图1(设置need_mapmatch=0的效果)

 

上图所示的是一辆沿着文一西路,从东向西行驶的车辆的轨迹,其中最右侧的267号轨迹点到270号轨迹点,都不在道路上;第272号轨迹点到275号轨迹点,都飘到了对向车道上;这与实际行驶情况不符,接下来看一下开启绑路选项后的情况:

 

图2(设置need_mapmatch=1的效果)

 

开启绑路之后,飘移到路边楼宇中的轨迹点都被“纠正”回了车道上,飘移到对向车道的轨迹点也被“纠正”回了自东向西方向的车道上。使用绑路的方式非常简单,对于道路匹配,只提供了开启或关闭的二元选项,而没有级别的概念。图一轨迹所示效果,和纠偏相关的请求参数设置如下:

 

is_processed=1&process_option=denoise_grade=4,need_mapmatch=0,transport_mode=auto,vacuate_grade=0

 

图二轨迹所示效果,和纠偏相关的请求参数设置如下:

 

is_processed=1&process_option=denoise_grade=4,need_mapmatch=1,transport_mode=auto,vacuate_grade=0

 

二者只有need_mapmatch子选项的值不一样。我们继续看同一段轨迹中的另一个子区域的例子:下图(图3)所示的是绑路的另一种典型应用场景:拐弯。

 

图3(未绑路的拐弯场景示例)

 

从图3中看到,车辆先从南向北行驶,行驶至宝淑北路91幢的丁字路口时,右转进入得胜快速路,向东行驶一段,随后在第111号轨迹点处掉头向西行驶。在第105号轨迹点处拐弯时,第105号到106号点之间的子轨迹,直接从路边的建筑中“穿过”,明显与实际情况不符,绘制出的轨迹也不“美观”。下面我们通过设置need_mapmatch=1,开启绑路功能后,对比一下效果:

 

图4(绑路后的拐弯场景示例)

 

从图4中可以看出,绑路后的轨迹在拐弯时,在路口处填补了拐点(图4中的第189号点),更符合车辆真实的行驶轨迹,在掉头处补充了很多细粒度的点(图4中第208号点到第218号点),使拐弯的轨迹更加自然平滑。

 

总结

经过绑路后的轨迹,已经比较符合车辆真实的行驶路径,但绑路的同时补充了很多道路的“形状点”,这造成了轨迹点数量的冗余。我们看到在同一段轨迹中的相同区域,图一中轨迹点序号在270左右,而图二中轨迹点序号就已经到550左右了,接近翻了一倍。之前我们有提过,原始轨迹在很多情况下,本身就是存在冗余的,绑路之后相当于雪上加霜。因此就需要对轨迹进行抽稀。

 

在下一篇教程中,我们将继续详细介绍,鹰眼历史轨迹查询中抽稀能力,如何解决轨迹点的冗余问题。