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

近期,我们围绕百度鹰眼轨迹服务(下简称鹰眼)发布了多篇技术教程,分别从主要功能应用:轨迹去噪轨迹绑路轨迹抽稀详细讲解了开发中的注意事项,本篇由鹰眼工程师继续为开发者带来轨迹补偿功能应用详解。

 

通过去噪、绑路、抽稀这三大神器,已经可以成功剔除掉原始轨迹中的飘移定位点、将飘移到路边和对面的轨迹点纠正回行驶的车道上、并能在保持原有轨迹细节的基础上,大幅缩减轨迹点的个数。但是,经过纠偏后的轨迹仍然有不尽如人意的地方,如下图(图1)所示:

 

图1(轨迹中断)

 

图1中仍然是前几篇教程中的那条熟悉的轨迹,该车辆由东向西行驶,但在文一路隧道中由于缺乏足够可靠的定位信息,导致隧道中的轨迹缺失。图中的第21号轨迹点到第22号轨迹点之间产生了中断,看起来好像车是从隧道北边的楼上飞过去的一样。轨迹的缺失不仅使轨迹绘制的效果大打折扣,还会影响里程的计算,从图中可以看出,相比直线而言,文一路隧道在春天花园附近有一个比较明显的南向偏移,如果直接使用图中的轨迹计算里程,那么第21号到第22号轨迹点之间算出来的里程就会比实际里程偏小。鹰眼历史轨迹查询接口中,提供了supplement_mode和supplement_content两个字段,用来对缺失的部分做补偿。

 

supplement_content 设置补偿内容

  该字段只有2个值可以选择,only_distance代表只补偿里程,而不补偿轨迹点;distance_and_points既补偿里程又补偿轨迹点。 如何选择这个字段的值呢? 如果应用场景只关注里程信息的准确性(如网约车根据里程作为收费依据),那么设置supplement_content=only_distance即可,此时返回结果中的distance字段将代表补偿过后的里程,但points数组中的轨迹点不会有变化,仍然是缺失的。 如果需要展示完整的轨迹,那么设置supplement_content=distance_and_points将是你的唯一选择,此时返回结果中不只是distance字段的里程数值是补偿后的,points数组中的轨迹点个数也会变多。对应在图1的例子中就是在21号点到22号点之间,沿路补偿出相应的轨迹点。 distance_and_points相比only_distance多出了补偿轨迹点的功能,这也会导致返回的数据量增多,增加客户端流量与服务端带宽的消耗。另外补偿轨迹点也需要更多的计算时间,请求的相应时间也会变长。因此需要结合实际需求,合理选择。

supplement_mode 设置补偿交通方式

supplement_mode字段的值提供了5种选择,其中no_supplement代表不进行补偿,而straight代表使用直线补偿。有的开发者可能会有疑惑,不补偿的情况下,图1中的21号点和22号点之间不是也是通过直线连起来的么,那和使用直线补偿有什么区别呢? 二者的区别在于对里程的计算。具体说来:
  • 在no_supplement不补偿的情况下,对于中断的区间,也就是21号点到22号点的直线距离,是不计入整段轨迹的总里程的,整段轨迹会被分割为2个部分,一部分是0号点到21号点之间的轨迹,另一部分是22号点之后的轨迹。
  • 而straight直线补偿的情况下,21号点到22号点之间的直线距离,会被计入整段轨迹的总里程,整段轨迹也不会被分割,21号点和22号点之间的部分,虽然定位时间间隔较长,距离也较远,但我们认为这两点之间和19号点到20号点之间的短区间没有区别。
另外三个可选的取值为driving,riding,walking,分别用于指定不同的交通方式。交通方式不同,补偿出的路线可能不一样,比如汽车只能在机动车道行驶,而行人需要在人行道行驶,下面我们分别以骑行和驾车为例,对比一下二者在文一路隧道的轨迹补偿效果: 图2中认为轨迹是汽车产生的,因此对中断区间补偿出的轨迹,在机动车道行驶,也就是认为是在隧道中行驶的。                                                                          图2(supplement_mode=driving的补偿效果) 图3中认为轨迹是骑行产生的,因此补偿出的轨迹,在隧道外面的非机动车道上行驶的。                                     图3(supplement_mode=riding的补偿效果)

总结

 

本篇教程介绍了如何通过鹰眼历史轨迹查询接口中提供的supplement_mode和supplement_content选项,对轨迹的中断区间进行补偿。经过补偿之后,轨迹里程的计算更加精确,也能更准确地还原轨迹的行驶原貌。