桔妹导读：IT技术的不断更新推进着公共交通的概念不断在深度和广度上扩展。深度上，精准的公交ETA和实时到站等信息能够帮助用户更好的规划行程时间；广度上，配合单车，网约车等共享出行方式能够帮助用户更好的决策出行方式。 html
整体来讲，路径规划分为算路和排序两个阶段，在算路阶段召回能到达用户指定OD的线路，分为离线和在线两个阶段；排序阶段综合步行距离，到达时间，换乘次数，乘车价格等不一样的用户偏好给出最匹配用户的N条结果。算法
2.1.1. 离线算路与在线算路微信
路径规划问题的基本思路是首先将城市的公交和地铁线路数据，以站点集合为顶点集合V，每条公交或地铁线路上相邻的两站用边链接起来获得有向图。同时，因为站点之间换乘须要一段步行是常见状况，所以还须要将距离较近的两个站用步行路网也用边链接起来（图中的蓝色虚线）。最后，以每段路径的预估消耗时间做为每条边的权重，就获得了一张有向带权图。有了这样一张有向带权图后，当用户输入起点和重点请求换乘路线信息的时候，问题就转换为：已知有向带权图中的起始节点O和终止节点D，搜索找到O和D之间的K条较优通路。网络
这类问题常规的解法有BFS，Dijkstra，Floyd等，但在实际应用中，基于性能考虑，都不会在线实时的用这张图去计算，而是将一部分预处理的工做转移到离线阶段。架构
2.1.1.1. 离线算路app
尽管离线计算对性能的要求比在线低不少，但因为加入了步行以后的公交地铁有向图网络每一个顶点的分叉很是多，直接使用BFS，Dijkstra这类算法依然会难以忍受，所以滴滴根据自身的实际的数据状况进行了如下几种优化：机器学习
路网分层函数
在现实中，咱们每每会有一些你们熟知的大区之间的联络线路，如地铁4号线能够从中关村区域到大兴区域。当咱们从海淀其余区域本身规划乘车去大兴的时候也会先想到坐到地铁4号线的某站到大兴区域的某站，而后再看从这一站怎么到达最终目的地。这当中大区之间为人熟知的联络线路其实就是一种先验信息，借鉴这种思路，咱们在离线阶段抽象出若干较大片的区域，提早计算好这些区域之间几条主干通路，在线时，将起终点转换为区域，取出事先已算好的区域通路路径，能够大幅下降计算成本。工具
双向搜索(Bidirectional Search)
正如他的名称同样，借鉴你们实际应用中找路线的想法，同时从起点和终点扫描各自通过相向的线路，寻找其中有没有共同的车站（或步行可达的车站）。双向是一种很是有效的提效手段，BFS，Dijkstra都有双向的变种。性能使用估值函数剪枝
在搜索中一个常见提高性能的最重要的策略就是剪枝，经过一些耗时小的估算，提早结束一些明显会比当前路径更差的。咱们采用的是AStar算法。
2.1.1.2. 在线算路模块
在线算路模块，须要根据用户输入的起终点在上一步离线算路模块中选出最佳方案，并根据实时车辆状况，计算单车拼乘和网约车拼乘方案。
多模实时换乘
在离线算路阶段产出的方案，根据用户输入的起终点选择最佳上下车站点。再根据实时单车/网约车信息，生成步行/骑行/网约车前往站点来接驳公交/地铁的方案。在线剪枝
多模接驳阶段会产生大量方案，为了提升线上服务性能，须要将方案进行剪枝。包括将不在运营时间的方案、价格明显偏高，网约车排队时间过长，或单车数量较少区域的方案去除。同时，将多个路线一致的方案合并成一个。粗排计算
通过前面处理后，获得了全部可行方案，下面须要对这些方案进行排序，选择最优的方案。粗排计算阶段须要根据每条方案的基础特征（例如耗时、路程等），对上千条可行方案快速计算评分，根据分数选出候选方案集送给后续排序模块。
2.1.1.3. 排序模块
ETA
ETA是用户选择时最主要的参考信息。为了更精准地获得方案的耗时，推荐出实时最佳方案。滴滴利用路况信息、历史通行耗时等信息，借鉴网约车的经验，创建了公交车专用ETA模型用来估计车辆当前位置到达站点和到达目的站点的时间。更精确地预计了用户的等车时间和到达目的地时间。
网约车模型收益
精排
多模换乘推荐引擎中须要比较众多包含多种交通工具的候选方案。而将包含多种不一样交通工具公平地进行比较，并推荐出若干个符合大众心目中最优的方案是一个较为复杂的问题。除了基础特征外，还须要从方案中挖掘出更多信息，加强模型的表征能力。咱们设计了包含预计通行时间、换乘次数、步行距离、综合距离、地铁距离、单车距离、价格、发班时间、备选车次数量、交通工具类型、是否在主干道行驶、是否公交专用道、各类交通工具占比等若干高级特征。在线计算出特征后，提供给后续排序模型使用。
Rerank和多样性
为了兼顾用户的个性化诉求，最终展现给用户的N条方案时，经过rerank来保证总体方案的多样性。通常用户的个性化因素包括价格是否敏感，地铁偏好，步行长短，换乘偏好等等。以点击率做为整个公交方案的线上观察指标。
▍2.2 实时公交服务
随着传统行业的线上数字化改造，已有200多个城市公交巴士都配置了智能硬件设备，能够实时上报公交的位置。以此为基础，向用户提供实时公交位置，预估等待时间等相关信息成为公交服务的又一基础功能。总体架构以下：
2.2.1. 数据接入
实时公交的数据来自公交公司和交委，然而因为没有统一的标准。上报的格式，各字段的含义都不同，所以滴滴制定了一套本身的数据规范来适配各地数据，从而对应用层提供统一格式的数据。除了格式的统一以外，因为公交站点和线路的名称，ID编码规则各地也都会不按期发生变化，所以，为了保障应用层使用的继承性，滴滴对全部数据也定义了本身的ID编码规则。在数据接入阶段，还有一个重要的工做就是对数据实体进行映射。
2.2.2. GPS位置补偿
位置的正确性和时效性是实时公交服务的核心能力，若是用户在线下看到车的位置和APP上的位置有比较大的差异，就会失去信任感，流失到竞品。
然而各地上报的GPS都有必定的延迟，且延迟有不可预知性，若是彻底依赖上报的位置数据呈现给用户，在极端状况下（如隧道等网络很差的地方），可能会出现用户真实看见了一辆车可是在APP上未出现的状况。所以必须经过AI的方式对实际的位置进行估算才能给到用户准确的信息展现。在这里，源数据上报的时效性是位置预测时最大的困扰，以下图一所示，对于不一样的延迟时间，偏差和延迟的比例正相关。
图一
延迟时间统计图
另外，因为各地上报GPS的规范性不一致。还须要处理一些边界问题。如：GPS的延迟上报若是处理很差，在前两站给用户的伤害更为明显：车辆可能在已经驶过第二站后才上报了第一个GPS点，这意味着，若是咱们不对车辆的发出时间作预估，而彻底依赖上报的数据的话，第二站用户看到的永远是车辆等待发车。而在前两站会比较容易出现的特殊状况是：
场站线路
即车辆在到达上一方向的终点站后，会回到场站，停留一段时间后发出；循环线路
即车辆在到达上一方向的终点站后，直接驶向下一方向的起点。
咱们目前的解决方案是：
根据历史数据，离线统计出车辆的上下行换向时间，即当车辆到达上行方向的终点站后，停留在场站（或继续行驶）多长时间后会出如今下行方向的起点位置。
线上使用时，当收到车辆上行方向上报的最后一个GPS点后，对于场站线路，咱们会在换向时间事后判断车辆从下行方向驶出；对于循环线路，会让车辆从下行方向驶出的同时，继续模拟前行。
使用/离线挖掘出车辆的发车时刻表。
随着公交数据的不断积累，咱们将在如下两个方向持续深耕：
一方面，经过用户使用公交服务的数据，进一步优化路径规划服务和实时公交服务，如：
结合用户的历史行为，对用户历史行为建模，实现个性化和场景化排序
使用深度时序模型优化实时位置补偿，提高预测的准确率，强化对全国不一样城市，各类不一样地理特征的泛化能力。
利用用户轨迹补偿实时公交信息和步行路网信息
另外一方面，能够结合整个滴滴各类出行方式积累下的大数据，能够赋能给传统公共交通行业，优化线路选择，智能排班调度等，真正助力智慧交通和智慧城市早日到来。
本文做者
▬
团队招聘
▬
滴滴地图与公交事业部信息公交团队，依托滴滴海量出行数据和多种共享出行方式的优点，使用人工智能和大数据等技术，致力于为用户提供多模、高效、智能的公共出行解决方案。
团队长期招聘研发工程师，包括C++/go引擎和业务开发、数据挖掘，机器学习等方向，欢迎有兴趣的小伙伴加入，可投递简历至 diditech@didiglobal.com，邮件请邮件主题请命名为「姓名-应聘部门-应聘方向」。
扫描了解更多岗位
内容编辑 | Charlotte 联系咱们 | DiDiTech@didiglobal.com
本文分享自微信公众号 - 滴滴技术（didi_tech）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。