一种推荐上车地点的方法和装置与流程

本发明涉及计算机应用技术领域，特别涉及一种推荐上车地点的方法和装置。

背景技术：

随着无线通信技术以及计算机技术的迅速发展，各种运行于智能手机、平板电脑等智能终端的APP(应用)如雨后春笋般涌现。叫车类应用就是其中应用越来越多的一类，乘客通过客户端输入起始地点和目的地点，客户端将包含起始地点和目的地点的叫车请求发送给服务端。服务端将该起始地点和目的地点发送给起始地点附近的司机客户端，待接收到司机客户端发送的接单请求后，形成乘客与司机之间的订单。

在订单形成后，需要司机与乘客之间就上车地点达成共识，目前的方式主要有两种：

第一种方式，司机与乘客之间通过打电话的方式取得联系，口头商议上车地点。

第二种方式，以比较有名的地点作为推荐地点。

但上述两种方式可能存在如下问题：

司机与乘客在电话联系时通常会约定双方都知道的地点作为上车地点，但该上车地点可能距离双方都不近，则会造成等待时间很长。以比较有名的地点作为推荐地点同样会存在类似问题。

技术实现要素：

有鉴于此，本发明提供了一种推荐上车地点的方法和装置，以便于缩短司机与乘客等待的时长。

具体技术方案如下：

本发明提供了一种推荐上车地点的方法，该方法包括：

获取订单信息，所述订单信息包括乘客信息、司机信息以及目的地点信息；

确定乘客所在位置附近的所有可上车位置；

针对各可上车位置分别预估：乘客到达该可上车位置的时长T1、司机到达该可上车位置的时长T2以及该可上车位置到达目的地点的时长T3；

依据各可上车位置的T1、T2和T3，选择行程总耗时最小的可上车位置作为推荐上车地点。

根据本发明一优选实施方式，所述确定乘客所在位置附近的所有可上车位置包括：

获取乘客所在位置；

若乘客在被包围的区域内，则将所述被包围的区域的各出口作为可上车位置；

否则将距离乘客所在位置设定范围内的可停车位置作为可上车位置。

根据本发明一优选实施方式，所述司机到达该可上车位置的时长T2由以下因素确定：

司机当前所在位置与该可上车位置的距离；或者，

司机当前所在位置与该可上车位置的距离，以及从司机当前所在位置到该可上车位置的路况信息。

根据本发明一优选实施方式，所述该可上车位置到达目的地点的时长T3由以下因素确定：

该可上车位置到达目的地点的距离；或者，

该可上车位置到达目的地点的距离，以及从该可上车位置到达目的地点的路况信息。

根据本发明一优选实施方式，所述行程总耗时为：

T3+max(T1,T2)。

根据本发明一优选实施方式，该方法还包括：

将所述推荐上车地点的信息发送给所述乘客的客户端和所述司机的客户端。

根据本发明一优选实施方式，所述推荐上车地点的信息在所述乘客的客户端和所述司机的客户端中以地图中标记或文本的形式显示。

根据本发明一优选实施方式，该方法还包括：

若接收到所述乘客的客户端或所述司机的客户端发送的拒绝推荐上车地点的请求，则从除了被拒绝的推荐上车地点之外的可上车位置中，选择行程总耗时最小的可上车位置作为新的推荐上车地点。

根据本发明一优选实施方式，该方法还包括：

将从所述乘客所在位置至所述推荐上车地点的导航信息发送给所述乘客的客户端；

将从所述司机所在位置至所述推荐上车地点的导航信息发送给所述司机的客户端。

本发明还提供了一种推荐上车地点的装置，该装置包括：

订单获取单元，用于获取订单信息，所述订单信息包括乘客信息、司机信息以及目的地点信息；

位置确定单元，用于确定乘客所在位置附近的所有可上车位置；

时长预估单元，用于针对各可上车位置分别预估：乘客到达该可上车位置的时长T1、司机到达该可上车位置的时长T2以及该可上车位置到达目的地点的时长T3；

地点选择单元，用于依据各可上车位置的T1、T2和T3，选择行程总耗时最小的可上车位置作为推荐上车地点。

