1. 聚能聊>
  2. 话题详情

聊一下防止网约车司机绕路、下车后不停止计费的技术手段

网约车已经营运多年,但是还有不少用户遇到绕路、下车后继续计费的问题。

__meitu_0

因为这个问题,甚至很多公司禁止出差时使用网约车。

那么技术上就这么难解决这个问题吗?

大家一起来讨论一下,有什么好的解决手段呢?

我抛一个砖头先:

1. 绕路问题

其实在PostgreSQL数据库中,有一个很好的插件pgrouting,就可以根据上车地点,下车地点,计算出最佳路径,可以在用户在结账的时候将司机的实际行驶路径(及里程)、推荐路径(及里程)展示给用户,那么用户一眼就能看出司机师傅有绕路了。

甚至可以做成智能的,当实际行驶里程超出多少百分比后,司机必须在平台做出解释,并将解释提示用户,用户确认无误后钱才能到司机手中。

pgrouting的其他应用案例 :

《聊一聊双十一背后的技术 - 物流, 动态路径规划》

2. 下车后不停止计费的问题

这个问题也蛮好解决的,用户只有在车上的时候,用户的手机和车载设备的轨迹才是重叠(或者相差无几)的,当用户离开车辆,那么用户的手机位置就已经和车辆分离了,分离后,如果司机还不结束计费,可以强制停止,并发出警告,提示用户。

这里实际上需要用到流式处理,对车辆,乘客的上载位置进行流式处理,实时的反映问题。

关于轨迹的实时流式计算,在PostgreSQL生态中也有相应的产品支持,比如pipelineDB,我们来看看有哪些类似的案例:

《一场IT民工 与 人贩子 之间的战争 - 感受来自PostgreSQL的爱》

《金融风控、刑侦、社会关系、人脉分析等场景思考 - PostgreSQL如何实现图式应用场景》

《从天津滨海新区大爆炸、危化品监管聊聊 IT人背负的社会责任感》

《流计算风云再起 - PostgreSQL携PipelineDB力挺IoT(物联网)》

参与话题

奖品区域 活动规则 活动已结束,可继续参与讨论哦

  • 奖品一

    淘公仔 x 2

  • 奖品二

    阿里云代金券 x 2

63个回答

1

snowcc 已获得淘公仔

在乘客确认支付时可以看到司机走的真实路线,乘客确认没问题就付款,3天不确认不异议强制扣款。

德哥 回复

好提议啊,和淘宝的交易思路类似。

dragonwang 回复

某个路段单行、禁止左转等造成的绕路,当乘客看不懂地图或者不懂的情况下提出异议,谁来解决纠纷?举个例子:中国是右侧通行,直接右转规则,但是西直门桥要右转需要绕一个中国结才能右转,如果乘客提出异议怎么解决?---例子有些极端,但是确实会存在类似情况。长安街部分时段不允许左转等。。

爱西西里 回复

归根到底还是设计思路

德哥 回复

恩,这个可以技术手段规避,比如设置方向weight。比如禁止左转,那么可以设置左转时的weight=无穷大

评论
1

keller.zhou 已获得阿里云代金券

  我觉得“网约车是在‘互联网+’这样大背景下产生的一种新业态,但是技术不是全部。”一位业内人士表示,我们用开放的心态接受新的技术和互联网思维,但对于网约车平台来说,要真正起到承运人的职责,在确保乘客舒适体验和乘坐安全的前提下,通过技术手段实现出行的智能化。

有人可能会说上述两个事件“是少数、是极端”,但经常叫网约车的乘客肯定遇到过司机故意绕路、导航错误开错路、司机态度非常不好、拒载等“不极端”的“小事”,可是目前网约车领域连相对畅通、公正、高效的投诉监督平台都没有,尤其是优步,乘客对服务不满意、有纠纷,连个服务投诉电话都没有,只能在APP上操作或邮件往来。我认为,有必要建立一个统一的投诉监督平台,由政府主管部门牵头、第三方机构管理,对市民和乘客的投诉举报内容进行记录和追溯,确保乘客能够得到优质的服务。

德哥 回复

恩,轨迹要记录下来,有迹可循。存储要高效,查询也要高效,使用PostGIS,存储轨迹数据就很不错,线段,点,数组都可以选择。

评论
2

妙正灰 已获得阿里云代金券

我倒是觉得,数据就是证据,结合其他技术的同时,保存数据并且规避隐私后就是可以利用的财富。

如果打车软件的数据和地图软件的数据整合,再结合一些其他的技术。

  1. 我们可以分析那个时段那条路,那个路口,司机可能会想做点小动作,具体是动作就可以提示用户注意
  2. 哪些经过的地方司机的不良事件比较多,就要优先安排高分的司机给女性用户,男性则以路程来判断
  3. 如果在不涉及隐私的前提下,数据足够详细,在恐怕袭击、安全事件发生后,分析还可以用于追查凶手

1

kenshino 已获得淘公仔

                           【2017重大更新】

