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

 

通过去噪、绑路、抽稀这三大神器，已经可以成功剔除掉原始轨迹中的飘移定位点、将飘移到路边和对面的轨迹点纠正回行驶的车道上、并能在保持原有轨迹细节的基础上，大幅缩减轨迹点的个数。但是，经过纠偏后的轨迹仍然有不尽如人意的地方，如下图（图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选项，对轨迹的中断区间进行补偿。经过补偿之后，轨迹里程的计算更加精确，也能更准确地还原轨迹的行驶原貌。