根据本发明一优选实施方式，所述位置确定单元，具体用于获取乘客所在位置；若乘客在被包围的区域内，则将所述被包围的区域的各出口作为可上车位置；否则将距离乘客所在位置设定范围内的可停车位置作为可上车位置。

根据本发明一优选实施方式，所述司机到达该可上车位置的时长T2由以下因素确定：

司机当前所在位置与该可上车位置的距离；或者，

司机当前所在位置与该可上车位置的距离，以及从司机当前所在位置到该可上车位置的路况信息。

根据本发明一优选实施方式，所述该可上车位置到达目的地点的时长T3由以下因素确定：

该可上车位置到达目的地点的距离；或者，

该可上车位置到达目的地点的距离，以及从该可上车位置到达目的地点的路况信息。

根据本发明一优选实施方式，所述行程总耗时为：

T3+max(T1,T2)。

根据本发明一优选实施方式，该装置还包括：

交互单元，用于将所述推荐上车地点的信息发送给所述乘客的客户端和所述司机的客户端。

根据本发明一优选实施方式，所述推荐上车地点的信息在所述乘客的客户端和所述司机的客户端中以地图中标记或文本的形式显示。

根据本发明一优选实施方式，所述交互单元，还用于若接收到所述乘客的客户端或所述司机的客户端发送的拒绝推荐上车地点的请求，则触发所述地点选择单元从除了被拒绝的推荐上车地点之外的可上车位置中，选择行程总耗时最小的可上车位置作为新的推荐上车地点。

根据本发明一优选实施方式，所述交互单元，还用于将从所述乘客所在位置至所述推荐上车地点的导航信息发送给所述乘客的客户端；将从所述司机所在位置至所述推荐上车地点的导航信息发送给所述司机的客户端。

由以上技术方案可以看出，本发明综合考虑乘客到达可上车位置的时长、司机到达可上车位置的时长以及可上车位置到达目的地点的时长，选择行程总耗时最小的可上车位置作为推荐上车地点，尽可能地缩短司机与乘客等待的时长。

【附图说明】

图1为本发明实施例提供的系统结构图；

图2为本发明实施例提供的方法流程图；

图3为本发明实施例提供的装置结构图；

图4为本发明实施例提供的一个实例的示意图。

【具体实施方式】

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

为了方便理解，首先对本发明所基于的系统进行简述，如图1所示，该系统主要包括：乘客客户端、服务端和司机客户端。乘客通过乘客客户端向服务端发送请求并接收服务端反馈的信息，司机通过司机客户端向服务端发送请求并接收服务端反馈的信息。本发明实施例提供的方法和装置主要在服务端实现。

图2为本发明实施例提供的方法流程图，如图2所示，该方法主要包括以下步骤：

在201中，获取订单信息。

本发明实施例提供的推荐上车地点的方法在生成订单之后执行，因为只有生成订单之后，达成订单的双方即乘客和司机才正式确定。订单生成的过程大致为：服务端接收到乘客客户端发送的叫车请求后，依据乘客所在位置向附近司机发送订单邀约信息。若接收到司机客户端的接单请求，则从中挑选一个司机，形成订单信息后发送给乘客客户端和该挑选的司机客户端。

获取的订单信息至少包括乘客信息、司机信息以及目的地点信息，还可以包括其他信息，诸如起始地点信息、乘客所在位置信息、司机所在位置信息等等。后续步骤中涉及的乘客和司机均是该订单的达成方，即订单信息中涉及的乘客和司机。

在202中，确定乘客所在位置附近的所有可上车位置。

首先获取乘客所在位置，可以从订单信息中获取，也可以对乘客客户端进行定位从而获取乘客所在位置。

乘客所在位置可以大致分为两类：

一类是乘客在被包围区域内，其中被包围区域指的是被栏杆、围墙、植物、建筑物等包围的区域，例如商场、小区、学校、工厂、公园等等。对于这类区域一般会存在多个出口，那么可以将被包围区域的各出口作为可上车位置。例如若乘客在某商场内，那么可以将该商场的所有出口确定为所有可上车位置，从这些位置进行后续推荐上车位置的挑选。