1.程序猿君加入了司机和乘客的评分征信系统.
2.多次被投诉的司机将失去确认到达目的地的权力,由乘客发起到达事件,司机只能同意或申请调解.
3.加入社交系统,多次匹配到同一司机的会渐渐建立起“道路羁绊·组合技”,使运营公司抽成减少,让利乘客和司机,建立更加稳定的,持续的,和谐的出行服务.

0

西秦说云

前者不好说,因为路径的规划涉及到了路径设计的问题,那么不妨整合阿里的智慧城市,结合城市流量自动规划路径。而且这个比单纯数据库的优化效果更好,因为数据库的优化终归是直接计算的,远不如大数据的智能分析整合的关键点多。毕竟这个社会是多变量的。PGSQL的路径规划我不认为可以处理比如上下班高峰期、实时路况等等信息。
至于后者,我觉得与其将其交给数据库来处理,倒不如基于LBS数据,将汽车的GPS和用户的GPS进行坐标的判断,两点间距在10M以内(正常情况下手机GPS的误差为5m),可以正常计费,超出10M就停止计费。或者根据情况来适当的调整距离。

虽然说德哥是专门搞PGSQL的,但是我依然认为这个东西交给数据库来处理过于牵强。任何技术都有实现的可能,但是可实现的最优解才是我们所需要的,PGSQL可以搞,但是这些活我依然认为应该交给其他的组件来完成。

聚小编 回复

艾玛,开撕了,兄弟你摊上事儿了~~^-^

德哥 回复

首先,应用肯定是第一手拿到数据的,比如GPS的判断,如果应用层可以处理,不需要交给数据库这么复杂。但是不管怎样,这些数据都是需要入库作为后期的评判依据的,在PostgreSQL里面,两点距离的运算是PostGIS很基本的功能之一,这种运算也不需要太复杂的逻辑,32C的机器应对每秒百万次的请求也完全不是问题。

而这只是个开始,PostGIS里面有很多功能可以去探索,来应对更多复杂的应用需求。

其实是,路径规划,首先要有道路信息,其次需要动态数据,最后还需要有数据处理逻辑。车流,可以作为设置道路的权重;单行线,禁止行驶的路线,也可以作为规划的过滤条件。pgrouting恰巧很好的整合了这些功能点,可以很好的满足需求。

程序能实现的,在数据库中都可以实现。PGSQL并不是单纯的数据库,它更像是一个数据工厂,你几乎可以在PGSQL基础之上干任何事情。

小旋风柴进 回复

哈哈,我们来凑热闹

dannnnns 回复

我倒是觉得只用用GPS距离不靠谱,毕竟城市里面还是有gps的盲区的,倒是可以考虑基于基站,附近wifi和GPS共同判断乘客与司机的相对位置,从而判断司机是否未停止计费

dannnnns 回复

我倒是觉得只用用GPS距离不靠谱,毕竟城市里面还是有gps的盲区的,倒是可以考虑基于基站,附近wifi和GPS共同判断乘客与司机的相对位置,从而判断司机是否未停止计费

评论
2

润泽民生

我认为这本就是个诚信问题,主体责任落实到网约车服务平台,给出一个严厉的惩罚制度和赔偿机制,就不会有绕路和不停止计费的问题!建立以客户为中心的管理制度和服务机制才能让企业更好的发展!

润泽民生 回复

很好的建议

v阿哲 回复

杀人的话,法律判死刑,还是有那么多。机制是給君子而不是給小人的!

顺其孜然 回复
回复@v阿哲:

然而,你不管怎么设计数据库,我车上开一个 GPS 虚拟信号,模拟更绕的路线,你依然避免不了,所以还是得靠各种手段来防止,单凭一点绝非正确做法。

评论
2

szm.

最佳路径这个真不好说,现在很多路线有单行线,施工路线,导致最佳路径无法走,只能绕远,所以最佳路径只能做为参考。
但是可以采用多条路径可供选择的方案,至少有一条一定可行,这样,如果网约车的路线与推荐路线都不相符则认定为绕远路进行判罚。

第二个问题,可以结合硬件比如ibeacon或者其他技术对用户进行判断,文中提到的路径重合也是一个很好的解决方案。当然,还可以通过起点到终点的最差路线做为最终的金额限制,超过的话,直接停止计费,并将网约车司机信息标注为异常,由人工审核。

德哥 回复

恩,付钱时能看到推荐路线(推荐路线确实需要更多的考虑单行线、禁行、拥堵等情况,让推荐更加智能),又能看到实际行驶路线的话,对用户来说会比较透明。

szm. 回复
回复@德哥:

在确定出发地点与目的地之后就可以为用户推荐路线,这样可以和司机进行商量路线。付款时有异议可以将司机实际路线,车费和推荐路线等信息进行上传作为证据,由网约车软件公司进行判罚。

评论
1

我的中国

本地人,敢多收费试试。
看着高德地图打车,谁敢绕路

v阿哲 回复

本地人你还需要看高德?你确定你是本地的?

我的中国 回复
回复@v阿哲:

