地图产品：地图APP是怎么实现实时路况的

编者按：本文来自微信公众号“人人都是产品经理”（ID:woshipm），作者：小林，36氪经授权发布。

对于习惯小轿车出行的人来说，了解路况是出门的第一步。通过地图产品，可以知道当前的交通情况，从而避开拥堵路段。这是如何做到的呢？本文作者通过自身工作经验，复盘了所做的路况真伪判断策略，总结策略产品工作方法，与你分享。

最近看了某著名科普up主关于导航软件规划路线的视频，其中提到了一个梗，在德国柏林，一位名叫西蒙·弗雷克特的艺术家，一个人推着一辆小推车装着99台安卓手机，在谷歌地图上“瘫痪”一条街，让很多司机绕道而行。

他是怎么做到的呢？从谷歌地图上看，只要弗雷克特走到哪里，他后面的道路就是一条红彤彤的拥堵线，这会让很多司机甚至google map误以为，这条路十分拥堵。

实际上，无论是国内的百度地图、高德地图，还是海外的google map、waze，在点对点规划路线和导航时一定会考虑到当前和未来一定时间通过道路的拥堵、交通事件和限行等情况，实时道路情况是收集了装有gps的设备（也就是地图产品的用户）上报的数据，利用大数据根据道路匹配计算出来的。

实时路况的真实性直接影响了地图产品的用户体验和产品的路径规划及导航能力，那么在以上这种情况，单单只是收集和呈现实时道路情况是远远不够的，还需要深刻理解行人和车辆，行车和休息状态等交通参与者的场景，判断数据真伪。

正好最近在做路况产品，借本文复盘所做的路况真伪判断策略，总结策略产品工作方法，所以本文先介绍常用的交通路况判断方法以及项目中实际操作，再总结策略产品工作方法。

01 道路拥堵情况

各大地图厂商收集实时路况的途径无外乎以下几种：

1. 交通传感器和摄像头

截止2009年，google通过路上的交通传感器和摄像头收集数据，这些设备使用激光雷达或主动红外技术，通过观察汽车的总体尺寸和速度来检测整体交通移动的速度，政府交通部门和一些企业会在主要道路上安装这些设备，然后把数据汇总到服务器上并且定时更新，google map就从这些来源获取数据。

但是这种方式的缺点是：覆盖度和更新的及时性都不够。

2. Crowdsourcing

2009年开始，google采用众包数据（Crowdsourcing）的技术，这种技术设计非常巧妙，可以更快速获取实时交通数据，服务器收集用户地理位置、行驶速度、方向等数据，通过大数据分析和路网匹配计算出道路的实时路况下发给客户端。

Crowdsourcing的精髓就在于此：从app的用户设备上收集数据并实时上传到服务器，快速分析和验证数据，然后下发给用户的客户端。

3. TMC（Traffic Message Channel）

据说TMC公司大多采用浮动车辆的形式，比如说跟某个出租车或者长途车公司合作，在车上安装定期实时回传速度的车载设备，这样就可以获得每个路段的通过逻辑计算之后的平均车速，据此判断路段的拥堵程度。

这里说到的路段其实不是我们实际理解的一条完整的路，在地图上可以看到同一条路经常不是完全变成了红色，而是一段红色，一段橙色，一段绿色。

在渲染地图和作用于导航时，我们会把道路切分成更小的分段，每个分段被称作一个link，道路的等级、方向、名称、坐标、范围等信息都会记录在对应的link上；理论上link被分得越细，导航的精度和地图的渲染准确度就会更高，所以当每个link都被渲染上了代表不同拥堵程度的不同的颜色时，就呈现出了实时路况的效果。

联想自动驾驶使用的高精地图，所谓高精就在于：

1）数量密度，link划分得足够密集，甚至小于厘米级；

2）信息密度，除了普通导航地图包含的静态道路数据之外还具备秒或毫秒级更新的动态道路数据，如：道路拥堵情况、施工情况、是否有交通事故、交通管制情况、天气情况等动态交通信息。

02 交通事件

iOS 14.5 beta版本中对apple map提供了一项更新，用户可以上报包含accident、hazard和speed check在内的交通事件，被指抄袭waze-like features，Waze与google map、apple map等传统地图应用的不同之处在于它是一个由社区驱动，收集用户的地图数据和其他信息，并学习用户的驾驶时间，提供路线和实时路况更新的应用程序。用户可以报告事故、交通堵塞、速度和警察，并能更新道路、地标、门牌号码等。Waze还可以根据用户的报告，确定附近最便宜的加油站。

Waze的交通事件主要有两个来源：

1. 用户上报