对于其他情况可作为另一类，例如乘客在街边、在道路附近等等，对于这类情况，则可以在距离乘客所在位置设定范围内的可停车位置作为可上车位置。例如，在距离乘客200米范围内的可停车位置作为可上车位置。

当然，这种分类是比较简单粗犷的分类，还可以存在其他情况以及其他确定可上车位置的方式，本发明实施例中不一一穷举。

在203中，针对各可上车位置分别预估：乘客到达该可上车位置的时长T1、司机到达该可上车位置的时长T2以及该可上车位置到达目的地点的时长T3。

乘客到达可上车位置的时长T1主要由乘客与可上车位置的距离确定，当然还需要结合行走速度。其中行走速度可以采用该乘客的平均行走速度，例如对乘客设定历史时长中的行走速度进行采集，从而确定出一个平均行走速度。或者行走速度也可以采用一个预设值，即将人通常行走的速度作为一个设定的行走速度。

司机到达可上车位置的时长T2可以由司机当前所在位置与该可上车位置的距离确定，当然还需要结合驾驶速度。同样驾驶速度可以采用该司机的平均驾驶速度，例如对该司机设定历史时长中的驾驶速度进行采集，从而确定出一个平均驾驶速度。或者驾驶速度也可以采用一个预设值，即将汽车通常驾驶的速度作为一个设定的驾驶速度。

除了司机当前所在位置与该可上车位置的距离之外，还可以进一步结合从司机当前所在位置到该可上车位置的路况信息，例如拥堵状况的，根据拥堵状况对司机到达可上车位置的时长进行预估。

可上车位置到达目的地点的时长T3可以由该可上车位置到达目的地点的距离确定，同样也会结合驾驶速度。除此之外，还可以进一步结合从该可上车位置到目的地点的路况信息，不再赘述。

在204中，依据各可上车位置的T1、T2和T3，选择行程总耗时最小的可上车位置作为推荐上车地点。

行程总耗时可以看做是等待上车的时长与上车后到达目的地的时长之和，即T3+max(T1,T2)。分别针对各可上车位置计算出行程总耗时之后，选择其中行程总耗时最小的可上车位置作为推荐上车地点。

在205中，将推荐上车地点的信息发送给乘客客户端和司机客户端。

推荐上车地点的信息在乘客客户端和司机客户端中可以以地图中标记或文本的形式进行显示，从而使得乘客和司机能够清楚直观地知晓推荐上车地点的位置。

另外，为了方便乘客和司机方便准确地到达推荐上车地点，可以将乘客所在位置至推荐上车地点的导航信息发送给乘客客户端。将从司机所在位置至推荐上车地点的导航信息发送给司机客户端。这样，乘客和司机的客户端开启导航功能后，就能够依据导航信息到达推荐上车地点。

若乘客或者司机对推荐上车地点并不满意，例如乘客觉得从该推荐上车地点上车不方便，可以通过乘客客户端向服务端发送拒绝推荐上车地点的请求。此时，服务端可以从除了被推荐的推荐上车地点之外的可上车位置中，选择行程总耗时最小的可上车位置作为新的推荐上车地点。之后将新的推荐上车地点再次发送给乘客客户端和司机客户端。

以上是对本发明所提供方法进行的详细描述，下面结合实施例对本发明所提供的装置进行详述。

图3为本发明实施例提供的装置结构图，该装置设置于图1中所示的服务端，如图3所示，该装置可以包括：订单获取单元01、位置确定单元02、时长预估单元03和地点选择单元04，还可以包括交互单元05。各组成单元的主要功能如下：

订单获取单元01负责获取订单信息，其可以在订单信息生成之后执行操作。其中，订单信息可以包括乘客信息、司机信息以及目的地点信息，还可以包括其他信息，诸如起始地点信息、乘客所在位置信息、司机所在位置信息等等。

位置确定单元02负责确定乘客所在位置附近的所有可上车位置。具体地，位置确定单元02可以首先获取乘客所在位置，可以从订单信息中获取，也可以对乘客客户端进行定位从而获取乘客所在位置。若乘客在被包围的区域内，则将被包围的区域的各出口作为可上车位置；否则将距离乘客所在位置设定范围内的可停车位置作为可上车位置。