话说本地人也不是哪里都去过 我是路痴 记不住

评论
0

1634284440557178

关于计费问题是否可推荐用户微信,支付宝什么的付费。用户付费好之后就停止计费。

v阿哲 回复

司机不确认到地方,会一直计费,你乘客只能看着!

评论
1

1973764080877551

单纯的技术来制约类似于这些种种的现象,在我感觉已经满足不了当前现状,当务之急是建立诚信管理体系,不知道是不是现在有人在做,在不侵犯个人隐私的情况下,屏蔽客户信息,对约车相关数据处理,例如实际行车路线与模拟路线进行技术比对,在这之中人为干预,对司机进行信用评级评价,建立评级系统,对司机进行制约,不合格司机拉入黑名单,对约车乘客及时提醒,在我看来用技术+人为干预,能有效遏制这种现象。

1

dannnnns

防止绕路我认为平台应该首先保存行车过程中的实时路况图和行驶轨迹图以及车辆行驶的动态(如车速和低速行驶位点,来判断中途是否有上下客行为),同时进行判断下车点是否与原终点一致,一致时再判断里程是否超过预估里程一定百分比(10~20左右),若超过则判断司机所开的路线是否为合理避堵,避开施工点路线,若合理,则乘客端不提示,不合理,则乘客端提示确认行驶路线是否为自己所要求走的路线,若乘客无疑义付款则判断为未绕路,乘客提出异议则进入处理流程。

1

familyblog

实际上网约车司机为了躲避拥堵也会绕路的,看问题要客观一点。

1

麦兜0668

绕路这应不难解决,出发前智能规划路线,可以算出标准公里数,行车公里数与规划公里数同时展示,设定误差范围!一般绕路也不可能是什么百分之几的事!一眼便可识别!至于离开计费问题,可以设计一个手机与车相对定位系统,当相对地址超过一定范围,便结束所有计费功能,展现计费统计数据

1

azinoa

有一个常用的场景就是:家到公司,可以用历史数据的平均值来算费,可以同时解决这两个问题。其他场景,还是文中的方案不错

1

1733583585478542

系统计算出距离和价格 客人能看到路线

1

1508083525012252

你可以等他结财结束后在下车

0

simonwu

有这样的一个场景,如果是替别人打车的话,手机和汽车行车的路线就不存在重复,导致你的计算方式就行不通了

0

任1220

网约车现实使用场景中存在一些复杂的非常规的用车情况,技术手段只能做为用户投诉时的佐证,不建议做为系统对业务的智能化、自动化干预。
举几个我用车中的实例供大家参考,集思广益、抛砖引玉:
1、有次约朋友聚餐,我从我家出发,顺便接上朋友一起去目的地。本人所住科技园下班后的晚高峰道路拥堵,基本打不到车,在长时间打不到车的情况下,将出发地点改为了朋友家,我准备走到朋友家(大约半个小时内路程)再从他家出发,采用这个策略后,成功打到一辆车,巧的是这辆车接单时所在位置在朋友家和我家之间,遂致电司机,请先过来我家接上我再过去。
这个时候存在了两个异常业务:A、司机计费时起点非约车指定起点 B、司机行车路线必然与最佳行车或建议行车路线不同。(PS:上车后司机师傅很担心系统封掉他账号)
2、一次外出,需要先购置一些礼品再到目的地,在shoppingmall让司机等候了十多分钟。此时,若按照乘客定位与车辆定位位置距离较远而系统自动结束行程,是肯定不行的。
3、去苏州游玩的一次,从拙政园出来到苏州站,地图显示基本起步价就到。司机将部分路段修路需要绕行,这种临时修路限行的情况很难去证实。结果司机选的路线不是推荐路线,而走的路线是修路路段,司机再次将需要继续改道。最后短短一段路走了二十多分钟,多绕了近十公里,期间我手机百度地图多次修正路线,司机依旧绕路。本人是知道投诉规则的,不赶时间,他想这么玩我就陪他玩,也就没吭声,当顺便看看苏州城建了。前后多次变错道,变错路口,就在司机想再次变道转向高速绕路时,本人讲苏州这么小也不堵车走了这么久,才慌忙直奔苏州站。

0

1106184817860981

躲避红灯绕路的有的确实快一些,什么事情都有两面性,如何提升司机乘客素养是关键,技术解决的只是固定的思路

0

1280084800633679

只求红包

4
10331
浏览
0
收藏
邀请他人互动
关注
61
粉丝
3471
话题
14

简介:

公益是一辈子的事, I'm digoal, just do it.
阿里云流计算(Aliyun StreamCompute)是运行在阿里云平台上的流式大数据分析平台,提供给用户在云...

快速、完全托管的TB/PB级数据仓库解决方案,向用户提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更...

GPU云服务器是基于GPU应用的计算服务,多适用于视频解码,图形渲染,深度学习,科学计算等应用场景,该产品具有实...

为您提供简单高效、处理能力可弹性伸缩的计算服务,帮助您快速构建更稳定、安全的应用,提升运维效率,降低 IT 成本...