血拼到底

为减少能源消耗和尾气排放,弥补当前公共交通运力的不足,将出租车目前闲置的运力最大程度的利用,我们推出一种"实时共享出租车拼车系统",小名"二公共". (小狼提供命名)


基本构想:

如果出租车运行路线如下:

|              |            |              |            |
A -------      B --------  C -----------  D -------    E
|              |            |              |            |

如果乘客p1想打车从A点到E点,其中经过B,C,D. 如果他愿意与同路线的人(在A->E所涵盖的路径里)共享这个出租车(出租车一般有三个空余座位),在这条路径上的乘客都可以乘坐这辆出租车与其分摊费用.
如果乘客p2在B点,要前往D点,那么他在B点上车,D点下车,他需要承担的费用是B->D的分摊费用;
如果乘客p3在C点,要前往E点,那么他在C点上车,E点下车,他需要承担的费用是C->E的分摊费用;


    具体费用分摊规则:
整个路线的付费单位被划分为4段,A->B ; B->C; C->D; D->E; 每一段分别计费,计费公式为:
每个人的费用 = SUM (他所乘坐经过的路段费用 / 该路段上的乘坐人数) + 分摊起步价.

举例来说,如果上述路线中每段路的车费是6块,那么乘客P1的应付总价(假设起步价格每人1块)
PAY(p1) = FEE(A->B) / 1 + FEE(B->C) / 2 + FEE(C->D) /3 + FEE(D->E) / 2 + STARTUP_FEE
= 6 + 3 + 2 + 3 + 1 = 15;
PAY(p2) =  FEE(B->C) / 2 + FEE(C->D) /3 + STARTUP_FEE = 3 + 2 + 1 = 6;
PAY(p3) =  FEE(C->D) /3 + FEE(D->E) / 2 + STARTUP_FEE = 2 + 3 + 1 = 6;

当然了,如果乘客p3从C前往F,F比E要远,那么只要加上E->F这一段计价就可以了,这一段费用由p3独自承担.
起步价的分摊是一个问题,不可能平分,原则上来说,应该与车上的人数和你所走的路程按比例划分.在下车前才能计算出你的起步价格均摊,与你一路上拼车的人数成反比,与你所走的路程成反比.(起步总价 * 系数H / 共享人数 * 你的路程).
计费过程应该是比较简单的,你上车的时候,司机记录一个编号和上车地点,输入系统;下车时候再输入一次,系统可以计算你的编号应该付多少钱.

最主要的问题在于如何判断出租车的路线跟你的计划路线吻合,也就是你如何分辨一辆出租车是可拼的.简单办法是在车顶显示出发点和终止点,由你自行判断,但 是由于光知道出发点和终止点无法确定行进线路,可以在路上设置N个出租车临时停靠点,系统可以根据起点终点计算要经过的停靠点,如果要经过的停靠点足够 多, 基本轨迹也就足够确定下来了;拼车的人也可以在停靠点上等待.

这样做仍然没有解决问题,1:线路的不确定性导致上错车的可能性大. 2:出租车本来是图方便的,这样做每个停靠点都停变成公交车了; 3:每个停靠点会挤很多公交车,造成塞车问题. 4:实现起来还是比较困难,如何确定路上经过的停靠点?

PP 提供了一个想法:停靠点上可以有输入装置,你可以输入自己想去什么地方,当有车租车发现自己行驶的路线有吻合,或是是空车,并且在座的乘客愿意拼车,离你 的停靠点很近,那么他可以选择经过停靠点的时候稍上你;很好的想法,部分的解决了上面的问题.由出租车司机来判断你的路线是否吻合显然要比你判断准确的 多.这应用了著名的好莱坞原则: don't call us, we call you.
小狼在此基础上进一步:有一个手持终端,可以随时输入自己的起点和终点;可以选择输入到网上,在附近的出租车收到消息以后,如果和你的路线吻合,可以在起点捎上你.易用性有了提高.
当然这里面还是存在问题:司机知道有人要拼车了,可是你并不知道是那辆车,大致可以通过车顶牌显示来判断,或者口头交流(浪费时间).而且同时吻合的车可能有多辆,原则是先到先得.


由于以上方案要利用到特定终端设备,接收设备,造价过高.我回来以后重新设计了一个方案,以求最大限度利用现有设备.
1: 乘客p1从A点打车,告知司机目的地为E; 现在一般汽车上都有GPS定位系统,可以在GPS上输入E, 由系统计算出行车路线.(道道通等软件有此功能),如果有多条路线,乘客可自行选择.
2: 将选定的路线,还有当前乘客人数上传到服务器.服务器自动分配一个临时编号,出租车接收到以后显示在车顶.(并附显示路点和路线)
3: 乘客p2在网站上查询,想从B到D,系统做自动MATCH,返回能够拼车的出租车编号,你要等待的临时停靠点,路点路线,按最大匹配原则排序.(排序条件,路线与你吻合度,当前行驶离你停靠点最近),完全涵盖你的路线的车辆吻合度最高.
3.1: 车辆需要实时更新自己目前所处的位置，可以采用一个时间间隔的heartbeat协议，如果服务端一段时候内没有收到hearbeat，只能根据最近一次收到的位置估算车辆的位置信息，由于估算的误差比较大，这个也需要做为一个重要的排序条件。
4: 用户选定一辆车进行叫车请求.(出租车可能中途接上了别的人,所以人数需要实时更新)
5: 服务器反馈给被请求的出租车,告知某个停靠点有请求,出租车接人.
6: 用户等待选定编号的车辆.

在此方案中,用户所需的投入为零,无需购买任何终端,手持设备完全可以利用能上网的手机.出租车也可以利用现有的GPS系统.

因为此方案可以极大减小出租车的空驶率,我们将出租车载人行驶视为有效行驶距离,那么出租车每天的利润率正比于每天的有效行驶距离,如果实施拼车,那么有 效行驶距离大幅增大,那么利润会提高,平均成本下降,自然导致每公里价格下降,那么乐于拼车的人越来越多,由此形成良性循环.出租车有可能成为大家日常出 行的优先选择.

注意:此系统适用于价格死贵,距离贼远的城市,如北京上海.象杭州这种一泡尿远的地方就不够麻烦了.

本系统初始构想kenry,原创版权属于818项目组,欢迎抄袭并实现,以后我到北京也有便宜车坐了.如果有人想实现可以找我去写服务端,我打算在系统中留个后门,专门给我的ID发送"车内是否有美女"的专属消息.