无论是否处于导航模式，用户都可以随时点击按钮上报交通事件，通过waze的验证过后向平台上的所有用户展示。

2. 对接DOT交通部门的监控数据

美国各个州的交通管理部门Department of Transportation提供了详细的道路拥堵情况，实时交通事件，天气预警，主要道路的实时监控等。

03 交通事件真伪判断

涉及到用户上传的内容就肯定离不开内容审核机制和反作弊机制，那么如何制定策略确保发布的交通事件的正确率呢？

这里介绍我的思路：

交通事件产品上线后，没有添加任何反作弊和审核策略，空跑一个月之后，利用人工标注10k样本数据后发现只有43%的准确率，大量的虚假和错误的交通事件对用户体验造成了影响，需要开发策略自动判断路况的真实性，进一步的策略是对于道路不匹配的交通事件匹配到对应的路网上。

1. 路网匹配

交通事件之于路网，就是点之于线的关系，点一定存在于线上，考虑交通事件的地址位置一定要匹配在对应的路网上，想象一下一个拥堵事件发生在居民小区内、一个车祸事件发生在公园内是不是不太符合实际情况，所以可以直接排除没有对应路网的事件，于是这里得到：以某个event的坐标为圆心10m为半径的路况一定要完全匹配在一条路上。

2. 时间关系

对于城市的拥堵和交警测速的情况，通常来说有严格的时间段限制，拥堵会发生在白天高峰时期，交警测速也会发生在白天上班时间，所以可以排除local time凌晨时段发生的这两种事件，于是得到：traffic和speed check的创建时间在6am-9pm之间。

3. 用户和事件可信度

用户信任度可以单独拆分出很多细分策略，简单方法是假设每个用户都拥有相同的初始信用分，每提交一次false event信用分降低，随着用户信用分降低到不同分段阈值之下时，用户上报event的授信程度也随之降低。当信用分降低到某个阈值以下时，系统不再相信该用户上报的所有event。

反之，用户每提交一次true event则信用分上涨，当信用分上浮到不同分段阈值之上时，在漏判的情况下，事件的可信程度增加。

另外一个思路是假设每个事件都拥有相同的初始信用分，除以上两条策略可以直接导致路况变为不被信任的情况之外，其他用户对事件的认可会增加事件的持续时间（但不超过每类事件的持续时间上限），反之其他用户对事件的不认可会减少事件的持续时间，直到降低到某个比例之下时，事件被视为不被信任，于是得到跟用户提交历史和用户对事件的互动产生的可信度策略。

4. 多源验证

多源验证可以直接帮助我们更好的去伪存真，那么直接对接交管部门官方发布的数据则是最简单有效的手段。

以上几条策略上线之后，可以把事件分类成可信和不可信两类，再继续利用同期人工标注10k样本，用分类问题的评价指标来评估策略的效果。

由于我定义的理想态是100%的事件都能且能被正确分类也就是accurancy=100%，目前准确率不足50%，决定开启下一轮产品循环，下一步的思路是拆解未达到理想态的case，我随机抽样没有被正确分类的样本中的10%，并做分类统计，分析断错误原因。

通过对错误分类原因的综合影响面，问题严重程度以及问题解决成本三个因素考虑，决定下一轮产品解决方案中优先修复路网匹配和时间关系。

1）匹配到了低级道路但没有匹配到高级道路

上个版本中我只匹配level1-2等级的公路，但是实际上交通事件是可能发生在level3-5等级的道路上的，所以要把匹配道路的等级放宽。

2）GPS偏移

国外的公路基本上都是在山区沙漠当中，gps的准确度跟网络环境，用户设备，应用设置的精准度等等客观条件均有影响，那么在公路环境条件下，gps的准确度会大大受到影响，于是在计算用户位置是否位于道路内部时，对道路边界做一定延展以减少gps偏移带来的误差。

3）位于休息站附近

用户提交的交通事件常常位于高速服务区附近，于是猜想即使用户在高速上遇到了堵车车祸等交通事件，也倾向于先进入服务区再上报，对于这种case，如果一个事件位于高速服务区内，则系统把这个事件的位置改到临近的高速路上，而不是直接判定为错误。

4）时间关系

由于服务时间是UTC时间，人工标注时认为utc时间就是local time，所以导致了标注判断错误，这里直接把utc时间转换成local time重新标注即可。

项目上线后继续通过指标验证策略解决问题的效果，根据效果觉得是否开启下一轮产品循环，直至达到理想态。

04 策略产品工作方法

• 定义理想态

• 拆解未达理想态的情况

• 提出解决方案

• 验证是否解决