时长预估单元03负责针对各可上车位置分别预估：乘客到达该可上车位置的时长T1、司机到达该可上车位置的时长T2以及该可上车位置到达目的地点的时长T3。

乘客到达可上车位置的时长T1主要由乘客与可上车位置的距离确定，当然还需要结合行走速度。其中行走速度可以采用该乘客的平均行走速度，例如对乘客设定历史时长中的行走速度进行采集，从而确定出一个平均行走速度。或者行走速度也可以采用一个预设值，即将人通常行走的速度作为一个设定的行走速度。

司机到达可上车位置的时长T2可以由司机当前所在位置与该可上车位置的距离确定，当然还需要结合驾驶速度。同样驾驶速度可以采用该司机的平均驾驶速度，例如对该司机设定历史时长中的驾驶速度进行采集，从而确定出一个平均驾驶速度。或者驾驶速度也可以采用一个预设值，即将汽车通常驾驶的速度作为一个设定的驾驶速度。

除了司机当前所在位置与该可上车位置的距离之外，还可以进一步结合从司机当前所在位置到该可上车位置的路况信息，例如拥堵状况的，根据拥堵状况对司机到达可上车位置的时长进行预估。

可上车位置到达目的地点的时长T3可以由该可上车位置到达目的地点的距离确定，同样也会结合驾驶速度。除此之外，还可以进一步结合从该可上车位置到目的地点的路况信息，不再赘述。

地点选择单元04负责依据各可上车位置的T1、T2和T3，选择行程总耗时最小的可上车位置作为推荐上车地点。其中，行程总耗时可以为：T3+max(T1,T2)。

交互单元05负责将推荐上车地点的信息发送给乘客的客户端和司机的客户端。推荐上车地点的信息在乘客客户端和司机客户端中可以以地图中标记或文本的形式进行显示，从而使得乘客和司机能够清楚直观地知晓推荐上车地点的位置。

另外，为了方便乘客和司机方便准确地到达推荐上车地点，交互单元05可以将乘客所在位置至推荐上车地点的导航信息发送给乘客客户端。将从司机所在位置至推荐上车地点的导航信息发送给司机客户端。这样，乘客和司机的客户端开启导航功能后，就能够依据导航信息到达推荐上车地点。

若乘客或者司机对推荐上车地点并不满意，可以通过各自的客户端向服务端发送拒绝推荐上车地点的请求。交互单元05若接收到乘客的客户端或司机的客户端发送的拒绝推荐上车地点的请求，则触发地点选择单元04从除了被拒绝的推荐上车地点之外的可上车位置中，选择行程总耗时最小的可上车位置作为新的推荐上车地点。

举一个例子，如图4所示，假设乘客在某商场内，该商场有A、B、C和D四个出口。乘客通过手机客户端发送了叫车请求，某司机接单，服务端在生成订单后，开始上车地点推荐流程。假设目的地点较远，图中未示出。

若采用现有技术中的方式，乘客与司机联系后，由于并不知晓司机的位置，司机对附近的状况也不太了解，很可能就近将出口A确定为上车位置。这种情况下，司机就需要先向东行驶后，再向北行驶，通过一个立交桥绕行之后才能到达出口A，十分耗时，双方都需要等待很长时间乘客在能够上车。

若采用本发明提供的方式，服务端确定商场的4个出口分别作为可上车位置。针对各可上车位置分别预估乘客到达该可上车位置的时长T1、司机到达该可上车位置的时长T2以及该可上车位置到达目的地点的时长T3，然后选择T3+max(T1,T2)最小的可上车位置作为推荐上车地点。经过该方式确定出口D为推荐上车地点，服务端将该推荐上车地点发送给乘客客户端和司机客户端，并启动到出口D的导航。虽然乘客到出口D的距离相比较出口A稍远，但综合考虑司机的因素，两者到达出口D的时长最大值以及从出口D到达目的地的时长最小，尽可能缩短等待时长。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。